🧪 Beta — Available today; the interface contract may still change. This is a mixed page: the multi-hop delegation section covers a roadmap capability and is badged separately inside that section.
Three access patterns
Access patterns answer the two questions no authorization system can avoid: for this action, whose account does it go on (who is the token's subject) and whose rules apply (whom is policy evaluated against). GenAuth sorts agent action into three patterns: the delegated pattern that acts on behalf of the user, the autonomous pattern where the agent acts as itself, and multi-hop delegation where an agent calls another agent.
Why an agent needs it
One key for everything is the most common wrong start in agent authorization. Record every agent action as "some user did this" and audit goes blind — after an incident you can't tell the person from the agent. Treat every action as "a service running a batch job" and permissions go out of control — user data gets touched by an identity that represents no user, and afterward you can neither name the authorizer nor draw a boundary.
The three patterns aren't three systems. They are three subject arrangements inside one identity and token system. Pick the right pattern and the subject and policy target land correctly on their own; pick the wrong one and authorization, audit, and revocation are all misaligned behind it.
One table, three patterns
| Pattern | Token subject | How the actor is identified | Whom policy applies to | Is there a delegator? | Status |
|---|---|---|---|---|---|
| Delegated (on-behalf-of) | The user (sub = user) | The access token from the exchange marks the agent in act | This delegation: the scope and lifetime the user consented to, layered with the agent identity and template boundary | Yes | 🧪 Beta |
| Autonomous | The agent itself (sub = agent) | The subject is the actor; no act | The agent identity and the policy on its template | No — but it has responsible people | 🧪 Beta |
| Multi-hop delegation | The original user | An act chain records each hop | Each hop is evaluated independently; scope only narrows | Yes, preserved across hops | 🚧 Roadmap |
Delegated: acting on behalf of the user
🧪 Beta — This section's capability is available today; the interface contract may still change.
The user hands a task to the agent and, at the same time, explicitly cedes the small slice of permission the task needs. This is GenAuth's main pattern, corresponding to hops ②–⑥ of the main sequence (full diagram in The full journey of one delegation).
Who the token's subject is: always the user. The Delegate Token's sub is the user; after the exchange, the access token's sub is still the user, with act marking which agent is the actual actor. That's how audit can answer both "under whose identity" and "who did it" — precisely what borrowing a user account can't do.
Whom policy applies to: to "this delegation." The scope and lifetime the user approved on the consent page are written into the token; the agent identity and template boundary constrain it as well; and above all of that sits the ceiling of the user's own real permissions. How the three intersect and when each is checked is in Delegate Token and attenuation.
Typical scenario: an employee data assistant. Zhang San in sales ops asks a reporting agent for last week's customer report, and the agent gets a slice that says "read-only, report endpoints only, two hours" — not Zhang San's account. Full story in Employee data assistant.
Flow skeleton (with responsible parties): the user hands off the task and approves (User, hop ②) → GenAuth issues the Delegate Token (GenAuth, hop ④) → the agent exchanges it for an access token for the target resource (Agent × GenAuth, hop ⑤) → the resource side validates sub / act / scope and allows the call (App, hop ⑥).
Autonomous: acting as itself
🧪 Beta — This section's capability is available today; the interface contract may still change.
Some agents represent no user at all: scheduled reconciliation, batch processing, internal service inspection. They act under their own first-class identity.
Who the token's subject is: the agent. The token's sub is the agent identity, and there is no act — subject and actor are the same thing.
Whom policy applies to: the agent identity and its template. What it can access is decided entirely by the boundary the enterprise drew during registration and approval (see Agent identity model); there is no user-consent step.
No delegator does not mean no responsible person. An autonomous agent still registers an Owner and a Sponsor, still enters the registry, still goes through approval, and can still be killed. Typical scenario in Unattended scheduled agent.
Autonomous is not a shortcut around delegated
Any action that touches a specific user's data should go through the delegated pattern, keeping the user's consent in the chain. Using an autonomous agent's broad identity to touch user data leaves the "who authorized this" column permanently blank — and neither audit nor compliance will accept that.
Multi-hop delegation: agent calling agent
🚧 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.
In complex tasks, a supervising agent splits subtasks out to specialist agents: a travel agent calls a booking agent, which calls a payment-lookup agent. The delegation relationship travels across hops, and two rules must hold:
- The subject does not drift: however long the chain, the token's
subis always the user who started the delegation; each hop's actor is appended to theactchain, and the full delegation chain can be replayed. - Scope only narrows: each hop receives a subset of the previous hop, subtracting only — that is attenuation. Every agent authenticates independently, and passing the previous hop's token through verbatim is forbidden.
Whom policy applies to: each hop. Every handoff is an independent policy evaluation point, so if any agent in the chain is disabled or steps outside its boundary, the chain breaks at that hop.
How to choose
Three questions, in order:
- Does this action touch a specific user's data or permissions? If yes — delegated.
- Is no user involved at all, with only the agent's own approved resources in play? If yes — autonomous.
- Is there a second agent in the chain? If yes — multi-hop delegation, and every hop still has to answer the first two questions.
Standards and protocols
- RFC 8693 (OAuth 2.0 Token Exchange) — the protocol origin of the actor (
act) semantics used in delegated and multi-hop scenarios; GenAuth implements its exchange flow with an extendedactstructure (see Token and claims reference). - RFC 6749 (OAuth 2.0) — the protocol prototype for the autonomous pattern is the client credentials grant: an application obtains a token as itself; GenAuth layers first-class agent identity and governance on top.
- IETF AAT draft (Attenuating Agent Tokens) — the standardization direction for "each hop only narrows" in multi-hop; GenAuth's multi-hop design aligns with it.
Next steps
- Scenario: Employee data assistant — the delegated pattern end to end
- Guide: Call your APIs on behalf of a user — the delegated pattern in code
- Reference: Token and claims reference — the field contract for
subandact