A file has only ever been able to hurt you through a reader. Something in it had to be perceived, and understood, and acted on. That sounds like a truism. It was actually a security control, and it was doing more work than anyone gave it credit for.
Think about what it quietly disposed of. Text sized to nothing, or set in the same color as its background, or sitting in a layer no renderer draws. Content in a part of the file the application never displays. Words inside a picture. A passage in a language neither correspondent reads. All of it could travel between two people for years, in ordinary documents, and cause nothing at all, because the reader never perceived it. It was not stopped. It was simply never seen.
So the file controls we all built were calibrated to that reader. They defend what a person could be made to notice and act on, because for thirty years that was the only way a file could reach into anything.
The file did not change
An agent calling a file tool reads the bytes and puts them in the model’s context, and the model reasons over them before anything reaches a screen. What it perceives there is not what a person at a desk perceives. It reads what was hidden as readily as what was shown, because to it there is no difference between the two. It reads the text in the picture. It is not limited to the languages you happen to read.
Nothing about the files changed. The perceptual range of the thing reading them did, and content that was latent for decades became live in the same instant. That is the whole of it, and most of the industry is still defending the older reader.
Concealment only ever worked against a reader who could not see it. The new reader can.
The controls at this boundary check the call, not what comes back
There is real work happening in agent security, and it is aimed one step upstream. Is this server trustworthy. Is this skill hiding instructions. Is this tool name allowed. Is this path off limits. Good questions, worth asking.
None of them is a question about the file. A trustworthy server, invoked by an approved tool, reading a permitted path, hands back a document carrying something nobody looked at. The supply side was verified. The content was not.
You can see the shape of it in how those controls are configured. The things a rule can name are a server, a tool, a path, a glob. That vocabulary has no way to say this file is not what it claims to be, because nothing in it refers to the bytes. As of August 2026 we have not found a control at this layer that documents checking a file’s declared type against its actual content, or failing closed on a format it cannot parse.
Inspection, in the path, in front of the model
Subtext for MCP is live today. It replaces the file tools your agent already calls, using the same names, so it goes in as a substitution rather than an addition. When the agent asks for a file, the bytes are read and scored before anything returns. A blocked read comes back as a tool error naming the file, so the agent treats it as a failed read rather than as data, and the reason lands in your own logs.
What it inspects is the content, reduced to the text a model would act on, with the container opened rather than trusted. A page pulled from a URL gets exactly what a file off the disk gets, because a URL is a file with extra steps. Type is resolved from the bytes, so the extension and the header the source declared are recorded as claims rather than accepted as answers.
Same engine and same verdicts as Zero Trust for Files. Only the enforcement point is new.
Coverage follows the enforcement point
Which is the part worth being precise about, because it decides what any of this is worth.
A connector covers what the agent asks for through tools. It does not cover what the client goes and fetches on its own. A built-in web fetcher or a browser tool is run by the client, and the result goes straight into context without passing through any connected tool. And if you leave the tools you are replacing registered alongside the inspected ones, the agent keeps an uninspected route to the same files and will use it. Replace them rather than adding to them.
For content the client fetches itself, the answer is not a better connector. It is a second enforcement point. The same engine runs at the network gateway, where that traffic does cross a boundary you control, and returns the same verdicts on the same content. Two places to put one decision, and which you need depends on the paths your agents actually use.
Shell access is a different matter, and not a gap in the boundary. It is a decision not to have one. If an agent can run arbitrary commands, file inspection is not the control that helps you, and nothing at this layer changes that.
Where to start
The engine ships as a container you run in your own environment. The connector goes on the endpoints running Claude and points at it, one entry in the MCP config. Nothing calls out, and nothing leaves the machines you already control.
What it gates, what it does not cover, and how it behaves when the engine is unreachable are all on the Subtext for MCP page. The limits are stated there on purpose. A control you cannot describe the edges of is one you cannot trust the middle of.