Adopting Mission-Bound Authorization

Overview

A definitive architecture that ends without “what do I do now” is a tour, not a blueprint. 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 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, is where those live.

The stages map onto the Mission Assurance Levels 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, the roadmap beyond it, the operational surfaces you will own, and the pieces 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 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:

The ceiling has an infrastructure reading too: it is what operating without a control plane 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 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 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 and the core draft, 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 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 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, 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 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, the runtime draft, and the AuthZEN profile.
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, 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, 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 same recipe as one reference architecture, each edge numbered by the row it implements:

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:

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

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. The short version: at the coarse end, crawl’s 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 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 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 levels are also an unlock ladder, and this is the reading that answers the read-only ceiling. In the runtime contract’s own action classes, each level makes a broader class of agent work defensible:

A deployment names its level and its enforcement scope, and the Reference’s 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 (Appendix E) carries the spec-by-spec survey behind it:

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 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 binds that workflow to OAuth completion for the token-side case. The Least-Privilege MCP series walks this per-call stack from the beginning, and the MCP application post 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 for delegation chains, and the Client Instance Assertion with the AI Agent Instance Profile for attributable instances. Mission-Bound Authority is the binding between that substrate and the Mission.

Credential custody composes the same way: credential brokers, with the proposed CB4A as the spec-shaped instance, are the custody fabric the crawl stage 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 carries them: Deferred Approval (From a Request to an Approved Mission), Expansion and Completion with the fleet Management surface (Mission Lifecycle and Change), Child Delegation and Cross-Domain Projection (Mission-Bound Authority), Audit Transparency (The Agent Runtime and Audit), Intent Shaping (From a Request to an Approved Mission), and the Mandate.

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:

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 rides the AAuth protocol. And the standalone Mission Authority Server is not a roadmap item at all: it is Standards Track, the estate control plane of the layer, with the issuance grant as its middle path. The Authority Control Plane carries the trade this binding makes.

The Reference’s 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 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) 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, 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’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:

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.

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:

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 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 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 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, 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 chapter carries each control at implementation depth, the editor’s copies are public, and the Reference is the citable definition. That experience has a place to land: issues and pull requests on the draft repository are the fastest path into the documents. The gap has a name now. It should have an object.