---
title: "Mission-Based Authorization: The Field Reference"
date: "2026-07-10T20:00:00-07:00"
lastmod: "2026-07-10T20:00:00-07:00"
description: "The canonical reference for mission-based authorization, the authorization layer for AI agents: the category definition, the six-property litmus test, how it compares to scopes, sessions, task IDs, and PDPs, the adoption stages, the threats and non-goals, the glossary, and one worked example end to end."
summary: "Mission-based authorization governs the approved task, not just the credential, session, or request. This page is the field reference: the definition and litmus test for what counts as mission-based, a competitive landscape, the minimum viable deployment, threats and non-goals, the canonical diagram and glossary, and the Q3 board-packet example threaded through the handbook."
slug: "mission-based-authorization-field-reference"
tags:
- "OAuth"
- "Authorization"
- "Agentic Identity"
- "Mission-Bound Authorization"
- "Intent-Based Authorization"
- "AuthZEN"
- "Internet-Draft"
---
This is the standing reference for the
[Mission-Bound Authorization handbook](/mission-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-mission-in-one-sentence), the
[five laws](#the-five-laws-of-delegated-authority) with their
violations, [the numbers](#the-numbers), the
[layer vocabulary](#the-layer-vocabulary), the
[protocol MVP formula](#the-protocol-mvp-formula), the
[honest deployment claim](#the-honest-deployment-claim), the
[what-not-to-claim list](#what-not-to-claim), the
[revocation statement](#revocation-in-one-statement) and its
[matrix](#when-revocation-bites), the
[vendor test](#the-vendor-test), and the
[canonical picture](#the-canonical-picture), each written to be copied
whole, with
[Mission-Bound Authorization on the Wire](/notes/mission-bound-authorization-on-the-wire/)
as the companion exhibits. The [litmus test](#what-counts-the-litmus-test)
and everything deeper follow. This page tracks the draft family's
editor's copies as of July 11, 2026.
| Use this page to | Start at |
| --- | --- |
| Get the mental model first | [What the Corporate Card Already Solved](/series/what-the-corporate-card-already-solved/), then [the bridge into the architecture](/notes/from-the-card-to-the-architecture/) |
| Define the category | [The bottom line](#the-bottom-line) and the [litmus test](#what-counts-the-litmus-test) |
| Evaluate a vendor or deployment claim | [The vendor test](/notes/mission-based-authorization-vendor-test/), then [the implementation checklist](#the-implementation-checklist) and [what not to claim](#what-not-to-claim) |
| Implement the protocol MVP | [The formula](#the-protocol-mvp-formula) and the [wire exhibits](/notes/mission-bound-authorization-on-the-wire/) |
| Define the primitive, its roles, and its name | [The object model](#the-mission-object-model), [trust boundaries and roles](#trust-boundaries-and-roles), and [why "Mission"](#why-mission) |
| See what changes and what never does | [The object model's aggregate and mutability rules](#the-mission-object-model) |
| Price revocation by path | [The statement](#revocation-in-one-statement) and [the matrix](#when-revocation-bites) |
| Place the record in the estate | [Where the Mission record lives](#where-the-mission-record-lives) and [the division of labor](#trust-boundaries-and-roles) |
| Check the record's own privacy | [The Mission record is itself sensitive](#the-mission-record-is-itself-sensitive) |
| Compare to scopes, sessions, PDPs, IGA, PAM | [The landscape](#competitive-landscape) and the [objections](/notes/common-objections-to-mission-based-authorization/) |
| Cite the draft family | [The catalog](#the-draft-family-at-a-glance) and [how to cite](#how-to-cite-this-handbook) |
# 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](https://github.com/mcguinness/mission-bound-authorization)
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:
| Term | What it names |
| --- | --- |
| **Delegated authority management** | The missing layer of the stack |
| **Mission-based authorization** | One design pattern for that layer, and the category this page defines |
| **Mission-Bound Authorization** | This draft family: one instance of the category, with OAuth 2.0 as the flagship binding, and the standalone Mission Authority Server and AAuth as the others |
| **Mission** | The concrete approved-task object in this draft family |
| **Mandate** | A portable, verifiable statement about a Mission. Evidence, not a second object |
> 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:
| Layer | The question it answers |
| --- | --- |
| Identity | Who? |
| OAuth | Who delegated? |
| Scopes | Roughly what? |
| Policy | Whether, right now. |
| **Mission** | **Why does this authority exist, and does it still?** |
And the shorthand contrasts, for the same slide:
| Concept | Answers |
| --- | --- |
| Prompt | *What was requested?* |
| Workflow | *How will it execute?* |
| Token | *Is this credential currently valid?* |
| Policy | *Is this request permitted right now?* |
| **Mission** | ***What authority exists, why, for how long, on whose approval?*** |
## The five laws of delegated authority
The layer's invariants, stated to be quoted. They hold on any
substrate, and the [handbook](/mission-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:
| Law | The failure when violated |
| --- | --- |
| Durability | The 02:00 resume: every credential valid, the approved task gone |
| Attribution | The blurred principal: nobody can say who acted under whose authority, through what chain |
| Narrowing | The borrowed card: the delegate inherits everything the delegator had |
| Termination | The gym that bills the replacement card: the ending that does not end |
| Containment | The deleted production database: nothing the agent did was outside what its credentials allowed |
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](/series/mission-shaping/):
> **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:
| Artifact | Job | Count | Relation |
| --- | --- | --- | --- |
| The five laws | Architectural invariants | 5 | What must remain true on any substrate |
| The litmus properties | The category gate | 6 | What a system must implement to claim the category |
| The vendor questions | The gate as an interview | 6 | One question per property |
| The Mission Assurance Levels | Deployment claims | 4 | How much of the architecture is deployed |
| The adoption stages | The build order | 3 | Crawl, walk, run |
| The bindings | Substrates | 3 | Where the Mission record lives |
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](/series/designing-mission-bound-authorization/#the-protocol-mvp)
carries the adoption-wedge argument, and
[Adopting Mission-Bound Authorization](/notes/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](#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.
| Claim line | Example |
| --- | --- |
| Claim | Runtime-Enforced (the protocol MVP) |
| Scope | Finance, docs, and workflow APIs |
| Enforcement | PEP at MCP `tools/call` and at the resource APIs |
| Mediated paths | Finance and docs APIs, and every `tools/call` |
| Issuance-gated only | Workflow API: revocation bounded by a 10-minute token lifetime |
| Unmediated paths | None claimed |
| Freshness | Mission Status within 30 seconds on mediated paths |
| Signals | Workflow-domain push revocation |
| Evidence | Decision Evidence for all consequential calls, denials included |
| Exclusions | No runtime-enforcement claim for direct shell egress |
## 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:
| Enforcement path | Worst-case revocation latency | What you may claim |
| --- | --- | --- |
| PEP + Status polling (or issuer introspection, or the swarm-scale [Status List](/notes/mission-lifecycle-and-change/#observe-and-revoke-pull-and-push)) | Staleness bound + permit validity window + the class's execution bound | Runtime revocation within a published freshness bound |
| PEP + Signals push, with Status fallback | Seconds, degrading to the polling bound when the stream goes quiet | Prompt revocation that never fails open |
| Issuance gating only, no PEP | The outstanding token lifetime | Bounded-staleness revocation at the token lifetime: the legacy-estate bridge, a conforming freshness source when the bound is published, for classes below high-consequence |
| Short-lived tokens alone | The token lifetime, renewed forever | Nothing: a revoked task keeps deriving fresh tokens unless issuance is gated on task state |
| An unmediated path | Never | Nothing. Name it in the enforcement scope |
## The vendor test
The test is its own page, built to be linked and pasted into an
evaluation:
[The Mission-Based Authorization Vendor Test](/notes/mission-based-authorization-vendor-test/).
Six questions, the [litmus property](#what-counts-the-litmus-test) each
one probes, and what failing answers sound like. A vendor that passes
all six should be able to write the
[honest deployment claim](#the-honest-deployment-claim) above, and the
[implementation checklist](#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.
```mermaid
flowchart LR
subgraph S1["Intent"]
U([User])
SH[Shaper]
end
subgraph S2["Mission"]
MI[Mission Issuer
OAuth AS]
M[("Mission record
intent_hash, authority_hash,
state")]
end
subgraph S3["Authority"]
AG[Agent instance
+ act chain]
end
subgraph S4["Enforcement"]
PEP[PEP]
PDP[PDP]
RS[Resource Server]
end
subgraph S5["Lifecycle"]
ST[Status pull /
Signals push]
H[Harness]
end
subgraph S6["Evidence"]
AUD([Auditor])
end
U --> SH
SH -->|Mission Intent via PAR| MI
MI -->|renders derived authority| U
U -->|approves| MI
MI --> M
M -->|state-gated issuance,
mission-bound token| AG
AG -->|action + parameters| PEP
PEP -->|evaluate| PDP
PDP -->|permit / deny| PEP
PEP --> RS
PDP -.->|current state| ST
ST -.-> M
ST --> H
H -.->|stop on non-active| AG
M -->|lifecycle events| AUD
PDP -->|decision evidence| AUD
PEP -->|execution evidence| AUD
```
Everything below is the detail behind the bottom line: what qualifies as
mission-based ([litmus](#what-counts-the-litmus-test)), how it differs
from what you already run ([landscape](#competitive-landscape)), the
smallest useful deployment ([stages](#minimum-viable-mission-based-authorization)),
the checkable claim ([checklist](#the-implementation-checklist)),
what it does *not* solve ([non-goals](#threats-and-non-goals)), the
[glossary](#glossary), and one [worked example](#the-running-example-end-to-end).
# 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](/series/designing-mission-bound-authorization/#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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html)
hosts the same governance object at the AAuth Person Server, and
[Mission Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html)
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](https://datatracker.ietf.org/doc/draft-hartman-credential-broker-4-agents/)
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?"
| Object | Why it is not a Mission |
|---|---|
| Prompt | What the user typed: free-form, untrusted, upstream of every governance object. The Shaper turns it into a proposal, and approval turns the proposal into a Mission. |
| Workflow | How the agent will execute, not what was approved. Two workflows for the same task share nothing at the protocol layer. |
| Ticket | Human work tracking. It references a task without bounding, deriving, or revoking authority. |
| Access token | A short-lived projection. `jti` identifies the token, not the task. |
| Scope / authorization detail | Expresses authority, not the approved task or its lifecycle. |
| Consent record | Proves an approval event. Does not govern the resulting work over time. |
| Session | Preserves runtime continuity. Commits no maximum authority. |
| Policy | Evaluates requests. It is not the user's approved task. |
| `purpose` URI | Labels a task *class*. Has no instance lifecycle. |
| Task / trace ID | Correlates activity. Carries no authority or approval. |
| OAuth grant | Records a delegation event. It carries no task, no lifecycle, and no purpose. |
| Relationship (a ReBAC tuple) | Encodes who relates to what, timelessly. No approval, no task, no end. |
| Delegation chain | Records actors, not the mandate they act under. |
## 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](/notes/mission-bound-authority/#crossing-authorization-domains).
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](#reproducible-test-vector) below.
```json
{
"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](/notes/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.
```mermaid
stateDiagram-v2
[*] --> active: Approval event
active --> revoked: Termination (user, admin, policy)
active --> expired: expires_at reached
active --> suspended: Pause (Status)
active --> completed: Task done (Status)
active --> superseded: Expansion successor
active --> cascaded: Parent terminal (Child Delegation)
suspended --> active: Resume
suspended --> revoked: Termination
suspended --> expired: expires_at reached
suspended --> completed: Task done (Status)
suspended --> cascaded: Parent terminal (Child Delegation)
revoked --> [*]
expired --> [*]
completed --> [*]
superseded --> [*]
cascaded --> [*]
```
- **`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](/notes/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.
| Activity | Trusted party | Trusted for | NOT trusted for |
| --- | --- | --- | --- |
| **Shaping Mission Intent** | Mission Shaper (client-side) | Producing a structured proposal from user input. | Authorizing anything. The Shaper's output is untrusted until the state authority validates it. |
| **Validating Mission Intent** | State authority (OAuth AS, or the MAS in the AS-optional mode) | Admitting or refusing the Mission Intent against deployment policy and requester bounds. Narrowing applies to the authority derived from it, never to the Intent. | Originating the user's task. The proposal comes from the Shaper or orchestrator. Validation accepts or refuses what is submitted. |
| **Deriving Authority Set** | State authority | Translating an approved Mission Intent into the maximum permitted Authority Set, scoped to resources and actions registered with the state authority. | Inventing authority not anchored in the Intent. The Authority Set is derived from approval, not enlarged by issuer policy alone. |
| **Rendering consent** | State authority (in the AS-optional mode, the MAS renders it itself) | Presenting the validated Intent and derived Authority Set to the approving principal, and committing to the rendered disclosure via the Consent Evidence companion's `consent_rendering_hash` where deployed. | Proving that the principal understood the disclosure. Consent UX assurance, language clarity, and human comprehension live above the protocol layer. |
| **Storing Mission state** | State authority | Committing the Mission record (Intent, Authority Set, integrity anchors, lifecycle state, consent reference). Owns the lifecycle state machine. | Owning credential issuance independently. Issuance gates on Mission state. The Mission record does not become an access credential by itself. |
| **Projecting authority into credentials** | Credential issuer (the OAuth AS for access tokens and ID-JAGs, with other substrates' issuers as future work) | Issuing audience-bound credentials that carry the Mission reference and stay inside the Authority Set. | Enlarging authority beyond the Authority Set. Every projection is a subset of the approved authority. |
| **Enforcing policy at runtime** | PDP (consulted by the Resource Server's PEP, or by an orchestrator PEP) | Evaluating each consequential action against current Mission state, the audience-relevant Authority Set projection, authenticated actor context, and Resource policy. | Replacing the state authority's authority commitment. The Authority Set is the upper bound. The PDP narrows, never widens. |
| **Emitting evidence** | Every party that makes a decision (admission, consent, lifecycle, runtime) | Producing a record bound to `mission.id` and `mission.issuer`, carrying the integrity anchors and binding evidence. | Mutating the Mission record. Evidence records reference the Mission. They do not modify it. |
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](/notes/adopting-mission-bound-authorization/#run-governed-and-beyond)
without introducing a new server component.
The [Mission Authority Server (MAS)](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html)
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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html)
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.
| Approach | What it solves | What it misses (for a governed task) | Law it breaks alone | How Mission composes with it | Enough on its own when |
|---|---|---|---|---|---|
| OAuth scopes / RAR | Expresses requested authority | No durable task lifecycle | Durability, Termination | Authority is derived from the Mission into RAR-shaped entries and projected into tokens with the `mission` claim | The credential's lifetime *is* the task (one grant, one resource) |
| Agent identity (WIMSE, SPIFFE, instance attestation) | Who is acting, provably | Not what the acting is for, or until when | Containment | Attested instances and actor chains are the substrate Mission authority binds to | The risk is impersonation, not ungoverned work |
| Sessions | Runtime continuity | Not approval or authority | Durability | The harness binds resumable session state to Mission state and re-checks before continuing | A human drives every consequential action |
| Workflow / task IDs | Operational tracking | Not interoperable authority | Termination, Containment | Workflow steps and unwind plans reference the Mission as the governed subject, not merely a work item | You need orchestration, not authorization |
| Trace IDs | Correlation | Not governance | Attribution | Evidence and logs carry the Mission reference so correlation joins to approved authority and lifecycle | You only need to join logs, not gate actions |
| PDP / ABAC / ReBAC | Per-request decisions | No approved task object by default | Durability | The PDP evaluates each consequential action against current Mission state, derived authority, actor context, and resource policy | Per-request attributes fully capture intent |
| Agent approval prompts | Human checkpoint | Often fragmentary and unauditable | Attribution | Consent Evidence and action-bound approval turn prompts into recorded decision input linked to the Mission | Volume is low enough to vet each action |
| Read-only agents + human-in-the-loop writes | Caps mutation blast radius while agents are piloted | The value ceiling: reads still steer and leak the agent, and the human executing the writes becomes the fatigued, unmediated enforcement point | Containment | The Mission makes write authority grantable: right-sized derivation, per-action permits, and exposure discipline replace the blanket deny | The work is genuinely read-only and the exposure surface is bounded |
| IGA access requests | Governed approval of entitlements | The grant it produces is standing authority: no task binding, no runtime enforcement, no automatic end | Termination, Containment | Deferred Approval is deliberately shaped like an IGA review, and the approval's output is a bounded, enforced, self-terminating Mission instead of a standing entitlement | Access is to durable roles, not tasks, and humans exercise it |
| PAM / just-in-time elevation | Time-boxed privileged access with check-out and recording | Elevates an identity, not a task. Session recording is evidence after the fact, not a permit before the action | Containment | A Mission is task-scoped elevation: authority derives from the approved work, each action needs a permit, and revocation ends the task everywhere | The privileged principal is a human whose session ends when they log off |
| Credential brokers (the proposed [CB4A](https://datatracker.ietf.org/doc/draft-hartman-credential-broker-4-agents/)) | No real credentials on agents: just-in-time, short-lived, sender-constrained leases minted per request, with custody done properly | The lease is not the task: no durable approved object, revocation ends tokens rather than authority, enforcement happens at issuance, and multi-agent composition is detected rather than structurally narrowed | Durability, Termination, Containment | The broker becomes a Mission-gated credential plane: issuance consults Mission state, and its policy point evaluates each request against the approved task rather than policy alone | The credential lease is the whole task and detection suffices for composition |
| MCP Tasks | Held / long-running work | Not approved purpose | Containment | MCP tool discovery and invocation can carry a Mission reference so each tool call is checked against approved work | You need a work handle, not a mandate |
| Capability tokens (macaroons, biscuits, UCAN) | Attenuable, offline-verifiable authority | No approval event, lifecycle, or task object | Durability, Termination | Attenuated tokens carry the same Mission binding and remain subject to runtime Mission-state checks | Offline attenuation is the whole need and revocation is not |
| [AAuth Mission](/notes/aauth-now-has-a-mission-layer/) (first-class in the proposed protocol since its 01 revision) | A native task object on a clean-slate agent substrate | *(a sibling instance of the category, not a competitor)* | None. An instance of the category | The family's AAuth binding hosts the Mission model at the AAuth Person Server, with issuance gating intact | You are on AAuth and need no cross-substrate governance |
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](#the-five-laws-of-delegated-authority), 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](/notes/mission-lifecycle-and-change/#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](/notes/adopting-mission-bound-authorization/#you-do-not-need-an-agent-to-start)
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:
| Level | One line |
| --- | --- |
| Baseline Issuance | Governance metadata and a derivation kill switch, not action safety |
| Runtime-Enforced (the protocol MVP) | Per-action enforcement plus state freshness, on ratified substrate |
| Governed Agent | Consent evidence, harness binding, and operational controls |
| High-Assurance Agent | Mediated custody, no unmediated path, action-bound approval, active freshness, and agent-isolated approval rendering |
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](/notes/adopting-mission-bound-authorization/#the-read-only-ceiling)
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.
| Dimension | What must be true | Defined in |
| --- | --- | --- |
| Surfaces | PAR accepts `mission_intent`. The approval event renders the derived Authority Set. A Mission Status endpoint and the lifecycle verbs are served at the issuer. The Signals push where revocation must bite in seconds | [The Mission](/notes/the-mission-is-the-missing-abstraction/), [Approval integrity](/notes/from-a-request-to-an-approved-mission/), [Lifecycle](/notes/mission-lifecycle-and-change/) |
| Claims carried | Every derived token carries `mission` (`id`, `issuer`, `authority_hash`) and its derived `authorization_details`, sender-constrained, with `exp` capped by the Mission's `expires_at`. Delegated work carries the `act` chain, and platforms running many instances carry attested instance identity | [The Mission](/notes/the-mission-is-the-missing-abstraction/), [Delegation](/notes/mission-bound-authority/) |
| PEP placement | A PEP sits at the last controllable boundary before every consequential action in scope: the resource API, the MCP `tools/call`, the egress proxy, the orchestrator for local side effects | [Runtime enforcement](/notes/mission-bound-runtime-enforcement/) |
| Evidence | Decision Evidence for every consequential decision, including denials. Execution Evidence for high-consequence and duration-metered actions. Consent Evidence where the Governed Agent level is claimed | [Approval integrity](/notes/from-a-request-to-an-approved-mission/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement/), [Agent runtime](/notes/the-agent-runtime-and-audit/) |
| Freshness | Only `active` permits reliance, within a published staleness bound. High-consequence classes require an active freshness mechanism: issuer introspection or Mission Status as the fail-closed source, with the Signals push as acceleration | [Runtime enforcement](/notes/mission-bound-runtime-enforcement/), [Lifecycle](/notes/mission-lifecycle-and-change/) |
| Honest claim | Name the assurance level and the enforcement scope: which resources, action classes, and execution paths are covered, and which are not | [Runtime enforcement](/notes/mission-bound-runtime-enforcement/) |
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](#the-honest-deployment-claim)
in the citation kit is the same claim as a reusable template, and
[what not to claim](#what-not-to-claim) is its negative space.
# Adversary model
The non-goals below say what this does *not* solve. This is the
complementary view: the adversaries it *does* constrain, the layer that
constrains each, and the residual it leaves. The reasoning is developed
across the parts. This table is the consolidated map, and the
[Mission Security Model](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-security-model.html)
draft (Informational) is its spec-level counterpart: the trusted base,
the cross-cutting assumptions, and the consequence of each component's
compromise.
| Adversary capability | What the layers deny it | Residual |
|---|---|---|
| **Compromised agent** (controls the model and loop) | Mediated custody keeps the sender-constraint key off the agent. The PDP checks every consequential action. Delegation only narrows ([Delegation](/notes/mission-bound-authority/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement/)) | It can still misuse authority *within* the approved scope. Keep scope tight |
| **Prompt injection / untrusted content** steering the task | Authority comes from the approved task, not runtime inference. The PDP checks against that task, not the prompt ([Approval integrity](/notes/from-a-request-to-an-approved-mission/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement/)) | Cannot make the model's reasoning trustworthy. A mis-shaped Intent the Approver accepts is still approved |
| **Stolen or exfiltrated token** | State-gated issuance, the kill switch, and runtime freshness stop use once the Mission is revoked or expired. Sender-constraint binds the holder ([The Mission](/notes/the-mission-is-the-missing-abstraction/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement/), [Lifecycle](/notes/mission-lifecycle-and-change/)) | A non-sender-constrained token used inside its window before revocation |
| **Confused deputy / parameter swap (TOCTOU)** | `parameter_digest` binds the permit to concrete parameters. Mismatched execution fails closed ([Runtime enforcement](/notes/mission-bound-runtime-enforcement/)) | Only as good as the parameters the digest covers |
| **Stale or poisoned capability** (a tool redefined under the agent) | The capability is bound to the source digest recorded at derivation. Drift fails closed as `capability_drift` ([Runtime enforcement](/notes/mission-bound-runtime-enforcement/)) | The deployment must actually record and check source digests |
| **Over-broad approval** | *(nothing technical denies it)* | Explicit non-goal: breadth approved is breadth granted. Mitigated, never denied, by consent rendering, shaping discipline, templates and organizational priors, and [policy ceilings with a human floor](/notes/from-a-request-to-an-approved-mission/#who-may-approve) |
| **Runaway fan-out / sub-agent sprawl** | Fan-out controls, bounded depth, cascade revocation. Children are strict subsets ([Delegation](/notes/mission-bound-authority/)) | Offline-minted breadth is unobserved by the issuer and must be bounded by policy |
| **Equivocating or tampered audit** | SCITT transparency makes evidence tamper-evident and, with multiple independent services, non-equivocating ([Agent runtime](/notes/the-agent-runtime-and-audit/)) | A single transparency service is *trusted*, not proven, not to equivocate. Completeness is checkable only against an expected schedule |
## 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](/notes/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](https://www.rfc-editor.org/rfc/rfc8785)),
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:
```json
{"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:
```sh
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](/notes/from-a-request-to-an-approved-mission/#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-five-laws-of-delegated-authority).
- **The claim gate / litmus test:** the six properties a system must
have to claim mission-based authorization,
[expanded above](#what-counts-the-litmus-test).
- **The vendor test:** the same six properties as
[questions to ask a vendor](/notes/mission-based-authorization-vendor-test/),
with what failing answers sound like.
- **The protocol MVP:** the adoption wedge, per
[the formula](#the-protocol-mvp-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](/notes/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](/series/designing-mission-bound-authorization/#the-control-plane-for-delegated-authority),
and the structural mapping is the
[Authority Control Plane part](/notes/the-authority-control-plane/#the-authority-control-plane).
- **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](/notes/adopting-mission-bound-authorization/#the-read-only-ceiling).
- **The discovery loop:** deny, request, approve, expand, retry: how
the open world arrives under governance, named in
[Adopting](/notes/adopting-mission-bound-authorization/#composing-with-the-ecosystem).
- **Survivable incorrectness:** the design stance beneath the laws,
inherited from the [Mission Shaping series](/series/mission-shaping/):
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](/notes/least-exposure-is-broader-than-least-privilege/)
whose enforceable slice today is the edges the trifecta-containment
claim names.
- **The honest deployment claim:** the
[claim template](#the-honest-deployment-claim) 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](/series/open-world-oauth/) 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](/notes/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](/notes/the-mission-is-the-missing-abstraction/))*
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](/notes/from-a-request-to-an-approved-mission/))*
3. **Issue.** The agent gets a Mission-bound token carrying the `mission`
claim. *([The Mission](/notes/the-mission-is-the-missing-abstraction/))*
4. **Permit a read.** The agent reads Q3 financials. The PDP permits
`query_financials` against the live Mission. *([Runtime enforcement](/notes/mission-bound-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](/notes/mission-bound-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](/notes/mission-lifecycle-and-change/))*
7. **Deny the expansion.** Policy declines the CRM expansion. The
original Mission is untouched and the agent does not get CRM access.
*([Lifecycle](/notes/mission-lifecycle-and-change/))*
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](/notes/mission-bound-authority/))*
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](/notes/mission-bound-authority/), [Lifecycle](/notes/mission-lifecycle-and-change/))*
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](/notes/the-agent-runtime-and-audit/))*
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](/notes/the-agent-runtime-and-audit/))*
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](/notes/mission-lifecycle-and-change/#complete-discharge-narrows-one-entry-at-a-time)),
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](#common-objections) 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](/notes/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.
| Draft (editor's copy) | Covered in | Track | Maturity |
| --- | --- | --- | --- |
| [An Architecture for Mission-Bound Authorization](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-architecture.html) | Front door | Informational | Adopt first |
| [Mission-Bound Authorization for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html) | [The Mission](/notes/the-mission-is-the-missing-abstraction/), [Delegation](/notes/mission-bound-authority/) (the core) | Standards Track | Adopt first |
| [Mission Intent Shaping](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-shaping.html) | [Approval integrity](/notes/from-a-request-to-an-approved-mission/) | Informational | Advanced |
| [Mission Consent Evidence for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html) | [Approval integrity](/notes/from-a-request-to-an-approved-mission/) | Standards Track | Recommended |
| [Mission Deferred Approval for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval.html) | [Approval integrity](/notes/from-a-request-to-an-approved-mission/) | Standards Track | Advanced |
| [Mission Approval Revision for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval-revision.html) | [Approval integrity](/notes/from-a-request-to-an-approved-mission/) | Standards Track | Experimental |
| [Mission Child Delegation for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-child-delegation.html) | [Delegation](/notes/mission-bound-authority/) | Standards Track | Advanced |
| [Mission Offline Attenuation for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-attenuation.html) | [Delegation](/notes/mission-bound-authority/) | Standards Track | Experimental |
| [Mission Cross-Domain Projection for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-cross-domain.html) | [Delegation](/notes/mission-bound-authority/) | Standards Track | Advanced |
| [Mission-Bound Runtime Enforcement](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-runtime.html) | [Runtime enforcement](/notes/mission-bound-runtime-enforcement/) | Standards Track | Minimum |
| [Mission-Bound Runtime Enforcement: AuthZEN Profile](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authzen.html) | [Runtime enforcement](/notes/mission-bound-runtime-enforcement/) | Standards Track | Minimum |
| [Mission Consumption Metering](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-metering.html) | [Runtime enforcement](/notes/mission-bound-runtime-enforcement/) | Standards Track | Experimental |
| [Mission Status and Lifecycle for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-status.html) (the suite root, carrying completion and discharge) | [Lifecycle](/notes/mission-lifecycle-and-change/) | Standards Track | Minimum |
| [Mission Lifecycle Signals for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-signals.html) | [Lifecycle](/notes/mission-lifecycle-and-change/) | Standards Track | Advanced |
| [Mission Expansion for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-expansion.html) | [Lifecycle](/notes/mission-lifecycle-and-change/) | Standards Track | Advanced |
| [Mission Progressive Authorization for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-progressive.html) | [Lifecycle](/notes/mission-lifecycle-and-change/) | Standards Track | Experimental |
| [Mission Open-World Discovery](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-discovery.html) | [Adopting](/notes/adopting-mission-bound-authorization/) | Experimental | Experimental |
| [Mission Management for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-management.html) | [Lifecycle](/notes/mission-lifecycle-and-change/) | Standards Track | Advanced |
| [Mission-Aware Agent Harnesses](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-harness.html) | [Agent runtime](/notes/the-agent-runtime-and-audit/) | Standards Track | Recommended |
| [Mission Orchestration and Unwinding](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-orchestration.html) | [Agent runtime](/notes/the-agent-runtime-and-audit/) | Standards Track | Experimental |
| [Mission Audit Transparency](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-audit.html) | [Agent runtime](/notes/the-agent-runtime-and-audit/) | Standards Track | Advanced |
| [Mission Security Model](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-security-model.html) | Cross-cutting | Informational | Overview |
| [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) | [The Authority Control Plane](/notes/the-authority-control-plane/) | Standards Track | By binding |
| [Mission Issuance Grant for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html) | [The Authority Control Plane](/notes/the-authority-control-plane/) | Standards Track | By binding |
| [Mission Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html) | [The Authority Control Plane](/notes/the-authority-control-plane/) | Standards Track | Advanced |
| [Mission-Bound Authorization for AAuth](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html) | [The Convergence and the Wagers](/notes/the-convergence-and-the-wagers/) | Standards Track | By binding |
| [Mission Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html) | [What Survives Without OAuth](/notes/what-survives-without-oauth/) | Standards Track | By binding |
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](/mission-handbook/), the front door with the introduction and the chapter map.
- **The category and definition:** this [Reference](/notes/mission-based-authorization-field-reference/).
- **The evaluation tool and the blueprint:** [the vendor test](/notes/mission-based-authorization-vendor-test/) (Appendix D), and [the blueprint](/notes/adopting-mission-bound-authorization/#walk-the-protocol-mvp).
- **The mental model for non-specialists:** [What the Corporate Card Already Solved](/series/what-the-corporate-card-already-solved/).
- **The missing layer and its laws:** [the five laws of delegated authority](#the-five-laws-of-delegated-authority) above, or the [architecture chapter](/series/designing-mission-bound-authorization/#the-missing-layer) for the full argument.
- **The argument for why the Mission is the missing object:** [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/).
- **The primitive's definition, roles, and name:** the [object model](#the-mission-object-model), [trust boundaries and roles](#trust-boundaries-and-roles), and [why "Mission"](#why-mission), on this page.
- **The safety claim (runtime is load-bearing):** [Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/).
- **The adoption path (crawl, walk, run):** [Adopting Mission-Bound Authorization](/notes/adopting-mission-bound-authorization/).
- **The OAuth wire implementation:** the [draft family](https://github.com/mcguinness/mission-bound-authorization).
- **The MCP application:** [Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls-need-a-mission/).
- **The wire exhibits:** [Mission-Bound Authorization on the Wire](/notes/mission-bound-authorization-on-the-wire/).
- **To discuss or object:** [issues on the draft repository](https://github.com/mcguinness/mission-bound-authorization/issues).
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](https://datatracker.ietf.org/doc/html/rfc2119),
[RFC 8174](https://datatracker.ietf.org/doc/html/rfc8174)) when they
appear in all capitals. Conformance applies to the profile section each
requirement appears in. The drafts are the normative text.