Prompt Injection Proves Identity and Scopes Are Not Enough

A correctly authenticated and authorized AI agent can still perform the wrong action. Prompt injection proves it.

Every classical control may pass. The user is real. The token is valid. The audience and scope match. The API call is allowed. The failure occurs because untrusted content changed what the agent decided to do inside its legitimate authority.

Identity remains necessary. It is not an information-flow control.

The Supabase MCP case is the clean proof

In the documented Supabase MCP attack, an attacker submitted a support ticket containing instructions addressed to a coding agent. Later, a developer asked the agent to inspect the latest ticket.

The ticket told the agent to read secrets from an integration_tokens table and post them back into the support thread. The MCP server used a Supabase service_role, which bypasses Row-Level Security by design. The agent followed the injected instructions, ran extra SQL statements, and wrote the data where the attacker could read it.

No credential was stolen. The service role did what it was configured to do. The permissions were valid. The instruction was not.

Authentication answered a different question

Authentication can prove which developer launched the agent. Workload identity can prove which runtime executed it. OAuth can prove that the developer authorized the client to reach the MCP server.

None identifies the origin of each instruction in the model context. The agent may process a trusted system instruction, the developer’s request, a tool description, an attacker-written ticket, retrieved webpage text, and previous tool results together.

The model sees tokens. It does not enforce a label that says “this sentence may be summarized but must never authorize a database read.”

Scopes authorize capabilities, not causal intent

Suppose the agent has:

tickets.read
database.read
tickets.write

Each scope can be defensible alone. Together they form an exfiltration path: read untrusted instructions, access sensitive data, then write to an attacker-visible channel.

Simon Willison calls this the lethal trifecta: access to private data, exposure to untrusted content, and an external communication path.

OAuth scopes do not express “allow any two capabilities, but not all three in the same context.” A scope says the call is inside a permission boundary. It does not say the call is faithful to customer intent.

Detection cannot be the authorization boundary

Another model can classify prompts or calls as malicious. Detection can reduce risk. It cannot make the final decision for a high-impact action.

The 2025 paper The Attacker Moves Second, written by researchers across Google DeepMind, OpenAI, Anthropic, and ETH Zurich, tested twelve prompt-injection defenses. Adaptive attacks bypassed most at rates above 90%, including defenses originally reported near zero attack success.

Web security would not accept a control that fails one request in twenty. Agent security should not accept it because the classifier sounds intelligent.

Use detection as a risk signal. Do not let it authorize a transfer, secret export, permission change, or external message.

Tool discovery is part of the attack surface

Invariant Labs’ tool-poisoning research showed that malicious instructions can live in tool descriptions. The model consumes the full description while a UI may show only a name or shortened summary.

Trail of Bits’ line-jumping research showed attacks that act during tools/list, before the user invokes the malicious tool. A compromised server can influence how the agent uses another server’s tools.

This weakens approval tied only to a tool name. If the description changes, the same name can cause different behavior. Enforcement and audit should bind to a normalized tool-definition hash, not only the name.

Separate identity, authority, and information flow

Identity systems are strongest at the first layer and increasingly useful at the second. Prompt injection lives in the third.

A perfectly identified agent can still be manipulated. A broader consent screen fails for the same reason: the user authorized capabilities, not the attacker’s instruction.

Capability separation is available now

Until models reliably preserve instruction provenance, prevent dangerous capability combinations.

Meta’s Agents Rule of Two proposes that one agent session satisfy at most two of three conditions:

1. process untrustworthy input;
2. access sensitive data; and
3. change state or communicate externally.

If a workflow needs all three, split it across a supervised boundary or fresh context:

Context A: read untrusted tickets + produce structured summary
                         │
                         v
             deterministic validation / approval
                         │
                         v
Context B: query approved records, no external write tool

This costs latency and flexibility. It removes the one-step exfiltration path.

Task grants reduce blast radius, not prove intent

Task-scoped authority can constrain tools, arguments, use counts, and expiry. That sharply reduces exposure. It does not prove that an invocation reflects the customer’s original intent; an attacker may steer the agent inside the granted boundary.

This is why agent authority needs task scope, attenuation, attribution, and intent binding. The first three can be modeled today. Intent binding remains an open problem.

Hashing the initial prompt is not enough. Plans evolve, tool results add context, prompts contain sensitive data, and injection may appear several hops after the request. A cryptographic link proves which bytes were present, not which instructions the model should obey.

Approval must expose the real decision

When a human must approve an action, show security facts rather than a model-written reassurance:

• exact tool and immutable definition version;
• normalized destination, amount, or record count;
• data classification;
• principal, agent, and runtime identity;
• task-grant limits and remaining uses;
• instruction-provenance warnings; and
• policy reasons that triggered review.

Bind approval to an action digest and consume it once. If arguments, tool definition, policy, identity, or grant changes, require a new decision. Why consent screens fail for agent authorization describes this model.

Audit needs cause, not only action

A useful chain connects:

principal → agent/runtime → task grant/policy → tool-definition hash
          → input trust classification → action digest → approval → outcome

Do not copy full prompts, secrets, or results into a general audit store. Preserve identifiers, hashes, classifications, and decision evidence; keep sensitive payloads in the systems that own them.

This does not make model reasoning provable. It makes surrounding control decisions reconstructable.

The lesson is narrow and useful: a valid identity plus a valid permission does not prove valid intent. Build identity as the root of accountability, task authority to reduce possible action, and information-flow separation so untrusted content cannot assemble a path from sensitive input to consequential output.