Prompt Injection Defense Before an Agent Acts

You must design your agent workflows so that a successful prompt injection attack cannot reach consequential actions. This means building controls outside the model itself—in application code, permissions systems, and human review gates—rather than relying on the model to refuse malicious instructions.

An analysis of 11 November 2026 of prompt injection defences that operate before an agent executes a tool argues that filtering and refusal training inside the model fail often enough in practice that you cannot build a safe workflow around them. When an agent reads external documents and then sends, deletes, exports, or modifies material, the accountable question is not whether a model will spot an injected instruction, but whether your surrounding controls can contain an attack that succeeds. In our assessment, this distinction moves the security burden from model robustness—which you cannot guarantee—to workflow design, where you can enforce concrete limits on what actions remain reachable and who must approve them.

The evidence is stark. Controlled evaluations show attack success rates of 57 per cent on average across indirect prompt-injection tasks, rising to 80 per cent after repeated attempts. A separate study of 30 LLM agents found that a ReAct-style model followed injected instructions in 24 per cent of cases, climbing to 47 per cent when an attacker reinforced the injection with additional prompting. Tests of agentic coding editors measured success rates between 67 and 84 per cent, with one scenario reaching 89 per cent. These figures come from different models, tasks, and populations, so they cannot be averaged into a single organisational rate. But they establish a consistent pattern: if your defence depends on the model refusing the attack, you are building on a foundation that fails regularly.

What counts as residual risk in an agent workflow?

Residual risk is not the percentage of attacks a model refuses. It is the set of consequential actions still reachable after an attack succeeds. An attacker who can influence the model's output but cannot reach a mailbox, a file export, or a permission change has not compromised your workflow. An attacker who can reach a draft that a person must review before sending has triggered a control, not bypassed one.

This definition changes how you evaluate a vendor's security claims. Instead of asking how often a model refuses a malicious instruction, ask what happens when the refusal fails. Can the agent still execute the action, or does a separate system gate stop it? The answer depends on controls that sit around the model, not inside its prompt.

Which controls must sit outside the model?

The OWASP guidance on prompt injection recommends treating the model as an untrusted user, enforcing least privilege, requiring human-in-the-loop approval for sensitive actions, and validating all outputs before they reach a tool. These controls belong in deterministic application code, not in model instructions. The vendor's own analysis identifies four failure modes that no prompt-based defence can reliably prevent:

• Instruction smuggling in retrieved documents — external content that contains directive language the model treats as a new task definition.
• Implicit influence without explicit instructions — passages or images that shift model behaviour without containing any recognisable directive sentence.
• Obfuscation through encoding and Unicode — instructions hidden in invisible characters, confusable glyphs, or alternative encodings that bypass text-based filters.
• Cross-context contamination — influence that spreads from one data source or conversation turn to another, compounding the attack surface.

How should you structure the separation between data and permissions?

Untrusted content remains data when the system separates what the model may read from what it is allowed to do. A document that arrives from outside your organisation should be normalised first—covering case, Unicode confusables, invisible characters, and whitespace—and then length-capped before any pattern matching runs. If a line reads like an instruction, the workflow does not delete it. It keeps the line in an evidence log with its original span, so a reviewer can later see exactly what arrived and what the system did about it.

In a retrieved medical PDF or legal intake email, the relevant passage should be wrapped in delimiters that mark it as data the model may quote or summarise, not as a new task definition. If the passage contains wording that resembles a directive, the model can report that wording as content. It cannot promote that wording into a tool call. This separation is the key boundary. A label does not enforce a trust boundary. Code that checks permissions before a tool runs is what enforces it.

What concrete controls must you demonstrate before deployment?

As build tickets, the requirement is concrete. You must be able to show:

1. Typed untrusted fields for every external source — mark all data that originates outside your organisation so the system can apply different handling rules.
2. Normalisation before any pattern matching — strip or flag invisible characters, Unicode confusables, and encoding tricks before the model sees the content.
3. No tool call whose arguments came only from unmarked external text — require that any action argument either comes from the user's direct input or is explicitly approved by a human reviewer.
4. A human gate for irreversible or privileged actions — require approval on the exact arguments, not a general description of intent; approval of "send this summary" is not approval of a recipient list the reviewer never saw.
5. A release record showing attack success beside task completion — measure both security and utility on a repeatable corpus, not headline figures from someone else's benchmark.
6. Five audit fields for every gated decision — record the proposed action, the tool arguments, the content span relied on, the reviewer outcome, and whether the gate stopped or released the action.

How should you test these controls?

You test by measuring attack success and task utility together on a repeatable corpus, rather than counting how often the model says no. Add one control layer at a time—normalisation, content filtering, least-privilege tools, independent verification—and record both security and task-preservation outcomes. Without benign but influential passages in your test cases, overblocking stays invisible until a legitimate user hits it in production.

Record seven metrics for every run: attack-success rate, false-positive rate, benign-task completion, unauthorised tool calls, secret exposure, abstention, and reviewer disagreement. Each one catches a failure the others miss. A configuration can post a strong refusal rate while still leaking through a tool call it never refused, because nobody asked it a question it recognised as an attack. Close each release cycle with a checklist showing security and utility numbers side by side, the corpus version used, and the specific layer added since the last run.

A verification layer can sit beside the gate rather than replace it. Verification supports review and control. It does not ensure correctness, compliance, or that an injection will be caught. The same limit applies to any single model output. Stating that limit plainly is part of a defensible position, not a concession. The workflow around the model protects the workflow. It does not turn any model output into a trusted instruction.