A file enforcement point binds to the path a file travels, not to the device that holds it. Subtext is one engine behind three connectors, one for each kind of crossing. Pick the one your file crosses. The inspection path is the same, so the verdict is the same.
Sits between the agent and every file it opens, writes, fetches, or reads through a shell. The tools carry the same names the agent already uses, so they replace the uninspected ones rather than adding to them.
Every read is scored before it returns and every write before it lands. A refused read comes back as a tool error that names the file. One entry in the client configuration, standard library only, nothing listening on the network. Validated on six agent clients.
Shell output is scored, the command is not. Replace the native file tools rather than running both, or the agent keeps an uninspected path to the same files.
Full page: Subtext for MCP →Sits beside a web proxy, an egress gateway, an upload point, or a managed file transfer appliance. The device hands Subtext the object over ICAP, on the request side or the response side, and gets the verdict back before the object moves on.
The same container deployed twice is inbound and outbound. Each instance carries the policy for its own direction, so there is no per-request guess about which way a file is going. The engine scores the exact bytes the proxy sends, whole and reassembled, and an incomplete or oversized message is refused rather than scored in part.
Enforcement depends on the proxy honoring the verdict. Every proxy and NAS family ships a setting that bypasses the scanner on error, and it stays off. We will tell you which dials, for which device, before you turn it on.
Sits wherever your own code touches a file: an upload handler, ingestion into a retrieval index, a transfer workflow, a build step, a queue consumer. The application sends the bytes to one endpoint and receives block, review, or pass with the reasons that produced it.
This is the connector the other two are built on. It inspects the object as it arrives, not a store after the fact, so it fits the moment a file becomes something your system or your model will act on. Nothing about the call requires knowing what else exists.
The verdict comes with evidence, not a rewritten file. What your application does with a block or a review is your decision, in your code.
The connector changes. The engine behind it, and the contract it keeps, do not.
No cloud, no feed, no external call in the decision path, at any of the three. It runs the same on an air-gapped network as it does on the internet. Every decision leaves one record, written outside the agent: who, from which host, through which client and tool, which file or URL, and what the verdict was.
A thirty-minute demo on the connector that matches your boundary, with a file you choose. A trial follows the demo, on your side of the wire.
