What is Delegation?
Delegation gives an actor limited authority to act for another principal, called the subject. A sound delegation preserves both identities and limits the target, scope, and lifetime of the authority.
Why it matters
Without a clear subject and actor, a downstream service cannot tell who authorized an action and who performed it. This weakens least-privilege policy and audit records.
How it works
- Authenticate the subject and the actor.
- Evaluate whether the actor can receive the requested authority for the target resource.
- Issue and validate a restricted credential that identifies the subject, actor, audience, scope, and expiry.
Example
Alice authorizes a deployment agent to read one repository for one release. The repository sees Alice as the subject and the deployment agent as the actor.
Pomerium boundary
The Pomerium Model Context Protocol client pattern can pass an External Token for the authenticated user to a model API so that later tool calls retain that user identity and use the configured policy and audit path. This is a Pomerium pattern, not a claim that Pomerium emits RFC 8693 actor chains.
Limits and non-claims
- Delegation is not unrestricted impersonation.
- A token exchange does not create continuous revocation linkage between input and output tokens by itself.
- User consent does not replace authorization at the target service.
- Pomerium protects Model Context Protocol servers that use Streamable HTTP through a Pomerium route. It does not secure local stdio connections, the model runtime, tool code, or traffic that bypasses the route.
Evaluation checklist
- Who delegates to whom, and which resource, action, audience, purpose, and time limit apply?
- Does each downstream request preserve the original actor and current delegated subject?
- Can redelegation, token exchange, replay, or weak revocation widen the authority?
