Preventing Confused Deputy Attacks in Agentic AI Systems with Identity Propagation

Understanding the Confused Deputy Problem in AI Agents

The "Confused Deputy" is a security vulnerability where a legitimate program (the "deputy") with excessive privileges is tricked by a less privileged entity into misusing its authority, often to access or manipulate resources it shouldn't. In the context of AI agents, this typically occurs when an agent is granted a broad service principal with wide read/write access to backend systems (e.g., an HR system). When a user requests sensitive information, the agent, acting on its extensive permissions, might retrieve and expose data that the requesting user themselves is not authorized to see, simply because the agent's credentials allow it.

The Solution: Identity Propagation with OAuth 2.0 On-Behalf-Of Flow

1. User Identity Carried: The execution run must carry the authenticated user's identity.
2. Short-Lived Token Exchange: Before each tool call, the agent's harness exchanges the user's identity for a short-lived token. This token is scoped precisely to the *tool's audience* and its *required scopes* using the OAuth 2.0 on-behalf-of (RFC 8693) flow.
3. Downstream Authorization: The downstream system then authorizes the token, not the agent. It filters access based on the token's subject (the actual user), ensuring that authorization is enforced by the data owner, not by the agent's logic.

This mechanism ensures that the agent cannot over-share because it never possesses a credential that grants it more access than the requesting user. Authorization responsibility shifts from the agent to the data-owning service, which already has robust authorization capabilities. This directly addresses OWASP ASI03 (Identity and Privilege Abuse) and ASI07 (Privilege Escalation across agents in multi-agent systems).

Key Design Decisions for Robust Identity Propagation

• Token Subject is Human, Actor is Agent: RFC 8693 correctly models this with `sub=mallory, act=agent`, providing clear audit trails.
• IdP Grants User's Subset of Permissions: The Identity Provider (IdP) issues tokens with only the permissions the *user* legitimately holds, even if the agent requests broader scopes. This allows one tool to serve users of varying privilege without complex role-based branching within the agent, which could be vulnerable to prompt injection.
• Credential Seclusion: The delegated credential should never appear in the tool's schema or be accessible to the AI model itself. It should travel in a request-scoped context variable (e.g., a `ContextVar` in Python), preventing the model from seeing, forging, or leaking it.
• No Ambient Credentials: Each tool call should be explicitly delegated. Calling an undelegated tool must clear any previous context variable to prevent a narrow grant from silently becoming a wider one.
• Short TTL, Single Audience: Tokens should have a short Time-To-Live (e.g., 5 minutes) and be specific to a single audience (e.g., `hr-system`), minimizing the blast radius if compromised.
• IdP Enforcement for Unknown Users: The IdP must refuse to mint authority for users who lack entitlements, ensuring the agent cannot bypass policy through misdirection.

Trade-offs and Considerations

While effective, this pattern introduces trade-offs. It adds latency due to the token exchange per tool call and creates a hard dependency on the IdP. Caching can mitigate latency, but careful invalidation is needed for revocation. Additionally, long-running agent sessions might outlive their tokens, requiring re-authentication or token refreshing, which could expose changes in user entitlements. It is also crucial to leverage existing IdP solutions (e.g., Entra ID, Okta, Auth0) for token exchange rather than implementing a custom solution, which is prone to security vulnerabilities.