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: the definition, the terminology, the one-sentence Mission, the five laws with their violations, the numbers, the layer vocabulary, the protocol MVP formula, the honest deployment claim, the what-not-to-claim list, the revocation statement and its matrix, the vendor test, and the canonical picture, each written to be copied whole, with Mission-Bound Authorization on the Wire as the companion exhibits. The litmus test and everything deeper follow. This page tracks the draft family’s editor’s copies as of July 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 three 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 that keeps it honest:

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 protocol MVP formula

Protocol MVP = issuance core + runtime enforcement + AuthZEN binding + a freshness source (Status, or issuer introspection)

Every dependency in the formula is a ratified OAuth RFC or a finalized OpenID specification, with one tracked exception scoped out of the wedge: 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 adoption-wedge 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 architecture’s Mission Deployment Profile is the spec-level form of this claim: a publishable manifest of level, binding, state sources, PEP coverage, custody, evidence, and residual_risks. 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.
• 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:

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 (stages), the checkable claim (checklist), what it does not solve (non-goals), the glossary, 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 mandate, 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 and AAuth 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, and Mission Substrate Requirements consolidates what any further binding must provide. 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

A system is mission-based only if it has all six:

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. Runtime enforcement: consequential actions are checked against the current task state at the point of use, not just at issuance.
5. Lifecycle: the task can expire, be revoked, expand (via fresh approval), and complete. Only an active task permits reliance.
6. Evidence: decisions and lifecycle events bind back to the task, so audit can reconstruct it.

Drop any one and you have something weaker: scopes without a task, sessions without approval, a PDP without an approved object, or a claim without enforcement.

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

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.
• 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 precision keeps the rule honest. 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 (so a derivation can be re-checked), 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.

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.

Minimum viable mission-based authorization

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:

Naming the Baseline level is honest. Claiming the category from it is not: Baseline alone cannot pass the six-property litmus, whose runtime-enforcement property arrives one level up.

The level is one axis. The binding (OAuth AS, standalone Mission Authority Server, or AAuth Person Server) is orthogonal, and a deployment names both. 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 protocol MVP, 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 this:

This deployment claims the Runtime-Enforced level (the protocol MVP) for the finance, docs, and workflow APIs, with PEP coverage at MCP tools/call and the resource APIs, Mission Status freshness within 30 seconds, push revocation for the workflow domain through the Signals profile, and no runtime-enforcement claim for direct shell egress.

Every clause maps to a row above and can be verified. A claim that cannot be written in this form is not a conformance claim. It is marketing. The honest deployment claim in the citation kit is the same claim as a reusable template, and 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 honest 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

Intent step

• Mission Shaper: a client-side component that turns a prompt or trigger into a candidate Mission Intent. Proposes only. Grants no authority.
• Mission Intent: the structured proposal: goal, resources, and expires_at (required), with optional constraints, proposed_authority, success_criteria, purpose, and controls. Closed at the top level: unknown members are rejected, and machine-actionable extensions ride in controls. Submitted via the mission_intent parameter through PAR.
• Shaping Evidence: an optional record of how the proposal was produced. Audit material, not authority.

Mission step

• Approval event: the AS validates the Intent and derives the Authority Set, the Approver consents to the rendered Intent + derived Authority Set, and the AS commits the anchors and creates the Mission active, atomically.
• Authorization Server (Mission Issuer): holds the Mission record, derives authority, runs the approval event, gates issuance.
• mission claim: the object on every issued token: id, issuer, authority_hash, plus the OPTIONAL expires_at the issuance grant profile defines.
• intent_hash: canonical hash of the approved Mission Intent.
• Consent Evidence / consent_rendering_hash: a companion artifact committing the structured disclosure the AS recorded as rendered (not the pixels, not comprehension).
• Subject / Approver: {iss, sub} principals: the user the task is for, and the principal who approved it. They may differ. The Approver may be a human or an authorized policy authority, and a non-human approval traces to a human-consented ceiling or policy (who may approve).

Authority step

• Authority Set: the maximum authority committed by authority_hash, as mission_resource_access entries (resource, actions, constraints, per-entry delegation), plus any other RFC 9396 types a deployment registers.
• authority_hash: canonical hash of the Authority Set.
• authorization_details: the RFC 9396 wire shape for derived authority.
• act chain: the RFC 8693 actor chain. A delegated token carries the same mission claim with subset authority.

Enforcement step

• PEP / PDP: the Policy Enforcement Point obtains a permit from the Policy Decision Point before each consequential action. The PDP evaluates against the live Mission.
• parameter_digest: binds a permit to concrete request parameters, closing the time-of-check-to-time-of-use gap.
• Decision Evidence / Execution Evidence: per-decision and per-outcome audit records.

Lifecycle, roles, delegation

• Core states active / revoked / expired. Companion states suspended / completed (Status), superseded (Expansion), and cascaded (Child Delegation). Unknown states are treated as non-active.
• Mission Status (pull, signed, mission_id-keyed) and Lifecycle Signals (SET events, delivered push or poll). Expansion widens via a fresh approval that supersedes the predecessor. Completion / terminal_when is monotonic, per-entry discharge.
• Child Mission: a strict-subset Mission a parent authorizes for a sub-agent, with cascade revocation. Offline attenuation: minting a narrower child token off the AS hot path, kept safe by the runtime re-checking Mission state.

The handbook’s named artifacts

• The five laws: Durability, Attribution, Narrowing, Termination, and Containment, the layer’s substrate-neutral invariants, quoted above.
• The claim gate / litmus test: the six properties a system must have to claim mission-based authorization, expanded above.
• The vendor test: the same six properties as questions to ask a vendor, with what failing answers sound like.
• The protocol MVP: the adoption wedge, per the formula: issuance core, runtime enforcement, AuthZEN binding, and Status.
• The Mission Assurance Levels: Baseline Issuance, Runtime-Enforced (the protocol MVP), Governed Agent, and High-Assurance Agent, with the binding (OAuth AS, standalone Mission Authority Server, or AAuth Person Server) as the orthogonal axis, staged as crawl, walk, run in Adopting Mission-Bound Authorization, and read as an unlock ladder: each level makes a broader class of write authority defensible.
• The control plane for delegated authority: the operational reading of the layer: the Mission record is desired state, issuance and the runtime gate are the data plane consulting it, the freshness dial is propagation, and the discovery loop is reconciliation for authority. The strategic case is in the architecture chapter, and the structural mapping is the Authority Control Plane part.
• The read-only ceiling: the posture most estates start from (read-only agents, humans approving or executing the writes, permanent pilots), what it costs, and the graduation path off it, named in Adopting.
• The discovery loop: deny, request, approve, expand, retry: how the open world arrives under governance, named in Adopting.
• Survivable incorrectness: the design stance beneath the laws, inherited from the Mission Shaping series: assume the agent will sometimes be wrong and keep the system governable when it is, with least exposure as the input arm and the laws and runtime gate as the action arm.
• Least exposure: bound what the agent may see as deliberately as what it may do, the exposure discipline whose enforceable slice today is the edges the trifecta-containment claim names.
• The honest deployment claim: the claim template naming level, enforcement scope, freshness, evidence, and exclusions, published at spec level as the architecture’s Mission Deployment Profile.
• Open world: the deployment condition the architecture assumes: tools and resources discovered at runtime rather than pre-registered, trust relationships that form after authorization time, delegation to actors unknown at approval, untrusted content in the working set, and authorization decisions made with incomplete knowledge of what the task will need. The Open-World OAuth series is the published treatment, and the discovery loop is how the open world arrives under governance.

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 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 answer 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, the protocol MVP. 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, and the substrate requirements, adopted where the estate calls for them. 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 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.
• To discuss or object: issues on the draft repository.

One-line definition to quote:

Mission-based authorization is the layer between user intent and per-request authorization. It makes the approved task a first-class governance object, then binds credentials, runtime decisions, delegation, lifecycle, and audit back to it.

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.