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, 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 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 is the advanced companion.

The stages map onto the adoption ladder 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, the roadmap beyond the wedge, the operational surfaces you will own, and the pieces 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 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, 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 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, 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 protocol MVP half of 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, The Agent Runtime and Audit).

The whole walk stage compresses into one recipe, and Minimum Viable Mission-Based Authorization carries it as a standalone one-pager, ready to hand to a team:

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

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

A deployment names its rung 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 the protocol MVP composes with rather than replaces. One stack answers where everything sits, from the substrate up:

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

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), 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 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:

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

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

Where this leaves you

If you arrived from 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 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.