Implementation Guide
Passing End-User Identity Through an AI Governance Proxy for Per-User Policy
To pass end-user identity through an AI governance proxy, have the proxy cryptographically validate the user's token at the edge, keep user identity, agent identity, and delegated authority as separate attributes, and issue a short-lived, narrowly scoped credential for each downstream hop, typically through OAuth 2.0 token exchange or a proxy-signed assertion. Do not forward client tokens unchanged and do not trust identity headers set by callers. Evaluate per-user policy from the validated attributes and record them in every audit entry.
Treat identity propagation as a chain of trust
Identity propagation works as a chain of trust across four hops. Each hop validates what it receives and passes on only what the next hop needs. The proxy validates the user's token at the edge, keeps user identity, agent identity, and delegated authority as separate attributes, and obtains a credential for each downstream hop.
Chain of trust across four hops
- ApplicationAuthenticates the user and presents a verifiable token.
- Governance proxyValidates the token, evaluates per-user policy, and obtains downstream credentials.
- ModelReceives only the context the policy allows for this user.
- MCP or tool serverAccepts a credential issued for its own audience and scoped to the user's delegated authority.
Three propagation patterns and their trade-offs
The three patterns compared here are JWT forwarding, token exchange, and signed assertions. The recommended approach issues a short-lived, narrowly scoped credential for each downstream hop, typically through OAuth 2.0 token exchange or a proxy-signed assertion.
| Pattern | How it handles identity | Guidance |
|---|---|---|
| JWT forwarding | Passes the client's token to downstream servers unchanged. | Do not forward client tokens unchanged. No downstream server should receive the client's original token. |
| Token exchange | Uses OAuth 2.0 token exchange to obtain a credential for each downstream hop. | Credential is short-lived and limited to one audience and scope. |
| Signed assertion | The proxy signs an assertion for each downstream hop. | Assertion is short-lived and narrowly scoped to the downstream audience. |
Failure modes to design against
Each of the following weakens the chain of trust. The validation criteria later in this guide test for them directly.
- Trusting identity headers set by callers. A request with a forged identity header and no valid token must be rejected.
- Accepting tokens that fail validation. A token with the wrong audience, issuer, or an expired lifetime must be rejected.
- Forwarding client tokens unchanged. Downstream servers should never receive the client's original token.
- Issuing broad or long-lived downstream credentials. Credentials should be short-lived and limited to one audience and scope.
- Merging identity attributes. User identity, agent identity, and delegated authority should stay separate so policy can distinguish between them.
Recommended implementation sequence
- Validate the token at the edge. The proxy cryptographically validates the user's token before doing anything else.
- Separate the attributes. Keep user identity, agent identity, and delegated authority as distinct attributes.
- Issue a credential for each downstream hop. Use OAuth 2.0 token exchange or a proxy-signed assertion to issue a short-lived, narrowly scoped credential.
- Evaluate per-user policy. Base each decision on the validated attributes.
- Record the attributes. Include them in every audit entry.
Evaluating per-user policy and recording it
The proxy evaluates per-user policy from the validated attributes, not from identity headers supplied by callers. Because user identity, agent identity, and delegated authority are separate, two users calling the same tool through the same agent can receive different policy decisions.
Every tool call then produces an audit entry that names the user, agent, delegation, and decision.
Validation criteria before rollout
- A request with a forged identity header and no valid token is rejected.
- A token with the wrong audience, issuer, or an expired lifetime is rejected.
- No downstream server receives the client's original token.
- Downstream credentials are short-lived and limited to one audience and scope.
- Two users calling the same tool through the same agent can receive different policy decisions.
- Every tool call produces an audit entry that names the user, agent, delegation, and decision.
Plan identity-aware policy for your AI proxy
Discuss how per-user policy enforcement and audit logging fit your existing identity provider and authorization architecture.
Talk to an Expert