---
title: "Mission-Bound Authority: Instances, Actors, and Delegation"
date: "2026-06-06T14:00:00-07:00"
lastmod: "2026-06-06T14:00:00-07:00"
description: "Agent authentication answers who is acting. The Mission answers what the acting is for. This part is the bridge: the mission claim on tokens bound to attested agent instances, the actor chain that records who acts for whom, the cross-domain grant that lets another Authorization Server honor the Mission, and delegation that only narrows, from act chains to Child Missions to offline attenuation."
summary: "The AI agent auth best practices give an agent workload identity, credentials, and delegated user authority. This part binds Mission authority to that identity. The mission claim projects the approved task into every derived token, attested instance identifiers and actor chains keep every actor attributable, and delegated work gets explicit, narrower, separately revocable authority. A sub-agent that acts because it descends from a parent session is inheriting ambient authority, not delegated authority. Child Missions give durable sub-agents their own revocable handles with strict-subset authority and cascade revocation. Offline attenuation, the experimental roadmap for fan-out at scale, keeps the Authorization Server off the hot path with the runtime state check as the surviving kill switch."
slug: "mission-sub-agents-and-delegation"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Intent-Based Authorization"
  - "AuthZEN"
  - "Internet-Draft"
series:
  - "building-mission-bound-authorization"
---


{{< spine steps="authority" >}}

{{< tldr >}}

- **The question.** [AI Agent Authentication and Authorization](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) establishes who the agent is and how it authenticates. This part answers how Mission authority attaches to that identity, and how it flows *down* when agents spawn agents without becoming inherited, ambient authority. A child gets explicit, narrower authority that dies with its parent, and a child is *never* created by session ancestry alone.
- **What lives in this post.** [How authority rides the token](#the-projection-how-authority-rides-the-token) and [which instance is acting](#which-instance-is-acting), the bridge from agent identity to Mission authority. [Crossing authorization domains](#crossing-authorization-domains), where one Mission is honored by an Authorization Server that did not issue it. Then fan-out: the [authority-by-ancestry threat](#fan-out-the-threat-of-authority-by-ancestry), the [act-chain baseline](#what-the-core-already-gives-you) the issuance core gives you, [Mission Child Delegation](#mechanism-1-the-child-mission) for a sub-agent that needs its own durable, revocable handle, [Offline Attenuation](#mechanism-2-offline-attenuation) for fan-out at scale, and [the tradeoff](#choosing-which-to-use) between them.
- **The card analogy.** A sub-agent gets its own card with a lower limit, never a loan of yours. [The Contractor Gets Their Own Card](/notes/the-contractor-gets-their-own-card/) is this part with no protocol in sight. ([Where the analogy breaks](/notes/the-contractor-gets-their-own-card/#where-the-analogy-breaks).)
- **The laws.** This post operationalizes [Attribution and Narrowing (Laws 2 and 3)](/series/mission-bound-authorization/#the-five-laws-of-delegated-authority): attribution survives every hop of instances and delegates, and authority only narrows as work fans out.
- **Specs (editor's copies).** [Mission-Bound Authorization for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html) (the projection and act chain), [Mission Cross-Domain Projection](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-cross-domain.html), [Mission Child Delegation](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-child-delegation.html), and [Mission Offline Attenuation](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-attenuation.html), on the identity substrate of the [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/), [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/), and [AI Agent Instance Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/).

**Reading path.** ~18 minutes start to finish. Read in order, or jump to [fan-out](#fan-out-the-threat-of-authority-by-ancestry) if delegation is your question.

{{< /tldr >}}

# Overview

[The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/) defined the Mission and [From a Request to an Approved Mission](/notes/mission-approval-integrity/) 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](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/). 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](/notes/mission-approval-integrity/). 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 control at a glance | |
| --- | --- |
| **Minimum useful version** | Every derived token carries the `mission` claim, sender-constrained, and delegated work extends the `act` chain through token exchange. No sub-agent acts on inherited session credentials |
| **What it prevents** | Authority by ancestry: sub-agents exercising the parent's credential with no grant, no attribution, and no separate kill |
| **What it does not prevent** | Misuse inside the delegated subset by a legitimate delegate |
| **Operational owner** | The Authorization Server owns the exchange and the subset checks. The agent platform owns instance identity |
| **Evidence emitted** | The actor chain on every token and decision, so audit answers who acted for whom on each hop |
| **Maturity** | The projection and act chain are the core. Child Delegation and Cross-Domain Projection are advanced. Offline Attenuation is experimental |

# 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](/notes/mission-bound-runtime-enforcement-profile/) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html) 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](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-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](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-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](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/) 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](/notes/mission-bound-runtime-enforcement-profile/)) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-cross-domain.html) 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](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-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](/notes/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](/notes/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](/notes/the-mission-is-the-missing-abstraction/) 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.

```mermaid
flowchart TB
    M[("Parent Mission<br/>active")]
    M --> AC["Act-chain delegation<br/>(issuance core)<br/>same Mission, extra actor"]
    M --> CM["Child Mission<br/>AS-mediated<br/>own mission_id + lifecycle"]
    M --> OA["Offline attenuation<br/>holder-minted<br/>same mission claim, no new Mission"]

    AC -.->|"delegate works inside<br/>the delegating flow"| U1[Within parent's lifetime]
    CM -.->|"sub-agent needs its own<br/>durable, revocable handle"| U2[Separate lifecycle]
    OA -.->|"AS round-trip is the<br/>fan-out bottleneck"| U3[Scale and latency]
```

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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-child-delegation.html)) 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](/notes/mission-bound-authorization-reference/)) 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.

```mermaid
flowchart TB
    PA["Parent agent / harness"]
    AS["Authorization Server<br/>(Mission Issuer)"]
    V["Resolve parent from grant,<br/>verify active + delegation,<br/>verify strict subset,<br/>apply fan-out controls"]
    CM[("Child Mission<br/>own mission_id<br/>parent lineage<br/>cascade mode")]
    TK["Mission-bound token<br/>(carries parent member)"]
    PA -->|"1. PAR: child Intent<br/>+ parent grant"| AS
    AS --> V
    V -->|"2. approval / policy<br/>adjudication"| CM
    CM -->|"3. derive child token"| TK
```

One clean separation worth stating: a Child Mission is **not** Mission Expansion. Expansion ([Mission Lifecycle and Change](/notes/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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-attenuation.html)) removes the issuer from that path. It profiles [Attenuating Agent Tokens](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-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](/notes/mission-bound-runtime-enforcement-profile/). 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.

```mermaid
flowchart LR
    R["Root token<br/>mission claim<br/>cnf key, del_depth=0"]
    C1["Child (offline)<br/>same mission claim<br/>narrower tools<br/>par_hash, del_depth=1"]
    G["Runtime PEP / gateway<br/>verify chain + PoP"]
    AS["Mission state source"]
    R -->|holder mints, no AS contact| C1
    C1 -->|present chain + PoP| G
    G -->|"check Mission active<br/>(the kill switch)"| AS
    AS -->|state=active / revoked| G
```

# 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.

| | Child Mission (AS-mediated) | Offline attenuation |
|---|---|---|
| **Who mints** | The Authorization Server, per delegation | The token holder, offline |
| **New Mission?** | Yes. Own `mission_id`, lifecycle, `act` chain | No. Same `mission` claim rides the chain |
| **Authority commitment** | Child's own `authority_hash` over its set | Root's `authority_hash`, as a lineage anchor |
| **Revocation** | Cascade revocation at the issuer (under `immediate`). The `bounded_staleness` and `status_required` modes also require consumer-side parent-state checks | Runtime Mission-state re-check ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement-profile/)) |
| **Issuer sees each delegation** | Yes. Central visibility and control | No. Unobserved until use |
| **Cost** | Round-trip per delegation | None. Built for fan-out scale |
| **Reach for it when** | The sub-agent needs its own durable, separately revocable Mission | The sub-agent needs a narrower token under the same Mission, fast, at fan-out scale |

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](/notes/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](/notes/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](/notes/mission-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.