Prompt injection as an identity problem

Reframing the problem

A prompt injection succeeds when text an agent processes causes it to take an action the operator did not intend. Note what is absent from that description: any vulnerability, any credential theft, any privilege gained. The agent used permissions it legitimately held, in response to input it was designed to process.

That is why it belongs on an identity site. The security question is not "how do we detect malicious text" but "what can this agent do, and who authorised it to do that in this context." The first question has no stable answer. The second is a configuration you control.

Why filtering cannot be the primary control

Three structural reasons, all independent of how good any particular filter is:

• Asymmetry. The defender must anticipate every effective phrasing; the attacker needs one. This asymmetry does not improve with better filters.
• The channel is the product. An agent that processes untrusted content is doing its job. You cannot refuse the input class without removing the capability.
• Injection is not only in the prompt. It arrives through retrieved documents, tool outputs, web pages, file contents, and messages from other agents. Every one of those is an input surface, and several are not visible to a prompt-level filter at all.

Filtering is worth doing. It is worth doing as a layer that reduces volume, not as the control your risk position rests on.

Identity-layer controls that actually bound the damage

1. Per-invocation scope narrower than the agent's ceiling. An agent capable of many things should receive, for this task, authority for only this task. Successful injection then escalates to nothing, because there is nothing to escalate to. This is the single most effective control and it requires delegation to be modelled properly.
2. Separate read authority from write authority. Most injection payloads seek an action: exfiltrate, send, modify, delete. An agent that reads broadly and writes narrowly is a far smaller target than one holding symmetric permissions.
3. Human approval on irreversible actions. Not on everything, which trains people to click through, but on the specific set that cannot be undone. CIBA provides a clean out-of-band mechanism for this without the agent handling user credentials.
4. Provenance on inputs. Track whether content originated from a trusted source or an untrusted one, and reduce available authority when acting on untrusted input. This is difficult and imperfect and still worth attempting.
5. Egress control. Many payloads end in exfiltration to an attacker endpoint. An agent that can only reach an allowlist of destinations cannot complete that step regardless of how well the injection worked.
6. Log the chain, not the outcome. When an injection succeeds you need to reconstruct what the agent was authorised to do and under whose delegation. That is an incident-response requirement and a governance one.

The confused deputy, with a natural-language interface

The confused deputy problem is old: a program with privileges is tricked by a less-privileged party into misusing them on that party's behalf. Agents reproduce it exactly, with two aggravating properties.

First, the instruction channel and the data channel are the same channel. In a conventional system, data does not become instructions. In an agent, text in a retrieved document can function as an instruction, so the classical separation is unavailable at the interface.

Second, authority is often ambient. The agent holds standing permissions rather than obtaining them per task, so anything that influences its behaviour inherits everything it can do. The mitigation the capability-security literature has always given for the confused deputy is the same one that applies here: replace ambient authority with explicit, narrow, per-operation authority.

Where the security boundary belongs

Not at the model. The model is the thing being manipulated and cannot be relied on to police its own manipulation, however well it is trained or instructed. System prompts that instruct the model to ignore injected instructions are useful and are not a boundary.

The boundary belongs at the authorization layer between the agent and every resource it touches: an external decision point that evaluates each tool call against policy, with context about what is being requested and on whose authority, and no dependence on the model's cooperation. That is the AuthZEN-shaped design and it is why externalised authorization keeps appearing as the answer to otherwise unrelated agent problems.

The practical test: assume the injection succeeded completely and the agent is fully attacker-controlled. What can it do? That answer is your real risk position, and it is determined entirely by scope rather than by filtering.

Frequently asked questions

Why is prompt injection an identity problem rather than a content problem?

Because a successful injection involves no vulnerability, no stolen credential and no privilege gained. The agent uses permissions it legitimately holds, in response to input it was designed to process. The security question is therefore what the agent is authorised to do and in what context, which is a configuration you control, rather than whether malicious text can be detected, which has no stable answer.

Can prompt injection be prevented by filtering?

Not reliably, for three structural reasons independent of filter quality. The defender must anticipate every effective phrasing while the attacker needs one and moves last. An agent processing untrusted content is doing its job, so the input class cannot simply be refused. And injection arrives through retrieved documents, tool outputs, file contents and inter-agent messages, several of which a prompt-level filter never sees. Filter as a volume-reducing layer, not as the primary control.

What is the most effective control against prompt injection?

Per-invocation scope narrower than the agent's overall capability. If an agent receives authority only for the specific task at hand, a successful injection escalates to nothing because there is nothing to escalate to. This requires delegation to be modelled properly, with the agent's own identity separate from the authority it carries for a given task.

How does the confused deputy problem apply to AI agents?

Directly, with two aggravating factors. The instruction channel and the data channel are the same channel, so text in a retrieved document can function as an instruction and the classical separation is unavailable. And authority is usually ambient rather than per-task, so anything influencing the agent's behaviour inherits everything it can do. The historical mitigation applies: replace ambient authority with explicit, narrow, per-operation authority.

Where should the security boundary be for an agent?

At the authorization layer between the agent and every resource it touches, not at the model. The model is the thing being manipulated and cannot police its own manipulation, however it is instructed. An external policy decision point evaluating each tool call, with no dependence on the model's cooperation, is the only boundary that holds when the injection succeeds.

How do you assess prompt injection risk for a specific agent?

Assume the injection succeeded completely and the agent is fully attacker-controlled, then enumerate what it can do. That answer is the real risk position and it is determined by scope rather than by filtering. Run the same exercise separately for read and write authority, since most payloads seek an action rather than information.