Indirect Prompt Injection Defense: Containing What the Model Was Told to Do
Indirect prompt injection hides instructions inside content an AI agent reads, a web page, a document, a tool result, and the model acts on them as if they came from you. No request filter reliably stops a model from being fooled. This piece is honest about that limit and shows where the defensible control sits: identity-scoped authorization on what the agent may then do, plus a per-decision record of what it did.
Indirect prompt injection works by planting instructions in content an AI agent reads rather than in the message a user types. A support agent summarizes a web page that contains hidden text telling it to exfiltrate the conversation, a coding agent ingests a repository file with a comment instructing it to push secrets, a document parser meets a PDF whose body says to email its contents elsewhere. The model treats the injected text as instructions because, to the model, retrieved content and user intent arrive as the same token stream. The agent then acts, and the action carries the agent's own authority.
I want to be direct about what stops this and what does not, because the honest version of the defense matters more than a reassuring one. A request filter does not reliably prevent a model from being fooled by injected content. The control that holds is on the other side of the model, where the agent's resulting actions are authorized and recorded.
Why filtering the prompt does not close this
The appealing idea is to scan inputs and strip injection attempts before they reach the model. It helps at the margin and fails as a guarantee. Injected instructions can be encoded, translated, split across retrieved chunks, or phrased as ordinary content, and the model's job is to interpret language, so the same flexibility that makes it useful makes a complete input filter unreachable. Every published bypass of an input classifier makes the same point: the model is a probabilistic interpreter, and you cannot enumerate the phrasings that will move it.
That is why treating the model as trusted after it reads untrusted content is the mistake. The defensible assumption is that the model may be induced to attempt anything the injected text asks for. My view is that any control which depends on catching the malicious phrasing before the model sees it is built on sand, and the difference between prompt injection and jailbreak only sharpens the point: both exploit the model's willingness to follow language.
The control sits on the agent's actions, not its inputs
An agent that has been injected still has to act through calls: a model request, a tool invocation, an outbound fetch. Those calls are observable and authorizable at the request boundary, and that is where the blast radius gets contained. If the agent's identity is bound to a scope, an instruction to email data to an external address is denied because that identity has no route to that action, regardless of what convinced the agent to attempt it. The injection succeeded at persuading the model and failed at producing an effect, because the effect required an authorization the agent did not hold.
This reframes the defense as authorization rather than detection. Each agent runs under a verified identity with least privilege, its outbound model and tool calls are checked against policy for that identity, and disallowed actions are blocked inline. The post-authentication gap for AI agents is exactly this: authentication proves who the agent is, and per-call authorization decides what an injected agent is still not allowed to do.
Boundary: what a gateway does not do here
A policy gateway on HTTP AI traffic does not stop the model from being deceived, does not read the intent behind retrieved content, and does not prevent an injection from occurring inside the model's reasoning. Those are model-layer and application-layer concerns. If an injected instruction asks the agent to do something its identity is authorized to do anyway, the gateway allows it, because policy cannot distinguish a legitimate authorized action from an injected one when both are permitted. The gateway's contribution is narrower and real: it enforces the scope that keeps an injected agent from reaching actions outside its authority, and it records every call so the injection's attempted effect is visible after the fact. Naming that limit is the difference between a control and a claim.
DeepInspect
This is the gap DeepInspect closes. DeepInspect runs as a stateless proxy between your agents and any LLM or tool endpoint they call. Each agent call is bound to a verified identity, evaluated against per-role and per-route policy, and allowed or blocked before it reaches the model or the tool. An agent that has been injected still cannot make a call its identity is not authorized to make.
Every decision is written to a tamper-evident per-decision record naming the identity, the policy applied, the destination, and the outcome, so an attempted exfiltration or an out-of-scope action shows up in the trail whether or not it was blocked. DeepInspect does not promise to detect the injection inside the model; it contains what an injected agent is permitted to do and gives responders the record of what it tried. To scope your agents before an injection tests them, book an AI readiness assessment.
Frequently asked questions
- Can any tool fully prevent indirect prompt injection?
No tool reliably prevents a model from being influenced by injected content, because the model interprets language and injection is a language attack. Input filtering reduces some attempts but cannot be complete. The realistic goal is containment: assume an agent can be induced to attempt an action, and make sure its identity and authorization scope prevent that action from having an effect outside what the agent is allowed to do. Vendors promising to stop injection at the input are overselling a probabilistic filter.
- How does authorization help if the model is already fooled?
A fooled model still has to act through a call, and that call can be authorized independently of the model's reasoning. If the agent's identity has no permission to reach an external email endpoint or a production database, an injected instruction to do so is denied at the request boundary. The model's deception does not translate into an effect because the effect required an authorization the agent lacks. Authorization works precisely because it does not depend on knowing whether the intent was legitimate or injected.
- What does indirect prompt injection look like in a RAG system?
In retrieval-augmented generation, the model reads documents fetched from a store, and any of those documents can carry instructions aimed at the model rather than the user. A retrieved record might contain text telling the model to ignore prior instructions and reveal other users' data. Because the retrieved content and the user's question reach the model together, the model can act on the planted text. Scoping the agent's identity and authorizing its resulting calls limits what such an instruction can achieve.
- What audit evidence matters after a suspected injection?
The per-decision record of the agent's calls: which identity made each model and tool call, what policy applied, what destination it reached, and whether it was allowed or blocked. That trail lets responders reconstruct what an injected agent attempted and confirm which actions were contained. Application logs usually lack the identity and policy context to answer those questions, which is why a record produced independently at the request boundary is the artifact that makes post-incident analysis possible.