Most companies have approved an AI agent by now. Far fewer let it do the work it is capable of.
The usual rollout ends with a capable agent on a short leash. It can answer questions, but it cannot browse. It can edit code, but not the shared drive. It can draft a report, but a person checks every output before it goes anywhere. Each of those limits turns a task the agent could finish into one a person finishes by hand.
The leash is not there because security teams dislike AI. It is there because nothing checks what flows into the agent or out of it.
Two worries, both about content
What the agent reads. A web page or a document can carry instructions meant for the model instead of the person. Often they are placed where a person reading the page would never see them: in page source the browser does not display, in text inside an image, in a file packed inside an archive. The agent reads all of it, and it treats what it reads as part of the job.
What the agent writes. An agent trying to be helpful will put a credential into a config file, a customer record into a summary, or a key into a note it saves somewhere it should not. No intent is needed. It only needs the data to be in reach.
Approving tools one by one does not answer either worry. Both are about the content, so the content is where the check belongs.
Text injection is the low-hanging fruit
Most prompt injection defenses, and most of the benchmarks that score them, start and end with text: a typed prompt, or a sentence planted in a document. That is worth catching, and it is also the easiest case. When a product reports a high catch rate, it is worth asking what was in the test set. Often it is a large pile of text prompts.
Attackers have already moved past that. The instruction sits in an image the model reads and no filter OCRs, in markup the browser never renders, in characters a person cannot see, or inside a file inside a file. The rule for agents is simple: any path a tool uses to bring content into the model is a path an injection can use too.
So the question for any defense is not whether it catches a malicious sentence. It is whether it reads what the agent actually receives.
What Subtext does over MCP
Subtext runs as an MCP server. Your agent reads files, fetches web pages and writes files through it, and Subtext inspects each one before it reaches the model or the disk.
- Web pages. When the agent fetches a page, Subtext inspects the page source, not just what a browser shows. Content hidden from a person viewing the page is still inspected.
- Files. Subtext receives the file itself, not text another tool pulled out of it. Images are read, archives are opened, and anything decoded along the way is inspected again. The inspection engine is patent pending.
- Writes. When the agent saves a file, the content is inspected before it is written. A blocked write never reaches the disk.
- API keys and credentials. These can be blocked whether they show up in a page the agent fetches or in a file it is about to write. Hiding a key in an element the browser does not display does not get it past the check.
- Clean content passes untouched. When something is blocked, the agent gets a short notice naming the reason and keeps working. A block costs one page or one file, not the session.
- A record outside the agent. Every decision is logged on your Subtext instance, where the agent cannot edit it.
It works in the agents your team already uses: Claude, ChatGPT, GitHub Copilot, VS Code Copilot, Grok and Google Antigravity. Setup is a configuration entry, not a new workflow. The MCP page has the details.
What “more” looks like
- Research tasks that read vendor docs, forums and search results, not only a list of approved sites.
- Work across the real shared drive instead of a sanitized copy of three files.
- Agents that write reports and configuration files without someone checking each one for secrets first.
None of that requires trusting the agent more. It requires checking what the agent reads and writes.
How we know
Every capability in this post has been tested against real attacks. We take part in public red-team competitions and private engagements against production AI systems. What we learn there becomes test cases, and the test cases decide what we are willing to claim. If a claim is on this page, we have watched it hold.
Questions worth asking about your own stack
- What did you stop your agent from doing because you could not see what it was reading?
- If a web page hid a key or an instruction in its source, would your control see it, or only what the browser rendered?
- Does your control decide before content reaches the model, or after the agent has acted on it?
- If your agent wrote a credential into a file today, what would stop it?
If the answers make you want to loosen the leash, or tighten it, I would like to hear about it.
Zero Trust for Files applies to agents too: check what they read, check what they write, and let them do the rest.