---
title: "Adopting Mission-Bound Authorization"
date: "2026-06-06T19:30:00-07:00"
lastmod: "2026-06-06T19:30:00-07:00"
description: "The adoption path for mission-bound authorization, staged honestly: crawl is the issuance core and a kill switch, walk is the protocol MVP with per-action enforcement on ratified substrate, and run is the governed and high-assurance tiers with the advanced and experimental roadmap. Each stage names what you get, what you do not, and what you will operate."
summary: "A definitive architecture that ends without a build order is a tour, not a blueprint. This closer stages the adoption: crawl by shipping the issuance core (approved, integrity-anchored Missions and a possession-independent kill switch, honestly labeled governance rather than safety), walk by adding the protocol MVP (per-action enforcement, the AuthZEN binding, and Status freshness, all on ratified substrate), and run by climbing to the governed and high-assurance tiers while the advanced and experimental roadmap earns its interfaces through deployment. Plus the ecosystem to compose with, the five operational surfaces you will own, and the pieces the community still has to standardize."
slug: "adopting-mission-bound-authorization"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Intent-Based Authorization"
  - "AuthZEN"
  - "Internet-Draft"
series:
  - "mission-bound-authorization"
---


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

{{< tldr >}}

- **Three stages.** [Crawl](#crawl-baseline-issuance): the issuance core, approved Missions and a kill switch, governance rather than safety. [Walk](#walk-the-protocol-mvp): the protocol MVP, per-action enforcement on ratified substrate, the wedge. [Run](#run-governed-and-beyond): the governed and high-assurance tiers, with the advanced and experimental roadmap earned through deployment.
- **The protocol MVP bias.** The implementation minimum (issuance core, runtime enforcement, AuthZEN binding, and Status as the freshness source) depends only on ratified OAuth RFCs and finalized OpenID specifications. It is the smallest interoperable surface that closes the gap [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) names, and it is adoptable today.
- **The roadmap.** Beyond the wedge sit two tiers: advanced profiles to adopt when the use case arrives (growth and completion, sub-agents, cross-domain projection, fleet management, the portable Mandate, audit transparency), and experimental ones for evaluation only (push signals, asynchronous and revisable approval, progressive drawdown, consumption metering, offline fan-out, safe unwinding, AS-optional governance, the AAuth binding). Each experimental profile is labeled for stated reasons.
- **The card analogy.** Nobody rolls out a card program in one quarter. Issue the first purpose-bound card, add per-transaction authorization, then grow the controls as the risk demands. ([Where the analogy breaks](/notes/agents-need-a-corporate-card-not-a-blank-check/#where-the-analogy-breaks).)
- **Specs.** The [draft repository](https://github.com/mcguinness/mission-bound-authorization) carries the editor's copies, and the [Reference's catalog](/notes/mission-bound-authorization-reference/#the-draft-family-at-a-glance) is the 26-document family with maturity labels on every row.

**Reading path.** ~15 minutes start to finish, or jump to [the walk stage](#walk-the-protocol-mvp) if you only want the build order.

{{< /tldr >}}

# Overview

A definitive architecture that ends without "what do I do now" is a tour, not a blueprint. [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/) defined the object. This closer turns the architecture into a staged build order, because the honest answer to "how do I adopt this" is not "all of it": it is crawl, walk, run, with each stage claimable on its own, honest about what it does not yet deliver, and chosen so that nothing waits on an unratified dependency. The maturity and status claims in this part are as of July 2026, and the [Reference](/notes/mission-bound-authorization-reference/) carries the reconciliation date the series tracks. For substrate independence, the three bindings, and the trade the standalone Mission Authority Server makes, [The Mission Framework](/notes/the-mission-framework-and-the-blueprint/) is the advanced companion.

The stages map onto the [adoption ladder](#run-governed-and-beyond) the repository publishes: crawl is the baseline-issuance rung, walk is the protocol MVP rung, and run is the climb through governed and high-assurance, with the standalone Mission Authority Server as a parallel lane at every stage for deployments that cannot change their Authorization Server. The three stages are the path, and the second half of this part is the terrain around it: the [ecosystem the protocol MVP composes with](#composing-with-the-ecosystem), the [roadmap beyond the wedge](#the-roadmap-the-next-layer-of-the-problem), the [operational surfaces you will own](#what-you-will-operate), and the [pieces the community still has to standardize](#what-the-community-still-has-to-standardize).

# Crawl: baseline issuance

Crawl is the issuance core alone. Mission Intent submitted through PAR, the approval event that derives and renders the Authority Set, `intent_hash` and `authority_hash` committing what was approved, the `mission` claim on every derived token, state-gated issuance as the kill switch, and the subset rule on every derivation. This is [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/) and the [core draft](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html), and a minimal conforming deployment fits on one screen.

What crawl buys you is real: every credential carries its purpose, issuance stops the moment the task does, and audit joins on one identifier. What it does not buy you is the thing the series keeps refusing to let anyone claim by accident. Stop here and you hold governance metadata, not agent safety. A mission-bound token that nothing checks at the point of use is bookkeeping, and the [what-not-to-claim list](/notes/mission-bound-authorization-reference/#what-not-to-claim) says so in writing. Crawl is the right first quarter. It is not a place to live.

# Walk: the protocol MVP

Walk is the wedge, and it is where the safety claim becomes real. Two additions:

1. **Put a PEP at every consequential boundary and adopt the runtime contract with its AuthZEN binding.** The PDP evaluates each action against the live Mission, parameters bound, consumption metered, failures closed. This is [Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement-profile/), the [runtime draft](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-runtime.html), and the [AuthZEN profile](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authzen.html).
2. **Serve Status as the freshness source.** Revocation is only as fast as consumers learn it. The signed pull surface (or issuer token introspection) is the protocol MVP half of [Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/), and it is what makes "only `active` permits reliance" operational. Where a revocation must bite in seconds, evaluate the experimental Signals push as the complement.

The order is the argument. Crawl alone is governance metadata. Walk is what turns the object into a control, and for AI agents the recommended additions come with it: Consent Evidence and the harness, because an agent's approval surface and its resume path are where the guarantees otherwise lapse ([From a Request to an Approved Mission](/notes/mission-approval-integrity/), [The Agent Runtime and Audit](/notes/mission-agent-runtime-and-audit/)).

The whole walk stage compresses into one recipe, and
[Minimum Viable Mission-Based Authorization](/notes/minimum-viable-mission-based-authorization/)
carries it as a standalone one-pager, ready to hand to a team:

| | The minimal enforced deployment |
| --- | --- |
| 1 | The Mission Issuer records the approved task |
| 2 | Tokens carry the mission id and authority hash |
| 3 | A PEP gates each consequential action |
| 4 | The PDP checks action, parameters, actor, and current Mission state |
| 5 | Status (or issuer introspection) provides fail-closed freshness |
| 6 | Evidence joins on the mission id |

The same recipe lands at four different boundaries, and only the deployment details change:

| Where it lands | What changes | What carries the enforcement |
| --- | --- | --- |
| An Authorization Server you can extend | The AS is the Mission Issuer and gates issuance on Mission state | Issuance gating plus the PEP fleet |
| An Authorization Server you cannot change | A standalone [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) issues and governs, and tokens stay ordinary | PEP coverage entirely, with the PDP joining each token to its Mission at the point of use |
| An MCP server | The `tools/call` handler is the PEP, and the AuthZEN check runs per call | The tool boundary you already own ([the MCP application post](/notes/least-privilege-mcp-tool-calls-need-a-mission/)) |
| The agent harness | The harness mediates local side effects and gates every resume on Mission state | The harness as the PEP for the paths no gateway sees |

And the equally opinionated negative. Do not start with Signals,
Deferred Approval and Revision, the Mandate, offline attenuation,
cross-domain projection, SCITT audit transparency, or the standalone
Mission Authority Server unless your Authorization Server truly cannot
change. Every one of them is on the roadmap for a reason, and none of
them is the wedge. Build the recipe above, run it, and let deployment
experience tell you which of these you actually need.

Why protocol MVP first, stated as reasons rather than modesty:

- **Every normative dependency is ratified.** The protocol MVP rests on OAuth RFCs and finalized OpenID specifications, including the [AuthZEN Authorization API 1.0](https://openid.net/specs/authorization-api-1_0.html), which reached Final in January 2026. The one tracked exception, the issuance core's Internet-Draft reference to the Actor Profile, is confined to its OPTIONAL delegation capability. There is nothing to wait for. The claim is about dependencies, not the profiles themselves: they are individual drafts whose wire details will keep moving with review, which is one more reason the laws and the architecture, not the claim names, are what to design against.
- **It is the smallest object that closes the named gap.** [Section 9.1 of the best practices](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) expects the mission to be translated into authorization requirements and leaves the process out of scope. The protocol MVP is that process: an approved, integrity-anchored task object, authority derived from it, actions enforced against it, state observable for it.
- **The roadmap should be earned, not speculated.** The experimental extensions encode design bets about asynchronous approval, fan-out, and unwinding. Real protocol MVP deployments are what turn those bets into interfaces worth hardening.

# Run: governed and beyond

Run is the climb above the wedge, and the ladder is one named artifact. Climb it in order, and claim the rung you are on:

| The adoption ladder | Stage |
| --- | --- |
| 1. Baseline issuance | Crawl |
| 2. Protocol MVP | Walk |
| 3. Governed agent | Run |
| 4. High-assurance agent | Run |
| Standalone governance | Parallel lane, AS-optional |

| Bundle | Adopt | What you get | What you do not get |
| --- | --- | --- | --- |
| **Baseline issuance** | [The Mission](/notes/the-mission-is-the-missing-abstraction/) core | Approved, integrity-bound Missions, state-gated token issuance, and a possession-independent kill switch for future derivation | Action-time defense, prompt revocation of already-issued tokens, safe unwinding |
| **Protocol MVP (enforced agent)** | + [runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/) and [lifecycle](/notes/mission-lifecycle-and-change/)'s Status surface | Per-action PEP/PDP enforcement, current Mission-state checks, Status (or introspection) for revocation freshness, with the experimental Signals push where seconds matter | Full consent-rendering evidence, runtime harness binding, orchestration unwind |
| **Governed agent (agent safety minimum)** | + consent evidence and the harness ([approval integrity](/notes/mission-approval-integrity/), [agent runtime](/notes/mission-agent-runtime-and-audit/)), growing with delegation, expansion, and orchestration as needed | Approval evidence, session-continuity stop, sub-agent containment, and tamper-evident audit where adopted | Proof that every possible side channel has been mediated. Deployments still must define their enforcement scope |
| **High-assurance agent (compromise-resistant)** | + mediated custody, action-bound approval, and a published execution-environment scope with no unmediated path ([runtime](/notes/mission-bound-runtime-enforcement-profile/), [agent runtime](/notes/mission-agent-runtime-and-audit/)) | The runtime profile's agent-compromise-resistant claim: a compromised agent cannot present the credential or reach a mediated action without a fresh independent approval | Protection inside the approved scope. A compromised agent can still misuse authority the Mission grants, which is why scope stays tight |
| **Standalone governance (AS-optional)** | Mission Authority Server + [runtime](/notes/mission-bound-runtime-enforcement-profile/) surfaces served by the MAS | Mission governance and per-action enforcement with an unmodified Authorization Server. The MAS serves Status and the lifecycle verbs itself, is the freshness source, and hosts expansion and Child Mission creation on its own submission surface | Mission-bound tokens and issuance gating. Revoking a Mission stops nothing at the token layer, so enforcement rests entirely on PEP coverage |

A deployment names its rung and its enforcement scope, and the
[Reference's implementation checklist](/notes/mission-bound-authorization-reference/#the-implementation-checklist)
is the checkable form of that claim, down to the sentence a vendor
should be able to write.

# Composing with the ecosystem

The staged path is behind you. From here to the close, this part maps the terrain around it, starting with what the protocol MVP composes with rather than replaces. One stack answers where everything sits, from the substrate up:

| Layer | What sits there |
| --- | --- |
| Identity substrate | WIMSE, SPIFFE, and [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/), with the [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) and [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) |
| Issuance | OAuth 2.0 (PAR, RAR) plus the Mission core: the approval event, the integrity anchors, the `mission` claim |
| Decision | The runtime contract on [AuthZEN 1.0](https://openid.net/specs/authorization-api-1_0.html), with ARAP and AROP for governed requests |
| Tool boundary | MCP `tools/call` as the PEP most builders already own |
| Lifecycle and evidence | Status pull, Signals push (experimental), the harness, SCITT audit transparency |

**AuthZEN** standardizes the decision. The runtime profile deliberately specifies invariants rather than a wire, and the AuthZEN binding is the interoperable PEP-to-PDP surface. **[ARAP](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html)** turns a denial into a governed request, and the AuthZEN profile marks `out_of_authority` and `action_approval_required` denials as requestable so an agent can start narrow and ask for what it discovers it needs. That composition has a name in this publication: **the discovery loop**. Deny, request, approve, expand, retry. It is how the open world arrives under governance. A tool or resource discovered at runtime shows up as a requestable denial rather than as an error or an excuse for standing breadth, and the widening lands as a separately approved successor Mission with lineage. The proposed **[AROP](https://github.com/openid/authzen/pull/531)** binds that workflow to OAuth completion for the token-side case. The [Least-Privilege MCP series](/series/least-privilege-mcp/) walks this per-call stack from the beginning, and the [MCP application post](/notes/least-privilege-mcp-tool-calls-need-a-mission/) shows both of its models becoming projections of one Mission.

Two observations from that series matter for the blueprint, because they name what the ecosystem still lacks:

- **Fulfillment is undefined.** ARAP standardizes the request, the status, and the re-evaluation, and deliberately not how an approval becomes durable authorization state. Token-resident state fulfills by minting, which AROP binds to OAuth issuance. Store-resident state fulfills by a write no standard defines. When the durable state an approval becomes is a Mission, fulfillment has a governed shape: an in-bounds approval is decision input, and a widening lands as a separately approved successor Mission with lineage.
- **The task object is the gap every layer routes around.** The denial signals, the decision API, and the approval workflows each standardize an interface inside a single call. None names the work the calls serve. That is the object this series proposes, and it is the piece to bring to the standards conversation rather than reinvent per deployment.

The identity substrate composes from below: the best practices for agent authentication, the [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) for delegation chains, and the [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) with the [AI Agent Instance Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/) for attributable instances. [Mission-Bound Authority](/notes/mission-sub-agents-and-delegation/) is the binding between that substrate and the Mission.

# The roadmap: the next layer of the problem

The roadmap beyond the wedge has two tiers, and the labeling is the design discipline, not a disclaimer. The **advanced tier** is stable design to adopt when its use case arrives, and the practice series carries it: Expansion and Completion with the fleet Management surface ([Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/)), Child Delegation and Cross-Domain Projection ([Mission-Bound Authority](/notes/mission-sub-agents-and-delegation/)), Audit Transparency ([The Agent Runtime and Audit](/notes/mission-agent-runtime-and-audit/)), Intent Shaping ([From a Request to an Approved Mission](/notes/mission-approval-integrity/)), and the [Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html).

The **experimental tier** is for evaluation only. Each extension answers a question the protocol MVP will surface in production, and each is experimental for a stated reason:

| Next-layer problem | Extension | Why it needs iteration | Stable path today |
| --- | --- | --- | --- |
| Revocation must bite in seconds | [Mission Lifecycle Signals](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-signals.html) | Push is a latency optimization over correctly sized status polling | Status polling sized to the risk, or introspection |
| Approvals take days | [Mission Deferred Approval](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval.html) | Depends normatively on OAuth Deferred Token Response, an unratified draft | Synchronous approval through the core |
| Reviewers narrow instead of denying | [Mission Approval Revision](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval-revision.html) | Companion to Deferred Approval, riding the same unratified substrate | Deny, then resubmit a narrower Intent |
| Open-ended tasks need governed drawdown | [Mission Progressive Authorization](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-progressive.html) | Ceiling-and-drawdown is a newer model | Per-step Expansion with fresh approval |
| Budgets and call caps need runtime metering | [Mission Consumption Metering](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-metering.html) | Cumulative-bounds enforcement is a newer model | Per-action constraint checks and short expiries |
| Fan-out at swarm scale without an issuer round-trip per delegation | [Mission Offline Attenuation](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-attenuation.html) | Depends normatively on Attenuating Agent Tokens, an in-progress draft | AS-mediated Child Delegation |
| A Mission stops mid-workflow with work in flight | [Mission Orchestration and Unwinding](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-orchestration.html) | Reversibility classes and unwind plans are less exercised | Harness stop behaviors, human review |
| Governance when the Authorization Server cannot change | [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) | The PDP join is the family's newest mechanism, and the mode gives up issuance gating | Adopt the core at the AS where possible |
| The same model on a non-OAuth substrate | [Mission-Bound Authorization for AAuth](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html) | Tracks the AAuth protocol, itself an in-progress draft | The OAuth binding |
| Requirements for bindings that do not exist yet | [Mission Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html) | Written ahead of the substrates it constrains | The Architecture's substrate interface |

The honest sequencing claim, once more: adopting the protocol MVP first is not settling for less. The protocol MVP produces the deployment experience, the failure cases, and the interoperability pressure that tell us which of these interfaces to harden and how. An experimental extension frozen before that evidence exists would be a guess wearing a MUST.

The [Reference's draft family at a glance](/notes/mission-bound-authorization-reference/#the-draft-family-at-a-glance) is the whole 26-document catalog in one table, with these maturity labels on every row.

# What you will operate

The blueprint is honest only if it names the operational surfaces that
come with it. Adopting the protocol MVP means owning five things:

- **Derivation policy.** Someone maintains the policy that turns a
  validated Intent into an Authority Set, per resource, the same
  onboarding work scope design was. The record's `policy_version`
  exists so a derivation can be re-checked, and the owner is typically
  the IAM team together with the resource owners.
- **The approval surface.** The shaper is client-side and app-owned.
  The consent rendering and approval routing belong to the Mission
  Issuer, and [Deferred Approval](/notes/mission-approval-integrity/)
  lets an existing request-and-approval workflow drive the decision.
- **The PEP fleet.** Gateways, MCP servers, egress proxies, and
  orchestrators each need a PEP at the last controllable boundary,
  owned by the platform teams that own those boundaries, with the
  enforcement-scope statement naming what is and is not covered.
- **The PDP as a tier-0 dependency.** Fail-closed means agents stop
  when the PDP is unreachable. That is the design, and the
  permit-as-lease model with published staleness bounds
  ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement-profile/))
  is the availability story: bounded caching, never fail-open.
- **The incident playbook.** Revocation by `mission_id` is the kill
  switch, Status is how consumers learn it (with the Signals push where
  seconds matter), and fleet-scale response (enumerate a compromised
  principal's active Missions and bulk-revoke, dry-run first) is
  [Mission Management](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-management.html)'s
  job.

# What the community still has to standardize

A blueprint should also name the pieces nobody owns yet. Five stand out.

- **A standard task object.** This family proposes one, as individual drafts published for discussion. The gap it fills is now named in the best-practices document, and the per-call standards keep converging on shapes that assume something like it exists. The right venue conversation, whether that is the OAuth working group, AuthZEN, or both, is the next step, and deployment experience is the strongest input anyone can bring to it.
- **Approval fulfillment for store-resident state.** Every Zanzibar-style store's write API is product-specific, so the approval-to-state step of ARAP has no interoperable form outside OAuth issuance. A Mission gives the durable state a governed shape, but the write itself still needs a standard.
- **Task binding at the tool boundary.** The MCP proposals standardize the denial and the brokered approval. Carrying a verifiable task reference through `tools/call`, so the resource can weigh the call against the approved work, is the natural next step the [MCP application post](/notes/least-privilege-mcp-tool-calls-need-a-mission/) sketches.
- **Instance-attested delegation as the default.** The actor chain, instance assertion, and agent provenance exist as individual drafts. The mission layer assumes them. Their adoption path is part of this blueprint, not an afterthought, because an unattributable actor makes every downstream guarantee weaker.
- **Trust establishment for discovered counterparties.** The Mission layer governs whether newly requested authority is inside the approved task. Whether a runtime-discovered issuer, tool server, or its metadata can be trusted at all is the substrate problem beneath it, and the [Open-World OAuth series](/series/open-world-oauth/) maps that terrain: discovery, issuer trust, sender constraints, and metadata integrity are prerequisites this blueprint composes with rather than solves.

# Where this leaves you

If you arrived from [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/), you now have the answer to the question its Section 9.1 leaves open. The Mission is the durable, approval-backed record of the task your authenticated agent pursues, and the adoption of it is staged: crawl with the issuance core, walk with the protocol MVP, run up the governed and high-assurance tiers as the deployment earns them.

Ship the protocol MVP, and add the agent-specific assurance pieces when the system is actually running agents. It is ratified substrate end to end, it is the smallest interoperable surface that makes the approved task first-class, and it is the version of this architecture that earns the right to harden the rest. The [Building Mission-Bound Authorization](/series/building-mission-bound-authorization/) series carries each control at implementation depth, the editor's copies are public, and the [Reference](/notes/mission-bound-authorization-reference/) is the citable definition. That experience has a place to land: [issues and pull requests on the draft repository](https://github.com/mcguinness/mission-bound-authorization/issues) are the fastest path into the documents. The gap has a name now. It should have an object.