Delegation lets a person, service, organization, or agent authorize another entity to act within defined limits. It is useful when work must cross boundaries—such as a customer connecting an application, a support engineer investigating a tenant issue, a supplier employee handling an order, or an agent assigning a subtask—without transferring unrestricted control. section 11.0 section 13.6.2 section 16.8.1 section 18.6
Delegation is constrained authority, not a new source of permission. A delegate can act only where its own request satisfies the underlying authorization policy and the delegation’s scope. Scope commonly identifies the delegate, permitted actions, allowed resources or tenant, purpose or relationship, and an expiration. Making these limits explicit prevents a delegate from expanding authority beyond what was approved. section 18.6.1 section 18.6.5
A secure delegation flow keeps the authorization decision separate from the act of assigning work:
- Create an approval, token, credential, relationship, or delegation record that states the granted scope rather than sharing a password or relying on implicit trust. section 11.2 section 18.6.1
- Have the policy enforcement point validate the credential and place its scope, identity, time limits, action, and resource into the authorization request. section 13.6.2 section 18.6.1
- Evaluate both guardrails and positive permissions. A request is denied when the caller is not the named delegate or exceeds the delegated action, resource, tenant, or time window. section 18.6.3 section 18.6.4
- Log and govern decisions so authority flows can be examined, adapted, and revoked as business relationships, employment, or conditions change. section 16.8.1 section 19.10
Time-limited support escalation
A support engineer requests access to a customer tenant for a specified time window. After manager approval, the portal issues a short-lived credential. The enforcement point validates it, confirms that it applies to that tenant and has not expired, then passes the request to the tenant policy decision point for its normal relationship-based access control checks. The support portal’s broad capability is not itself authority to access customer data; the approved credential supplies the bounded delegation. section 13.6.2
Delegating an agent subtask
A primary agent preparing a customer briefing can authorize a research subagent to search, read, and summarize documents for one customer until a stated expiration. The delegation record becomes policy input for every tool call. A policy can first forbid use by any principal other than the named subagent, then permit only listed actions against the allowed resource scope. Reading another customer’s documents or performing an unapproved action is denied. section 18.6 section 18.6.3 section 18.6.4
delegation_id: "d-1027" delegator: Agent::"acme_assist" delegate: Agent::"research_agent" delegatedActions: [ Action::"documents.search", Action::"documents.read", Action::"documents.summarize" ] resourceScope: CustomerDocs::"CustCo" expires: "2026-03-31T18:00Z"
This delegation record shows the minimum operational shape of structured authority: delegator, delegate, allowed actions, resource scope, and expiration. section 18.6.1
Delegation can be represented in several authorization models. OAuth uses revocable scopes for external API access. Relationship-based access control can derive access from changing organizational relationships. Verifiable credentials can carry employment and contract authority across supply chains. Policy-as-data records expose delegation attributes to runtime policy, while policy-as-code attaches narrowly scoped permissions to a role or principal. These approaches can combine with role-based and attribute-based controls rather than replace them. section 11.2 section 16.8.1 section 18.6.1 section 19.10
Operationally, delegation should be explicit, narrowly scoped, time-bounded where appropriate, and evaluated at runtime. Shared policy infrastructure makes it easier to apply those rules consistently across APIs, partners, services, and agents, while audit logs and governed identity or context signals make authority understandable and reviewable. This supports automation and collaboration without treating technical reachability, organizational status, or a prior trust relationship as blanket authorization. section 19.3 section 19.6 section 19.7
