Mission-Based Authorization: The Field Reference

This is the standing reference for the Mission-Bound Authorization handbook. It is written to be linked, quoted, and shared. The parts carry the argument. This page carries the definition, the litmus test, the landscape, and the vocabulary. The top of the page is the citation kit, each item written to be copied whole, with Mission-Bound Authorization on the Wire as the companion exhibits. The litmus test and everything deeper follow. Everything here tracks the draft family’s editor’s copies as of October 5, 2026.

Mission-based authorization in brief

Mission-based authorization governs the approved task, not just the credential, session, or individual request.

It is a category, not one product. Mission-Bound Authorization, the draft family this handbook explains, is one concrete instance of it, carried on five peer bindings, with OAuth 2.0 as the first, on the most deployed infrastructure.

The vocabulary has a strict hierarchy:

A mission-based authorization system has a durable approved task object, derives authority from it, lets that authority only narrow, and ends it with the task’s lifecycle. At runtime strength it also checks consequential actions against the task’s current state and binds audit evidence back to it.

Why existing objects are not enough: a token authorizes a request, a session preserves runtime continuity, a scope names requested authority, a task/trace ID correlates activity. None of them is the approved task with a lifecycle that authority is derived from and gated on. That object is the Mission.

The triad that makes it work:

Tokens carry authority. Missions govern purpose. PDPs enforce actions.

And its limit:

A Mission-bound token is as strong as the Resource Server that enforces its bounds. Per-action, parameter-level, and state-aware checks come from runtime enforcement.

The bottom line

Mission-based authorization is the missing layer between user intent and per-request authorization. It makes the approved task a first-class governance object: tokens and delegation derive from it and only narrow, and its lifecycle ends them. At runtime strength, each consequential decision and its evidence bind back to it as well.

And the positioning line, for the slide:

Identity says who. Credentials say what may be accessed. The Mission says what the work is, who approved it, and when it ends.

The Mission, in one sentence

The Mission is a durable, approval-backed governance object for authorization: the approved task, with a lifecycle, that authority is derived for, bound to, and gated on. In a Mission-Bound deployment, credential issuance, runtime decisions, and audit records project from it.

And the questions, laddered, because each generation of the stack answered one and the last never became first-class:

And the shorthand contrasts, for the same slide:

The five laws of delegated authority

The layer’s invariants, stated to be quoted. They hold on any substrate, and the handbook is an enforcement mechanism for all five.

1. Durability. Authority must outlive credentials.
2. Attribution. Every action must remain attributable, and the approval record commits exactly what the approver was shown.
3. Narrowing. Authority can only narrow as work fans out.
4. Termination. Revocation must end authority, not merely tokens.
5. Containment. Execution must continuously remain inside approved purpose.

Each law is easiest to remember by its violation:

The names are stable across the handbook: Durability is always Law 1, Containment is always Law 5. The specification family states them in its own terms, mapped below.

And the design stance beneath all five, inherited from the Mission Shaping series:

Survivable incorrectness: the system remains governable and limits damage even when the agent’s semantics are partial or wrong. Perfect fidelity is not achievable at agent scale. Survivable failure is.

The laws in the drafts’ terms

The specification family states the same ground twice, and neither statement maps one to one onto the laws. The Architecture document’s seven Mission Invariants are the substrate-neutral form. The OAuth binding’s six properties, listed in its Implementation Map, are what token issuance alone establishes; they are a different six from the litmus properties. A reader moving between the handbook and the drafts can translate with this table:

One invariant, only active permits, serves two laws: Termination at issuance and Containment at each decision. No binding property names the actor chain, which the binding carries in RFC 8693’s act claim as attribution.

The numbers

The handbook counts several things, and each count has one job:

The six questions are the six litmus properties in interview form, and the laws are what those properties enforce.

The layer vocabulary

Four functions any implementation of the layer must supply, whatever it names its governance object:

• Authority compilation: approved intent becomes bounded, integrity-anchored authority.
• Authority projection: that authority reaches instances, credentials, domains, and delegates without ever exceeding its source.
• Authority containment: every consequential action is checked against the approved purpose at the point of use.
• Authority continuity: reliance stays conditioned on the current state of the task, across time and across the runtime.

The reference security architecture

Reference security architecture = issuance profile + runtime enforcement + AuthZEN profile + runtime evidence + a freshness source (Status, or issuer introspection)

This is the Runtime-Enforced bundle as a formula, and the sizing is real: a substantial build, not a wedge, measured from the runtime profile’s conformance section rather than from this one line. The issuance-only floor (Baseline Issuance) needs the OAuth binding and published RFCs, and it runs on Resource Servers that need not be Mission-aware. The drafts the Runtime-Enforced bundle adds, which is where the remaining dependency risk sits, are named in the standards map and, document by document, in the adoption sheet; none of them blocks the floor. Lifecycle Signals, the push complement, sits outside the formula. The architecture chapter carries the sizing argument, and Adopting Mission-Bound Authorization carries the staged build order.

The honest deployment claim

A deployment claim names its assurance claims and its enforcement scope, and every line can be verified against the implementation checklist below. The assurance claims are what a relying party compares: approved-record integrity, bounded revocation latency per path, action-time enforcement, parameter-bound enforcement, transaction-grade execution, and the named high-assurance claims, each with a proof obligation an existing profile fixes. The adoption bundle names the documents a deployment runs and the claims that become available with it. The architecture’s Mission Deployment Profile is the spec-level form of this claim: the composition of the per-layer statements the profiles themselves demand, covering level, binding, state sources, PEP coverage, custody, evidence, and residual_risks, with the machine-readable manifest schema named as deferred family work. The coverage split is what a reviewer reads first: which paths are mediated per action, which are issuance-gated only with revocation bounded by the token lifetime, and which are unmediated and named as exclusions.

What not to claim

The negative space of the claim, stated to be quoted:

• A Mission-bound token alone is not action-time defense. A check finer than the bounds its Resource Server enforces needs a PEP on each consequential action. And the OAuth binding’s taxonomy polices the word itself: a token that merely references or carries Mission data without state-gated issuance is not Mission-bound, only Mission-referenced or Mission-derived.
• Status without PEP coverage is not runtime enforcement. Freshness feeds a gate. It does not replace one.
• Signals without a fail-closed state source is not revocation safety. A missed event must read as stale state, never as still active.
• Harness logs without mediated execution paths are not containment. A record of the resume is not a boundary on it.
• Audit transparency is evidence, not prevention. It makes a false record permanent and attributable. It stops nothing.
• A renewed charter is not a governed standing agent. Renewal is a review only when the prior cycle’s record is in front of the reviewer, and a ceiling whose renewals carry no evidence review is a blank check with a calendar.

Revocation, in one statement

Revocation changes the Mission’s authoritative state immediately. Enforcement latency is path-dependent: runtime-gated actions stop within the published freshness bound, new derivation stops when the issuer observes state, and outstanding offline-valid tokens run to expiry unless the path checks Mission state.

When revocation bites

Termination is a law, and its implementation burden lives in this table. Revocation ends authority only where enforcement consults live Mission state within a published bound. What a deployment runs determines what it may claim:

Revocation is also only one kill among seven. The containment matrix places Mission termination beside the capability, agent, Agent Deployment, credential, workload, and egress kills, each with its own blast radius and owner, because revoking a Mission terminates no process and closes no network path.

The vendor test

The test is its own page, built to be linked and pasted into an evaluation: The Mission-Based Authorization Vendor Test. Six questions, the litmus property each one probes, and what failing answers sound like. A vendor that passes all six should be able to write the honest deployment claim above, and the implementation checklist is how you verify it.

The canonical picture

One diagram for the whole model: the six stages, and the actors and objects in each.

Everything below is the detail behind the bottom line: what qualifies as mission-based (litmus), how it differs from what you already run (landscape), the smallest useful deployment (the adoption order), the checkable claim (checklist), what it does not solve (non-goals), the glossary (Appendix F), and one worked example.

Mission-based authorization as a category

The field has converged on the same gap from several directions: agent IAM, intent-based access control, capability systems, the lethal trifecta. The shared answer is to elevate the approved task to a first-class object. That move is the category. A system is in the category whether it calls the object a Mission, a charter, or a governed task, and whether it rides on OAuth, on a clean-slate agent protocol, or on something else. The decisive distinction from every task-shaped record nearby is not the fields: the object is the authorization root, with authority derived from it, execution enforced against it, and lifecycle and evidence joined on it. In infrastructure terms the category is the control plane for delegated authority: the layer that holds the desired state of the work, with credentials and enforcement as the data plane reconciled against it.

Identity was the control plane for human access. The Mission layer is the control plane for delegated authority.

The category is not enterprise-shaped either, even though this handbook’s examples deliberately are. A vacation-planning agent’s Mission has the same anatomy as the board packet’s (an approved task, authority derived from it, an expiry, and evidence that joins), and the same is true for the smart-home agent or the assistant booking a dinner. The handbook’s examples stay in the enterprise because that is where the adoption pressure, the estates, and the approval workflows live, not because the object knows the difference.

This handbook is about one instance: Mission-Bound Authorization, the draft family where the object is the Mission and enforcement uses a PEP/PDP contract. Its first binding, on the most deployed infrastructure, is OAuth 2.0, where authority is derived as Rich Authorization Requests and the token binding is the mission claim. Its peers are the standalone Mission Authority Server, a deployment topology over the same OAuth Mission data model; AAuth; and the UMA 2.0 and GNAP sketches, each with its binding’s own authority semantics. Where this page says “mission-based,” it means the category. Where it says “the Mission” or names a draft, it means this instance.

The category does not depend on OAuth. OAuth is the substrate used here because it is the dominant deployment reality, and it already supplies the derivation, exchange, sender-constraint, and revocation machinery a Mission binds to. The family itself now demonstrates the independence: the AAuth binding maps the Mission kernel (approval, the Mission Reference of the approving Person Server and s256, the active-state gate, and the ordered mission log) onto AAuth’s native mission at the Person Server, against AAuth -11 (2026-09-25) and the exploratory R3 -00 (2026-09-28). Authority stays in AAuth’s own scopes, resource tokens, and optional R3, the lifecycle stays active or terminated, and the Person Server gates only person-token issuance, PS authorization, and federated authorization. AAuth Mission Expiry profiles AAuth’s native expires_at, and AAuth Mission Management adds authenticated status and termination. Mission Substrate Requirements consolidates what any further binding must provide, a mandatory contextual-governance kernel plus eight optional capabilities claimed per binding, and the experimental UMA 2.0 sketch is the first binding authored against that contract, with RPT issuance and upgrade gated on Mission state. This handbook’s reference model is the six properties, and OAuth is its first binding.

Mission-based authorization and IBAC

Intent-Based Access Control (IBAC) is the property: authorize by what the user approved, not by what an agent infers at runtime. Mission- based authorization is the mechanism that makes IBAC practical, by moving interpretation to admission, before any authority exists, where an adjudicator (the user in the common case, otherwise a deterministic, versioned policy acting within a ceiling a human consented to) decides against committed inputs with a human accountable as the Approver, and committing the result so enforcement consumes approved intent instead of reconstructing it. The distrust of runtime-stated intent is shared ground now: the proposed CB4A credential broker meets the same threat and resolves it by demoting the agent’s stated justification to audit evidence, excluded from authorization. The Mission resolves it the other way, by making approved intent the authorization root. IBAC is the property. The Mission is the object that carries it.

What counts: the litmus test

The test is this handbook’s category bar, and it splits at two strengths. A system is mission-based at issuance strength, the strength the Baseline Issuance bundle provides, when the first four category properties hold:

1. Approved task object: a durable record of the approved task, activated by a human or by a versioned policy within a ceiling a human consented to, with a human accountable. Not a prompt, trace ID, session, ticket, or token.
2. Authority derivation: credentials and decisions are derived from that approved task, not minted independently of it.
3. Narrow-only delegation: derived authority, child tasks, and sub-agents can only narrow. Exceeding the parent requires a fresh approval.
4. Lifecycle: the task can expire, be revoked, expand (via fresh approval), and complete. Only an active task permits reliance.

It reaches runtime strength, the bar behind any action-time defense claim and behind the action-time assurance claims that become available with the Runtime-Enforced bundle, when two more hold:

5. Runtime enforcement: consequential actions are checked against the current task state at the point of use, not just at issuance.
6. Evidence: decisions and lifecycle events bind back to the task, so audit can reconstruct it. This is verifiable continuity: the approval, the decisions including denials, and the executions can be shown to belong to one undertaking.

Relax any of the first four and the design is not mission-based: scopes without a task, sessions without approval, a PDP without an approved object. Hold the first four without the last two and it is mission-based at issuance strength, and it claims nothing about action-time defense.

The bar is stricter than the drafts’ own substrate contract. Mission Substrate Requirements requires a kernel (a Mission reference, controller and actor binding, approved context, an approval event, an active/non-active gate with bounded reliance, context propagation, and an ordered governance record) and treats structured authority and monotonic derivation as optional capabilities, so a binding can meet the substrate contract and still fail properties 2 to 4.

What looks like a Mission but is not

The object-level version of the same test, useful when someone points at an artifact and asks “is that the Mission?”

What becomes possible only with a Mission

The case for the Mission as a primitive, not just a useful design pattern, is concrete. The following all require a shared, integrity-anchored task object, and none is reliably achievable through disciplined use of existing OAuth primitives alone:

• Cross-audience revocation of a long-running task. Without a shared task identifier, revoking an agent’s work requires hunting credentials at every audience independently. With the Mission, revocation at one state authority terminates future derivation across every audience that ever projected from it.
• Cross-hop audit join on the user-approved task. Without a shared identifier, audit reconstruction stitches per-AS logs by timestamp and client identifier. With the Mission, every record across every audience and substrate joins through mission.id and mission.issuer.
• Cryptographic commitment to the approved record. Without integrity anchors over a canonical Mission Intent and Authority Set, the authority’s record of approval is reconstructed from per-token authorization_details and consent-system logs. With intent_hash and authority_hash, the approved intent and the derived authority are committed at activation and can be checked for later modification, and the Consent Evidence companion’s consent_rendering_hash commits the presented disclosure where that profile is deployed. The hashes do not prove that a renderer displayed those objects faithfully or that a human understood them.
• Lifecycle as an authorization input. Without a Mission state machine, refresh and exchange gate on token validity alone. With a Mission, refresh, exchange, ID-JAG issuance, and PDP decisions all consult Mission state. A suspended or revoked Mission stops future derivation regardless of credential expiry.
• Risk evaluated at the undertaking’s grain, not the call’s. Without the Mission, the resource prices every action in isolation, and “delete database” carries the same risk whether it is a stray action or step four of an approved migration. With the Mission, the decision knows the committed why and the undertaking’s recorded progress, because evidence joins on mission.id, so a precondition like “the copy steps completed” is a checkable fact rather than a hope. The context is committed and recorded, never inferred, and no per-call primitive can supply it, because a resource holds that history only where it runs the workflow itself.
• Governance without changing the issuer. Without a Mission service, a deployment that cannot modify its Authorization Server has no governance object at all. With the Mission Authority Server, the Mission record and its lifecycle live in a standalone service that serves the status and lifecycle surfaces itself, and a PDP joins ordinary tokens to the Mission at the point of use.

Each of these can be approximated with deployment-specific extensions. None is interoperable across vendors without a standardized object. That is the difference between a useful design pattern and a primitive.

The Mission object model

The approved task is a typed object, not a label, and it is an aggregate of three logically separate components plus a stable identity:

The approval commitment, immutable after approval:

• Purpose: an optional task-class URI, not the instance.
• Mission Intent: the structured, approved task description, committed by intent_hash.
• Consent reference: a pointer to the canonical disclosure behind the approval, hashed by the optional Consent Evidence companion so an auditor can verify the stored disclosure has not changed.
• Authorization basis: the approved root the Mission traces to, recorded as approval_basis beside the approver and never folded into the hashes: direct for a human’s own approval, or a standing-consent basis such as template or policy_drawdown, each naming the same accountable human as consent_principal. It also records what activated this instance (activation), who triggered it (activation_actor), and the consented root (root_commitment), and it can name the deciding mechanism (adjudication): the human Approver, or a deterministic, versioned policy acting within a ceiling a human consented to. A model’s judgment enters adjudication only as a recorded input to that policy, and it can refuse or narrow, never grant or widen.
• Authority source: whose authority the approval draws on, recorded immutably as authority_source: user_delegated, service_owned, or organizational (naming its governed policy). The AS verifies the Approver may activate the source and that the derived Authority Set lies within it, distinct checks, because an organizational owner may activate policy without personally holding every operational permission.

The approved authority, immutable after approval:

• Approved Authority Set: the maximum grantable authority derived from the Intent and fixed at the approval event, committed by authority_hash. Authority is one component of the Mission, not the whole. The ceiling the derivation narrows against is itself a composition: the issuer’s derivation policy intersected with the ceiling of the Mission’s authority source (a delegating person’s own authority, a workload’s provisioned authority, or governed organizational policy), because approval activates authority the source already holds, and the Approver needs authority to activate the source, not personal possession of its permissions, while resource-owner and deployment policy stay live checks at each decision point. Where the client proposed authority as top-level authorization_details beside the Intent, the conditional proposal_hash commits the proposal, so the narrowing from proposal to derived set is itself checkable.
• Delegation context: credentials derived for delegated actors stay bounded by the same Mission and preserve authenticated actor context (the RFC 8693 act chain where an adopted profile supplies it). An ordinary Token Exchange (in-Mission delegation or self-exchange down-scoping) derives tokens under the same Mission and never creates a child Mission. A Child Mission comes only from the Child Delegation profile’s child-creation token exchange, and broader authority is a separately approved successor via Mission Expansion.

The lifecycle state, mutable and versioned:

• Lifecycle state: owned by the issuer, with a state version for concurrency control. Only active permits reliance.
• Effective Authority Set: the Approved Authority Set after every issuer-held narrowing the deployment runs, such as containment and entry discharge, has subtracted from it. The Status profile owns it, and a narrowed Mission stays active.

The identity, immutable:

• Identity: id and issuer, the same pair on the record and on the mission claim that every projection carries.

The mutability rules answer the questions the aggregate raises. The hashes commit the approval side and never change afterward. A lifecycle transition changes the state and its version; subtraction changes the Effective Authority Set and its version while leaving the lifecycle state unchanged. Suspension changes reliance, not the approved task. Completion records fulfillment and retires reliance. Widening anything committed is a separately approved successor Mission, never a mutation. And a Child Mission inherits a subset of the parent’s Effective Authority Set under the subset rule, with its own lifecycle bounded by the parent’s.

Authority moves along one path, and no stage holds more than the one before it:

The lifecycle gate sits beside the path: resume reopens a suspended Mission’s gate without changing either set.

“Consent” here names the Mission-layer authorization anchor, the legitimacy source that approved this specific Mission. That is a narrower technical use than GDPR-style data-processing consent, and deployments subject to those regimes still owe their own consent contracts on top. Where no user is present at approval time, the anchor is a prior human-approved template Mission, a standing organizational policy in a formal auditable language, or a verifiable standing delegation from a service owner. LLM inference about organizational intent, runtime configuration supplied by the agent, and pre-existing general-purpose scope grants anchor nothing, because they do not establish authority for a specific Mission.

Everything an agent touches is a projection of this object: a Mission-bound token, a runtime decision, a child Mission, a lifecycle signal, an evidence record. Each carries the Mission reference and derives from, never exceeds, the Effective Authority Set.

The subset rule, compactly, for the mission_resource_access entries every example here uses. The OAuth binding’s own rule is type-agnostic, and the Resource Access Profile defines this type’s comparison. Every derivation, delegation, exchange, and attenuation yields authority that is:

• the same or a narrower resource set (exact match by default, or the opt-in prefix containment),
• the same or a smaller action set,
• the same or tighter constraints,
• expiry no later than the Mission’s expires_at,
• per-entry delegation policy no broader (max_depth no greater, allowed_delegates no wider),
• and the same mission claim, because re-binding to a different Mission is refusal, and crossing a trust domain rides a separately approved, audience-scoped projection.

Widening anything on that list is a fresh approval, never an inference.

One distinction matters. What the machinery tests is representational narrowing: the child’s authority is formally no broader under the comparison relation the entries define. Semantic narrowing, that the child cannot produce effects outside the parent’s approved boundary, is a stronger property that representation alone cannot always prove, especially where constraints are contextual, quantitative, or translated across domain vocabularies. Where the two can diverge, the family’s answer is conservative refusal or a separately approved projection, never an optimistic mapping.

The Mission contains the Authority Set. The Authority Set does not define the Mission. A bundle of permitted actions with no approved task, lifecycle, or evidence is just authority, which OAuth already had.

A concrete Mission record

The running example as a record. Its intent_hash and authority_hash are the ones reproduced byte-for-byte in Reproducible test vector below. No authority was proposed at submission, so the conditional proposal_hash is absent, and the AS derived the set in configured-mapping mode: the mapping for the board-packet purpose binds the current reporting period, the board-packet template, and the audit-committee group, and the AS never reads the task_bounds shown to Alice. The record carries the authorization basis and authority source the OAuth binding requires.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

{
  "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "purpose": "urn:example:mission:board-packet",
    "target_resources": ["https://finance.example.com",
      "https://docs.example.com",
      "https://workflow.example.com"],
    "task_bounds": ["Q3 2026", "Example Corp", "confidential"],
    "expires_at": "2026-10-15T18:00:00Z"
  },
  "authority_set": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } },
    { "type": "mission_resource_access",
      "resource": "https://docs.example.com",
      "actions": ["create_doc"],
      "constraints": { "template": "board-packet" } },
    { "type": "mission_resource_access",
      "resource": "https://workflow.example.com",
      "actions": ["notify_reviewer"],
      "constraints": { "group": "audit-committee" } }
  ],
  "intent_hash":
    "sha-256:yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw",
  "authority_hash":
    "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY",
  "subject": { "iss": "https://login.example.com",
    "sub": "alice@example.com" },
  "approver": { "iss": "https://login.example.com",
    "sub": "alice@example.com" },
  "approval_basis": {
    "type": "direct",
    "consent_principal": { "iss": "https://login.example.com",
      "sub": "alice@example.com" },
    "activation": { "approval_event_id": "ape_5D8wQ1kR7mX2vT4nH6jZ" },
    "activation_actor": { "iss": "https://login.example.com",
      "sub": "alice@example.com" },
    "adjudication": { "kind": "human" },
    "root_commitment":
      "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY"
  },
  "authority_source": { "type": "user_delegated" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "approval_event_id": "ape_5D8wQ1kR7mX2vT4nH6jZ",
  "created_at": "2026-09-30T17:03:00Z",
  "expires_at": "2026-10-15T18:00:00Z"
}

Derived tokens carry the record’s id and issuer, and optionally its expires_at, in the mission claim. The claim carries no authority_hash and no approval_basis: the anchors stay on the record, an authorized introspection caller can receive both, and a Resource Server that must check a token’s authority against the complete approved set adopts Approved-Set Verification. subject and approver are {iss, sub} pairs, authoritative for principal equality, and they may differ when an administrator approves on a user’s behalf. approver is kept as the compatibility alias of approval_basis.consent_principal, the accountable human. Here adjudication is human, and root_commitment, for a direct approval, is the Mission’s own authority_hash. The record also carries its issuance context: the agent’s client_id, the policy_version the Authority Set was derived under (an opaque audit correlator, not a re-derivation promise), the approval_event_id, created_at, and a top-level expires_at mirroring the Intent’s. The consent disclosure the Approver saw is committed separately by the Consent Evidence companion (From a Request to an Approved Mission).

Lifecycle states

The issuer owns the state machine. The OAuth binding defines three states. Companion profiles add more, and the one rule a consumer always applies is that only active permits reliance. Every other state, recognized or not, is treated as non-active, so the model fails safe as it evolves.

• active (issuance profile): approved. Derivation and reliance permitted.
• revoked (issuance profile): terminated by user, admin, or policy. Terminal.
• expired (issuance profile): expires_at passed. Terminal.
• suspended (Status companion): paused. Reversible to active.
• completed (Status companion): finished. Terminal. Legal from active or suspended.
• superseded (Expansion companion): replaced by an approved successor. Terminal.
• cascaded (Child Delegation companion): a child terminated because its parent reached a terminal state. Terminal, and distinct from revoked so audit can tell a cascade from a direct termination.

A consumer that has never heard of suspended, superseded, or cascaded still refuses to rely on them, because they are not active. New states are therefore safe to add. (One exception, by design: an unrecognized entry-level terminal_when condition, which the Entry Discharge companion registers, must fail closed, not be ignored. See Mission Lifecycle and Change.)

Trust boundaries and roles

Mission-Bound Authorization spans multiple parties. Each is trusted for a specific bounded responsibility, and explicitly not trusted for adjacent ones. This is the canonical role map, and the profiles populate it for their substrate.

The division of labor across domains is worth one plain statement. The Mission Issuer governs the approved objective and its global ceilings. The resource authority defines resource-local actions and constraints. The PDP evaluates the intersection of the two. And translation across authority vocabularies is trusted, verified, or separately approved, never assumed.

The most important boundary is the first one: the Mission Shaper is never an authorization component. It produces a proposal the state authority can validate or refuse. Diagrams that place the Shaper inside the authorization trust envelope are wrong.

Agent IAM and the Agent Registry

The division of labor with agent identity is one sentence. Agent IAM preserves who is acting. Mission-Bound Authorization preserves why their authority exists. Neither replaces the other, and the combined stack is the deployment story:

1. The Agent Registry and workload identity authenticate an approved agent instance.
2. The Mission and its derived Authority Set say what sanctioned work that instance carries.
3. Per-hop credentials narrow that authority, audience by audience.
4. The runtime layer enforces each consequential action and its parameters at the point of use.
5. Decision, execution, and lifecycle evidence join on the Mission.

The registry itself is a complementary dependency, not part of the Mission system, and this family defines no agent identity and no registry (three objects, three lifecycles). Where one exists, the Mission Issuer and the PDP consume a small, stable slice of it:

Registry state is a state source like any other. The consuming decision point treats it under the runtime profile’s freshness discipline, with a declared staleness bound, failing closed when the state cannot be established. And the three lifecycles gate conjunctively: all three must be live, and each is checked on its own.

Who owns the meaning

Three layers need three different relationships to a vocabulary none of them owns jointly. The resource owns the ontology: only the finance system knows what query_financials(period, entity) means, which parameters are dangerous, and which constraints its objects can enforce, because it implements the call. Governance needs enough of that meaning to derive and render faithfully, since the Authority Set is derived against resource-defined action semantics and the approval discloses meaning the issuer does not own. Policy needs enough of it to evaluate, since the PDP checks concrete parameters against entries whose semantics the resource defined. The ontology problem is the published statement of why this is hard, and the family answers it with four supply mechanisms rather than one global vocabulary:

The direction matters. OAuth’s inherited ontology is client-proposed: the client asks in types the issuer must understand, which is why a generic multi-tenant issuer struggles with domain meaning. The resource-declared direction inverts it, and where semantics should live is the published treatment. Either direction ends at the same rule: translation across authority vocabularies is trusted, verified, or separately approved, never assumed.

And the asymmetry runs both ways. The resource owns what an action means. The Mission owns why it is happening and where the undertaking stands. A risk decision needs the join, because semantics without purpose prices every delete the same, and purpose without semantics cannot read the call.

Where the Mission record lives

By default, the Mission record lives at the binding’s Mission control point, its state authority. On the OAuth binding that is the Mission Issuer, the Authorization Server, which validates Intents, runs approval events, stores the record, and gates issuance on its state. In AAuth it is the Person Server. The substrate-local default keeps the minimum profile coherent, since a deployment can adopt the Baseline Issuance bundle without introducing a new server component.

The Mission Authority Server (MAS) is the standalone controller over the OAuth Mission data model, the AS-optional mode: a peer deployment topology, not an independent substrate, since it imports the OAuth Mission record and issuance profile. Beyond serving deployments whose Authorization Server cannot yet change, it is the estate control plane for approved-task authority, one Mission Issuer spanning many Authorization Servers, SaaS systems, APIs, and agent runtimes, with an Enterprise Mission Authority Profile above its conformance floor. The MAS implements the Mission Issuer role without being an OAuth AS. It validates Mission Intents, runs approval events, records Missions, operates the lifecycle, and serves Mission state. It derives no tokens. Access tokens remain ordinary OAuth tokens with no mission claim, and a Policy Decision Point joins each presented credential to its Mission at the point of use, enforcing through the runtime profile.

That difference is architectural, not just topological. The MAS mode buys Mission governance and per-action enforcement with no change to the deployment’s Authorization Server, at the cost of Mission-bound credentials and issuance gating. Without that join, revoking a Mission stops nothing at the token layer, so enforcement rests entirely on PEP coverage. The issuance grant is the middle path that restores the token-layer chokepoint: estate Authorization Servers redeem MAS-minted grants for Mission-bound tokens without moving approval into the AS, so one canonical Mission record gates credentials minted across many issuers. A consuming AS with a Mission-state integration projects every redemption and refresh through the Effective Authority Set; one without it relies on the active-at-minting gate alone and issues no refresh tokens, so tokens derived under a revoked Mission can keep working for the grant’s remaining redemption window and clock-skew leeway, plus the issued token’s lifetime, plus that of each further exchange that checks no Mission state, never past the Mission’s expiry.

Competitive landscape

Each of these is real and useful, and none is a substitute for an approved task object. Mission-based authorization composes with them rather than replacing them.

The pattern is consistent. The credential and decision layers are well-served. The approved task is the missing object. Mission-based authorization supplies it and lets the others bind to it: RAR derives from it, the PDP decides against it, sessions and traces reference it. And the “Law it breaks alone” column is the sense in which the category follows from the laws. Used alone, every row breaks at least one of the five laws, so an architecture that satisfies all five contains a Mission-shaped object, whatever it is called, and the one row that breaks none is itself an instance of the category. Because the laws and the object come from the same analysis, the column is a consistency check on the design.

When it is the wrong tool. If there is no durable task to govern (a single user-driven request, a machine-to-machine service credential, a short-lived consumer authorization where the credential lifetime is the task), a Mission adds cost without value. Do not read the standing agent out through this door: a service credential’s work is fixed at integration time, while a standing agent exercises delegated judgment on every unit of work, which is exactly what needs a charter and cycling authority (the standing agent at scale). And do not read small tasks out either: one resource, one approver, and one afternoon is a perfectly formed Mission, because what disqualifies is never size, it is the absence of a durable task. The category earns its keep whenever authorization must outlive a single request and stay bound to a task, however small, and whoever the actor is: a Mission governs a human’s task access as readily as an agent’s. And note that AAuth Mission is itself an instance of this category on a different substrate, not a rival to it. The interesting question there is shared governance across substrates, not which one wins.

Granularity has decision rules, because both failure directions are real: Missions broad enough that ambient authority has merely moved upward, and Missions so fine that approval and evidence volume overwhelm the plane. Work stays in one Mission while the undertaking and its bounds hold. A helper that finishes inside the parent’s flow gets a narrower delegated projection. A durable sub-agent that needs its own observable lifecycle and stop handle gets a Child Mission. The same undertaking needing different bounds gets a successor. A new objective gets a separate Mission, related in evidence. And one high-consequence effect gets an action-bound permit, never a Mission of its own.

The adoption order

The smallest useful deployment, and the order deployments build the rest in. A deployment adopts as far as its risk warrants and stops there:

• Stage 0: Substrate only. Ordinary OAuth, no Mission. Fine for single-request, non-agentic flows.
• Stage 1: Mission-bound issuance. A mission claim on derived tokens, with state-gated issuance: a possession-independent kill switch for future derivation. Audit and derivation control at the grain the Resource Server enforces, not action-time defense. This is the entry point, the issuance-only deployment: only the Authorization Server and the Mission-creating client change. A Resource Server that introspects per request stops honoring a token at its next request once the Mission leaves active, with no Mission-specific code. The deployment claims approved-record integrity and bounded revocation latency.
• Stage 2: State and revocation freshness. Status / introspection so consumers can check current Mission state.
• Stage 3: Runtime enforcement. Per-action PDP checks for consequential actions. This is the stage that adds per-action, parameter-level, and state-aware checks beyond the bounds the receiving Resource Server enforces.
• Stage 4: Lifecycle. Signals, expansion, and entry discharge: prompt revocation, governed growth, and monotonic narrowing.
• Stage 5: Delegation. Child Missions and offline attenuation: strict-subset authority for sub-agents, without ambient inheritance.
• Stage 6: Operational assurance. Harness binding, safe unwinding, and audit transparency.

Stages 1 and 2 cover consequential reads and writes whose bounds the receiving Resource Server enforces. Most AI agents that touch private data, untrusted content, or external side effects also need Stage 3 for the actions whose parameters or state matter, and Stages 5 and 6 for fan-out and full governance.

The stages group into the four Mission Assurance Levels. They are adoption bundles, not a conformance class, an earned label, or a ladder, and a deployment names the bundle it runs. A level does not determine any action class’s containment property. One line each:

Baseline Issuance is in the category at issuance strength, and does not by itself establish an action-time defense claim: the litmus’s four-and-two split.

The bundle is one axis. The binding is orthogonal, and a deployment names both. The bindings are not one security system either: the architecture classifies them as credential-carried (the Mission rides the credential), PDP-joined (the decision point joins ordinary credentials to the record), and context-carried (the substrate’s own mission context is the record), and a deployment names its security architecture, not only its binding.

Custody of the execution environment is the third axis, because assurance follows it. For a harness the enterprise does not run, a third-party SaaS agent or an employee’s consumer assistant, Baseline Issuance still applies to the credentials the estate mints, plus boundary PEPs at its edge, and Runtime-Enforced survives route-scoped: enterprise PEPs in front of enterprise resources enforce at the point of use whoever runs the loop. The Governed Agent bundle binds the harness, so it is out of reach without harness custody, while the high-consequence classes stay reachable per route, because mediated custody holds the key at an enterprise-controlled handler either way. And delivering a usable secret into the agent’s environment is custody transferred, not use mediated. Only the mediated form supports the highest claims.

Read in adoption order, each bundle makes a broader class of agent work defensible to grant. The mapping is informative, and what a bundle grants varies with the binding:

The read-only ceiling breaks at Baseline Issuance for writes whose bounds the Resource Server enforces, and the adoption path carries that reading in full.

The implementation checklist

The claim a deployment makes should be checkable. This is the field checklist for a Runtime-Enforced deployment, with the deeper treatments linked.

Claims are scoped, not global. A deployment that cannot prevent an action class on some path must not claim runtime enforcement for that class, and must name the paths it does mediate. A claim worth trusting reads like the honest deployment claim in the citation kit, each clause mapped to a row above and checkable. A claim that cannot be written in that form is marketing, not an assurance claim. What not to claim is its negative space.

Adversary model

The non-goals below say what this does not solve. This is the complementary view: the adversaries it does constrain, the layer that constrains each, and the residual it leaves. The reasoning is developed across the parts. This table is the consolidated map, and the Mission Security Model draft (Informational) is its spec-level counterpart: the trusted base, the cross-cutting assumptions, and the consequence of each component’s compromise.

The Mission record is itself sensitive

The object that makes agent work governable is also a record of business intent: purpose, targets, constraints, approver identities, and the evidence that joins them. The same mission.id join that makes reconstruction possible is a correlation surface. The OAuth binding already keeps the token-side claim a reference, never the Intent’s contents, and leaves the anchors on the record. Deployments should hold that line: resource servers and intermediate PEPs need the identifier, not the task description. Where a party outside the issuing domain needs some committed facts and not all of them, the Mandate’s selective disclosure is the built tool. The rest is deployment discipline: evidence stores behind the same access control as the systems they describe, retention set deliberately because the evidence chain outlives the task by design, and awareness that a Mission reference projected across domains is a correlation handle in someone else’s logs.

The sober reading: the strong adversary, a fully compromised agent, is contained at the boundary (custody, per-action checks, narrow-only delegation, the kill switch), never by trusting what the agent says. The residual column is the part no claim should paper over.

Threats and non-goals

The Mission is the declared governance envelope, and the runtime layer is what keeps the system survivable when the envelope turns out to be incomplete: a deployment with the object but no runtime layer is protected only as far as its Resource Servers enforce the carried bounds, and one with enforcement but no shared approved object is ungovernable. Mission Shaping Is Not Enough makes that two-layer argument in full. And one sentence bounds the whole claim: Mission compliance is evaluated against the approved representation of purpose, not against an independent oracle of human intent. A sufficiently broad or badly derived Authority Set can permit an action that is syntactically compliant and purpose-inconsistent, which is why shaping, disclosure integrity, authority derivation, and runtime enforcement are each required rather than redundant.

Mission-based authorization is credible because it is precise about its edges. It does not:

• make an LLM’s reasoning trustworthy
• replace resource-local policy (the resource remains authoritative for its own decisions)
• provide full information-flow control
• prove that every side channel has been mediated
• eliminate the need for human step-up on high-risk actions
• make a broad, over-scoped Mission safe (breadth approved is breadth granted)
• lean on deterrence as a compensating control. Human delegation quietly does, because people fear the audit that follows. An agent has no career to protect, and its judgment can be rewritten mid-task by content it reads, so the runtime boundary must carry the weight that deterrence carries for people.

What it does:

It gives policy, credentials, lifecycle, delegation, and audit a common object (the approved task) and a runtime layer that checks each consequential action against it.

The safety properties most people assume from “Mission-bound agents” (action-time defense, prompt revocation, safe unwinding, evidence) come from the runtime and operational layers, not from the mission claim alone.

Noun distinctions

Keep these stable. Do not let “task,” “mission,” “workflow,” and “session” blur.

• Mission Intent: the proposed task (untrusted until validated).
• Mission: the durable, lifecycle-owned record of the approved task; the task itself is the undertaking the record governs.
• Approved Authority Set: the derived, grantable authority the Mission bounds, fixed at the approval event and committed by authority_hash.
• Effective Authority Set: the Approved Authority Set after subtraction by containment and entry discharge, the set derivation and runtime decisions read.
• Projection: any substrate-specific, audience-bounded credential or assertion derived from the Effective Authority Set: a Mission-bound token, an ID-JAG, a downstream grant, or another substrate’s native credential. Every projection carries the Mission reference.
• Mission-bound token: a credential projection carrying the mission claim.
• Runtime decision: a per-action permit or deny.
• Evidence: an audit artifact (approval, consent, decision, lifecycle).
• Harness: the runtime continuity and mediation layer, not authority.

The canonical sequence behind these nouns: Mission Intent → Approved Authority Set → Mission → Effective Authority Set → Projection → Runtime Decision → Evidence. Before consent, the state authority derives the Approved Authority Set in narrowing or configured-mapping mode. The approved Mission commits the Intent and the set, subtraction yields the Effective Authority Set, and every profile specifies one or more of the transitions.

Why “Mission”?

The name was deliberate, and alternatives were considered. Each captured a piece of the object without doing justice to the whole:

• mandate carries political and legal connotations the protocol object does not. A mandate is an instruction. A Mission is a governance container that includes intent, authority, lifecycle, and evidence.
• delegation_context muddles with OAuth’s existing notion of delegation, which sits at the credential layer (one principal authorizing another). The Mission is above credential delegation. Both the original credential and any delegated credential project from the same Mission.
• task_authorization describes a credential, not a governance object. The Mission is what task authorization derives from. Calling the governance object “task authorization” reduces the layer above to the layer below.
• purpose_bound_authorization correctly names one aspect (purpose) but presents the object as a flavor of authorization rather than as the durable container that authorization projects from.
• authorization_context is too generic. “Context” in OAuth-adjacent specifications means many different things. The Mission has a specific structural commitment to integrity, lifecycle, and consent that “context” does not imply.

“Mission” captures the durable, purpose-bound, lifecycle-governed quality of the object without overloading any existing OAuth term. It signals that this is not a refinement of scope, authorization_details, grant, or session, and it implies purpose plus duration plus boundedness in one word, which is what the governance object actually is.

A standards-track adoption could use a more neutral on-the-wire name (the OAuth claim could be mbo or authorization_mission rather than mission) while preserving “Mission” as the conceptual term. The family uses mission as the claim name to keep the conceptual and wire terminology aligned, and deployments may rename if a working-group consensus settles on a different label.

Reproducible test vector

The credibility of this model is its hashing, so here is one anchor you can reproduce byte for byte. Every integrity anchor is a SHA-256 over a domain-separated, issuer-bound envelope ({ "typ", "iss", "value" }), canonicalized with JCS (RFC 8785), encoded as sha-256: followed by base64url with no padding. For intent_hash, typ is mission-intent and value is the approved Mission Intent.

The JCS canonical bytes of the envelope, for the running example, are exactly:

1

{"iss":"https://as.example.com","typ":"mission-intent","value":{"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","target_resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"],"task_bounds":["Q3 2026","Example Corp","confidential"]}}

Hash those bytes and you get the anchor. Reproduce it from a shell:

1
2
3

printf '%s' '{"iss":"https://as.example.com","typ":"mission-intent","value":{"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","target_resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"],"task_bounds":["Q3 2026","Example Corp","confidential"]}}' \
  | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '='
# => yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw

So intent_hash = sha-256:yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw. The same procedure with typ = mission-authority-set and value = the Authority Set array yields authority_hash = sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY.

Two rules make this interoperable: JCS sorts object keys but preserves array order (so the Authority Set’s entry order is part of the canonical form), and the typ value domain-separates the anchors so a digest of one object can never be read as the other. A verifier reproduces the digest from the recorded object alone.

Glossary

The handbook’s vocabulary has its own appendix: the Glossary (Appendix F) carries every term in one alphabetical table, each entry linking its canonical home.

The running example, end to end

The handbook follows one task. This is the canonical walkthrough, each part picks up its step, and Mission-Bound Authorization on the Wire shows the same steps as actual protocol exhibits. The drafts illustrate the same machinery with a different task, an agent reconciling Q3 invoices and posting adjustments under a cap, so a reader moving between them finds the same steps applied to different resources.

Scenario. Alice asks an agent: “Put together the Q3 board packet for the audit committee and let them know it’s ready.” The Mission’s Authority Set is query_financials (finance, Q3 2026), create_doc (docs, board-packet template), and notify_reviewer (workflow, audit-committee group), bounded to an expiry.

1. Derive. The AS validates the Intent, which it records verbatim, and derives the Authority Set it will ask Alice to approve in configured-mapping mode, keyed on the board-packet purpose and bounded by target_resources. (The Mission)
2. Approve. The AS renders the validated Intent + derived Authority Set. Alice interrogates the disclosure if anything is unclear, with the exchange recorded, and consents. The AS commits intent_hash and authority_hash and creates the Mission active, atomically. (Approval integrity)
3. Issue. The agent gets a Mission-bound token carrying the mission claim. (The Mission)
4. Permit a read. The agent reads Q3 financials. The PDP permits query_financials against the live Mission. (Runtime enforcement)
5. Gate a write. Drafting the document is a write. The create_doc permit is bound to concrete parameters and checked at the point of use. (Runtime enforcement)
6. Attempt expansion. Mid-task the agent decides it “needs” CRM customer data (outside the Authority Set). It cannot widen in place. Widening requires a fresh approval (a successor Mission). (Lifecycle)
7. Deny the expansion. Policy declines the CRM expansion. The original Mission is untouched and the agent does not get CRM access. (Lifecycle)
8. Delegate, narrowed. A sub-agent gathers the financials under a Child Mission scoped to query_financials only, expiry ≤ parent, no create_doc or notify_reviewer. (Delegation)
9. Revoke. The board meeting is cancelled. An admin revokes the Mission. Status reports the new state and the Signals push announces it. All further derivation stops, and the child transitions to the terminal cascaded state. (Delegation, Lifecycle)
10. Stop the work. The harness, which bound the session and queue to Mission state, halts the paused draft (session continuity is not authority), and orchestration unwinds the half-written document. (Agent runtime)
11. Reconstruct. The SCITT audit feed for this Mission shows one verifiable, append-only history (approval → consent → the permitted read → the denied CRM expansion → revocation), committed by hash so the financial contents stay out of the log. (Agent runtime)

And run the ending the other way, because most Missions do not die, they finish. No cancellation: the sub-agent returns the financials, the packet is published, and the notice goes to the audit committee. The Mission closes as completed through the Status profile’s complete operation. A deployment that wants each entry to retire as its step finishes gives the entry an Entry Discharge terminal_when condition (the record above carries none). The entry’s authority is spent once the party approved to assert that condition reports it and the AS commits the discharge, and the Mission stays active until it completes (Completion). Either way the same evidence feed reads clean end to end: proposed, approved, exercised inside bounds, finished. Alice got her packet, and the deployment can prove exactly how.

That is the whole category in one task: an approved object, authority derived from it, every consequential action checked against it, delegation that only narrows, a lifecycle that can stop it or let it finish, and evidence that reconstructs it either way.

What this replaces, and what it does not

Mission-based authorization adds one object. It does not displace the stack around it.

• Not OAuth. The Mission rides OAuth issuance, exchange, and sender constraint. The OAuth binding is an OAuth profile, not a successor.
• Not AuthZEN or your PDP. The runtime contract is binding-neutral: its AuthZEN profile binds it to the AuthZEN Authorization API, and its OAuth 2.0 profile maps OAuth access tokens and introspection onto its inputs. The Mission is a new input to the decision, not a new decision engine.
• Not resource policy. The resource stays authoritative for its own objects. A Mission permit is an upper bound, never a command.
• Not session management. The harness keeps owning execution continuity. It consults Mission state before resuming, and that is the whole change.
• Not model alignment. Nothing here makes an LLM’s reasoning trustworthy. The Mission bounds what a drifted or injected agent can reach, and the runtime layer enforces the bound.

What it adds is the piece those layers keep routing around: the governed task object they all bind to. The objections below route to the answers for the sharper versions of “isn’t this just X.”

Common objections

The recurring pushbacks live on their own page, built to be linked into the thread where the objection was raised: Common Objections to Mission-Based Authorization. The answers, for the people who run today’s control planes, organized by the plane the reader operates, from “isn’t this just RAR” and “we run Zero Trust” through the state tax, the consent screen, and the standing agent, each with the short answer and where the long one lives.

The draft family at a glance

Every part links its drafts inline. This table is the whole family in one place, all 51 documents: individual Internet-Drafts published as editor’s copies and proposed for discussion, none adopted by a working group. The names reflect the architecture: substrate-neutral profiles carry draft-mcguinness-mission-* names, while most OAuth-specific documents keep oauth in the name and “for OAuth 2.0” in the title.

The Role and Spec maturity columns are the repository’s own labels: Substrate Requirements is the only core document and the only candidate spec, and most of the rest are experimental. Track is the IETF category each draft requests. The Handbook guidance column is this handbook’s adoption advice. Adopt first is the Architecture, the OAuth binding, and the Resource Access Profile every example uses. Runtime-Enforced marks what agents that act add for that bundle, and Recommended what AI agents add for the Governed Agent bundle. By binding documents are adopted where the estate calls for them. Advanced documents wait for their use case. Evaluate only documents are for evaluation: each depends on a draft external dependency or defines a newer, less-exercised model. The proposed standardization surface is the Architecture, Substrate Requirements, and the OAuth binding. No production Mission deployment is known on any binding.

For AI agents, the architecture is explicit that consent evidence and the harness are not optional extras. They are the recommended agent stack, the Governed Agent level.

How to cite this handbook

Link the piece that matches what you are referencing:

• The whole handbook: the cover, the front door with the introduction and the chapter map.
• The category and definition: this Reference.
• The evaluation tool and the blueprint: the vendor test (Appendix D), and the blueprint.
• The standards map: the outside-in survey, every OAuth, WIMSE, and OpenID spec mapped to the architecture with its role and deltas (Appendix E).
• The vocabulary: the Glossary (Appendix F), every term, A to Z.
• The mental model for non-specialists: What the Corporate Card Already Solved.
• The missing layer and its laws: the five laws of delegated authority above, or the architecture chapter for the full argument.
• The argument for why the Mission is the missing object: The Mission Is the Missing Abstraction.
• The primitive’s definition, roles, and name: the object model, trust boundaries and roles, and why “Mission”, on this page.
• The safety claim (what runtime enforcement adds): Mission-Bound Runtime Enforcement.
• The adoption path (crawl, walk, run): Adopting Mission-Bound Authorization.
• The OAuth wire implementation: the draft family.
• The MCP application: Least-Privilege MCP Tool Calls Need a Mission.
• The wire exhibits: Mission-Bound Authorization on the Wire (Appendix B).
• To discuss or object: issues on the draft repository.

One-line definition to quote: the bottom line, at the top of this page.

A note on requirement language

The handbook quotes requirement keywords such as MUST, SHOULD, and MAY with their BCP 14 meanings (RFC 2119, RFC 8174) when they appear in all capitals. Conformance applies to the profile section each requirement appears in. The drafts are the normative text.