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.
| Channel | What the attacker controls |
|---|---|
| An email or message the agent summarises | The body, including text the person never sees |
| A ticket, issue or record in a system of record | Inbound text your company already stores |
| A web page or document fetched during a task | Anything on the page, including hidden markup |
| A calendar invite | The description field |
| A tool description or configuration file the agent reads as part of its own setup | The agent's instructions (AML.T0081) |
| The agent's own memory or an earlier turn in the thread | What 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.
| Layer | Real effect | Documented limit |
|---|---|---|
| Input and output filtering, injection classifiers | Catches known payloads and raises the attacker's cost | The 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 training | Measurably lowers success rate, and this is where frontier labs put their effort | The lab's own number is not zero: 8.5% within 15 attempts (GPT-6 Astra system card) |
| Least privilege and tool allowlisting | Shrinks the set of actions an injected agent can reach, which is the highest-value cheap control | The 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 pattern | Structural, 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: CaMeL | Extracts 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 control | Removes network paths out | The 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 Two | An 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 actions | OWASP 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 logging | The only layer that still works after the attack succeeded | OWASP names T8 Repudiation and Untraceability. A log written by the acting system is that system's claim about itself |
| Red teaming and adversarial evaluation | Turns "we think it holds" into a number against an attacker who adapts | A 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.
- Which actions an agent can take today without a person deciding.
- Which of those cannot be undone.
- How many actions ran that no written rule covered. If you cannot answer it, that is the finding.
- 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.
Read next
- Indirect prompt injection: no attacker ever touches your prompt.
- Defences and their limits: one layer per row, in detail.
- Prompt injection in AI agents: where a bad answer becomes an action.
- Containing a successful injection.
- The OWASP Top 10 as an agent threat model.
- Guardrail frameworks and what none of them can do.
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.