When an AI agent’s valid token authorizes the wrong user’s data

Find where the agent borrows excessive authority

Consider a hypothetical assistant helping Alice find a document. Retrieved text contains a prompt injection that redirects the assistant to request Bob’s document, supplying Bob’s user identifier and a document identifier as tool arguments. The tool API accepts the agent’s application-only token and retrieves the object without checking Alice’s entitlement. The token can be valid while the request is unauthorized for Alice. The agent becomes a confused deputy because its application authority serves a request that exceeds the initiating user’s authority.

Microsoft distinguishes interactive agents operating on behalf of users from autonomous agents using application-only access without user context. That distinction should drive your architecture review. For each interactive tool route, identify whether the downstream credential represents the initiating user or only the application. Treat user and document identifiers in arguments as requested targets, not authenticated identity. This is a design recommendation: neither successful authentication nor an application’s permission establishes that the signed-in user may access the selected object.

Evidence: Authentication protocols in agents, Zero Trust Architecture, Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow

Carry user delegation into downstream calls

Microsoft’s standard on-behalf-of flow lets a middle-tier API exchange an incoming user access token for a downstream API token. The incoming token must target the middle tier; a token intended for another resource must be rejected. The middle tier authenticates itself, presents the user assertion, and receives the downstream token. OBO uses delegated scopes, not application roles, and works for user principals rather than application-only tokens. Microsoft also excludes middle-tier applications with custom signing keys. Prefer supported authentication libraries over manual protocol implementation.

Entra Agent ID adds a blueprint-to-child exchange before the delegated resource request. The client supplies a user token addressed to the blueprint. The blueprint uses its credential to obtain exchange token T1, and the child agent identity presents T1 together with the user token for OBO. Microsoft validates the user-token audience and T1’s linkage to the blueprint and child identity. Review those bindings explicitly. Do not substitute a resource-audienced token or assume an application-only credential can be converted into Alice’s delegated authority.

Evidence: Agent OAuth flows: On behalf of flow, Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow

Separate consent, credentials, and resource authorization

Agent entities cannot initiate interactive authorization flows or operate as public clients. A blueprint’s redirect URI supports consent only, not interactive token acquisition. Child identities require preauthorized delegated permissions and administrator-granted consent on the parent blueprint. Documented permission inheritance applies with FIC impersonation and stays within tenant boundaries. Verify these conditions before rollout. Microsoft prefers managed identities and recommends approved SDKs; it warns against production client secrets for blueprints. These choices support secure credential handling but do not authorize individual documents.

At the resource API, require an authorization decision for the authenticated user, requested object, and requested operation. Derive the caller’s identity from validated authentication context rather than a model-supplied user identifier. Check the resource’s access policy before returning data, including shared-resource rules where applicable; ownership equality alone may be insufficient. These are implementation recommendations, not automatic Entra guarantees. Delegated scopes identify permitted API access, but your resource still needs to decide whether this user may read or modify this particular object.

Evidence: Agent OAuth flows: On behalf of flow, Authentication protocols in agents, Zero Trust Architecture, Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow

Review the boundary, then test injected requests

Use a concrete review sequence. First, inventory interactive tool endpoints and identify every downstream token acquisition path. Next, verify audiences, delegated permissions, consent, and the user identity reaching the resource. Then inspect every lookup accepting user or document identifiers and locate its object-level authorization check. Finally, examine failure paths: recommend denying requests when delegated context is missing, rather than silently retrying with broader application authority. Keep autonomous application-only operations explicitly separate so an interactive request cannot inherit their privileges through fallback behavior.

For a hypothetical regression test, give Alice access to one document and deny her access to Bob’s document. Establish a permitted baseline, then place an instruction in retrieved content that asks the agent to substitute Bob’s identifiers. Also test the substituted arguments directly against the tool API, independent of model behavior. Expect authorized access to succeed and unauthorized access to fail at the resource. Recommend recording the principal, target, operation, and decision without storing tokens. A passing test demonstrates that case, not universal protection against prompt injection.

Evidence: Agent OAuth flows: On behalf of flow, Authentication protocols in agents, Zero Trust Architecture, Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow