Orchestration & Agentic Security · Agent Authorization, Delegation, and Continuous Enforcement
Pass the user's permissions down the chain
Verify that when an agent acts on a user's behalf, the runtime propagates an integrity-protected, scope-limited token that carries the user's authorization context and is enforced at every downstream call.
OWASP AISVS v1.01, requirement 9.5.2
In plain English
When an agent acts for a user, it should carry that user's permissions with it, in a protected token that every downstream service checks. Otherwise the agent acts with its own, usually much wider, access, and any user can reach data through it that they could not reach directly. This is the confused deputy problem.
What good looks like
- A signed, scope-limited token carries the user's identity and permissions through the chain.
- Every downstream service validates the token and applies the user's permissions.
- The token is narrowed for each downstream call, and the agent cannot widen it.
- Logs show both the user and the agent for each action.
How teams usually do it
- OAuth 2.0 token exchange (RFC 8693) to obtain a downstream token on behalf of the user, with the agent recorded as the actor.
- The on-behalf-of flow in your identity provider.
- Audience-restricted, short-lived tokens for each downstream service.
Suggested evidence
- The token flow design.
- Downstream validation code or configuration.
- A test where a user's request through the agent is refused for data that user cannot access directly.
Common mistakes
- Calling downstream services with the agent's own broad credentials.
- Passing the user's ID as a plain parameter, which an injection can change.
- Forwarding the user's original token everywhere, giving every service more than it needs.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.