In a chatbot, a successful prompt injection produces a wrong answer. In an agent, it produces an action: an API call, a payment, a deleted record, a message sent as you. The agent already holds the permissions the task needs, so the injected instruction inherits them. Nothing has to be escalated. The attack is complete at the moment the agent decides to call a tool.
What changes when the model can act?
Three things, and each one raises the stakes of the same underlying flaw.
- Effects replace text. The output is no longer read by a person who might notice it is odd. It is executed.
- The authority is the agent's own. MITRE ATLAS records tool use as its own technique, AML.T0053 AI Agent Tool Invocation, because reaching the tools is the attacker's objective, not a side effect.
- The loop keeps going. An agent that reads its own previous turns, or a stored memory, carries the payload forward. ATLAS calls that AML.T0080 AI Agent Context Poisoning, with sub-techniques for memory and for the thread. An injected instruction written into the agent's own configuration is AML.T0081, and it persists across sessions.
What is the lethal trifecta?
Simon Willison's name for the combination that turns an injection into a breach. An agent is exposed when it has all three of: "access to your private data", "exposure to untrusted content", and "the ability to externally communicate" (Willison). Any two are survivable. All three means an attacker who can place text in front of the agent can read your data and get it out.
Meta reaches the same conclusion with a rule for builders. An agent may satisfy at most two of: processing untrusted input, access to sensitive systems, and the ability to change state or communicate externally. Meta's own sentence: "An agent operating without human approval is allowed to satisfy two of the three. Combining all three requires a human in the loop" (Meta). Meta's premise is worth quoting too, because it sets the design assumption: prompt injection is "a fundamental, unsolved weakness in all LLMs."
The awkward part for a real deployment: a useful agent usually needs all three. An agent that triages tickets reads untrusted text, touches customer records, and writes a reply. That is the trifecta, described as a job.
Why is excessive agency the other half of the problem?
Because the injection decides what to ask for, and the agent's standing authority decides what happens next. OWASP separates the second half as LLM06:2025 Excessive Agency and names three root causes exactly: excessive functionality, excessive permissions, excessive autonomy.
That split is the useful diagnostic. LLM01 says the delivery cannot be reliably filtered. LLM06 says the damage is a function of what you handed the agent. One of those two you can decide. Anthropic's published agent framework lands in the same place: agents "must ask for human approval before taking any actions that modify code or systems", and persistent permissions are for routine tasks the user already trusts (Anthropic).
Which failures show up in practice?
Described by channel and by outcome, because the channel is what you can inventory.
| The agent was asked to | The injected text arrived in | The proposed action |
|---|---|---|
| Triage inbound support tickets | The ticket body | Read a private table and write its contents into a field the reporter can see |
| Summarise the morning's mail | An email nobody opened | Forward a thread to an external address |
| Fix an issue in a repository | A public issue description | Read a private repository and post what it found in a public comment |
| Reconcile supplier invoices | A PDF attachment | Pay an outstanding balance to a new account |
| Respond to an alert | The alert's own enrichment text | Disable logging on the host |
The pattern: the read was legitimate every time, and the action was the first illegitimate step. That is why the controls that matter sit on the action.
What actually limits the damage?
- Remove a leg of the trifecta where the workflow allows it. A read-only credential is the cheapest version of this.
- Give the agent no standing credential. An agent that cannot authenticate cannot act, whatever it was persuaded to want.
- Keep the approval surface small. OWASP's agentic threat list names T10, Overwhelming Human in the Loop, because a gate that fires on everything trains the person to sign (OWASP). Hold what cannot be undone, and grade the rest in advance.
- Record the outcome where the acting system cannot edit it. OWASP's T8 is Repudiation and Untraceability, and it is the failure that makes an incident unreviewable afterwards.
Related: indirect prompt injection, defences and their limits, and containing a successful injection.
The agent was persuaded. What is it able to do?
Whatever your policy says, and nothing else. That is the layer ZIFFER is.
The agent holds no credential on your systems. It proposes an action, and the credential that performs it sits with an executor on your side of the line. The proposal from a compromised agent is graded against the same signed policy as any other, because the grade, the reversibility and the owner of the target are recomputed from your policy rather than read from what the agent sent. Reversible, in-scope actions run. Irreversible ones are held for a quorum of two named humans who sign the exact bytes that will run, and a hold nobody signs expires with nothing run. Every outcome, refusals included, leaves a signed receipt naming the action, the policy version, the signers and the time.
ZIFFER is not a guardrail. It inspects no text, detects no injection and prevents none. It decides whether a proposed action is entitled to run. See agent authorization, the agent audit trail and every refusal.