The missing abstraction in OAuth for agents is not another token. It is a durable governance object for the task the user approved.

OAuth solves 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.

A valid token can still be used for the wrong task. A session can outlive the mandate. A delegation chain can preserve actors while losing intent.

Current proposals add agent-aware authorization details, attestations, token profiles, exchange mechanics, and call-chain context. Each addresses a real problem. Deployed OAuth still lacks a first-class object for the task the user approved. That task remains implicit across application state, prompt context, credentials, and audit logs.

AAuth protocol -01 independently defines a native Mission for its clean-slate substrate. Part 4 therefore treats AAuth Mission as an existing protocol concept and defines a composition, not a replacement.

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 the Mission’s compiled policy artifact and produces a decision plus advice or 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: Part 2 defines the Shaper that produces it; Parts 3 and 4 define how each substrate admits it.
• Mission is defined by the litmus test in the next section. Parts 3, 4, and 5 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 (Part 2) is the closest substrate-neutral artifact and covers the prompt-to-Intent stage; downstream planning is out of scope.
• Mission Execution is partially specified: Part 6’s decision evidence records cover per-action enforcement, and Part 7’s capability acquisition 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 owns Authority Set. Authority Set is a component of Mission, not a separate 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 Part 6’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": "resource_access",
        "resource": "https://finance.example.com",
        "actions": ["query_financials"],
        "constraints": { "period": "Q3 2026", "entity": "Example Corp" }
      },
      {
        "type": "resource_access",
        "resource": "https://docs.example.com",
        "actions": ["create_doc"],
        "constraints": { "template": "board-packet", "classification": "confidential" }
      },
      {
        "type": "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 Part 5 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 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 compiled policy 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 what was approved: proposal_hash (the structured Mission Intent), authority_hash (the Authority Set), consent_rendering_hash (the canonical disclosure the user saw). The Mission cannot be silently rewritten.
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 Part 3 Gaps).

Substrate-specific projections.

• OAuth substrate (Part 3): 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 (Part 4): 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 (Part 5): the MAS owns lifecycle transitions and propagates them as Mission state events to both OAuth and AAuth consumers.

Runtime consequence (Part 6): 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. (Part 2 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. (Part 3 specifies the OAuth wire; Part 4 composes with AAuth’s native Mission; Part 5 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. (Part 3 and Part 4 define the substrate projections.)
4. Enforcement. A PDP evaluates each consequential request against the Mission’s compiled policy plus current Resource policy, and writes per-decision evidence bound to the Mission. (Part 6 specifies this layer, substrate-independent. Part 7 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. Parts 3-5 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. Part 6 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 Part 3, the AAuth PS in Part 4. The Mission Authority Server Profile (Part 5) 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 Conformance Ladder describes how much of the Intent → Mission → Authority → Enforcement progression a deployment claims to implement:

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 Compliance Tiers (1, 2, 3) — describe per-RS behavior and per-authorization-domain capability. The full coordinate model, valid combinations, and substrate-specific mappings are defined in Part 8.

The Mission Authority Server Profile (Part 5) 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.

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 Part 2.
• 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 Part 5; 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.
• 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 compiled policy 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 Part 5. 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 post is Part 1. The remaining seven parts are grouped into five reading stages:

II. Intent layer.

• Part 2: 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.

• Part 3: 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.
• Part 4: 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.
• Part 5: 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.

• Part 6: 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.

• Part 7: Least-Privilege MCP Tool Calls Need a Mission. The full spine applied to a concrete deployment. The five-step capability acquisition 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. Framework is substrate-independent; current wire details follow MCP’s OAuth-shaped authorization model.

VI. Conformance.

• Part 8: Mission-Bound Authorization Conformance. The substrate-neutral Conformance Ladder, Resource Server Tiers, and Compliance Tiers, with the mapping from each level onto OAuth-only, AAuth-only, and cross-substrate deployments.

Part 3 stands on its own as the OAuth-substrate wire profile. Part 4 assumes AAuth protocol -01 and defines only the composition delta. Parts 6 and 7 specify substrate-independent layers that compose with either wire profile. AAuth-only deployments can use native AAuth Missions without this series; they adopt Part 4 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.