Overview

OAuth represents credential issuance and delegation. It does not represent the durable task those credentials serve. Agents need authority that remains bound to a user-approved purpose as work spans tokens, calls, tools, actors, and time. This post argues that the missing object is a Mission: a governance primitive standardized across substrates, durable across credentials, and the anchor for every other claim the series makes.

AAuth protocol -01 independently defines a native Mission for its clean-slate substrate. The AAuth Composition Profile therefore treats AAuth’s Mission as an existing protocol concept and defines a composition, not a replacement. The sections that follow trace how the argument converged from prior lines of work, define what a Mission is, distinguish Mission from Intent, and show what every later post in the series projects from this object.

How the argument converged

Several earlier lines of work expose the same structural gap from different directions:

You Don’t Give Agents Credentials, You Grant Them Power of Attorney. Enterprise IAM governs who an agent is and what each call may do. It does not govern whether the mission behind those calls should still be running. Tokens stay valid past the moment approval expired. Policies still pass after intent has changed. Credentials remain secure while the work they authorize has become unauthorized. The breach is structurally invisible because no layer of the stack was built to ask the question. Agents need delegated authority that behaves like a Power of Attorney, not a credential.

Mission Shaping. A user approves an objective, not the authority needed to execute it. Something has to turn that approval into something a control plane can evaluate. In most deployments today that shaping step is implicit, local, or delegated to the agent itself. The model infers its own boundaries and the system trusts it. That is not governance. It is optimism.

Open-World OAuth. OAuth succeeded because its closed-world relationships were known ahead of time. The client knew the AS, the RS knew its issuers, scopes were configured before deployment. Agents push OAuth into an open-world model where tools, Resource Servers, and ASes are discovered at runtime and may not share prior trust. That exposes two challenges at different layers. The substrate problem covers protocol mechanics like discovery, resource binding, sender constraints, metadata integrity, and first-contact trust. The governance problem is deciding whether newly requested authority is still inside the task the user approved. Fixing the substrate does not fix the governance.

Sessions Are Not Missions. Modern agent harnesses make work durable across restarts, devices, sub-agents, and reconnected tools. That durability is a runtime property, not a governance property. A session can prove the runtime survived. It cannot prove the mission did. The harness that runs the agent is not the layer that owns the mission.

Mission-Bound OAuth (the architecture series). The proposed answer is a durable governance object: bounded by purpose, committed to maximum authority, governed across its lifecycle, and referenced by every derived credential and decision.

Mission-Bound Authorization makes the task explicit. A state authority holds the Mission, commits its maximum approved authority, and governs its lifecycle. Credentials carry references to it. Resource Servers can resolve its current state and audience-relevant authority. PDPs evaluate it with current resource policy. Audit systems use it to join activity across hops.

The Mission as the common object

The Mission lets OAuth, AuthZEN, Token Exchange, Resource Servers, tool runtimes, and audit systems refer to the same delegated task.

• OAuth projects the Mission into access tokens, refresh tokens, and ID-JAGs via the mission claim carrying id and origin.
• AuthZEN evaluates per-action requests against a versioned Mission policy view and produces a decision plus response context; the Runtime Enforcement Profile separately requires decision evidence.
• Token Exchange and Identity Chaining provide the framework for preserving the Mission binding across trust-domain boundaries. ID-JAG supplies the user-identity assertion profile; Mission carriage in Transaction Tokens and the Transaction Token Chaining Profile is a proposed MBO composition, not behavior those drafts currently define.
• Mission-aware Resource Servers obtain Mission state through issuer introspection or Mission Status, or consume lifecycle events through SSF and CAEP.
• Tool runtimes verify parameter_digest at execution time to close TOCTOU gaps; deployments adopting the Optional Tool Binding Profile also receive tool_id-bound permits.
• Audit systems key on the Mission, proposal_hash, authority_hash, consent_rendering_hash, authenticated actor context, and act when delegation exists.

Without a Mission, each system carries its own implicit notion of the task. Logs join by approximate timestamps, and stopping the work means finding every credential and execution surface independently. With a Mission, each layer consumes an authenticated projection of one governance record. The default OAuth profile carries a canonical mission.id; privacy-sensitive deployments can use audience-pairwise identifiers resolved through mission.origin.

Mission, Shape, Plan, Execution

Four related concepts appear around a user-approved task. Keeping them separate prevents the Mission from becoming a vague name for every artifact in the system.

They are related but not interchangeable. A Mission can outlive multiple plans and execution attempts. Plans and execution draw from its authority; neither can expand it.

The Shape is not the Mission. It can be edited, narrowed, or refused before approval. Until the state authority validates it and the user approves it, it remains a proposal.

The Plan is not the Mission. It describes how the agent intends to execute the task, but it does not commit or grant authority.

The Execution is not the Mission. Runtime events reference the Mission. Revoking the Mission stops future derivation and, where state is checked, future execution; it does not undo completed actions.

The distinction has three practical consequences:

1. Identity. The Mission has a protocol identifier. Plans and execution events may have their own identifiers, but those identifiers only reference the Mission.
2. Authority. The Mission commits the maximum authority through authority_hash. Plans and execution can use or narrow that authority, never enlarge it.
3. Audit. Governance records and execution evidence join through the Mission binding. A plan records intended work; decision evidence records attempted work.

Mapping to current series terminology.

• Mission Shape is specified in this series under the name Mission Intent: The Mission Shaper Profile defines the Shaper that produces it; the OAuth Profile and the AAuth Composition Profile define how each substrate admits it.
• Mission is defined by the litmus test in the next section. The OAuth Profile, AAuth Composition Profile, and Mission Authority Server Profile specify where the Mission record lives and how each substrate commits the authority it carries.
• Mission Plan is orchestrator-side. The series does not specify a wire shape for the agent’s task plan. The Shaper Trace (the Mission Shaper Profile) is the closest substrate-neutral artifact and covers the prompt-to-Intent stage; downstream planning is out of scope.
• Mission Execution is partially specified: The Runtime Enforcement Profile’s decision evidence records cover per-action enforcement, and the MCP application’s authorization pipeline shows how Execution traverses substrates at the MCP boundary.

This separation prevents three common mistakes: treating Mission Intent as already approved, treating an agent plan as authority, and treating an executed call as the governance object itself.

Mission versus Intent

The Mission and Mission Intent are not the same object. Conflating them is the most common analytic mistake about this series, so the boundary deserves its own treatment.

Mission Intent is the proposal. Mission is the approval. The integrity anchors commit the moment of transition.

The transition happens at one explicit moment: the state authority validates the Intent, the user consents to a rendering of the validated form, and the state authority creates an Approved Mission record committed by proposal_hash, authority_hash, and consent_rendering_hash. Before that moment, only Intent exists; after it, only the Mission is authoritative.

Six consequences follow from the distinction:

1. Trust. Mission Intent is untrusted input. The orchestrator, the Shaper, the LLM behind the Shaper, and the user’s raw prompt are all parts of the untrusted plane. The validating server’s admission decision is the trust boundary. A Mission only exists after that decision; before it, only Intent exists.

2. Identity. Mission Intent has no protocol identifier. Two submissions of the same Intent produce two pending records, not one canonical Intent. A Mission has mission.id and mission.origin from the moment of activation, and those references survive every derived artifact.

3. Integrity. proposal_hash is computed at the moment the Mission becomes active, over the post-validation form the user consented to. If the AS narrows the proposed expiry, removes an unsupported resource, or tightens a constraint during validation, the Mission Intent that becomes part of the Mission record is the narrowed form, and proposal_hash covers that. This is also why proposal_hash is different from ACAP’s att_intent: ACAP commits the raw instruction text; proposal_hash commits the typed object the user approved.

4. Lifecycle. Mission Intent has no lifecycle of its own. It is either pending, rejected, expired-as-pending, or it became a Mission. The Mission has the seven-state lifecycle defined in Mission Lifecycle. Revoking a Mission does not “revoke an Intent”; the Intent is preserved on the Mission record as the audit anchor for what was approved.

5. Authority. Mission Intent describes a task. It does not commit authority. The Authority Set is derived from the Approved Mission, not from Intent. A client that submits a Mission Intent with broad objects is asking the AS to derive an Authority Set from a broad task, not asking for broad authority. The AS may narrow, refuse, or accept based on requester registration, resource metadata, and policy.

6. Audit. Audit records key on mission.id, never on a hash of the original prompt or the original Intent submission. The integrity anchors join the Mission to the typed Intent it carries; they do not join it to the prompt that produced the Intent. The Shaper Trace is the audit anchor for the prompt-to-Intent stage.

Common confusions, called out by name:

• “The user approved a Mission Intent.” Strictly, the user approved a rendering of the post-validation Intent and the AS-derived Authority Set. The user’s approval activates the Mission; the Intent is preserved as a field on the Mission record.
• “The Mission Intent is the user’s prompt.” No. The prompt is upstream of the Intent. The Shaper interprets the prompt into structured Intent. Multiple prompts can produce equivalent Intent; one prompt can produce different Intent depending on the Shaper and the discovery snapshot.
• “Validation-time narrowing invalidates proposal_hash.” The reverse. proposal_hash is taken over the post-narrowing form the user consented to, and is stable for the lifetime of the Mission. The original submission is not what proposal_hash covers.
• “A Mission can have multiple Intents over its lifetime.” No. A Mission has exactly one approved mission_intent, committed by proposal_hash, for its entire lifecycle. Mission Expansion creates a successor Mission with its own new Intent; the prior Mission completes.
• “Mission Intent is authority.” No. Authority is committed only by authority_hash over the derived Authority Set. A Mission record carries both the approved Intent and the derived Authority Set; the Authority Set is what every credential and decision is bounded by.

In one line: the Intent is the proposal; the Mission is the approval; the hashes anchor the moment of transition.

The Mission Object Model

Mission versus Intent drew the trust boundary between proposed and approved. This section names what an Approved Mission is: a typed container whose components carry the user’s task, its bounds, its consent record, its integrity anchors, and its derived authority. Every subsequent post specifies how to project this object onto a specific substrate. This is the canonical reference for what is being projected.

The relationship rules are explicit and load-bearing across the series:

• Mission contains and governs Authority Set. Authority Set is a component of Mission, not a separate governance object. authority_hash covers the Authority Set; proposal_hash covers the Mission Intent that produced it. Both hashes live on the Mission record.
• Authority Set does not define Mission. A bundle of permitted actions without a purpose, lifecycle, or consent record is not a Mission. It is just authority, which is what OAuth’s authorization_details already supplied without this profile.
• Mission is the durable thing. Projections (tokens, ID-JAGs, runtime decisions) are short-lived artifacts derived from the Mission. The Mission record outlives any single projection.
• Every projection references the Mission. OAuth’s mission claim, AAuth’s (approver, s256) plus governance mapping, and the Runtime Enforcement Profile’s decision evidence records all carry a Mission reference resolvable at mission.origin.

In one line: Mission contains Purpose, Lifecycle, Consent, Integrity, and Authority Set. Authority is one component of Mission, not the whole.

A concrete Mission record

Before defining the rules, consider a concrete Mission record for the board-packet example used throughout the series. An authorized consumer resolves the appropriate read or status surface through mission.origin; the URI does not itself imply one universal retrieval endpoint.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

{
  "mission": {
    "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://as.example.com",
    "state": "active",
    "purpose": "urn:example:mission:board-packet",
    "mission_intent": {
      "goal": "Prepare the Q3 board packet for the audit committee",
      "objects": ["Q3 financials", "board presentation", "audit-committee reviewer"],
      "constraints": [
        "confidential classification",
        "Example Corp tenant",
        "audit-committee-q3-2026 meeting"
      ],
      "success_criteria": ["packet drafted", "reviewer notified"],
      "mission_expiry": "2026-10-15T18:00:00Z"
    },
    "authority_set": [
      {
        "type": "mission_resource_access",
        "resource": "https://finance.example.com",
        "actions": ["query_financials"],
        "constraints": { "period": "Q3 2026", "entity": "Example Corp" }
      },
      {
        "type": "mission_resource_access",
        "resource": "https://docs.example.com",
        "actions": ["create_doc"],
        "constraints": { "template": "board-packet", "classification": "confidential" }
      },
      {
        "type": "mission_resource_access",
        "resource": "https://workflow.example.com",
        "actions": ["notify_reviewer"],
        "constraints": { "group": "audit-committee" }
      }
    ],
    "integrity": {
      "proposal_hash": "fS8h4w7Z3Lq_xkN2vYpA8mC4tR1bU6oI9eW0jH3yL2k=",
      "authority_hash": "o2j2H8qP3sN4xL7vT9rD1mY6bC0gE5wA2uK8nF4iJ3a=",
      "consent_rendering_hash": "e9X2K7mB4nL3hY8sR1pT0jC6vF5dA9wU2gI4oQ7eN0c="
    },
    "lifecycle": {
      "approved_at": "2026-09-01T10:23:45Z",
      "activated_at": "2026-09-01T10:23:47Z",
      "supersedes": null
    },
    "tenant": "example-corp",
    "subject": "alice@example.com",
    "approver": "alice@example.com",
    "policy_version": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1@v1"
  }
}

Reading the record:

• mission.id and mission.origin form the OAuth governance reference carried by derived artifacts. The identifier is opaque and high-entropy. The origin identifies the state authority: the AS here, or the MAS under the MAS topology.
• state is the current lifecycle position. Only active permits new derivation. See Mission Lifecycle below.
• mission_intent is the Shape the user approved. proposal_hash commits its canonical form.
• authority_set is the maximum approved authority. Every derived credential and permitted decision must remain within it. This example uses OAuth mission_resource_access entries; other substrates use their own projections.
• integrity carries the three canonical hashes. proposal_hash covers mission_intent. authority_hash covers authority_set. consent_rendering_hash covers the structured disclosure the user saw at approval.
• lifecycle carries timestamps and the supersedes link to a prior Mission if this one was created by Mission Expansion.
• tenant, subject, approver bind the Mission to the deployment, the user the task is for, and the principal who approved it.
• policy_version is present when the deployment uses Runtime Enforcement. It identifies the versioned policy view evaluated by PDPs.

The rest of the series defines projections of this record. OAuth credentials carry mission.id and mission.origin. AAuth preserves its native (approver, s256) reference and resolves the governance mapping when the composition profile is used. Resource Servers obtain authorized, audience-filtered state through issuer introspection or Mission Status. PDPs evaluate policy derived from the record together with current resource policy.

When the series says “the Mission,” this object is what it means.

What makes something a Mission

The term needs a precise boundary. A reader should be able to point at any object in the stack and decide whether it is a Mission or merely a related artifact.

Definition. An Approved Mission is a durable governance object that binds user-approved intent to maximum authority, owns the task lifecycle, and persists across credential issuance, delegation, execution, and audit.

The state authority may create a pending Mission record before approval, but it becomes an Approved Mission only after consent and activation. Rejected and expired pending records remain lifecycle and audit records; they never become approved authority.

An Approved Mission has seven defining properties:

1. User-approved. The user or an authorized delegate explicitly consented to a validated rendering of the task and effective authority. Session state or policy defaults are not substitutes.
2. Durable. The Mission record persists independent of credential lifecycle. Revoking a token does not revoke the Mission. Issuing a new token does not create a new Mission. The Mission outlives individual derivation events.
3. Authority-bounded. The Mission commits to a canonical Authority Set at approval time. That set is the maximum any derived credential or decision can claim. Authority narrows during derivation; it expands only through Mission Expansion, which creates a successor Mission with a new approval.
4. Identified. The Mission has a stable, substrate-appropriate reference. OAuth uses mission.id plus mission.origin; AAuth uses (approver, s256) and may resolve an additional governance projection.
5. Integrity-anchored. Three canonical hashes commit the state authority’s approved record: proposal_hash (the structured Mission Intent), authority_hash (the Authority Set), and consent_rendering_hash (the canonical disclosure object the authority records as presented). The Mission cannot be silently rewritten; the hashes do not prove faithful display or human comprehension.
6. Lifecycle-governed. The state authority owns its state machine. Any non-active state refuses new derivation, and Mission-aware enforcement points receive current state through queries or events.
7. Projectable. Its governance semantics can be projected into OAuth, AAuth, or another credential substrate without confusing the Mission with any one credential format. The record may live at an AS, PS, or MAS.

What looks like a Mission but is not. The boundary is easier to see with concrete near-misses.

• A token is a short-lived projection. Its jti identifies the token, not the task.
• A scope or authorization detail expresses authority but not the approved task or its lifecycle.
• A consent record proves an approval event; it does not govern the resulting work over time.
• A session preserves runtime continuity but does not commit maximum authority.
• A policy evaluates requests; it is not the user’s approved task.
• A purpose URI labels a task class but has no instance lifecycle.
• A delegation chain records actors but not the mandate under which they act.
• A workflow definition describes a reusable template, not one approved instance of work.

The boundary matters because every later contract depends on it. A Mission-bound token references the Mission. A consent record helps establish it. A policy artifact is compiled from it. None of those artifacts replaces it.

Mission Lifecycle

The state authority owns the Mission lifecycle. The model includes pre-approval states for admission and audit, active governance, temporary suspension, and terminal outcomes.

The seven states:

• pending_approval. The state authority has admitted the Mission Shape and is awaiting consent. This is a pending record, not yet an Approved Mission; no credentials are issued.
• active. The user has approved. The state authority issues Mission-bound credentials and gates derivation on this state. Only active permits new derivation.
• suspended. Active Mission paused by administrator action or risk signal. Existing credentials may remain valid until their next state check or natural expiry; new derivation refused.
• revoked. Mission terminated by user, administrator, or policy. Terminal.
• completed. Task is done. Reached either by client completion advisory plus state-authority confirmation, or by Mission Expansion creating a successor (the prior Mission completes as the successor activates). Terminal.
• expired. mission_expiry reached, or the pending_approval approval window elapsed. Terminal.
• rejected. User denied at consent time. Terminal.

Invariants:

• Only active permits new derivation. Every non-active state refuses.
• Terminal states (rejected, revoked, completed, expired) are absorbing; once a Mission enters them, it stays there.
• The reserved Mission identifier survives every transition, including pre-approval and terminal states.
• Existing credentials remain valid until they expire naturally unless the Resource Server validates Mission state per request or consumes Mission state events.

Mission Expansion and supersession. If an active Mission is too narrow, the deployment creates and approves a successor. The prior Mission transitions to completed; the successor references it through mission.supersedes. Whether a future revision should add a distinct superseded terminal state remains open (see the OAuth Profile’s Gaps section).

Substrate-specific projections.

• OAuth substrate (the OAuth Profile’s Mission Lifecycle section): inactive-Mission errors at the token endpoint return error="invalid_grant" plus a mission_state extension field carrying one of the six non-active states. The diagnostic value mission_not_found is returned when mission.id does not resolve; it is not a lifecycle state.
• AAuth substrate (the Mission-Bound AAuth Composition Profile): AAuth’s native lifecycle is two-state (active and terminated). The canonical seven-state model projects onto AAuth’s native states with extension signals carrying the precise governance state for deployments that need richer lifecycle.
• Cross-substrate (the Mission Authority Server Profile): the MAS owns lifecycle transitions and propagates them as Mission state events to both OAuth and AAuth consumers.

Runtime consequence (the Runtime Enforcement Profile): every PDP decision is conditioned on Mission state. A suspended or revoked Mission produces a denial regardless of policy. A pending_approval Mission cannot be enforced against because no Authority Set has been committed.

Why IBAC becomes practical

Intent-Based Access Control is hard when intent is inferred from agent behavior at enforcement time. A PDP that reconstructs “what did the user actually want” from a prompt, a tool call, or an observed trajectory is doing probabilistic interpretation against adversarial input. Paraphrasing, incomplete context, and prompt injection make that reconstruction an unstable authorization boundary.

IBAC becomes practical when enforcement consumes approved intent instead of reconstructing it from runtime behavior. The validating server checks a structured proposal against requester bounds, resource metadata, and deployment policy. The user approves the resulting intent and effective authority. proposal_hash, authority_hash, and consent_rendering_hash commit those inputs. A trusted compiler then produces a reproducible policy artifact with a stable policy_version.

The interpretation problem moves to consent time, where the user is present and the validating server owns admission, instead of to enforcement time, where the agent is adversarial-input territory and the PDP has no user to ask.

That is the design move that makes IBAC ship.

The intent-to-enforcement spine

The series follows one temporal spine: intent becomes a Mission, the Mission bounds authority, and enforcement evaluates actions against it.

The four steps:

1. Intent. A user prompt or workflow trigger is shaped into a structured Mission Intent. The Shaper does not issue authority; it produces a typed proposal. (the Mission Shaper Profile specifies the Shaper.)
2. Mission. The state authority validates Mission Intent, renders it for consent, and on approval creates an Approved Mission record committed by proposal_hash, authority_hash, and consent_rendering_hash. (the Mission-Bound OAuth Profile specifies the OAuth wire; the Mission-Bound AAuth Composition Profile composes with AAuth’s native Mission; the Mission Authority Server Profile defines the optional MAS topology when the Mission record is shared.)
3. Authority. The Approved Mission derives a canonical Authority Set, projected into credentials the substrate can issue (OAuth access tokens, AAuth resource and auth tokens, ID-JAGs). Each credential carries its substrate-native Mission reference; OAuth uses the mission claim, while AAuth preserves (approver, s256) and may additionally carry the governance projection. (the Mission-Bound OAuth Profile and the Mission-Bound AAuth Composition Profile define the substrate projections.)
4. Enforcement. A PDP evaluates each consequential request against the Mission’s versioned policy view plus current Resource policy, and writes per-decision evidence bound to the Mission. (the Runtime Enforcement Profile specifies this layer, substrate-independent. Least-Privilege MCP Tool Calls Need a Mission applies the full spine to MCP.)

Each post specifies one or two steps. The spine explains when each concern enters the system; the stack below explains where it belongs architecturally.

Three layers, one stack

The same design can be viewed as a three-layer stack:

1. Credential substrate. OAuth authenticates clients, binds and narrows tokens, exchanges authority across audiences, and revokes credentials. AAuth identifies agent instances, signs requests, and supports identity-based, resource-managed, PS-asserted, and federated access. The series composes with both substrates rather than treating either credential model as universal.
2. Mission governance. The state authority preserves the approved task, commits maximum authority, owns lifecycle, and provides the reference carried by downstream artifacts. Credential issuance and derivation gate on Mission state. The OAuth Profile, AAuth Composition Profile, and Mission Authority Server Profile define this layer across OAuth, AAuth, and MAS topologies.
3. Runtime enforcement. A PDP evaluates consequential actions against Mission policy and current resource policy, then records decision evidence. This is where Mission-Bound Authorization becomes Intent-Based Access Control. The Runtime Enforcement Profile defines the contract.

The Mission connects the layers without collapsing them. Credentials remain credentials, governance remains durable state, and resource policy remains authoritative for each request.

Where the Mission record physically lives is a deployment choice. The default for each substrate is its own state authority: the OAuth AS in the Mission-Bound OAuth Profile, the AAuth PS in the Mission-Bound AAuth Composition Profile. The Mission Authority Server Profile pulls the record into a dedicated server that OAuth ASes, AAuth Person Servers, and future substrates all consume in common. The three-layer model holds across topologies; only the location of the governance-layer record changes.

How this fits with adjacent proposals

The OAuth community has several agent-focused drafts in flight. Each addresses a real gap. None defines a durable, user-approved task object that issuance, derivation, enforcement, and audit can all reference. Mission-Bound Authorization provides that composition point.

Three points matter. First, this gap is specific to OAuth deployments; AAuth has a native Mission with different semantics. Second, Mission-Bound Authorization composes with adjacent work rather than replacing it. Third, proposal_hash only commits the typed object the validating server approved and disclosed. It does not prove faithful prompt interpretation or replace agent-attestation evidence.

Adoption is incremental

Mission-Bound Authorization is designed for incremental adoption, not an all-or-nothing rollout. The six-level Capability Ladder describes how much of the Intent → Mission → Authority → Enforcement progression a deployment implements:

Deployments sit at the level that matches their infrastructure today and move up as the governance, runtime, and verification layers are ready. Two complementary axes, Resource Server Tiers (RS-A through RS-D) and Authorization Domain Tiers (AD-1 through AD-3), describe per-RS behavior and per-authorization-domain capability. The full coordinate model, valid combinations, and substrate-specific mappings are defined in the Capability Model.

The Mission Authority Server Profile is an independent deployment choice available at any level. It is the right choice for multi-AS, governance-team-owned, or cross-substrate (OAuth + AAuth) deployments.

When Mission-Bound Authorization is the right tool

The Mission layer is for deployments where authorization governs a user-approved durable task that may span multiple credentials, calls, audiences, or actors. That includes agentic deployments (LLM-driven orchestrators, MCP tool use, autonomous workflow agents), long-running governed workflows, and any deployment where audit needs to join across hops on a shared task identifier.

Plenty of OAuth deployments do not fit that description. Single-call user-driven web flows, machine-to-machine service credentials, short-lived consumer authorizations where the credential lifetime is the task lifetime: these do not benefit from a Mission layer and should not pay its cost. The Capability Ladder describes maturity for deployments that have chosen to adopt Mission-Bound governance, not for OAuth deployments in general. Level 0 is a perfectly fine destination for a deployment that has no agentic surface and no cross-hop audit requirement.

Mission-Bound is also strained where the task itself resists structured shaping at approval time. Open-ended research agents, conversational assistants whose scope emerges turn by turn, ambient or background agents whose actions are not user-initiated: these are the cases Mission Shaping Is Not Enough calls containment-primary. The Mission record still has value as a governance audit anchor in those deployments, but the safety properties come more from runtime containment than from anything the Mission shape can guarantee. A deployment in that regime should be honest about which layer is carrying the weight.

Terminology key

The series introduces many terms. They map onto the four steps of the spine. Use this as a reference card while reading subsequent posts. For the precise layer separation between Mission, Mission Shape, Mission Plan, and Mission Execution, see Mission, Shape, Plan, Execution above. For the canonical Mission definition and litmus test, see What makes something a Mission.

Intent step:

• Mission Shaper. Client-side component that turns a prompt or trigger into a Mission Intent. Does not issue authority. Defined in the Mission Shaper Profile.
• Mission Intent. Structured proposal containing goal, objects, constraints, success_criteria, and mission_expiry. OAuth submits it through the top-level mission_intent request parameter. An AAuth adapter maps it into AAuth’s native Mission proposal and optional governance extensions.

Mission step:

• Approved Mission. Mission Intent the state authority validated and the user approved.
• Mission record. Server-side lifecycle record for a pending proposal or Approved Mission. Lives at the OAuth AS, AAuth PS, or MAS, depending on topology.
• State authority. The server that holds the Mission record: AS, PS, or MAS.
• mission claim. OAuth object carried on issued credentials. Minimum fields: id, origin. mission.origin identifies the state authority. AAuth preserves its native (approver, s256) reference and may also carry this governance projection.
• proposal_hash. Canonical hash of the approved Mission Intent.
• consent_rendering_hash. Canonical hash of the consent disclosure object the user approved.

Authority step:

• Authority Set. Substrate-neutral canonical container for the maximum authority committed by authority_hash. Defined in the Mission Authority Server Profile; OAuth-only deployments may use the AS-derived authorization_details array as their single-substrate Authority Set.
• authority_hash. Canonical hash of the Authority Set.
• mission_resource_access. Generic per-resource RAR type (resource, actions, constraints) on the OAuth substrate.
• authorization_details. OAuth wire shape for derived authority (RFC 9396).
• Mission Expansion. A newly approved successor Mission with broader authority. The prior Mission completes, and mission.supersedes preserves lineage.

Enforcement step:

• PDP. Component that evaluates per-action requests against the Mission’s versioned policy view and current Resource policy.
• Mission Status. Authenticated state-authority view returning Mission state, integrity hashes, the audience-filtered Authority Set projection, and compiled policy_version when Runtime Enforcement is enabled. It may share an issuer endpoint with credential introspection when the roles coincide; otherwise it is a separate service.
• Decision evidence. Per-decision audit record bound to the Mission.

Deployment roles (cross-cutting):

• AS (Authorization Server). OAuth server.
• PS (Person Server). AAuth server. Already defines a native Mission (AAuth -01).
• MAS (Mission Authority Server). Dedicated governance server defined in the Mission Authority Server Profile. Holds the Mission record when OAuth and AAuth share one governance object, or when governance lives outside any one credential issuer.

Where to start

This is the framing post. The remaining eight posts are grouped into six reading stages:

I. Framing (continued).

• The Mission Model. The affirmative argument: the Mission is a new governance primitive, distinct from prompts, workflows, tickets, scopes, tokens, policies, and tasks. Defines the Mission positively, contrasts it with existing objects, and shows how every subsequent post projects from this primitive.

II. Intent layer.

• Mission Shaper Profile. The layer between user input and Mission Intent. Discovery snapshot, non-authoritative derivation hints, the structured ambiguity protocol, and the Shaper Trace.

III. Mission Governance layer.

• Mission-Bound OAuth Profile. The OAuth-substrate wire profile. Five protocol surfaces, the seven-state Mission lifecycle, cross-AS handoff, deployment-defined context constraints, audit anchors.
• Mission-Bound AAuth Composition Profile. A composition profile for AAuth -01. It preserves the native PS mission endpoint, Mission blob, AAuth-Mission header, resource and auth tokens, call chaining, and resource-owned policy while defining the additional Mission-Bound identifier, authority, lifecycle, status, and audit contracts.
• Mission Authority Server Profile. The cross-substrate topology. An optional Mission record home for one substrate, and the required topology in this series for one canonical Mission spanning OAuth and AAuth. Defines the generic Authority Set, projection-issuer authorization, pairwise identifiers, and Mission Status.

IV. Runtime Enforcement layer.

• Mission-Bound Runtime Enforcement Profile. Substrate-independent runtime enforcement. OAuth and AAuth adapters supply native credential and actor context; the PDP evaluates current Mission state, audience-relevant authority, request parameters, and local resource policy.

V. Applied.

• Least-Privilege MCP Tool Calls Need a Mission. The full spine applied to a concrete deployment. The five-step authorization pipeline, the three authorization problems (discovery, invocation, approval), and how a Mission lets token-side and resource-side FGA become projections of the same task. The framework is substrate-independent; current wire details follow MCP’s OAuth-shaped authorization model.

VI. Capability model.

• Mission-Bound Authorization Capability Model. The substrate-neutral Capability Ladder, Resource Server Tiers, and Authorization Domain Tiers, with the mapping from each level onto OAuth-only, AAuth-only, and cross-substrate deployments.

The Mission-Bound OAuth Profile stands on its own as the OAuth-substrate wire profile. The AAuth Composition Profile assumes AAuth protocol -01 and defines only the composition delta. The Runtime Enforcement Profile and Least-Privilege MCP Tool Calls specify substrate-independent layers that compose with either wire profile. AAuth-only deployments can use native AAuth Missions without this series; they adopt the AAuth Composition Profile when they need the richer governance contract or MAS composition. OAuth-side artifacts compose with AuthZEN, Token Exchange, Identity Chaining, Transaction Tokens, and Shared Signals.