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 August 11, 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 four substrate bindings with OAuth 2.0 as the flagship.

The vocabulary has a strict hierarchy:

A mission-based authorization system has a durable approved task object, derives authority from it, checks consequential actions against it, 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 the hard truth:

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

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, then binds tokens, runtime decisions, delegation, lifecycle, and audit back to that object.

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 the durable, integrity-anchored, lifecycle-governed governance object for a user-approved task. 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 operationalizes them as the Architecture document’s seven Mission Invariants: the five laws plus two wire-level mechanics (enforcement fails closed, and the integrity anchors commit what was approved rather than prove its semantics).

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 numbers

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

The six questions are the six properties in interview form, and the laws are what the 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 core + runtime enforcement + AuthZEN binding + a freshness source (Status, or issuer introspection)

This is the Runtime-Enforced level 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. Every dependency in it is a ratified OAuth RFC or a finalized OpenID specification, with one tracked exception scoped out of the formula: the issuance core’s single Internet-Draft reference, the Actor Profile, is confined to its OPTIONAL delegation capability. Lifecycle Signals, the stable 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 conformance claim names its assurance level and its enforcement scope, and every line can be verified against the implementation checklist below. The level names the dependency bundle a deployment runs. The claims name what it can prove: proof obligations become available at a level, and a relying party compares claims, not level names. 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 the load-bearing part: 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 agent safety. It is governance metadata until a PEP checks each consequential action against it. And the core’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 six. The containment matrix places Mission termination beside the 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 that own 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 ladder), 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 flagship binding is OAuth 2.0, where authority is derived as Rich Authorization Requests and the token binding is the mission claim. The standalone Mission Authority Server, AAuth, and (as an experimental sketch) UMA 2.0 bindings carry the same object on other substrates. 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 hosts the same governance object at the AAuth Person Server, with lifecycle extensions covering the expiry and management surfaces base AAuth leaves open, Mission Substrate Requirements consolidates what any further binding must provide, a mandatory contextual-governance kernel plus seven 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. The reference model is the six properties. OAuth is the flagship binding of it.

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 accountable approver (the user in the common case, an authorized policy tracing to one otherwise) decides against committed inputs, 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 splits at the family’s own conformance seam, because the family defines conformant deployments at two strengths. A system is mission-based, providing Mission-substrate conformance (the bar the Baseline Issuance level and every binding meets), when the first four hold:

1. Approved task object: a durable record of the task a human (or authorized policy) approved. 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 provides Runtime-Enforced Mission conformance, the bar behind any action-time defense claim, 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, which is what a Baseline deployment is, and it claims nothing about action-time defense.

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 it does not exist at the resource to be consulted.
• 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.

The authority ceiling, immutable after approval:

• Authority Set: the maximum grantable authority derived from the Intent, 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 Approver’s own authority, because an approval grants nothing the Approver could not grant, while resource-owner and deployment policy stay live checks at each decision point.
• 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). Token Exchange never creates a child Mission, 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.

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, so a lifecycle transition moves the state and its version, never a hash. 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 ceiling under the subset rule, with its own lifecycle bounded by the parent’s.

“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 Authority Set.

The subset rule, compactly. 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.

 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

{
  "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "purpose": "urn:example:mission:board-packet",
    "resources": ["https://finance.example.com",
      "https://docs.example.com",
      "https://workflow.example.com"],
    "constraints": ["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:jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE",
  "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" },
  "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 in the mission claim alongside authority_hash. subject and approver are {iss, sub} pairs, authoritative for principal equality, and they may differ when an administrator approves on a user’s behalf. 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 core 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 (core): approved. Derivation and reliance permitted.
• revoked (core): terminated by user, admin, or policy. Terminal.
• expired (core): 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 discharge condition 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 substrate’s state authority. On the OAuth substrate that is the Authorization Server, which validates Intents, runs approval events, stores the record, and gates issuance on its state. The substrate-local default keeps the minimum profile coherent, since a deployment can claim the Baseline Issuance level without introducing a new server component.

The Mission Authority Server (MAS) is the standalone binding, the AS-optional mode: 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 is a standalone service that 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, state-gated tokens without moving approval into the AS, so one canonical Mission record gates credentials minted across many issuers.

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 precise sense in which the category is forced rather than preferred. 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. The one row that breaks none is not an alternative but an instance.

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 deployment ladder

The smallest useful deployment, and the path up:

• 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, not action-time defense.
• 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 turns governance metadata into agent safety.
• Stage 4: Lifecycle. Signals, expansion, and completion: 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.

Most AI agents that touch private data, untrusted content, or external side effects need at least Stage 3, and Stages 5–6 for fan-out and full governance. Stages 1–2 alone are not enough for consequential autonomy.

The stages roll up into the four claimable Mission Assurance Levels, one line each:

Baseline is a real category claim at issuance strength, and what it cannot claim is action-time defense: the litmus’s four-and-two split.

The level is one axis. The binding (OAuth AS, standalone Mission Authority Server, AAuth Person Server, or the experimental UMA sketch) 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 authority-native (the substrate’s own authority object 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 is claimable on 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 level is a harness claim and structurally 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 the levels as an unlock ladder too: Baseline governs the read-only pilot, Runtime-Enforced makes reversible writes defensible (the read-only ceiling breaks here), Governed Agent makes unattended operation and delegation defensible, and High-Assurance covers the irreversible, external-commitment, and privileged classes. 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 the Runtime-Enforced level, with the deeper treatments linked.

Conformance is 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 not a conformance claim. It is marketing. 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 core already keeps the token-side claim a reference (id, issuer, authority_hash), never the Intent’s contents, and deployments should hold that line: resource servers and intermediate PEPs need the identifier and anchors, 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 unprotected, 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 all load-bearing 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 approved, governed task (durable, lifecycle-owned).
• Authority Set: the derived, grantable authority the Mission bounds.
• Projection: any substrate-specific, audience-bounded credential or assertion derived from the 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 → Authority Set → Mission → Projection → Runtime Decision → Evidence. The state authority derives the Authority Set from the validated Intent before consent, the approved Mission commits both, 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":{"constraints":["Q3 2026","Example Corp","confidential"],"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"]}}

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":{"constraints":["Q3 2026","Example Corp","confidential"],"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"]}}' \
  | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '='
# => jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE

So intent_hash = sha-256:jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE. 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.

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 and narrows the Intent and derives the Authority Set it will ask Alice to approve. (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. Each entry’s terminal_when condition fires as its step completes (Completion), so create_doc and notify_reviewer retire themselves, the Mission closes as completed, and 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 core is an OAuth profile, not a successor.
• Not AuthZEN or your PDP. The runtime contract binds to the AuthZEN Authorization API. 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 of these are individual Internet-Drafts published as editor’s copies and proposed for discussion. None is adopted by a working group. The names reflect the architecture: substrate-neutral profiles carry draft-mcguinness-mission-* names, while the OAuth bindings keep oauth in the name and “for OAuth 2.0” in the title.

The Maturity column follows the repository’s adoption order. Adopt first is the Architecture and the core. Minimum is what agents that act add for the Runtime-Enforced level. Recommended is what AI agents add for the Governed Agent level. By binding profiles carry the standalone Mission Authority Server, the issuance grant join, the AAuth Person Server with its two lifecycle extensions (expiry and management), and the substrate requirements, adopted where the estate calls for them, with the UMA 2.0 sketch as the experimental fourth binding. Advanced profiles are stable design to adopt when the use case arrives. Experimental profiles are for evaluation only: each depends on an unratified substrate or defines a newer, less-exercised model, and each names a stable path to prefer where one exists.

For AI agents, the README is explicit that consent evidence and the harness are not optional extras. They are the Recommended maturity, 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 (runtime is load-bearing): 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.