Mission-Bound Authority: Instances, Actors, and Delegation

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 next to AIMS. That work establishes the agent’s identity, credentials, and delegated user authority. Its Section 10.1 names the agent’s mission and leaves the translation of that mission into authorization requirements out of scope. 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 two required members, id and issuer, and an optional expires_at. The id and issuer say which governance record this credential serves and who holds it, and expires_at lets a validator check that the token’s exp stays inside the Mission’s clock. The claim carries no authority_hash and no approval_basis: the anchor commits the complete Authority Set, which a Resource Server holding a narrowed token does not have, so the anchors stay on the record, and an authorized introspection caller can receive authority_hash and the approval basis type. Offline attenuation, below, is the one exception: it puts the root’s authority_hash back on every token in its chain as a lineage anchor. The token’s authorization_details carry the derived authority itself. The Resource Server enforces them, relying on the token’s signature as the Authorization Server’s assertion that they are a subset of what was approved. A Resource Server or PDP that must check that independently adopts Mission Approved-Set Verification: it retrieves the complete set over a channel authenticated to the issuer, recomputes authority_hash, verifies each carried entry as a subset, and fails closed on any mismatch. Its second tier also pins an expected authority_hash obtained independently of that retrieval, which defends against a set substituted after approval. 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, under the subset relation each entry’s type defines. For mission_resource_access, the Resource Access Profile defines it: resources may only narrow (exact match by default, with an opt-in prefix match), actions may only shrink, constraints may only tighten. Nothing derived ever exceeds what was approved.
• Sender constraint. Mission-bound tokens can be bound to a key with DPoP or mutual TLS, and a bound token is useless off the instance that holds its key. The drafts require it where theft does the most damage: a delegated token is bound to the delegate’s own key, a credential that crosses a trust domain is sender-constrained, a refresh token is sender-constrained or rotated, and the runtime layer requires a sender-constrained credential for the high-consequence classes. The primary access token may stay a bearer token for Resource Servers that accept nothing else, at the cost of stolen-token exposure. The high-assurance level 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 profile is the normative detail, and this projection is the anchor of the reference security architecture: it runs on published OAuth RFCs, with Client Instance Identification needed only for the optional instance-context composition.

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 Runtime-Enforced minimum. A single-instance deployment with no delegation enforces Missions with the OAuth binding alone, which cites the Actor Profile informatively for its OPTIONAL delegation capability and Client Instance Identification only for the optional instance-context composition. 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 chapter 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.
• Client Instance Identification extends attestation-based client authentication to identify the specific client instance behind the shared client_id, so instance-level policy and revocation become possible. Its Instance Context grants no authority, and it identifies no actor: it attributes a presentation to an instance only under a sender-constraint key unique to that instance.
• OAuth 2.0 Client Attester Endorsement lets a client endorse its instance attesters in its client metadata.

The composition is the point. One Mission-bound token can now say: this authority derives from this approved task (mission), presented by this authenticated client instance (Instance Context, attributable under its instance-unique key), acting for this user (sub) through this delegation chain (act). The actor’s identity, and its association with the instance, are established separately from the instance evidence. 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.

The swarm: multiplication, not delegation

That composition also settles the swarm. When many instances run the same Mission under one authorized agent identity, nothing is delegated: the same principal is multiplied. Authorization attaches to the shared agent identity, which does not distinguish instances, and attribution stays per instance, because every instance presents its own Client Attestation and verified Instance Context attributes a presentation to an instance only under a key unique to it. Where a deployment implements the Mission’s Agent Deployment pin, every instance also satisfies it. The pin is an architectural pattern, not a wire member: the OAuth binding reserves no Intent member for it and leaves it to a future Agent Deployment Binding profile. An agent identity and an Agent Deployment stay distinct: a profile may map a Deployment version to its own client registration, but nothing requires that mapping.

Late binding is attestation: an instance spun up mid-task joins by authenticating as the shared client with its own Client Attestation, not by receiving a credential from a peer. What bounds the swarm’s aggregate consumption is the Mission-grain budget of Consumption Metering, which every instance shares. A derivation_limit from Mission Derivation Limits is a different control: the issuer’s cap on its own issuance events under the Mission, requested in the Intent as requested_derivation_limit and clamped by policy. It is not a fan-out or concurrency ceiling, because it counts issuance events, not instances. The kills stay separable: revoke one instance’s credentials, deregister the Deployment, or terminate the Mission and end every instance’s authority at once.

The rule that keeps this honest is that the shared identity is an authorization subject, never an attribution subject. The moment instances become indistinguishable in the record, the shared service account is back.

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 OAuth binding states this capability’s conformance bar self-contained, citing the companion informatively as the interoperable mechanism.

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.

Revocation is where the domains differ. 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, plus the projection grant’s remaining lifetime where the Resource AS checks no Mission state when it mints from that grant. 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.

Revocation is not the only place the domain boundary bites, and the failure modes are worth naming plainly. The downstream domain may not speak the parent’s authority vocabulary, so entries either translate under a mapping both sides trust or do not cross at all. The downstream AS cannot independently verify the upstream approval’s semantics, only the grant’s signature and shape, so its trust in the projection is trust in the issuing domain. Two domains can disagree about what counts as narrower once constraints are contextual or quantitative, which is the semantic-narrowing boundary the Reference names, and the safe resolution is conservative refusal. And an action can be locally permitted while globally outside the Mission, because the local PDP sees only the projected slice. Those are the reasons the projection is one hop, audience-scoped, and subset-ruled rather than a general federation mechanism, and the portability wager is the bet underneath it.

In the suite’s adoption order this is advanced: a design to adopt when the use case arrives, with its dependencies tracked. As of October 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 Runtime-Enforced deployments are unaffected by it entirely.

Projection carries a Mission across a domain boundary in one hop. The experimental Mission Continuation profile names the wider verb this hop belongs to: how a Mission’s authorization continues, under the same approval and constraints, when the acting identity must be re-established at the next hop or the original credential is gone. The Mission owns the authorization continuity, and an identity-continuity transport carries who is acting: the Identity Continuation Assertion for connected cross-workload hops, async delegation for disconnected work over time, and this projection at the domain boundary. One invariant binds all three: a continuation handle grants nothing. Every continued grant re-passes the Mission’s active gate, so continuity is never authority, and Continue stays distinct from Delegate, which narrows authority to a sub-actor.

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 OAuth binding already gives you

Before reaching for new machinery, note what the issuance profile already covers. The OAuth binding 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 part 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 an RFC 8693 token exchange at the token endpoint. The subject_token is the parent’s own sender-constrained Mission-bound access token, and the requester proves possession of that token’s confirmation key; a refresh token is refused, because the proof must never ride a reusable bearer credential. The exchange carries the child’s mission_intent envelope, a child_actor identifying who will hold the child, and a required creation_request_id that makes the creation idempotent. Critically, the Authorization Server resolves the parent from the subject_token, not from any identifier. An optional parent identifier is a cross-check and audit value only, refused on a mismatch. Naming a parent you do not control gets you nothing. You have to present the parent’s bound token and prove its key. The response is a child-bound JWT authorization grant that only the named child actor can redeem, as itself, under its own client credential, so child credentials never transit the parent and the parent never holds child tokens. 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 exchange carrying the parent’s own sender-constrained token.

Subset authority. Every child authority entry must be a subset of a parent entry under the same narrow-only subset rule the issuance profile uses for any derived token. The child entry’s resource must be contained in a parent entry’s resource (equal by default, or narrowed under the Resource Access Profile’s opt-in prefix match), 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 and keeps it on the child’s record; the child’s tokens carry the baseline {id, issuer} claim plus the parent member, and a Resource Server enforces their carried authorization_details exactly as it does any Mission-bound token’s. 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. These are per-Mission figures, and they do not multiply into a lifetime total: max_children counts children alive at once, not children created over the Mission’s life, and a child’s own derivation_limit is set from its own Intent rather than drawn from the parent’s. A finite aggregate bound on a whole subtree holds only where a deployment runs a lineage-keyed budget under Consumption Metering, and an approval that shows these figures must say whether one is enforced.

Cascade revocation. A Child Mission depends on its parent, and “dependent” means every transitive descendant. 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 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). The issuer commits that terminal transition whatever the cascade mode. The mode governs only what consumers must verify in the interim. Cascade is transitive. The children of a cascaded parent cascade in turn, in generation order. And derivation gates on the whole lineage: a child derives nothing while any ancestor, not just its immediate parent, is non-active, so a cascade in progress opens no window. 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.

Does creation wait for a human? Only when the deployment requires a fresh human approval. Creation completes in one of three modes. Synchronous creation is the common case: policy adjudicates the creation of a subset of already-approved authority, which the parent entry’s children object must explicitly permit, and the record names the parent’s human Approver as consent_principal under a policy_drawdown basis. Deferred creation answers authorization_pending and the parent polls while a fresh approval runs asynchronously. Interactive creation runs the issuance profile’s PAR ceremony in the front channel. Where a human approves, the basis is direct and that Approver is recorded.

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 the successor Mission, 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. (Per-entry delegation policy is enforced by shaping the root at issuance, the one moment the issuer is present in the chain: a non-delegable entry never rides a root that can delegate.)

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

The zeroth question comes before the choice: is this delegation at all? A homogeneous swarm, many instances under the same authorized agent identity executing the same Mission with the same authority, needs neither mechanism. That is multiplication, not delegation: no act hop, no child, no attenuation, just per-instance tokens under the shared identity. The mechanisms below are for the cases where a different principal acts or authority must narrow per delegate.

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, which commits the terminal transition in every mode, while the experimental bounded_staleness and status_required modes push an interim 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 runs on published OAuth RFCs (token exchange and the JWT-bearer grant) and is the path to start with, while offline attenuation is labeled Evaluate only because its substrate, Attenuating Agent Tokens, is an in-progress draft. Adopt it for evaluation. And a single deployment can do both: a Child Mission for the durable reviewer sub-agent, offline attenuation for the sharded extraction workers under it, each narrowed to its own slice, and no delegation machinery at all for the homogeneous instances that simply multiply.

That deployment, drawn. Every edge names its mechanism, what narrows on it, and what bounds it, and no edge widens:

Read the edges, not the boxes. Three different mechanisms, one invariant: everything below alice’s approval is a subset of it, and ending M ends the graph.

The through-line

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. A handle is not a credential, and spawning is not delegation: authority moves down only by an explicit, narrower grant, never by ancestry.
• A child is bounded by the parent and dies with it. Cascade revocation for a Child Mission (issuer-committed in every mode, consumer-checked in the interim under the experimental 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.