---
title: "Adopting Mission-Bound Authorization"
date: "2026-07-22T05:50:00-07:00"
lastmod: "2026-07-22T05:50: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 Runtime-Enforced level with per-action enforcement on ratified substrate, and run is the Governed and High-Assurance Agent levels with the advanced and experimental roadmap. Each stage names what you get, what you do not, and what you will operate, and each level makes a broader class of write authority defensible: the graduation path off the read-only ceiling."
summary: "A definitive architecture that ends without a build order is a tour, not a blueprint. Most estates start at the read-only ceiling: agents capped at read access, humans approving or executing the writes, and pilots that never graduate. This closer names what that posture costs and stages the way off it: 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 Runtime-Enforced level (per-action enforcement, the AuthZEN binding, and Status freshness, all on substrate that already shipped), and run by climbing to the Governed and High-Assurance Agent levels, each of which makes a broader class of write authority defensible. 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:
  - "designing-mission-bound-authorization"
---


{{< tldr >}}

- **Three stages.** [Crawl](#crawl-baseline-issuance): the issuance core, approved Missions and a kill switch, governance rather than safety. [Walk](#walk-the-runtime-enforced-level): the Runtime-Enforced level, per-action enforcement on existing substrate, a substantial build. [Run](#run-governed-and-beyond): the Governed and High-Assurance Agent levels, with the advanced and experimental roadmap earned through deployment.
- **Where you start.** Most estates run agents read-only, with humans approving or executing the writes and pilots that never graduate. [The read-only ceiling](#the-read-only-ceiling) names what that posture costs, and the levels are the graduation path: each one makes a broader class of write authority defensible. If you already run a credential broker, [crawl starts from an asset](#crawl-baseline-issuance): the broker becomes the Mission-gated credential plane. And [you do not need an agent to start](#you-do-not-need-an-agent-to-start): the first deployment can govern human access requests.
- **The Runtime-Enforced bias.** The implementation minimum, the reference security architecture (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. And [not every resource checks Mission state](#not-every-resource-checks-mission-state): enforcement lands at chokepoints you already control, and the coarse end of the freshness dial (state-gated issuance with short-lived tokens) reaches legacy resources exactly as they are.
- **The roadmap.** Beyond Runtime-Enforced sit two labels: advanced profiles to adopt when the use case arrives (asynchronous approval, growth and completion, sub-agents, cross-domain projection, fleet management, push signals, the portable Mandate, audit transparency), and experimental ones for evaluation only (approval revision, progressive drawdown, consumption metering, offline fan-out, safe unwinding, open-world discovery). Each experimental profile is labeled for stated reasons.
- **The laws.** The stages are the laws' adoption path: each level operationalizes [all five](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority) at increasing strength, from issuance-time governance to action-time defense.
- **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-based-authorization-field-reference/#the-draft-family-at-a-glance) is the 34-document family with maturity labels on every row.

**Reading path.** ~24 minutes start to finish. Deciding whether to adopt? [The read-only ceiling](#the-read-only-ceiling) and [the levels](#run-governed-and-beyond) are your ~8 minutes. Building? Jump to [the walk stage](#walk-the-runtime-enforced-level) for 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, plain 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-based-authorization-field-reference/) carries the reconciliation date the handbook tracks. For substrate independence, the four bindings, and the trade the standalone Mission Authority Server makes, the concluding chapter, [Weighing Mission-Bound Authorization](/series/weighing-mission-bound-authorization/), is where those live.

The stages map onto the [Mission Assurance Levels](#run-governed-and-beyond) the repository publishes: crawl is the Baseline Issuance level, walk is the Runtime-Enforced level, and run is the climb through Governed and High-Assurance Agent, with the standalone Mission Authority Server as a parallel binding at every level, whether as the estate's control plane or because the Authorization Server cannot change. The three stages are the path, and the second half of this part is the terrain around it: the [ecosystem a Runtime-Enforced deployment composes with](#composing-with-the-ecosystem), the [roadmap beyond it](#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).

# The read-only ceiling

Name where most estates actually start. Agents run read-only, a human
approves or executes every write, and the deployment is a pilot with no
path to graduate. That posture is rational. In July 2025 a coding
agent [deleted a production database](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/)
during an explicit code freeze, against instructions repeated in
capital letters, and the story traveled because every enterprise
recognized the shape: nothing the agent did was outside what its
credentials allowed. A probabilistic model on
standing credentials has no stateable blast radius, so the only levers the current stack offers are to deny the writes, to put a human in front of each one, and to keep the whole thing fenced. The ceiling is a context problem before it is a courage problem: the layer deciding each call cannot see the undertaking, so it cannot price a write. The same deletion is catastrophic or routine depending on the approved work around it, and a context-free stack has to price for catastrophic every time. Task-grain context is what changes the arithmetic, which is why the graduation path below runs through the level where actions are checked against the undertaking, not through better model behavior. The posture is also expensive, and each compensating control costs more than it looks:

| Today's control | What it costs | What retires it |
| --- | --- | --- |
| Read-only scoping | The value ceiling, and the reads are not even safe: an agent can be steered by anything it was allowed to see, and everything it holds can leak ([least exposure](/notes/least-exposure-is-broader-than-least-privilege/)) | Authority right-sized from the approved task, with exposure bounded as deliberately as action |
| A human approves or executes every write | [Approval fatigue](/notes/from-a-request-to-an-approved-mission/#the-fatigue-budget) at exactly the scale where agents are useful, and the human quietly becomes the unmediated enforcement point | Approval at Mission grain, [human where the class demands it](/notes/from-a-request-to-an-approved-mission/#who-may-approve), machine-speed permits per action ([runtime enforcement](/notes/mission-bound-runtime-enforcement/)) |
| The permanent pilot | The sandbox never graduates, and shadow paths grow around it | A named enforcement scope and a claimable [assurance level](#run-governed-and-beyond) |

The ceiling has an infrastructure reading too: it is what operating
[without a control plane](/series/designing-mission-bound-authorization/#the-control-plane-for-delegated-authority)
feels like. Nothing holds a bounded desired state to reconcile the work
against, so the only safe posture is denying the data plane its writes.
The staged path below is the graduation path off this ceiling. Each
stage retires one of these compensating controls, and the point is the
prize: not safer read access, but write access you can defend.
What was managed for human delegates by judgment, deterrence, and
accountability has to be built for agents as architecture, and this
part is that architecture in adoption order.

# You do not need an agent to start

Nothing in the object requires the actor to be a model. The [card chapter](/series/what-the-corporate-card-already-solved/) runs five posts of mission-based authorization with no agent in sight, because expense governance is the pattern applied to humans, and the protocol version works the same way. A Mission does not care whether the judgment inside its bounds is a model or a person.

That makes human access the natural first deployment, and a better outcome than the one traditional IGA produces. Run crawl on access requests: the request rides the approval workflow the organization already staffs ([Deferred Approval](/notes/from-a-request-to-an-approved-mission/) is deliberately shaped like an IGA review), and what comes out the other side is not a standing entitlement waiting for the next recertification campaign but a bounded, self-terminating, evidence-joined grant: authority sized to the task, expiring with it, attributable through it. Access reviews shrink toward the ceilings and the exceptions, because the best access review is the one the expiry already performed.

And it scales down. A Mission is not reserved for the multi-agent overnight job: one resource, one approver, one afternoon is a perfectly formed Mission, and the machinery costs what the task warrants (synchronous approval, no delegation, and no per-action gate beyond issuance if the class does not demand one). What reads a use case out of the model is never smallness. It is the absence of a task, where the credential lifetime is the work.

And the actor does not need to be new. The estate already runs
standing agents that nobody calls agents: the CI pipeline that deploys
on merge, the Terraform apply that reshapes infrastructure, the RPA
bot filing what humans used to file, the Kubernetes operator
reconciling all night, the scheduled job that moves money on the first
of the month. Every one of them is long-running delegated work on
standing credentials sized for the integration rather than the task,
and every one qualifies for the same machinery for the same reason the
agent does: the work outlives the request, and the authority should be
bound to the work. Mission-based authorization is not AI tooling. It
is the missing primitive for delegated work, and the probabilistic
agent is only the actor that made the gap impossible to keep ignoring.

Sequencing follows: humans are the forgiving first users of the rails (they tolerate latency, they answer clarifying questions, and they do not get prompt-injected), and agents inherit issuance, enforcement, and evidence already proven on human traffic. The estate that governs human task access with Missions today has already built the delegated-authority control plane its agents will need tomorrow.

# 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, short-lived tokens turn that stop into a real bound (revocation reaches every path within the token lifetime, with no resource changing at all), and audit joins on one identifier. What it does not buy you is the thing the handbook 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-based-authorization-field-reference/#what-not-to-claim) says so in writing. Crawl is the right first quarter. It is not a place to live.

And meet the estate where it is. For many enterprises the first agent-credential control already shipped is a credential broker: real credentials moved into a vaulted plane, with agents holding just-in-time, short-lived, sender-constrained leases (the proposed [CB4A](https://datatracker.ietf.org/doc/draft-hartman-credential-broker-4-agents/) is the spec-shaped instance). If that is your starting point, crawl starts from an asset rather than zero, and it is one integration away: hold the Mission record at the Authorization Server or the standalone [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html), gate every mint on Mission state, and stamp the `mission` claim on the leases the broker issues. The chokepoint you already deployed becomes the issuance gate, the kill switch reaches every future lease, and the broker's ledger joins on `mission_id`. What the broker cannot supply on its own is the object, because a lease is not the task, which is the [landscape's broker row](/notes/mission-based-authorization-field-reference/#competitive-landscape) in one line.

# Walk: the Runtime-Enforced level

Walk is where the safety claim becomes real, and it is sized honestly: a substantial build, not a wedge, measured from the runtime profile's conformance section. 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/), 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 Runtime-Enforced 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, adopt the 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/from-a-request-to-an-approved-mission/), [The Agent Runtime and Audit](/notes/the-agent-runtime-and-audit/)).

The first design decision is not which extension to adopt. It is the enforcement scope: which resources, action classes, and execution paths you can actually mediate. A deployment that cannot prevent an action on a path must not claim runtime enforcement for that path.

The whole walk stage compresses into one recipe:

| | 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 as one reference architecture, each edge numbered by
the row it implements:

```mermaid
flowchart LR
    AP([Approver])
    AG([Agent])
    subgraph MI["Mission Issuer (the AS, or the standalone MAS)"]
        M[("Mission record<br/>intent_hash, authority_hash,<br/>state")]
        ST["Status surface<br/>(or issuer introspection)"]
    end
    subgraph EB["Enforcement boundary"]
        PEP[PEP]
        PDP[PDP]
    end
    RS[Resource Server]
    EV["6. Evidence,<br/>joined on mission_id"]
    AP -->|"1. approves the task"| M
    M -->|"2. mission-bound token:<br/>mission_id + authority_hash,<br/>state-gated"| AG
    AG -->|"3. each consequential action<br/>+ parameters"| PEP
    PEP -->|"4. evaluate action, parameters,<br/>actor, current Mission state"| PDP
    PDP -->|permit / deny| PEP
    PEP --> RS
    M --> ST
    ST -.->|"5. fail-closed freshness"| PDP
    M -.->|lifecycle events| EV
    PDP -.->|decisions| EV
    PEP -.->|executions| EV
```

These are six deployment surfaces, not six laws. They are how the five laws become checkable in production: a durable object, derived authority, bound credentials and decisions, runtime containment, lifecycle freshness, and attributable evidence. And the recipe is deliberately small. It does not prove every side channel is mediated, does not make the agent's reasoning trustworthy, does not unwind completed actions, and does not give cross-domain proof by itself. Those are governed-agent and advanced controls. This stage only does the thing the category cannot skip: it makes the approved task an object and checks consequential action against current state.

The same recipe lands at six 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 (until the AS redeems the [issuance grant](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html)'s MAS-minted grants for Mission-bound, state-gated tokens) | PEP coverage entirely, with the PDP joining each token to its Mission at the point of use |
| A credential broker estate | The broker keeps custody and mints short-lived leases as before, now gated on Mission state and stamping the `mission` claim, with the Mission record held at the AS or the MAS | The broker as the issuance chokepoint, plus the PEP fleet at action time |
| 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 |
| A resource you cannot change | Nothing changes at the resource: it validates short-lived, state-gated tokens exactly as it does today, with revocation bounded by the token lifetime, or a gateway or MCP PEP fronts it for the classes that need more | Issuance gating with a published token-lifetime bound, and the gateway where per-action checks are required |

Wherever it lands, the PEP has to sit at the last controllable boundary before the effect. An orchestrator check does not replace a resource PEP for a resource the agent can reach directly, and an API gateway does not cover local shell, browser, or file-system effects it never 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 the estate calls for it: the
Authorization Server truly cannot change, or one Mission Issuer must
govern many systems at once. Every one of them is on the roadmap for a reason, and none of them belongs to walk. Build the recipe above, run it, and let deployment
experience tell you which of these you actually need.

The acceptance test is the handbook's running example, run against your own deployment. Revoke a Mission and watch the next consequential action fail closed within your published freshness bound. Then pull the mission id and reconstruct the whole story: the approval, the derived authority, the decisions including denials, and the revocation. If both work, the claim is real.

Why Runtime-Enforced first, stated as reasons rather than modesty:

- **Every normative dependency is ratified.** Runtime-Enforced 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 Mission-Bound profiles themselves remain proposed Internet-Drafts: the claim is about the substrate under them, not their own status. 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, and the drafts' 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.** [The best practices' Agent Mission section](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 Runtime-Enforced deployment 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 Runtime-Enforced deployments are what turn those bets into interfaces worth hardening, and the wagers underneath the whole design are named, with their falsifying evidence, in [where this could be wrong](/notes/the-convergence-and-the-wagers/#where-this-could-be-wrong).

# Not every resource checks Mission state

Read the recipe again and notice what it does not say. It does not say every resource server evaluates Mission status, and the fastest way to stall an adoption is to hear it that way. The architecture asks one question per class, not one architecture per resource: what is this path's staleness bound, and is it published?

That is a dial, and its mechanics live where the enforcement does, in [fail-closed and active freshness](/notes/mission-bound-runtime-enforcement/#fail-closed-and-active-freshness). The short version: at the coarse end, [crawl's](#crawl-baseline-issuance) state-gated issuance with short-lived tokens is a complete revocation story for the classes below high-consequence, no resource changes, and the lifecycle suite names that pattern a conforming freshness source. At fleet scale, the [Status List](/notes/mission-lifecycle-and-change/#observe-and-revoke-pull-and-push) keeps every enforcement point current with one signed fetch.

And even the walk stage rarely touches a resource server. Look at where the six boundaries put the PEPs: the gateway, the MCP host, the harness, the credential broker, the Authorization Server or MAS. Per-action enforcement lands at chokepoints the platform already controls, in front of resources that keep validating tokens as they always have. A Mission-aware resource server, with its object-level context, is the strongest placement and the last mile, not the price of admission.

The discipline is only honesty about the setting: route high-consequence classes through a boundary that has an active freshness mechanism rather than pretending a TTL is fresh, publish the bound each path actually runs, and let the [Reference's revocation matrix](/notes/mission-based-authorization-field-reference/#when-revocation-bites) price it. Legacy is not an exception to the model. It is the model's coarse end, claimed honestly.

# Run: governed and beyond

Run is the climb above walk, and the levels are one named artifact, the Mission Assurance Levels. A level is a dependency bundle: which documents you run, in adoption order. What you can prove is the orthogonal claims axis, and the claims, not the level name, are what a relying party compares. Climb the levels in order, and claim the one you are on:

| The Mission Assurance Levels | Stage |
| --- | --- |
| 1. Baseline Issuance | Crawl |
| 2. Runtime-Enforced | Walk |
| 3. Governed Agent | Run |
| 4. High-Assurance Agent | Run |
| Standalone governance (the MAS binding) | Parallel binding, every stage |

The levels are also an unlock ladder, and this is the reading that
answers [the read-only ceiling](#the-read-only-ceiling). In the
runtime contract's own
[action classes](/notes/mission-bound-runtime-enforcement/#which-actions-are-consequential),
each level makes a broader class of agent work defensible:

| Level | What you can now defensibly grant |
| --- | --- |
| Baseline Issuance | Read access that is attributable and killable: the pilot, governed |
| Runtime-Enforced | Reversible writes inside approved bounds. This is where the read-only ceiling breaks |
| Governed Agent | Unattended operation and delegation: the overnight agent and the sub-agent, with approval evidence behind every grant |
| High-Assurance Agent | The highest classes: irreversible actions, external commitments, and privileged administration, under mediated custody and action-bound approval |

| Level | 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 |
| **Runtime-Enforced** | + [runtime enforcement](/notes/mission-bound-runtime-enforcement/) 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 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/from-a-request-to-an-approved-mission/), [agent runtime](/notes/the-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/), [agent runtime](/notes/the-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 (the MAS binding)** | Mission Authority Server + [runtime](/notes/mission-bound-runtime-enforcement/) 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, until estate ASs redeem the [issuance grant](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html)'s MAS-minted grants for Mission-bound, state-gated tokens. Without that join, revoking a Mission stops nothing at the token layer, so enforcement rests entirely on PEP coverage |

A deployment names its level and its enforcement scope, and the
[Reference's implementation checklist](/notes/mission-based-authorization-field-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 a Runtime-Enforced deployment composes with rather than replaces. One stack answers where everything sits, from the substrate up, and the [standards map](/notes/mission-bound-authorization-standards-map/) (Appendix E) carries the spec-by-spec survey behind it:

| 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, with credential brokers as the custody plane |
| 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, 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 handbook: **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 chapter 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-bound-authority/) is the binding between that substrate and the Mission.

Credential custody composes the same way: credential brokers, with the proposed [CB4A](https://datatracker.ietf.org/doc/draft-hartman-credential-broker-4-agents/) as the spec-shaped instance, are the custody fabric [the crawl stage](#crawl-baseline-issuance) already put to work, and CB4A's own future-work sketch, a native token carrying issuer, scope, expiry, and a confirmation key bound to an envelope hash, is reaching toward the `mission` claim.

Coexistence with the entitlement plane runs for years and needs a stated rule: the standing entitlement is the outer boundary, the Mission the inner one, derivation validates against what the underlying account currently holds, and a mid-Mission deprovisioning surfaces as a lifecycle event rather than a failure two systems disagree about. The gap between the two boundaries is the estate's own measure of what the layer bought.

# The roadmap: the next layer of the problem

The roadmap beyond walk has two labels, and the labeling is the design discipline, not a disclaimer. The **advanced profiles** are stable design to adopt when the use case arrives, and [the practice chapter](/series/building-mission-bound-authorization/) carries them: Deferred Approval ([From a Request to an Approved Mission](/notes/from-a-request-to-an-approved-mission/)), 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-bound-authority/)), Audit Transparency ([The Agent Runtime and Audit](/notes/the-agent-runtime-and-audit/)), Intent Shaping ([From a Request to an Approved Mission](/notes/from-a-request-to-an-approved-mission/)), and the [Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html).

The **experimental profiles** are for evaluation only. Each extension answers a question Runtime-Enforced deployments 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 |
| 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 an 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 |
| The agent meets resources its approval could not name | [Mission Open-World Discovery](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-discovery.html) | Encounters adjudicated against a pre-consented ceiling, with the lying-resource and tainted-session floors, are a newer model | The discovery loop: deny, request, approve as a successor Mission |

An experimental extension frozen before deployment evidence exists would be a guess wearing a MUST, which is the whole sequencing argument.

Two Standards Track profiles sit beside this table rather than in it, because each tracks an unratified substrate: Deferred Approval rides OAuth Deferred Token Response, and the [AAuth binding](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html) rides the AAuth protocol. And the standalone [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) is not a roadmap item at all: it is Standards Track, the estate control plane of the layer, with the [issuance grant](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-issuance-grant.html) as its middle path. [The Authority Control Plane](/notes/the-authority-control-plane/) carries the trade this binding makes.

The [Reference's draft family at a glance](/notes/mission-based-authorization-field-reference/#the-draft-family-at-a-glance) is the whole 34-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 Runtime-Enforced level means owning six 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/from-a-request-to-an-approved-mission/)
  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/))
  is the availability story: bounded caching, never fail-open. The
  design principle behind it: availability follows the artifact, not
  the issuer. Mission state distributes as signed, TTL-bounded
  artifacts, the Status response and the fleet-scale
  [Status List](/notes/mission-lifecycle-and-change/#observe-and-revoke-pull-and-push),
  cacheable and servable from replicas the way a JWKS is, so the
  Issuer's control plane can be briefly unreachable without the data
  plane losing its state source. The staleness bound you publish is
  also the outage you can ride: choose it with the Issuer's recovery
  objective in view, because a bound shorter than your recovery time
  is a promise to halt. And state the blast radius in the runbook
  rather than discovering it: an outage past the bound halts
  PDP-gated classes and only them, issuance-gated paths ride to token
  expiry, and the break-glass below is the named exception.
- **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.
- **The break-glass path.** Fail-closed is the design, so name the
  pressure valve before an outage improvises one: a dual-controlled
  emergency bypass that auto-expires, emits the same evidence as the
  path it bypasses, and suspends the runtime-enforcement claim for
  whatever it touches while active. A break-glass nobody designed
  becomes a standing unmediated path.

## The derivation policy, concretely

The first bullet above is the one deployments ask about most, so here
is the artifact at working depth. The family fixes no policy
language, deliberately: derivation policy is deployment policy, the
same kind of asset scope design was. What the drafts fix is its
contract. Derivation is mechanical, so the policy must be a function
from a validated Intent and the registry's facts to an Authority Set,
with no model in the loop and no discretion left for decision time.

One boundary keeps the word mechanical honest. The function consumes the Intent's structured members only. The Intent's free-text `constraints` bind at disclosure: they are what the Approver reads beside the derived authority, never what the function parses. A bound the PDP must enforce enters as structure, in a `proposed_authority` entry's machine-actionable constraints the shaper may translate from the request's words and the AS only ever narrows, or in the rule itself, authored by a human who read the same words. "Q3 2026" becomes an enforceable period bound at one of those two doors, and the Approver's check that the structure matches the words is what closes the gap between them.

One rule, in the shape most estates will write it. The language is
illustrative and the rows are the contract:

| The rule's parts | This rule (finance read, board-packet class) |
| --- | --- |
| Matches when | `resources` names the finance service and the validated Intent's `purpose` is in the reporting class |
| Registry facts consulted | The Agent Deployment's eligibility bounds and risk tier |
| Emits | One `mission_resource_access` entry: `query_financials`, read-only, with the fiscal-period bound sourced from the rule or the structured proposal, never parsed from free text |
| Never emits | Write actions, exports, or any entry for a resource the Intent did not name |
| Notices | The data-classification notice class, so the disclosure renders it |

Testing is fixtures, the same discipline the disclosure templates
use: a corpus of representative Intents with their expected Authority
Sets, run on every policy change, with the diff reviewed like a code
change, and `policy_version` on each record pointing at exactly which version derived what. That pointer is also the recall mechanism: a derivation version found faulty turns recall into a query, every Mission derived under it enumerable and suspendable as a class. Ownership follows the two vocabularies. The IAM
team owns the function and the ceilings. Each resource owner owns the
entries that touch their service, because
[the resource owns the meaning](/notes/mission-based-authorization-field-reference/#who-owns-the-meaning).

And price the authoring surface honestly, because this is scope
design's workload relocated, with better economics but not zero
economics. The surface is bounded by resources and action classes
rather than by integrations, it is populated once per resource and
amortized across every Mission that touches it, and templates are
where the common cases stop costing anything at all. Watch three
numbers the way the fatigue budget watches its four: the
unmapped-resource rate (Intents that fail derivation because no rule
exists), the template-hit rate (how much work rides pre-approved
shapes), and the rule-exception rate (policy edited under deadline,
the tell that the ontology is wrong).

One of those surfaces, rendered. Templates are where derivation
policy and the approval surface meet operations: pre-reviewed mission
shapes with risk and duration visible, governed by the policy
framework, and new templates entering through policy review rather
than around it:

![Mock mission templates catalog: pre-approved mission templates organized by category and risk level, usage statistics, and a create-new-template path that goes through policy review.](/images/posts/mission-templates.webp)

One more surface rides with all six: the signing keys. The Mission is a durable record rather than a token in flight, so an issuer key rollover invalidates projections and signed status while the records survive, and every projection re-derives under the new key. Key custody and a rehearsed recovery drill belong in the enforcement-scope statement, and the drill's measure is the time back to governed operation.

# What the community still has to standardize

A blueprint should also name the pieces nobody owns yet. Six 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. The venue question also has a shape answer, because a thirty-four-document family from one author is what working groups reflexively distrust: the chartering surface is deliberately small, the issuance core and the runtime invariants, with everything else evidence of thinking that enters scope only as the community pulls 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.
- **Exposure control surfaces.** Least privilege has standards and least exposure has an essay: [bounding what the agent may see](/notes/least-exposure-is-broader-than-least-privilege/) is enforced today only at its edges (catalog filtering, egress mediation, the taint rule). Scoping retrieval, memory, and context assembly to the approved task has no interoperable form, and the exposure half of minimal disclosure needs profile work nobody has started.

# 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 Agent Mission section 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 Runtime-Enforced level, run up the Governed and High-Assurance Agent levels as the deployment earns them.

Ship the reference security architecture, and add the agent-specific assurance pieces when the system is actually running agents. Its dependencies already shipped, 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/) chapter carries each control at implementation depth, the editor's copies are public, and the [Reference](/notes/mission-based-authorization-field-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.