The short answer: you can't count on catching every hidden instruction, so design for the one you miss. Give agents no credentials to steal, no open network to send data to, only the tools their job needs, and a person's approval on the changes that matter. Then a hijacked agent can read the instruction, but it can't carry it out.
Why documents are the attack surface
An agent that does real work reads things written by other people: vendor contracts, support tickets, shared spreadsheets, web pages, email. Any of them can contain text aimed at the agent instead of the human reader. It can be white text on a white page, a comment in a file, or a line buried in a long thread.
This is indirect prompt injection. The person asking the agent for help never typed anything malicious. The attack rides in on the content the agent was asked to read.
Assume the document will try
Filters and classifiers help, but none of them catches everything. Attackers can rephrase, hide characters or split an instruction across several places. A plan that depends on catching every instruction fails the first time one slips through.
So start from the opposite assumption: the agent will read the instruction, and some of the time it will try to follow it. The question becomes what it can actually do.
A document carries a hidden instruction. The agent reads it, and the instruction tries four things: Use a credential none in the sandbox to use Send data to an outside host denied by the egress allowlist, and logged Call a tool it wasn't given not in this agent's grants Change a system waits for a person to approve
The design assumes the instruction gets read. What matters is that nothing it asks for can happen on its own.
1. Give the agent nothing worth stealing
Most injection payloads want credentials or data. If an API key sits in the agent's environment, a hijacked agent can print it, send it or use it.
In Avispa Enterprise, agents never hold your credentials. Each agent works in its own sandbox, and the egress proxy adds the real credential to an approved request on its way out. The agent only ever sees a placeholder.
2. Leave it nowhere to send anything
An instruction like 'send this file to this address' needs a network path. Default-deny egress removes it: an agent can reach only the destinations on its allowlist, and the proxy also denies internal and cloud-metadata addresses.
Every connection and every denial is logged. A denial you didn't expect is a signal worth investigating, because something tried to reach a place it had no reason to.
3. Grant only the tools the job needs
An agent that summarizes contracts doesn't need to send email or delete records. In Avispa, tools are granted per agent, starting from none, and a grant can be read-only.
A read-only grant can't be talked into writing. It's enforced at the proxy, not left to the agent's judgment.
4. Put a person in front of the changes that matter
Choose which writes wait for a person, and gate the ones that change a system. The approval covers that exact action with those exact arguments, once. If the agent changes anything, it needs a new approval.
No agent approves its own work, and no agent can raise its own budget. A hijacked agent can propose a change, but someone has to see it before it happens.
5. Label what is untrusted
Containment does the heavy lifting, but it still helps when the model knows which text is data. In Avispa, results from synced knowledge sources such as SharePoint, OneDrive and Confluence arrive labeled as untrusted reference data, and they're searched rather than pasted into the agent's instructions.
Web pages can be read by a separate model that returns only an answer, so by default the agent works from the answer rather than the raw page. It's advisory, not enforced, so treat it as defense in depth rather than a guarantee.
6. Treat classifiers as an extra layer
A guardrail classifier can inspect inputs and outputs and stop or flag what looks harmful. Avispa supports one as an option you switch on. It ships off, and the model it ships with looks for harmful content in general, not injection in particular.
Be clear-eyed about it. A classifier reduces risk, it doesn't remove it, and it should never be the only thing between an instruction and an action.
7. Measure the gaps honestly
Keep a set of injection test cases and record which ones are still not mitigated. A test suite that only shows passes is telling you about the tests, not about your agents.
When a gap closes, update the case. When a new technique appears, add one.
What to ask any vendor
- Where do the agent's credentials live while it works?
- What can an agent reach on the network by default?
- Can a grant be read-only, and where is that enforced?
- Which actions need a person, and does an approval cover the exact action?
- Is every denied request logged, and can I send those logs to my SIEM?
- Which injection cases do you know you don't yet stop?
Questions people ask
Can prompt injection be fully prevented? Not by filtering alone. Instructions can be rephrased, hidden or split, and no filter catches every one. The reliable approach is to limit what a hijacked agent can do: no credentials, no open network, minimal tools and approval before changes.
What is indirect prompt injection? It's an instruction hidden in content an agent reads while working, such as a document, ticket, email or web page, rather than typed by the user. It's the bigger risk for agents, because they read so much content they didn't write.
Does Avispa scan documents for hidden instructions? It doesn't rely on scanning. Its main defense is containment: agents never hold credentials, reach only approved destinations, start with no tools and need approval to change anything. Results from synced knowledge sources are labeled untrusted.
Where do denied requests show up? Every connection and denial at the egress proxy is logged, and audit data can be exported to your SIEM over OpenTelemetry.
See containment on your own documents. Bring one you worry about to a demo, and we'll show what an agent can and can't do with it.