Overview

The Mission Is the Missing Abstraction defined the Mission and From a Request to an Approved Mission made its approval trustworthy. This part is where the approved Mission meets the agent identity stack: how authority is projected into tokens, how those tokens stay attributable to a specific agent instance acting for a specific user, and how authority flows down when one agent hands work to another.

The order matters for a reader arriving from the AI agent auth best practices. That work establishes the agent’s identity, credentials, and delegated user authority, and it expects the mission to have been translated into authorization requirements before the agent requests authorization. The translation happened in From a Request to an Approved Mission. What this part adds is the binding: the authority that came out of the approval, attached to the identity that draft established, in a form every downstream party can verify.

The projection: how authority rides the token

The Mission lives at the Authorization Server. What travels is a projection. Every token derived under a Mission carries a mission claim with three members: id, issuer, and authority_hash. The id and issuer say which governance record this credential serves and who holds it. The authority_hash commits the exact Authority Set the Approver saw, so a Resource Server can verify that the authority the token carries is a subset of what was approved without fetching the record. The token’s authorization_details carry the derived authority itself, and issuance is gated on Mission state: a Mission that is not active derives nothing, which is the possession-independent kill switch.

Three properties make the projection safe to rely on:

• The subset rule. Every derivation, refresh, exchange, and delegation yields authority that is equal to or narrower than the Mission’s Authority Set. Resources must match exactly, actions may only shrink, constraints may only tighten. Nothing derived ever exceeds what was approved.
• Sender constraint. Mission-bound tokens are bound to a key with DPoP or mutual TLS, so a stolen token is useless off the instance that earned it. The high-assurance tier in Mission-Bound Runtime Enforcement builds on exactly this property.
• Expiry capping. A derived token’s exp never exceeds the Mission’s expires_at, so the Mission’s clock transitively bounds every credential under it.

The issuance core is the normative detail, and this projection is the anchor of the protocol MVP: it depends only on ratified OAuth mechanics.

Which instance is acting

A projection is only as attributable as the identity it is bound to, and the default OAuth answer is not good enough for agent platforms. A platform runs thousands of concurrent agent instances under one client_id, so every session collapses into one identity at the Resource Server. Per-agent policy, audit attribution, incident response, and abuse containment all defeat themselves at that grain.

None of what follows is required for the minimum protocol MVP. A single-instance deployment with no delegation enforces Missions with the core alone, and the core confines its one reference to this substrate, the Actor Profile, to its OPTIONAL delegation capability. The substrate becomes necessary the moment work is delegated or instances multiply, which for an agent platform is immediately. Three composable profiles fix the attribution, and they are the identity substrate this series assumes rather than redefines:

• The Actor Profile standardizes the RFC 8693 act chain across assertion grants and JWT access tokens, so the decision and the audit record both see who is acting for whom, at every hop.
• The Client Instance Assertion identifies the specific client instance behind the shared client_id, with its own key, so instance-level policy and revocation become possible.
• The AI Agent Instance Profile adds what agents specifically need: an attester-minted instance identifier that survives key rotation, and provenance claims for the platform, model, and runtime environment.

The composition is the point. One Mission-bound token can now say: this authority derives from this approved task (mission), exercised by this attested agent instance (instance identifier and provenance), acting for this user (sub) through this delegation chain (act). Identity answers who. The Mission answers what for, and until when. The runtime layer (Mission-Bound Runtime Enforcement) evaluates all of it together on every consequential action.

Two hard problems remain once the token is attributable. The authority has to cross authorization domains without losing its binding, and it has to flow down to delegates without becoming ambient. The rest of this part takes them in turn.

Crossing authorization domains

The running example never fit inside one authorization domain. The finance, docs, and workflow systems can each sit behind their own Authorization Server, and a Mission held at one AS is worthless at the others unless something carries it across. The base profile deliberately stops at the issuing AS’s edge. Mission Cross-Domain Projection is the optional capability that crosses it, in exactly one hop.

The model preserves everything the projection already established. The Mission Issuer issues a cross-domain grant under the OAuth identity chaining architecture, with the Identity Assertion Authorization Grant (ID-JAG) as the recommended profile. The grant is short-lived (capped at 300 seconds), sender-constrained, and audience-scoped, carrying only the Authority Set entries relevant to the target domain under the same subset rule that governs every other derivation. The Resource AS validates the grant and mints its own local tokens, and the mission claim rides through unchanged. One Mission, one mission.id and mission.issuer, joining issuance, enforcement, and audit across every domain it touches.

The honesty is about revocation. Single-domain revocation is prompt, because the AS that issued a token also honors its revocation. Cross-domain is strictly weaker. The Mission Issuer can stop issuing new grants the moment a Mission is revoked, but it cannot reach a local token another domain already minted, so cross-domain revocation latency is the downstream token lifetime. That is why the draft requires Resource ASes to keep local Mission-bound tokens short-lived, why the grant lifetime is capped, and why the Status and Signals surfaces (Mission Lifecycle and Change) matter across domains. They are built for exactly the consumer that holds a mission_id and no token the issuer ever minted.

On the adoption ladder this sits on the advanced tier: stable design to adopt when the use case arrives, with its dependencies tracked honestly. As of July 2026, the identity-chaining work it profiles is approved and in the RFC Editor queue, ID-JAG is a working-group document, and the profile should not advance ahead of that substrate. Single-domain deployments of the protocol MVP are unaffected by it entirely.

Fan-out: the threat of authority by ancestry

A real agent does not stay a single actor. It decomposes the task: a research sub-agent, an extraction worker, a reviewer, each with its own session, queue, and tool handles. Every one of them needs some authority to do its slice, and every one of them is a place where the user’s approved task can quietly turn into more authority than the user ever saw. The Mission Is the Missing Abstraction committed the rule that keeps this from happening. Authority can only narrow. This part makes that rule true across fan-out, across the moment one agent hands work to another.

Here is the failure mode it must prevent. A parent agent, running under an active Mission, spawns a sub-agent. The sub-agent makes a consequential call. Why was it allowed? Because it descended from the parent. It shares the parent’s session, perhaps a cached tool connection, perhaps the parent’s token sitting in shared memory.

That is authority by ancestry, and it is the primary threat the Child Delegation draft names. It is dangerous precisely because it is the convenient default. The harness already has the parent’s credentials in hand, so handing them to a child is a one-liner. Nothing widened on paper. The child is “inside” an active Mission. And yet the user approved a board-packet task, not a board-packet task plus whatever every sub-agent the model decided to spawn can reach with the parent’s full token.

Session continuity is a runtime property. It can prove the sub-agent is part of the same execution. It cannot prove the sub-agent is authorized.

The rule, stated plainly: a child actor needs explicit, narrower authority, not session ancestry. A sub-agent handle is not a credential. Spawning is not delegation. Every mechanism below is a way to give a child explicit authority that is provably a subset of the parent’s and that stops when the parent does, and to make that the only path, so the ancestry shortcut is never available.

What the core already gives you

Before reaching for new machinery, note what the issuance core already covers. The core supports delegated Mission-bound tokens. Authority narrows down a delegation chain, and the chain records actor context through RFC 8693 token exchange and the act claim. This is in-Mission delegation. It extends a single Mission’s act chain to additional actors, bounded by each authority entry’s per-entry delegation policy. No new Mission is created. The work is still exercised under the original Mission.

That is the right tool when the delegate does its work within the lifetime and operational control of the delegating flow: a synchronous hand-off, a downstream service call, a delegate that finishes before the parent moves on.

The two mechanisms in this part exist for the case the act chain does not cover: a sub-agent with a durable task of its own. A child with its own queue, its own background jobs, its own harness session, its own audit lifecycle (work that outlives the call frame that spawned it). For that, the child needs more than an entry on someone else’s chain. It needs its own authority handle, or its own narrowed token, depending on the tradeoff you are making.

The act chain is the baseline. The rest of this post is the two new mechanisms. They answer the same question with different cost profiles.

Mechanism 1: the Child Mission

A Child Mission (Mission Child Delegation) is the answer when a sub-agent needs its own durable, separately revocable Mission. It is an ordinary Mission under the issuance profile with two additions: it is created under a parent grant rather than a first-party approval, and its record and tokens carry a parent member that records lineage. It has its own mission_id, its own actor identity, its own lifecycle, and its own act chain that restarts at depth zero. But it cannot outlive, out-broaden, or escape its parent.

Five properties make that true, and they are worth holding together because each closes a different gap.

Explicit creation, never inheritance. A Child Mission is created by submitting a Mission Intent through Pushed Authorization Requests, exactly like a first-party Mission, plus three required things: the parent Mission identifier, a parent_token (a refresh token or other grant bound to the parent Mission), and a child_actor identifying who will hold the child. Critically, the Authorization Server resolves the parent from the parent_token, not from the parent identifier. The identifier is a cross-check and audit value only. Naming a parent you do not control gets you nothing. You have to present a grant for it. This is what makes “child by session ancestry” impossible. There is no path to a Child Mission that does not run through an explicit, authenticated, back-channel request carrying a real parent grant.

Subset authority. Every child authority entry must be a subset of a parent entry under the same narrow-only subset rule the core uses for any derived token. The child entry’s resource must equal a parent entry’s resource exactly (the core defers ideas like resource containment to future work), its actions must be a subset, and its constraints may only tighten, so an entry may match the parent exactly. The child cannot add a resource, an action, or a constraint relaxation the parent lacks. The per-entry delegation policy must not be broader either: max_depth no greater, allowed_delegates no wider. “Strict” in the strict-subset rule means no relaxation anywhere, not inequality. The Authorization Server computes the child’s authority_hash over the child’s Authority Set. That hash is the authority commitment a Resource Server enforces against. The parent member’s authority_hash is lineage data, not authority. It records which parent commitment the child was derived under, for audit.

Expiry no later than the parent. The child’s expires_at must not be later than the parent’s. Because Mission expiry transitively caps every derived token’s exp, a child can never hand out a token that outlives the parent Mission’s clock.

Fan-out controls. This is the non-obvious one. Depth limits do not control breadth. A parent can authorize many children at the same depth, each a perfect subset, and the aggregate still amplifies authority. Twenty read-only sub-agents are a different risk than one. So child creation is off by default. The on-switch is a children object inside the parent entry’s per-entry delegation member, and an entry whose delegation carries no children permits no child at all (the denial reason is delegation_not_permitted). The children object then carries the controls the issuer must enforce: a cap on concurrently non-terminal children (max_children), a constraint on which actors may receive them (allowed_child_actors), a generation limit (max_child_depth, default 1), and a policy evaluated before each creation (child_creation_policy). An issuer that cannot enforce a control an entry carries refuses creation. Breadth is bounded explicitly, not as a side effect of depth.

Cascade revocation. A Child Mission depends on its parent. Any transition of the parent to a non-active state is the cascade trigger. Terminal triggers (parent revoked, expired, completed, superseded, or itself cascaded) stop new derivation under dependent children and, under immediate cascade, drive each child to a terminal cascaded state (distinct from revoked and expired so audit can tell a cascade-terminated child from a directly terminated one). Cascade is transitive. The children of a cascaded parent cascade in turn, in generation order. The one reversible trigger is suspended. Derivation stops while the parent is paused, but the children are not terminated, and they return to their prior state when the parent resumes. The through-line: a child dies with its parent.

The running example. The parent Mission for “prepare the Q3 board packet” (Reference and Glossary) holds query_financials, create_doc, and notify_reviewer. The orchestrator spawns a sub-agent just to gather the financials, under a Child Mission whose Authority Set is a strict subset of the parent’s: query_financials only (no create_doc, no notify_reviewer), with expires_at no later than the parent’s and the parent’s mission_id recorded in the child’s parent member. The sub-agent has exactly the read it needs and nothing else. It cannot write the doc or notify anyone. When the board meeting is cancelled and the parent Mission is revoked, the child is cascade-revoked to the terminal cascaded state, fails its next runtime state check, and the sub-agent stops too.

One clean separation worth stating: a Child Mission is not Mission Expansion. Expansion (Mission Lifecycle and Change) creates a successor Mission with broader authority by fresh approval. A Child Mission creates a dependent Mission with narrower authority. They move in opposite directions and must never be conflated. (A superseded parent, in fact, is a terminal cascade trigger. The successor carries a freshly derived Authority Set, so a child that was a subset of the predecessor is not guaranteed to be a subset of the successor. Continuing child work requires explicit re-creation under a successor grant, which re-runs subset validation.)

Mechanism 2: offline attenuation

The Child Mission puts the Authorization Server on the path of every delegation, which is exactly what you want when you want the issuer to see and own each one. But for deep sub-agent fan-out, the common agent topology, that makes the Authorization Server a per-delegation latency and availability dependency on the execution hot path. Every narrowing is a round-trip to the issuer.

Offline attenuation (Mission Offline Attenuation) removes the issuer from that path. It profiles Attenuating Agent Tokens so that a Mission-bound token holder can mint a narrower child token offline, with no Authorization Server contact. The holder selects a narrower tool and constraint set, increments the delegation depth, signs the child with the key the parent token’s cnf binds, and commits to the parent by hash. The child is valid by its signature chain.

One caveat the convenience hides: offline minting is unobserved by the issuer. A del_max_depth on the chain caps how deep the narrowing can go, but there is no offline equivalent of the Child Mission’s max_children. Nothing on this path bounds breadth. A holder can mint as many narrower siblings as it likes, unseen by the issuer, so breadth must be bounded by deployment policy rather than by the substrate.

The Mission binding is what makes this safe rather than a new way to leak bearer tokens, and the draft requires three things together:

The mission claim rides the chain unchanged. Every token in the chain, root and every offline-minted descendant, carries the same id, issuer, and authority_hash as the root. A child cannot re-bind to a different Mission or change the lineage anchor. A consumer that sees a link whose mission claim differs from the root’s (or that omits it) must refuse the whole chain, not treat it as a narrower grant. Here authority_hash is purely a lineage anchor. It still commits the root Mission’s Authority Set, while the child’s real authority is its own carried, narrower constraints. (Contrast the Child Mission, where the child computes its own authority_hash. Offline children never do. The root’s rides along.)

The narrowing is verifiable from the carried chain. Because each child carries its parent chain, a consumer holding only the leaf token and its chain can verify that the leaf is a subset of the root (checking signature linkage, capability monotonicity, and depth) without holding the Mission’s full Authority Set. The narrowing proves itself.

The kill switch is delivered by the runtime layer, not the token. This is the point everything else rests on. The attenuation substrate defines no revocation of its own. Once minted, an offline child is valid until its exp, and no issuer can reach it. So the Mission kill switch is not automatic for offline children. It is delivered only by the runtime enforcement layer. On every presentation of a token in the chain, regardless of action class, the consumer must establish that the chain’s Mission is active, within the deployment’s declared freshness bound, from a Mission state source, in addition to verifying the chain and the proof-of-possession. It fails closed when the state source is unreachable, and a cached chain is re-checked on every presentation. A revoked or expired Mission causes refusal of every token in the chain, regardless of any child’s own exp.

When alice revokes the Mission, the next action fails the state check and the whole chain stops, even though no issuer ever saw the children and their tokens have not expired.

This is why offline attenuation is only safe on runtime-enforced paths. It is not available to a deployment that relies on token lifetime alone. Without the runtime state check, an offline chain is ungoverned bearer authority until it ages out, which defeats the entire purpose of binding it to a Mission. A deployment must not accept Mission-bound attenuation tokens on a path that does not enforce current Mission state.

A residual risk survives even all three requirements: a compromised holder key. Whoever holds the parent token’s confirmation key can mint any narrower child offline and unobserved. There is no issuer round-trip to deny. The only bounds are narrow-only (capability monotonicity means the attacker can never broaden authority) and the runtime layer re-checking Mission state on every action, so revoking the Mission still stops every child the compromised holder minted. The compromise can fan out narrower children, but it cannot widen authority or evade the kill switch.

Choosing which to use

Both mechanisms narrow. Neither widens. The choice between them is a tradeoff between central control and scale, and the suite offers offline attenuation alongside Authorization-Server-mediated delegation, not instead of it.

The decision is not “which is more secure.” Both rest on the same narrow-only rule and the same kill switch. For the Child Mission, cascade revocation propagates from the issuer under immediate mode, while the bounded_staleness and status_required modes push a parent-state check onto the consumer. For offline attenuation, the runtime layer re-checks state at use. The decision is where you can afford to spend a round-trip. If you want the issuer to observe and own every delegation, and the latency is acceptable, mediate it. If issuer round-trips are the bottleneck on a deep fan-out, mint offline and let the runtime layer carry the kill switch. Maturity is a decision factor too. AS-mediated delegation depends only on ratified OAuth and is the stable path, while offline attenuation is labeled experimental because its substrate, Attenuating Agent Tokens, is an in-progress draft. Adopt it for evaluation. A single deployment can do both: a Child Mission for the durable reviewer sub-agent, offline attenuation for the swarm of short-lived extraction workers under it.

The through-line

Fan-out is where the convenient thing and the correct thing diverge most sharply. The convenient thing is to let a sub-agent act because it descends from a parent. It costs nothing, widens nothing on paper, and is wrong. The correct thing is to make the child’s authority explicit, narrower, and bounded by the parent’s lifetime, so that there is no ancestry shortcut to take.

Three invariants hold across both mechanisms, and they are the same three that have held since The Mission Is the Missing Abstraction:

• Authority can only narrow. A child is a strict subset of its parent: by subset validation at the issuer for a Child Mission, by capability monotonicity on the chain for offline attenuation. Neither path can broaden. Widening is Expansion (Mission Lifecycle and Change), a fresh approval, not a delegation.
• Delegation never widens. Spawning a sub-agent does not create authority. A handle is not a credential. The only way down is an explicit, narrower grant.
• A child is bounded by the parent and dies with it. Cascade revocation for a Child Mission (issuer-driven under immediate, consumer-checked under bounded_staleness or status_required). The runtime Mission-state check for an offline chain. When the Mission goes non-active, every dependent and every descendant stops.

That last invariant is the whole kill switch, projected onto fan-out. Revoking one Mission stops the parent, its children, and their children at once, whether the issuer minted them or a holder did. The agent runtime and audit is what makes that true inside a running harness. It binds the sub-agent handles, queues, and sessions to Mission state so that “the Mission stopped” actually reaches the work in flight.