← Learn

Prompt Injection: The Defender's Playbook

Prompt injection is content a model reads being treated as instructions. Every defence reduces it, none closes it. Contain the action instead.

what is prompt injection and how do I stop it

Prompt injection is an attack in which content the model reads is treated as instructions it should follow. A language model has one input channel. Your instructions and an attacker's text arrive on it together, as one stream of tokens, and nothing in that stream marks which part came from you. Every published defence reduces the attack. None of them closes it. So the defender's question is not how to stop the injection. It is what an injected system is still allowed to do.

What counts as prompt injection?

OWASP defines it as a vulnerability that "occurs when user prompts alter the LLM's behavior or output in unintended ways", and ranks it first in the Top 10 for LLM Applications 2025. OWASP splits it in two. Direct injection is text the attacker submits themselves. Indirect injection is malicious content placed in external data the model reads.

MITRE ATLAS files the same attack as AML.T0051 LLM Prompt Injection, under the Initial Access tactic, with sub-techniques .000 Direct, .001 Indirect and .002 Triggered. The placement is the useful part. ATLAS does not treat injection as a content-quality problem. It treats it as how an attacker gets in.

Two neighbouring terms get confused with it. A jailbreak makes a model produce text its policy forbids. Excessive agency is the functionality, permission and autonomy an agent holds whatever it was told, which OWASP ranks separately as LLM06. Injection is the delivery. Excessive agency is what makes the delivery matter.

Why can it not be closed the way SQL injection was?

SQL injection was closed by a boundary. A parameterised query separates the instruction from the data, and the database enforces the separation. Prompt injection exploits the absence of that boundary: instructions and data are the same token stream, and the model has no mechanism to keep them apart.

Three independent sources say so in print.

  • OWASP, in LLM01 itself: "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection."
  • The UK NCSC, in a December 2025 assessment: prompt injection "may never be totally mitigated in the way SQL injection attacks can be", and LLMs are "inherently confusable deputies" (NCSC).
  • OpenAI, about its own browser agent: injection, "much like scams and social engineering on the web, is unlikely to ever be fully 'solved'" (OpenAI).

There is a measured version of the same point. OpenAI's GPT-6 Astra system card reports an 8.5% attack success rate within 15 attempts across 1,810 curated indirect-injection attacks, against 27.0% for the previous model. Robustness improved threefold. Roughly one attack in twelve still lands against a patient attacker, in an agentic tool-use setting.

Where does the injected text arrive from?

Every channel below is content the agent was legitimately asked to read. None requires unusual access.

ChannelWhat the attacker controls
An email or message the agent summarisesThe body, including text the person never sees
A ticket, issue or record in a system of recordInbound text your company already stores
A web page or document fetched during a taskAnything on the page, including hidden markup
A calendar inviteThe description field
A tool description or configuration file the agent reads as part of its own setupThe agent's instructions (AML.T0081)
The agent's own memory or an earlier turn in the threadWhat the agent believes (AML.T0080, .000 Memory and .001 Thread)

The last two are persistent. A poisoned memory or tool description does not need the attacker present when the action runs.

What does each defence layer really do, and what does it still let through?

A defence layer is judged by what it still lets through, not by what it blocks.

LayerReal effectDocumented limit
Input and output filtering, injection classifiersCatches known payloads and raises the attacker's costThe classifier is the thing an adaptive attacker optimises against. Out-of-band detectors evaluated adaptively lose much of their reported effect (arXiv 2606.26479). Simon Willison on vendors advertising 95% catch rates: in security, "95% is very much a failing grade" (Willison)
Instruction hierarchy, system prompt hardening, adversarial trainingMeasurably lowers success rate, and this is where frontier labs put their effortThe lab's own number is not zero: 8.5% within 15 attempts (GPT-6 Astra system card)
Least privilege and tool allowlistingShrinks the set of actions an injected agent can reach, which is the highest-value cheap controlThe remaining set is often enough. One tool that reads and one tool that sends is already an exfiltration path (Willison)
Privilege separation: the dual LLM patternStructural, not statistical. The quarantined model handles untrusted content and holds no tools; it "is expected to have the potential to go rogue at any moment" (Willison, 2023)The privileged model must never see raw untrusted text, which constrains what the assistant can do at all
Capability enforcement at the tool call: CaMeLExtracts control and data flow from the trusted query, so untrusted data cannot influence program flow, and enforces security policies when tools are called (arXiv 2503.18813)Solves 77% of AgentDojo tasks with provable security. The policies have to be written, and not every workflow fits the pattern
Sandboxing and egress controlRemoves network paths outThe third leg of the trifecta can be a legitimate tool. Writing attacker-readable data into a record you own is exfiltration with no egress at all
Limiting the combination: Meta's Rule of TwoAn agent may satisfy at most two of three properties: untrusted input, access to sensitive systems, ability to change state or communicate. "Combining all three requires a human in the loop" (Meta)It is a design constraint, not a detector. Meeting it means giving up capability or adding an approval
Approval on high-impact actionsOWASP LLM06's own headline mitigation: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken" (LLM06)OWASP's agentic threat list names T10 Overwhelming Human in the Loop. A gate that fires on everything is itself an attack surface, and a fluent explanation is a persuasion channel (OWASP)
Monitoring and loggingThe only layer that still works after the attack succeededOWASP names T8 Repudiation and Untraceability. A log written by the acting system is that system's claim about itself
Red teaming and adversarial evaluationTurns "we think it holds" into a number against an attacker who adaptsA pass rate is a claim about a sample. The next attack is not in the sample

Read that as a stack, not a menu. Every row is worth building, and no combination of them returns the guarantee a parameterised query gives you.

Can you detect an injection after it happens?

Partly, and never on the text alone. The signals that survive a real attacker are behavioural: a tool-call sequence that does not match the task, a read outside the ticket's scope, a canary token appearing where it should not. Text-level detection sits on the same undifferentiated stream the model failed to parse. NCSC states the achievable objective as "reducing the risk and impact of prompt injection", not eliminating the input.

What should you measure instead of a block rate?

A block rate describes your filter. These four describe your exposure.

  1. Which actions an agent can take today without a person deciding.
  2. Which of those cannot be undone.
  3. How many actions ran that no written rule covered. If you cannot answer it, that is the finding.
  4. What you can hand to someone who was not there: a record they can check themselves, not a log line.

Questions 1 and 2 are a policy exercise. Question 3 is architecture. Question 4 is the agent audit trail.

What is still true after every filter has failed?

This is the layer ZIFFER is. It does not read the injected text and it does not try to recognise it.

The agent holds no credential. It proposes an action; the credential that would make the action happen sits with an executor on your side of the line. An injected proposal is graded against the same signed policy as a clean one, because the values the decision depends on are recomputed from your policy rather than read from the proposal. Actions that cannot be undone are held for a quorum of two named humans, who sign the exact bytes that will run. If the quorum is not met, nothing ran. Every outcome, refusals included, leaves a signed receipt: the action, the policy version, who signed, and when.

ZIFFER is not a guardrail. It never inspects text, it detects no injection, and it prevents none. It decides whether a proposed action is entitled to run, and it records the answer. See agent authorization for the mechanism and every refusal for the names it raises.

FAQ

Is prompt injection the same as jailbreaking?

No. A jailbreak makes a model produce forbidden text, while an injection makes it follow an attacker's instructions, usually to take an action. The same payload can do both, but the damage in an agent comes from the action.

Will a better model fix prompt injection?

It lowers the rate, and the frontier labs have the numbers to prove it. It does not reach zero: the most robust model OpenAI has published still reports 8.5% attack success within 15 attempts on the indirect-injection benchmark in its own system card.

Do guardrail products stop prompt injection?

They catch known patterns and raise the attacker's cost, which is worth having. They enforce a public taxonomy rather than your policy, and Willison's "95% is very much a failing grade" is the right way to read their headline numbers.

Is indirect injection more dangerous than direct?

Usually, because the attacker needs no access to your prompt and no session with your agent. They only need to place text somewhere your agent will read it, and then wait.

What can I sign off on today?

Write down which agent actions are reversible, which are not, and which no rule should ever cover. That list, plus a record of every action that actually ran, is what makes a rollout reviewable whether or not an injection lands.

Sources

  1. OWASP LLM01:2025 Prompt Injectionhttps://genai.owasp.org/llmrisk/llm01-prompt-injection/
  2. OWASP LLM06:2025 Excessive Agencyhttps://genai.owasp.org/llmrisk/llm062025-excessive-agency/
  3. OWASP Agentic AI: Threats and Mitigationshttps://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
  4. MITRE ATLAS AML.T0051 LLM Prompt Injectionhttps://atlas.mitre.org/techniques/AML.T0051
  5. MITRE ATLAS AML.T0080 AI Agent Context Poisoninghttps://atlas.mitre.org/techniques/AML.T0080
  6. MITRE ATLAS AML.T0081 Modify AI Agent Configurationhttps://atlas.mitre.org/techniques/AML.T0081
  7. UK NCSC: mistaking the nature of this AI vulnerability could lead to large-scale breacheshttps://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches
  8. Simon Willison: The lethal trifecta for AI agentshttps://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
  9. Simon Willison: The Dual LLM patternhttps://simonwillison.net/2023/Apr/25/dual-llm-pattern/
  10. CaMeL: Defeating Prompt Injections by Design (arXiv 2503.18813)https://arxiv.org/pdf/2503.18813
  11. Meta: Agents Rule of Twohttps://ai.meta.com/blog/practical-ai-agent-security/
  12. OpenAI: hardening Atlas against prompt injectionhttps://openai.com/index/hardening-atlas-against-prompt-injection/
  13. OpenAI GPT-6 Astra system card, prompt injectionhttps://deploymentsafety.openai.com/gpt-6-astra/prompt-injection/fig-5
  14. Adaptive Evaluation of Out-of-Band Defenses Against Prompt Injection (arXiv 2606.26479)https://arxiv.org/pdf/2606.26479