The OAuth Scope Your Agent Inherited When On-Behalf-Of Quietly Became Act-As

The security review said the agent acts "on behalf of" the user. The OAuth token said something else, and the audit log agreed with the token.

A small distinction in language did a lot of architectural work nobody noticed. "On behalf of" is the language a security review reaches for when it wants to capture an arrangement where the agent is a delegate, recognizable as a delegate, and constrained by being a delegate. "Act as" is the runtime behavior when the agent holds a token indistinguishable from the user's own and is therefore the user as far as every downstream system can tell. These two phrases describe completely different threat models. A typical enterprise OAuth integration ships the second one and prices it as the first.

The gap shows up the first time something goes wrong. A prompt-injected instruction reaches the agent through an email it was asked to summarize. The agent does what the injection told it to do. The audit log records the user as the author. The investigation starts as a personnel review of the user before anyone asks whether an agent was in the loop, because nothing in the runtime trail says one was.

The Review Approved Delegation. The Token Approved Impersonation.

The pattern is consistent across integrations I've seen. A product team wires up an OAuth flow that grants the agent a token scoped to the user's identity. Security review reads the integration spec, sees "agent acts on behalf of the user," and approves it on the basis that downstream systems will be able to distinguish a delegated action from a direct one. The token that comes back from the IdP is a user-shaped token, the same shape the user would hold if they had logged in directly.

The downstream systems are not in the conversation. The calendar service, the email service, the document store — each of them validates the token, identifies the bearer as the user, and proceeds. There is no field on the token that says "this action was initiated by an agent." There is no header the downstream service is required to read. The audit trail records actions by user ID, because that's the only identity the request carries. The architectural intent that security review approved exists in the design doc and nowhere in the wire format.

This is the gap RFC 8693's actor (act) claim was written to close. The spec defines a JWT field that "provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated." A chain of delegation can be nested — outermost act is the current actor, inner claims preserve the chain. The IETF draft for OAuth's on-behalf-of extension for AI agents builds on this, adding parameters that carry the agent's identity through the consent screen and into the issued token. But these mechanisms only do work if the downstream system reads them, and most production services in 2026 don't.

The practical consequence is that "on behalf of" is a security claim, not a technical one, unless the token machinery enforces it. A team that grants an agent a user-shaped token has handed the user's full identity to a runtime whose decisions are made by a model that does not know it is impersonating someone.

Prompt Injection Turns the Impersonation Into an Incident

When the integration is benign, the gap is invisible. The agent does what the user asked it to do, the audit trail looks like the user did it, and that's broadly accurate. The architecture's failure mode shows up the first time the agent does something the user did not ask for — and the most reliable way to reach that mode in 2026 is prompt injection.

The threat model is well understood. The agent reads untrusted content as part of its work — an email body, a document, a calendar invitation, a webpage. The content contains an instruction. The model treats the instruction as part of its working context and follows it. The instruction can ask the agent to send an email, share a document, schedule a meeting, or call any other tool the agent's token is scoped to. The agent's token, being user-shaped, authorizes all of these actions without ceremony.

Three things happen in sequence:

1. The agent executes the injected action using the user's identity.
2. The downstream system logs the action as user-initiated.
3. The user's manager, or the security team, reviews the audit trail and sees the user as the actor.

Loading…