Containing prompt injection when an agent reads outside content

Plan for an injection that works

OWASP's 2025 entry on prompt injection describes indirect injection as content from external sources, such as websites or files, that changes the model's behaviour, and notes that the instruction need not be visible to a person. It also states that it is unclear whether fool-proof prevention exists. Its mitigations include least privilege, human approval for high-risk actions, separating external content and adversarial testing. Our planning assumption follows from that: the useful question is what the agent can do once it has been fooled.

Our coding agent security guide covers agents working in repositories. This article is about business agents that read mail, documents, tickets, web pages and tool results.

Coding agent security for engineering teams

Map untrusted inputs against actions

Take a hypothetical accounts payable agent. It reads supplier emails with PDF invoices, looks up purchase orders, and as first proposed could create payment proposals, reply to suppliers and update supplier bank details. Its map looks like this:

• Email bodies and attachments: untrusted, written by anyone who can send mail to the inbox
• Purchase orders: trusted for amounts, but free-text fields may hold text the supplier provided
• Supplier replies: an outbound channel, so anything in the agent's context can leave through it
• Bank detail changes: a high-impact write that an injected message about a changed account would aim for

The dangerous combination is plain to see: untrusted text in context, a write that moves money and a way to send data out. The decision is which edge to cut. Here we would remove bank detail changes from the agent entirely, restrict replies to fixed templates with no free text, and let the agent only propose payments that a person releases in the ERP system.

Design patterns that remove the path

A 2025 paper by Beurer-Kellner and colleagues sets out design patterns built on one principle: once an agent has read untrusted input, it must be constrained so that this input cannot trigger consequential actions. Four of the patterns that apply to business workflows:

• Action selector: the model picks one of a fixed set of actions and never sees their results, so no tool output can steer it
• Plan then execute: the model fixes its tool calls before reading untrusted data, so injected text can change arguments but cannot add calls
• Map-reduce: each untrusted document is processed in isolation, so one malicious file cannot change how the others are handled
• Dual LLM: a privileged model with tools never reads untrusted text, while a quarantined model without tools reads it and returns values by reference

The CaMeL system, described by Debenedetti and colleagues, extracts the control and data flow from the trusted request and enforces capability policies when tools are called. Its guarantees hold within the authors' threat model, which treats the user's request as trusted, and depend on the security policies defined for each tool. They report solving 77% of AgentDojo benchmark tasks with provable security, against 84% for an undefended system. That gap is a measured utility cost on their benchmark, not a forecast for your workflow.

Controls the model cannot argue with

• Tool permissions scoped to the task and enforced by the server or business system
• Approvals bound to the exact action and payload and verified by trusted code, for anything that moves money, changes access or sends data out
• Egress limits on the agent's runtime, and output rendering that does not load images or links automatically, since OWASP describes exfiltration through an inserted image URL
• Deterministic checks of outputs against expected values, such as amounts matching the purchase order and recipients on an allowlist
• Tool results treated as untrusted input, which the MCP tools specification reflects when it asks clients to validate results before passing them to the model

Marking external content clearly in the prompt is still worth doing. It reduces how often an injection works, but the model can still be talked past it.

Checks before and after go-live

Build an adversarial test set from your own input channels: white text in PDFs, instructions in email signatures, text in other languages or encodings, and instructions inside tool results. For each case, assert the outcome at the boundary, not the model's wording: no unapproved write, nothing outbound beyond the templates, an alert raised. Re-run the set whenever the model, prompt or tools change. After launch, log each tool call with the IDs and sources of the inputs read before it and the decision taken. Capture raw content only through an approved, restricted and redacted capture with its own retention. Review refused actions, and treat a blocked attempt as a sign that someone is probing.

What the boundaries cost

Each pattern removes flexibility. An action selector cannot handle a request outside its list, plan then execute cannot adapt to what it finds, and approvals add a person's time to every case they cover. Match the strength of the boundary to the worst action the agent can reach. An agent that summarises documents for the person who uploaded them may need light controls. One that can pay, send or grant access should start with those paths cut, with capabilities added back one at a time after testing.

A practical next step: draw the input and action map for one agent and mark every path from untrusted text to a write or an outbound channel.

AI engineering and architecture