---
title: "The Mission Model"
date: "2026-06-06T10:30:00-07:00"
lastmod: "2026-06-06T10:30:00-07:00"
description: "OAuth standardized authorization grants and tokens. Agent systems need a standardized governance object for the task those artifacts serve: the Mission. This post defines the Mission as a new primitive in the authorization vocabulary, contrasts it with nearby objects, and names what the rest of the series projects from."
summary: "OAuth standardized grants and tokens, then added richer request, exchange, and assertion profiles around them. Agent systems still need an object above those artifacts: a durable, integrity-anchored, lifecycle-governed record of the user-approved task. That object is the Mission. This post makes the affirmative argument, distinguishes the Mission from prompts, workflows, tickets, scopes, tokens, policies, and tasks, and shows how later parts project from it."
slug: "the-mission-model"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Internet-Draft"
series:
  - "mission-bound-authorization"
---


{{< spine steps="mission" >}}

{{< tldr >}}

- **The claim.** The Mission is a new governance primitive, not a refinement of grants, tokens, scopes, sessions, or tasks. It is the durable, integrity-anchored, lifecycle-governed object that records an approved task.
- **What lives in this post.** [What becomes possible only with a Mission](#what-becomes-possible-only-with-a-mission), [What a Mission is](#what-a-mission-is), [Normative vocabulary](#normative-vocabulary), [Trust boundaries and roles](#trust-boundaries-and-roles), [Where the Mission record lives](#where-the-mission-record-lives), the [Why "Mission"?](#why-mission) name defense, and [why every later post projects from this primitive](#why-every-later-post-in-the-series-projects-from-this-primitive).
- **What is *not* here.** Wire detail. The [OAuth Profile](/notes/mission-bound-oauth-profile/), the [AAuth Composition Profile](/notes/mission-bound-aauth/), and the [Mission Authority Server Profile](/notes/mission-authority-server-profile/) each specify their substrate's projection; this post defines what is being projected.

**Reading path.** ~12 minutes start to finish. Read in order.

{{< /tldr >}}

# Overview

OAuth standardized authorization grants and the access tokens issued from them. Later specifications added richer authorization requests, refresh, token exchange, assertion grants, transaction context, and sender constraint. Those mechanisms improve how authority is requested, represented, issued, delegated, and exercised. Deployed OAuth does not standardize a durable governance object for the task those artifacts serve.

[The Missing Abstraction post](/notes/the-mission-is-the-missing-abstraction/) argued that gap. This post argues what fills it: a new governance primitive in the authorization vocabulary, distinct from prompts, workflows, tickets, scopes, tokens, policies, and tasks. The sections below name what we already have and why none of it is enough, define what a Mission is, give the normative vocabulary and trust boundaries the rest of the series uses, and show how every later post projects from this primitive.

# Why existing objects are not enough

Before naming the new primitive, name what we already have. Each object below is in the agent-authorization conversation today; none does the work the Mission does.

| Object | What it answers | Why it is not enough |
| --- | --- | --- |
| **Prompt** | What did the user type? | Free-form, untrusted, ambiguous. The Shaper turns a prompt into structured intent; the prompt itself is upstream of every governance object. |
| **Workflow** | How will the agent execute? | Implementation-specific. Two workflows for the same task have nothing in common at the protocol layer. Workflows describe code, not user approval. |
| **Ticket** | Who needs to do what, in human terms? | Human-centric. Ticket trackers are not authorization systems and were never designed to be. A ticket reference does not bound or revoke authority. |
| **Scope** | What broad category of access? | Pre-registered scopes name capability classes, not the specific task at hand. A `documents.write` scope tells you what's *possible*, not what was *approved*. |
| **Token** | Is this credential currently valid at this protocol boundary? | Ephemeral. Tokens project authority for minutes; tasks span hours, days, or longer. A token's `jti` identifies a credential, not a task. |
| **Policy** | Is this request permitted under current rules? | Policy can bind decisions to subjects, resources, and context, but it does not standardize the durable task instance shared across authorization domains. |
| **Task** | What discrete unit of work? | Workflow systems can preserve durable task state, but OAuth does not standardize that state as an integrity-anchored governance object carried across credential boundaries. |

Each of these is useful at its own layer. No existing OAuth object supplies all of the Mission's properties as one interoperable governance object for the approved task.

## 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.origin`.
- **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 `proposal_hash`, `authority_hash`, and `consent_rendering_hash`, the canonical objects the state authority records as proposed, approved, and presented are committed at activation and can be checked for later modification. 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.
- **Substrate-neutral governance.** Without a Mission, OAuth Authorization Servers and AAuth Person Servers maintain parallel governance records that have to be correlated. With the Mission Authority Server topology, one canonical Mission is consumed by both substrates' native credential issuance.

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.

# What a Mission is

A Mission is a durable, integrity-anchored, lifecycle-governed governance object that carries seven things:

- **Intent.** The validated, post-narrowing form of the user's task: what they actually approved, not what they typed.
- **Authority.** The Authority Set: the maximum permitted actions derived from the Intent, committed and bounded by `authority_hash`.
- **Integrity.** Three canonical hashes (`proposal_hash`, `authority_hash`, `consent_rendering_hash`) committing the approved proposal, the derived authority, and the disclosure object the state authority records as presented. The hashes prove the recorded objects haven't changed; they do not prove the renderer displayed them faithfully or that the approving principal understood them. The OAuth Profile's [Integrity Anchors](/notes/mission-bound-oauth-profile/#integrity-anchors) section spells out the limit.
- **Lifecycle.** A state machine the state authority owns. Only `active` permits new derivation; every non-active state refuses.
- **Consent.** A reference to the canonical disclosure associated with approval, hashed so a future auditor can verify that the authority's stored disclosure object has not changed. For headless deployments where no user is present at approval time, the Mission's authorization anchor should be a prior human-approved template Mission, a standing organizational policy expressed in a formal auditable language, or a cryptographically verifiable standing delegation from a service owner. LLM inference about organizational intent, runtime configuration supplied by the agent or orchestrator, and pre-existing general-purpose scope grants are not sufficient anchors; they do not establish authority for a specific Mission. The word "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 or similar legal frames; deployments subject to those regimes still owe their own consent contracts on top.
- **Reference.** A stable identifier (`mission.id`) and origin (`mission.origin`) that every derived artifact carries back to the governance record.
- **Delegation context.** Credentials derived for delegated actors remain bounded by the same Mission and preserve authenticated actor context, such as the RFC 8693 `act` chain when an adopted profile supplies it. Token Exchange does not create a child Mission by itself. Broader authority requires Mission Expansion, which creates a separately approved successor Mission; narrower delegated credentials remain projections of the existing Mission.

The [Mission Object Model](/notes/the-mission-is-the-missing-abstraction/#the-mission-object-model) in the Missing Abstraction post shows the structure visually. The [litmus test](/notes/the-mission-is-the-missing-abstraction/#what-makes-something-a-mission) names the seven defining properties an object must satisfy to be a Mission rather than a related artifact.

The relationship the rest of the series depends on, repeated everywhere it matters:

> **Mission contains and governs the Authority Set. The Authority Set does not define the Mission.**

Authority, even fine-grained, typed, RAR-derived authority, is a *component* of Mission, not its peer. A bundle of permitted actions without a purpose, lifecycle, or consent record is just authority. That is what OAuth already gave us. The Mission is the layer above.

# Normative vocabulary

This post and the rest of the series use the following terms with their full normative meaning. Each later profile narrows or extends these as needed for its substrate; this table is the canonical dictionary.

| Term | One-line definition |
| --- | --- |
| **Mission Intent** | The validated, post-narrowing structured form of the user's task, as the state authority records it for approval. The input to consent; the antecedent of an Approved Mission. |
| **Mission** | The durable, integrity-anchored, lifecycle-governed governance object that records an approved task. Carries Intent, Authority Set, integrity anchors, lifecycle state, consent reference, and a stable identifier. Created at activation; modifiable only through the lifecycle. |
| **Authority Set** | The maximum approved authority derived from the Mission Intent at consent. Substrate-neutral container; on OAuth substrates it serializes as `authorization_details` with `mission_resource_access` entries (or ecosystem-specific RAR types). |
| **Projection** | A substrate-specific, audience-bounded credential or assertion derived from the Mission's Authority Set: an OAuth access token, an ID-JAG, an AAuth resource token, an AAuth auth token, or a downstream JWT Authorization Grant. Each projection carries the Mission reference and is bounded by the Authority Set. |
| **Runtime Decision** | The per-action evaluation made by a PDP against current Mission state, the audience-relevant Authority Set projection, authenticated actor context, and Resource policy. Produces a Runtime Evidence record. |
| **Evidence** | A durable record of a state-authority decision (admission, consent, lifecycle transition) or a runtime decision (allow, deny, expand). Keyed on `mission.id` and `mission.origin`; carries the integrity anchors and the binding evidence (signer, timestamp, policy version, schema version, rendering template version, approval actor) that gives them meaning. |

The canonical sequence of the series is **Mission Intent → Mission → Authority Set → Projection → Runtime Decision → Evidence**. Every profile specifies one or more of these transitions.

# 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 table is the canonical role map; subsequent 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, AAuth PS, or MAS) | Admitting, narrowing, and binding the Mission Intent to deployment policy and requester bounds. | 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 MAS topology, the MAS rendering on behalf of the OAuth AS or AAuth PS) | Presenting the validated Intent and Authority Set to the approving principal and committing to the rendered disclosure via `consent_rendering_hash`. | 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; the AAuth PS for resource tokens and auth tokens) | 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.origin`, carrying the integrity anchors and binding evidence. | Mutating the Mission record. Evidence records reference the Mission; they do not modify it. |

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: at the OAuth Authorization Server in an OAuth-only deployment, at the AAuth Person Server in an AAuth-only deployment. The substrate-local default makes the minimum profile coherent: a deployment can claim [Level 1 Mission-Bound issuance](/notes/mission-bound-authorization-capability-model/#what-a-level-1-deployment-looks-like) without introducing a new server component.

The Mission record moves to a dedicated [Mission Authority Server (MAS)](/notes/mission-authority-server-profile/) when one or more of the following conditions hold:

- **More than one substrate consumes the same Mission.** When an OAuth AS and an AAuth Person Server must project from one canonical Mission, neither substrate's state authority can hold the canonical record without subordinating the other.
- **Governance team ownership independent of any issuer.** When the team operating Mission state (lifecycle, consent rendering, audit retention) is organizationally distinct from the teams operating credential issuance, the MAS is the natural home.
- **Long-running Missions that outlive a single issuing AS.** When the Mission lifetime exceeds the issuing AS's deployment lifetime, externalizing the Mission record decouples governance from credential issuance.

Substrate-local deployments and MAS deployments use the same Mission Object Model and the same Authority Set vocabulary. The choice is operational and topological, not architectural: every projection still carries `mission.id` and `mission.origin`, where `mission.origin` resolves to whichever state authority holds the canonical record.

# Mission versus the alternatives, in one line each

The shorthand readers can carry:

| 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 Mission answers the question authorization stacks have been routing around for two decades. Not "is this request allowed?" but "what authority exists and why?" Once that question has a typed answer, every other question is a projection of it: tokens project Mission authority into protocol boundaries; policy evaluates requests against Mission bounds; audit joins records across hops by the Mission reference; revocation terminates future derivation across every credential descended from the Mission.

# Why "Mission"?

The name was deliberate; 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 to a reader that this is not a refinement of `scope`, `authorization_details`, `grant`, or `session`. The term is rhetorically strong because 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 (for example, the OAuth claim could be `mbo` or `authorization_mission` rather than `mission`) while preserving "Mission" as the conceptual term. This profile uses `mission` as the claim name to keep the conceptual and wire terminology aligned; deployments may rename if a working-group consensus settles on a different label.

# Why every later post in the series projects from this primitive

The rest of the series exists because the Mission is the primitive every subsequent layer references.

| Post | What it does with the Mission |
| --- | --- |
| [Mission Shaper Profile](/notes/mission-shaper-profile/) | Turns user input into a Mission Intent the state authority can admit. Produces the proposal that becomes a Mission after consent. |
| [Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/) | Projects the Mission onto OAuth credentials. The `mission` claim binds every derived token back to the governance record; integrity anchors anchor what was approved. |
| [Mission-Bound AAuth Composition](/notes/mission-bound-aauth/) | Composes AAuth's native Mission with this governance model. Maps `(approver, s256)` to the substrate-neutral Mission reference so AAuth tokens and OAuth tokens reference the same canonical object. |
| [Mission Authority Server Profile](/notes/mission-authority-server-profile/) | Lifts the Mission record out of any single substrate. OAuth ASes and AAuth Person Servers become projection issuers; the MAS holds the canonical Mission for both. |
| [Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/) | Evaluates each consequential request against the Mission's versioned policy view. Decision evidence binds back to the Mission so audit joins across actions, actors, and substrates. |
| [Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls-need-a-mission/) | Applies the full Intent → Mission → Authority → Enforcement spine at the MCP tool-call boundary. Token-side and resource-side FGA become two projections of the same Mission. |
| [Mission-Bound Authorization Capability Model](/notes/mission-bound-authorization-capability-model/) | Describes how much of the Mission model a deployment implements. The Capability Ladder runs from "issues credentials" to "verifiable governance." |

Without the Mission primitive, these are seven coordinated-looking but structurally disconnected proposals. With it, they are seven projections of one object. The primitive is what makes the architecture an architecture rather than a collection.

# The Mission is necessary but not sufficient

The Mission is the *declared governance envelope*: what the user (or governed anchor) approved, how it is bounded, how it is revoked, and how every derived artifact references it. It is the protocol primitive every other layer projects from.

It is not by itself a guarantee that the agent stays inside the envelope at runtime. An agent can hold a perfectly well-formed Mission and still drift, hallucinate, be prompt-injected, or quietly broaden its own behavior. Preventing that requires a co-equal containment and runtime-governance layer: mediated tool calls, short-lived attenuated credentials, boundary observation that does not rely on agent self-report, trust budgets that consume against drift, and graduated containment for irreversible actions. [Mission Shaping Is Not Enough](/notes/mission-shaping-is-not-enough/) makes the two-layer argument in detail. The [Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/) specifies the runtime contract.

The Mission and the runtime layer are not alternatives. The Mission is the envelope; the runtime layer is what keeps the system survivable when the envelope turns out to be incomplete. A deployment that has one without the other is either ungovernable (no Mission, no shared notion of what was approved) or unprotected (no runtime layer, no defense when the approved envelope is wrong).

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

[The Missing Abstraction post](/notes/the-mission-is-the-missing-abstraction/) made the negative argument: OAuth has no first-class object for the task the user approved. This post makes the positive one: the Mission is that object, a new primitive in the authorization vocabulary, distinct from prompts, workflows, tickets, scopes, tokens, policies, and tasks. Everything else the series specifies is how to create it, store it, project it onto credentials, enforce it at runtime, apply it at the MCP boundary, and claim conformance to it.

The rest of the series follows from here.