🧪 Beta — Available today; the interface contract may still change. This is a mixed page: the three-way intersection and subtract-only attenuation sections cover roadmap capabilities and are badged separately inside those sections.

Delegate Token and attenuation

A Delegate Token is a verifiable, time-boxed authorization credential — it records which user granted which permissions to which agent, and for how long. It is a JWT (RFC 7519): self-contained and verifiable offline, so who signed it, who it was issued to, and when it expires are all stated by the token itself.

Why not just hand over the credential

Giving an agent a password or a long-lived API key means giving away the whole identity: permissions too broad, actor indistinguishable, nothing to take back. This is the question the classic OAuth client model (RFC 6749) never answered for agents — it assumes an "application" whose behavior is fixed at design time, while an agent reasons at runtime and needs different permissions for every task.

The Delegate Token flips the direction: what the agent receives is not your identity, but an attenuated, time-boxed, revocable slice of authorization. Zhang San asks a reporting agent for the weekly report, and the agent gets "read-only, report endpoints only, two hours" instead of Zhang San's account. Task over, slice expired, nothing left behind.

Three-way intersection: where the agent's permissions come from

🚧 Roadmap — The capability described in this section is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.

How much power a delegation can cash out is not any single party's call:

The agent's effective permissions = the person's real permissions ∩ the explicitly delegated scope ∩ the enterprise-approved boundary

Set	Who defines it	When it's checked
The person's real permissions	Your existing identity system (Human IAM)	Evaluated before issuance — hop ③ of the main sequence: you cannot delegate a permission you don't have
The explicitly delegated scope	The user, by checking boxes on the consent page	Written into the Delegate Token at issuance
The enterprise-approved boundary	Admins, on agent templates and policies	Verified at issuance and at exchange

Drop any one of the three and the model has a hole. Without the first, employees can "generously" hand out permissions they never had. Without the second, authorization loses the user's informed consent. Without the third, the enterprise's governance over agents is theater.

Attenuation only subtracts

🚧 Roadmap — The capability described in this section is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.

Attenuation is the one-way valve running through the whole chain: as permissions travel from person → agent → resource access token → next hop, each hop can only narrow, never widen.

• The delegated scope ⊆ the person's real permissions (the delegation hop);
• The exchanged access token's scope ⊆ the Delegate Token's scope (the exchange hop);
• Along a multi-hop chain, what each agent receives ⊆ the previous hop (see the multi-hop section of Three access patterns).

This is not a GenAuth house rule. The IETF AAT draft (Attenuating Agent Tokens) is standardizing exactly this hop-by-hop decay of agent tokens — attenuation is where agent authorization is heading as a standard, and GenAuth's design aligns with it.

Lifecycle: issue, use, terminate

A Delegate Token's life has three parts:

1. Issuance — two paths: user-level consent (interactive, where the user approves on the consent page in person) or organization-level consent (the trusted server-side path, where an org admin has consented in advance on the organization's behalf). Positioning and boundaries for both are in Consent and approval. Issuance assigns grant_id and audit_id, and the audit chain starts at that moment (see Audit and accountability chain).
2. Use — a Delegate Token never accesses resources directly; it is first exchanged for an access token (next section).
3. Termination — natural expiry (validity of 60–86400 seconds; set it as tight as the job allows), or active revocation. The revocation layers and how quickly each takes effect are recorded honestly in Revocation and emergency response.

Token exchange: a Delegate Token doesn't open doors

A Delegate Token is proof of authorization, not a key for access. To reach a resource, the agent first exchanges it (token exchange, RFC 8693) for an access token for the target resource. This is hops ④⑤ of the main sequence (full diagram in The full journey of one delegation and End-to-end business sequence):

1. Issuance (responsible parties: User × GenAuth, hop ④) — after the user approves, GenAuth issues the Delegate Token. Its audience (aud) is not any business resource but GenAuth's own exchange service: this token can only be traded in, never used to open a door.
2. Start the exchange (Agent → GenAuth, hop ⑤) — the agent presents the Delegate Token and declares the target resource and the scopes it needs.
3. Verify and mint (GenAuth, hop ⑤) — GenAuth validates the Delegate Token's validity and state, intersects the requested scope with the delegated scope, and mints an access token for the target resource: sub = user, act = agent, aud = target resource.
4. Constrained access (Agent → App, hop ⑥) — the agent calls the resource with the access token, and the resource side validates sub / act / scope before returning only data inside the granted scope. How to do that validation is in Protect your APIs: resource-side integration.

Why split this into two token types? Three reasons. Audience binding — one access token is valid for one resource, so stealing it opens no other doors. Policy re-evaluation — every exchange is a live decision point: if the Delegate Token has expired, the key that issued it has been disabled, or the requested scope exceeds the grant, the exchange fails on the spot. Audit continuity — audit_id carries from issuance through exchange and access, one unbroken line (see Audit and accountability chain).

The two tokens at a glance

Delegate Token (illustrative excerpt):

{
  "sub": "usr_demo_0001",
  "agent_id": "report-agent",
  "scope": ["webagent.web_search:run", "webagent.web_search:read"],
  "audit_id": "audit_demo_7f3a2c41"
}

Note: a Delegate Token has no act field — it records an authorization relationship, and no action has happened yet.

The access token after the exchange (illustrative excerpt):

{
  "sub": "usr_demo_0001",
  "act": { "type": "eak_delegation", "agent_id": "report-agent" },
  "scope": ["webagent.web_search:read"],
  "exchange_id": "exch_demo_2b91d4"
}

act is a GenAuth extension structure (not RFC 8693's standard nested-sub form of act). Parsing notes for the resource side and the full field tables for both tokens are in Token and claims reference. In the example, scope narrows from run + read to just read — that is attenuation doing its work during the exchange.

Standards and protocols

• RFC 8693 (OAuth 2.0 Token Exchange) — the protocol base for token exchange and delegation semantics; GenAuth implements its exchange flow with an extended act structure (annotated in Token and claims reference).
• RFC 7519 (JSON Web Token) — the carrier format for both Delegate Tokens and access tokens; implemented by GenAuth.
• RFC 6749 (OAuth 2.0 Authorization Framework) — the foundation of the whole authorization system; the delegation model is its client authorization evolved for agent scenarios.
• IETF AAT draft (Attenuating Agent Tokens) — the standardization direction for "each hop only narrows"; GenAuth's attenuation design aligns with it.
• ID-JAG / XAA — parallel evolution paths for cross-application authorization assertions; GenAuth declares a compatibility roadmap.

Next steps

• Reference: Token and claims reference — the full field contract for both tokens
• Guide: Call your APIs on behalf of a user — issuance and exchange in code
• Concept: Consent and approval — how an authorization slice gets consented to in the first place