---
title: "Mission-Based Authorization: The Field Reference"
date: "2026-06-06T20:00:00-07:00"
lastmod: "2026-06-06T20: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 series."
slug: "mission-bound-authorization-reference"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Intent-Based Authorization"
  - "AuthZEN"
  - "Internet-Draft"
---


{{< spine steps="intent,mission,authority,enforcement" >}}

This is the standing reference for the
[Mission-Bound Authorization series](/series/mission-bound-authorization/).
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
[five laws](#the-five-laws-of-delegated-authority), 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), 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 6, 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/) |
| Compare to scopes, sessions, PDPs, IGA, PAM | [The landscape](#competitive-landscape) and the [objections](#common-objections) |
| Cite the draft family | [The catalog](#the-draft-family-at-a-glance) and [how to cite](#how-to-cite-this-publication) |

# 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 for
OAuth 2.0**, the [draft family](https://github.com/mcguinness/mission-bound-authorization)
this series explains, is one concrete instance of it.

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** | 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 five laws of delegated authority

The layer's invariants, stated to be quoted. They hold on any
substrate, and the [series](/series/mission-bound-authorization/) 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.

The names are stable across the publication: Durability is always Law
1, Containment is always Law 5.

## 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 + Status** (the state freshness source)

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 experimental push complement, sits outside the formula.
The [series hub](/series/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 tier and its enforcement scope, and every
line can be verified against the
[implementation checklist](#the-implementation-checklist) below:

| Claim line | Example |
| --- | --- |
| Claim | Protocol MVP (enforced agent) |
| Scope | Finance, docs, and workflow APIs |
| Enforcement | PEP at MCP `tools/call` and at the resource APIs |
| Freshness | Mission Status within 30 seconds |
| Signals | Workflow-domain push revocation (experimental add-on) |
| 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.

## 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<br/>OAuth AS]
        M[("Mission record<br/>intent_hash, authority_hash,<br/>state")]
    end
    subgraph S3["Authority"]
        AG[Agent instance<br/>+ act chain]
    end
    subgraph S4["Enforcement"]
        PEP[PEP]
        PDP[PDP]
        RS[Resource Server]
    end
    subgraph S5["Lifecycle"]
        ST[Status pull /<br/>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,<br/>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.

This series is about one instance: **Mission-Bound Authorization for
OAuth 2.0**, where the object is the **Mission**, authority is derived
as Rich Authorization Requests, the binding is a `mission` token claim,
and enforcement uses a PEP/PDP contract. 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 consent time, where the user is present, and
committing the result so enforcement *consumes* approved intent instead
of reconstructing it. **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 |
|---|---|
| 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. |
| Delegation chain | Records actors, not the mandate they act under. |

# The Mission object model

The approved task is a typed object, not a label. It contains:

- **Purpose:** an optional task-class URI, *not* the instance.
- **Mission Intent:** the structured, approved task description, committed
  by `intent_hash`.
- **Authority Set:** the maximum grantable authority derived from the
  Intent, committed by `authority_hash`. Authority is *one component* of
  the Mission, not the whole.
- **Lifecycle state:** owned by the issuer. Only `active` permits
  reliance.
- **Identity:** `id` and `issuer`, the same pair on the record and on
  the `mission` claim that every projection carries.

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 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/mission-approval-integrity/)).

# 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 / Completion)
    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)
    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/).)

# 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 |
| 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 |
| 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 | 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 experimental 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. The category earns its keep
only when authorization must outlive and bound a multi-step,
multi-resource, possibly-delegated task. 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 adoption ladder's four claimable tiers, one
line each:

| Tier | One line |
| --- | --- |
| Baseline issuance | Governance metadata and a derivation kill switch, not action safety |
| 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, action-bound approval, and no unmediated path |

# 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 experimental Signals push where revocation must bite in seconds | [The Mission](/notes/the-mission-is-the-missing-abstraction/), [Approval integrity](/notes/mission-approval-integrity/), [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-sub-agents-and-delegation/) |
| 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-profile/) |
| Evidence | Decision Evidence for every consequential decision, including denials. Execution Evidence for high-consequence and duration-metered actions. Consent Evidence where the governed tier is claimed | [Approval integrity](/notes/mission-approval-integrity/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/), [Agent runtime](/notes/mission-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 experimental Signals push as acceleration | [Runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/), [Lifecycle](/notes/mission-lifecycle-and-change/) |
| Honest claim | Name the tier and the enforcement scope: which resources, action classes, and execution paths are covered, and which are not | [Runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/) |

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 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 experimental 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-sub-agents-and-delegation/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/)) | 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/mission-approval-integrity/), [Runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/)) | 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-profile/), [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-profile/)) | 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-profile/)) | 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 only by consent rendering and shaping discipline ([Approval integrity](/notes/mission-approval-integrity/)) |
| **Runaway fan-out / sub-agent sprawl** | Fan-out controls, bounded depth, cascade revocation. Children are strict subsets ([Delegation](/notes/mission-sub-agents-and-delegation/)) | 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/mission-agent-runtime-and-audit/)) | A single transparency service is *trusted*, not proven, not to equivocate. Completeness is checkable only against an expected schedule |

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

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

# 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`,
  `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`.
- **`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.

## 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 publication'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 adoption ladder:** baseline issuance, protocol MVP, governed
  agent, high-assurance agent, with standalone governance as the
  parallel lane, staged as crawl, walk, run in
  [Adopting Mission-Bound Authorization](/notes/adopting-mission-bound-authorization/).
- **The honest deployment claim:** the
  [claim template](#the-honest-deployment-claim) naming tier,
  enforcement scope, freshness, evidence, and exclusions.

# The running example, end to end

The series 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/mission-approval-integrity/))*
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-profile/))*
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-profile/))*
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-sub-agents-and-delegation/))*
9. **Revoke.** The board meeting is cancelled. An admin revokes the
   Mission. Status reports the new state and the experimental Signals
   push announces it. All further
   derivation stops, and the child transitions to the terminal
   `cascaded` state. *([Delegation](/notes/mission-sub-agents-and-delegation/), [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/mission-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/mission-agent-runtime-and-audit/))*

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, and evidence
that reconstructs it.

# 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, each with the short answer and where the long
one lives.

**"Isn't this just RAR?"** RAR is how the Authority Set serializes, not
what a Mission is. `authorization_details` expresses authority. It has
no approval event, no lifecycle, no state a consumer can observe, and
no identifier that joins records across domains. The Mission contains
the Authority Set. The Authority Set does not define the Mission, and a
bundle of permitted actions with no approved task, lifecycle, or
evidence is what OAuth already had.

**"Isn't this just a session?"** A session preserves runtime continuity
and commits no authority. It can prove the runtime survived, never that
the task did. [Sessions Are Not Missions](/notes/sessions-are-not-missions/)
is the full argument, and the harness profile exists precisely because
resume must be contingent on Mission state rather than the reverse.

**"Isn't this just ABAC or ReBAC?"** A PDP evaluates requests against
policy and attributes, one request at a time. Nothing in ABAC or ReBAC
supplies the durable, approved task instance the decision should be
conditioned on. Mission-based authorization does not replace the PDP.
It gives the PDP the missing input, and the AuthZEN binding carries it.

**"Isn't this just PAM, or an IGA request?"** Closest cousins, and the
differences are the point. An IGA approval produces a standing
entitlement. A PAM checkout elevates an identity for a window and
records what it did. A Mission binds the elevation to the approved
task: authority is derived from it, every consequential action needs a
permit against its current state, delegation can only narrow, and the
authority ends when the task does rather than when the clock or the
session does. Deferred Approval is deliberately shaped so an existing
request-and-approval workflow can drive it.

**"An agent discovers tools and resources at runtime. You cannot
approve what you cannot enumerate."** The Mission approves the task,
not the toolset, and discovery is a proposal event, not an authority
event. A runtime-discovered tool or resource acquires authority in one
of two governed ways. Either it was already inside the approved bounds
(the Intent's constraints and the derivation policy govern resources
the Approver bounded without enumerating), or it arrives through the
discovery loop: the PDP denies with a requestable `out_of_authority`,
[ARAP](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html)
turns the denial into a governed request, and the widening lands as a
separately approved successor Mission through
[Expansion](/notes/mission-lifecycle-and-change/#grow-expansion-creates-a-successor).
The alternative, broad standing grants to cover the unknown, is the
blank check this publication exists to retire. What a Mission cannot
do is make a discovered counterparty trustworthy: whether to trust a
runtime-discovered issuer, tool server, or its metadata is the
substrate problem, and the
[Open-World OAuth series](/series/open-world-oauth/) carries it.

**"An agent can stay inside every parameter bound and still do damage
with the content."** Correct, and the layer never claims otherwise.
Parameter binding, metering, and state checks are structural
enforcement: they bound the blast radius, and they cannot judge whether
an in-bounds email body leaks intellectual property. The architecture's
answers to semantic risk are deliberately structural too: keep the
envelope small (scope, and
[exposure](/notes/least-exposure-is-broader-than-least-privilege/)),
keep the
[lethal trifecta split at execution time](/notes/mission-bound-runtime-enforcement-profile/#the-lethal-trifecta-at-execution-time),
and escalate the classes where content is the harm to action-bound
human approval under mediated custody. Content-aware controls (DLP
verdicts, classifiers, an LLM judge) compose as decision inputs through
the AuthZEN binding's `context`, and they raise the bar without
becoming a guarantee, because a judge model reading attacker-influenced
content is itself injectable. The [adversary model](#adversary-model)
carries the residual in writing: within the approved scope, a steered
agent can still misuse what was granted, which is why scope stays
tight.

**"Isn't this overkill?"** For a single user-driven request, a
machine-to-machine service credential, or any flow where the credential
lifetime is the task, yes. Skip it. The category earns its keep only
when authorization must outlive and bound a multi-step, multi-resource,
possibly delegated task, and the protocol MVP is deliberately the
smallest surface that does that.

**"Why not just short-lived tokens?"** Short lifetimes bound staleness.
They do not represent the task, and they make the wrong thing the
clock. A revoked task keeps deriving fresh short tokens unless issuance
is gated on task state, and audit still joins by timestamp.
Mission-bound deployments use short-lived tokens too. They are a
control inside the design, not a substitute for the object.

# 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 ladder. **Adopt
first** is the Architecture and the core. **Minimum** is the Enforced
bundle, and together with the core it is the protocol MVP.
**Recommended** is what AI agents add for the Governed bundle.
**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-sub-agents-and-delegation/) (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/mission-approval-integrity/) | 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/mission-approval-integrity/) | 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/mission-approval-integrity/) | Standards Track | Experimental |
| [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/mission-approval-integrity/) | 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-sub-agents-and-delegation/) | 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-sub-agents-and-delegation/) | 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-sub-agents-and-delegation/) | 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-profile/) | 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-profile/) | 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-profile/) | 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) | [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 | Experimental |
| [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 Completion for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-completion.html) | [Lifecycle](/notes/mission-lifecycle-and-change/) | Standards Track | Advanced |
| [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/mission-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/mission-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/mission-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 Framework](/notes/the-mission-framework-and-the-blueprint/) | Standards Track | Experimental |
| [Mission Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html) | [The Framework](/notes/the-mission-framework-and-the-blueprint/) | Standards Track | Advanced |
| [Mission-Bound Authorization for AAuth](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html) | [The Framework](/notes/the-mission-framework-and-the-blueprint/) | Standards Track | Experimental |
| [Mission Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html) | [The Framework](/notes/the-mission-framework-and-the-blueprint/) | Standards Track | Experimental |

For AI agents, the README is explicit that consent evidence and the
harness are not optional extras. They are the Recommended tier, the
Governed bundle.

# How to cite this publication

Link the piece that matches what you are referencing:

- **The category and definition:** this [Reference](/notes/mission-bound-authorization-reference/).
- **The fast path (essay, test, blueprint):** [Agents Need a Mission, Not Just Credentials](/notes/agents-need-a-mission-not-just-credentials/), [the vendor test](/notes/mission-based-authorization-vendor-test/), and [the blueprint](/notes/minimum-viable-mission-based-authorization/).
- **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 [series overview](/series/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, vocabulary, and name:** [The Mission Model](/notes/the-mission-model/).
- **The safety claim (runtime is load-bearing):** [Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement-profile/).
- **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 series 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.