What is Explicit Delegation?
Explicit delegation records a deliberate grant from a subject to an actor, including the audience, permitted actions, lifetime, and evidence of consent or another authorization decision. The issuer constrains the credential, and the design defines revocation or reauthorization. Each receiver verifies the recorded relationship instead of inferring authority from a shared credential or network location.
Why it matters
Explicit subject, actor, audience, and scope data reduces confused-deputy risk and gives policy engines useful facts for each decision.
How it works
- Authenticate the subject and actor. Record consent or another valid grant decision for a named audience and action set.
- Issue a constrained, short-lived credential that preserves the subject and actor and can be revoked or replaced under the delegation policy.
- Validate the credential, delegation evidence, audience, scope, expiry, and requested action at each protected boundary.
Example
A user approves a named Model Context Protocol client for read-only repository tools. The issued access is limited to that server, and each call can be tied to the user and client.
Pomerium boundary
Pomerium can keep upstream Model Context Protocol connections separate by user and apply identity and tool policy to protected Streamable HTTP requests. Pomerium logs authorization decisions, and operators can add Model Context Protocol fields for the method, tool name, and parameters. These controls can support an explicit delegation design.
Limits and non-claims
- Explicit delegation is an architecture term, not a named Model Context Protocol or NIST protocol.
- A shared credential or inferred user intent is not explicit delegation.
- Cryptographic binding depends on the credential and validation design.
- Initial consent does not prove that every later action is permitted.
- 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
- Does the grant preserve the actor, delegated subject, target, action, audience, and expiry?
- Can a delegate widen, chain, replay, or transfer the authority?
- Can the owner revoke the grant and trace each use to the original intent?
Sources and further reading
- RFC 8693 OAuth 2.0 Token ExchangeStandard
- RFC 8707 Resource IndicatorsStandard
- Model Context Protocol authorizationStandard
- Model Context Protocol security practicesDocumentation
- Pomerium Model Context Protocol supportPomerium documentation
- Protect a Model Context Protocol serverPomerium documentation
- Pomerium MCP observabilityPomerium documentation
- Pomerium MCP referencePomerium documentation
