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 answer to “how do I adopt this” is not “all of it”: it is crawl, walk, run, with each stage a deployment in its own right, plain about what it does not yet deliver, and ordered so that the first stage depends on nothing but the OAuth binding and published RFCs. The maturity and status claims in this part are as of October 5, 2026, and the Reference carries the reconciliation date the handbook tracks. For substrate independence, the five 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 Governed Agent and then High-Assurance Agent. The binding is a separate axis, and the standalone Mission Authority Server is a peer entry point the estate can choose at any stage. The build order applies to the paths being changed, as not every resource checks Mission state shows just before crawl. 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 adoption sheet

Each bundle answers four questions before anyone builds it: what changes and who owns the change, what the deployment can then defend granting, what stays outside that, and which test shows it holds. The bundles are cumulative, each including the one before it, and a deployment adopts the bundle its risk warrants and stops there. Claims apply to the paths a deployment actually governs, with issuance gating on some paths and runtime enforcement on others (not every resource checks Mission state).

The Baseline tests come from the Architecture’s verification guidance, the Runtime-Enforced test is the handbook’s running example run against your own deployment, and the Governed and High-Assurance tests restate those levels’ proof obligations as checks.

The documents follow the family manifest’s reference stacks. The first six rows are the minimum interoperable implementation, the Architecture’s reference security architecture; for issuance alone, the minimum is the OAuth binding.

High-Assurance Agent adds no documents: it is a claims level, and the runtime profile fixes both claims’ obligations. Each claim requires execution-environment attestation of the Enforcement Scope Statement, so the claim is technical rather than organizational, while base runtime conformance requires no attestation. Beyond the manifest’s stacks, this handbook also adopts at Baseline the Architecture, as the front door, and the Resource Access Profile, which every example uses, and at Runtime-Enforced the runtime’s OAuth 2.0 profile, which maps a validated Mission-bound access token onto the runtime’s inputs. Every family document is a proposed individual Internet-Draft, none adopted by a working group, and no production Mission deployment is known on any binding.

The binding is the separate axis. The standalone Mission Authority Server, a controller over the OAuth binding’s Mission data model whose package brings the OAuth binding and Status, gives 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, where it claims the optional Expansion and Child Creation capability, hosts expansion and Child Mission creation on its own submission surface. What it does not give is Mission-bound tokens and issuance gating, until estate Authorization Servers redeem the issuance grant’s MAS-minted grants for Mission-bound tokens. Without that join, revoking a Mission stops nothing at the token layer, so enforcement rests entirely on PEP coverage. An estate chooses the MAS at any stage.

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, so the graduation path below runs through the approved task rather than through better model behavior. The first stage prices the write at approval: the credential carries only authority derived from the task, so a Resource Server that enforces the token’s bounds already enforces the task’s. The second prices it per action, against current Mission state, for the bounds the Resource Server cannot check. 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, and writes become defensible at its first stage. Each stage retires one of these compensating controls and widens the write access you can defend, as the “You can then grant” row of the adoption sheet shows. 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.

Not every resource checks Mission state

Start with a path whose bounds your existing resources already enforce. Add the approved Mission record and gate credential issuance on its state, and the resources keep validating credentials as they do today. Add runtime checks where a path needs finer constraints, faster revocation, or the controls its action class requires. A path is the route by which a credential is obtained and an action reaches a resource, including the enforcement boundaries it crosses, so a gateway-mediated call and a direct call to the same resource are different paths. Claims are held per path, and the enforcement-scope statement records which paths run which shape and which stay outside Mission enforcement.

Issuance gating needs a Mission-aware Authorization Server, an integrated credential broker, or an Authorization Server that redeems Mission Issuance Grants. Without one of those, a Mission Authority Server starts with records and audit, which stop no action and no token issuance because no PEP and no Authorization Server consults Mission state yet, and prevention begins on the paths a PEP mediates. The issuer choices are set out in crawl.

Neither shape replaces the systems the estate already runs. The identity provider keeps authenticating subjects. IGA keeps the standing entitlements that bound every Mission from outside (coexistence). Gateways, MCP servers, harnesses, and credential brokers keep their jobs and add a PEP or a Mission-state check only on governed paths. Resources stay unchanged where they already enforce the scopes, authorization details, and constraints they receive. Standing service accounts stay until each recurring job moves to a Mission. The Authorization Server’s role depends on the issuer choice.

The action class sets the minimum. The high-consequence classes (irreversible actions, external commitments, and privileged administration) need runtime enforcement with active freshness, parameter binding, reverification, and evidence. A path that carries them without those controls cannot claim action-time enforcement for them, and its enforcement-scope statement records that class as unenforced on that path. Below that floor, issuance gating is enough where the receiving resource already enforces the approved bounds and the revocation delay is acceptable. A risk signal may tighten or refuse, and it never enlarges authority or bypasses the classification floor (the adversary model).

Publish the worst-case revocation bound for each path. Issuance-only paths account for the credential lifetime and the age of any older state observation used at minting, including a delayed grant redemption. Runtime paths account for state freshness, permit validity, and execution under the freshness rules. Mediated custody does not remove those windows. The Status profile counts token lifetimes sized to the tolerated staleness as a propagation mechanism, and the Reference’s revocation matrix prices each setting.

For example, an estate can gate issuance for a reporting path whose existing resource enforces the approved scope, add a PEP to payments operations that need action-time checks, and keep a third integration explicitly outside Mission enforcement. The scope statement records all three. Adding the payments PEP changes nothing at the reporting resource and does not improve the excluded integration’s claim.

Crawl: baseline issuance

Crawl is the issuance profile 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 OAuth binding, and a minimal conforming deployment fits on one screen.

Crawl’s deployed shape is what the Architecture calls the issuance-only deployment: the Authorization Server and the Mission-creating client change, and Resource Servers need not be Mission-aware. It claims approved-record integrity and bounded revocation latency, and it sizes token lifetime to the staleness it tolerates. The draft repository includes a reference implementation built on the OAuth binding, with a requirement-level conformance ledger, and describes a proposed issuance-only reference deployment of this shape: a Mission-aware AS and Resource Servers that need not be Mission-aware.

Crawl’s grant, gains, and limits are the Baseline column of the adoption sheet. Two points the sheet compresses: short-lived tokens turn the issuance stop into a real bound, since revocation reaches every path within the token lifetime with no resource changing at all, and audit joins on one identifier. The what-not-to-claim list keeps a crawl deployment from claiming the checks it lacks. Crawl is the right first quarter, and a deployment whose risk it covers can stop there.

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 (CB4A, an individual draft that has since expired, 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.

Who issues

The issuer is chosen per Authorization Server or credential plane, and one Mission Authority Server can govern many. Choosing it is a crawl decision, but a Mission Authority Server beside an unchanged Authorization Server gains prevention only at walk, through PEPs, until that Authorization Server redeems issuance grants. Every option shares the record, the anchors, and the lifecycle, so an estate can start at any row and add others later (the Architecture’s entry ramps):

Walk: the Runtime-Enforced level

Walk is where action-time enforcement arrives, and it is a substantial build, not a wedge, measured from the runtime profile’s conformance section. Two additions:

1. Put a PEP at each consequential boundary the enforcement scope covers, and adopt the runtime contract with its AuthZEN profile. The PDP evaluates each action against the live Mission, parameters bound, failures closed, and an action governed by a consumption bound the deployment does not meter refused (the metering itself is the Evaluate-only Consumption Metering profile). This is Mission-Bound Runtime Enforcement, the runtime draft with its OAuth 2.0 profile (which maps a validated Mission-bound access token onto the runtime’s inputs), the AuthZEN profile, and Mission Runtime Evidence, which owns the Decision and Execution Records.
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, size the polling to that bound. Signals can serve as walk’s freshness source too, but the handbook’s advice is to start with Status and add the push once the polling is sized.

For AI agents, the Governed Agent bundle’s additions should come with walk: 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.

Choose the issuer for each Authorization Server (who issues) and the enforcement boundary for each governed path (not every resource checks Mission state).

Wherever the PEP lands, it 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. PEP placement and credential custody are separate choices. A PEP at the resource can use the resource’s object-level context, which makes it the strongest placement. A gateway PEP makes custody possible: it can hold the sender-constraint key, so the agent never holds a usable credential for the resource behind it. Neither placement establishes agent-compromise resistance on its own. For the high-consequence classes, that claim requires the sender-constraint key held by a mediating PEP rather than the agent, action-bound approval, a disclosure rendered by a component isolated from the agent, active freshness, and the declared, audited, and attested path scope described in the high-assurance level.

And the equally opinionated negative. Do not start with Signals, Deferred Approval and Revision, the Mandate, offline attenuation, cross-domain projection, or SCITT audit transparency. Every one of them is on the roadmap for a reason, and none of them belongs in a first walk build. Build the recipe above, run it, and let deployment experience tell you which of these you actually need. The standalone Mission Authority Server is not on that list, because the estate decides it per Authorization Server (who issues), and the recipe runs with it as the Mission Issuer.

The acceptance test is the Runtime-Enforced column of the adoption sheet: the handbook’s running example, run against your own deployment. If both halves pass, the claim is real.

Why Runtime-Enforced before the roadmap, stated as reasons rather than modesty:

• The issuance floor has the smallest dependency set. Baseline Issuance needs the OAuth binding, itself a proposed draft, and published RFCs. The additional drafts the adoption sheet lists enter with runtime enforcement and do not block that floor, and the profiles’ wire details can still change with review, so design against the laws and the architecture rather than the claim names.
• It is the smallest object that closes the named gap. That gap is the translation from mission to authorization requirements that AIMS leaves out of scope, and the Runtime-Enforced deployment is that translation: an approved, integrity-anchored task object, authority derived from it, actions enforced against it, state observable for it.
• The roadmap should follow deployment evidence. The Evaluate-only extensions encode design bets about approval revision, 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.

Run: governed and beyond

Run is what follows walk: the Governed Agent bundle for unattended agents and delegation, and the High-Assurance Agent bundle for the high-consequence classes, both laid out in the adoption sheet. The Architecture defines each Mission Assurance Level as an adoption bundle: a named set of documents, taken in the order deployments build them. A level is guidance, not a conformance class or a rank to reach. A relying party compares the assurance claims a deployment can show (approved-record integrity, bounded revocation latency, action-time enforcement, parameter-bound enforcement, transaction-grade execution, and the named high-assurance claims), not its level.

Read in adoption order, the levels also answer the read-only ceiling: in the runtime contract’s own action classes, each makes a broader class of agent work defensible to grant, which is the sheet’s “You can then grant” row. The mapping is informative, and what a level grants varies with the binding.

A deployment names the bundle it runs, its enforcement scope, and the assurance claims it can show, and the Reference’s implementation checklist is the checkable form of those claims, 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 profile is the interoperable PEP-to-PDP surface. ARAP turns a denial into a governed request, and the AuthZEN profile lets the PDP mark out_of_authority and 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. AROP, the AuthZEN Access Request OAuth Profile, merged into the AuthZEN working group’s repository in September 2026, 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: AIMS’s best practices for agent authentication and authorization, the Actor Profile for delegation chains, and Client Instance Identification with Client Attester Endorsement for attributable instances. Instance evidence alone identifies no actor, so attribution also needs an instance-unique key. Mission-Bound Authority is the binding between that substrate and the Mission.

Credential custody composes the same way: credential brokers 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. They are the handbook’s adoption guidance, separate from the drafts’ own spec-maturity axis, on which 43 of the 51 documents are experimental. The advanced profiles are designs to adopt when the use case arrives, and the practice chapter carries them: Deferred Approval and Intent Shaping (From a Request to an Approved Mission), Expansion, Entry Discharge, Lifecycle Signals, and the Mission Status List 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), and the Mandate.

The Evaluate only profiles are for evaluation. Each extension in the table answers a question Runtime-Enforced deployments will surface in production, and the third column says why it waits. Signals, in the first row, is advanced, and sits here because push is an optimization a deployment adds after sizing its polling:

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

Two profiles proposed for the Standards Track sit beside this table rather than in it, because each tracks a substrate that is still a draft: Deferred Approval rides OAuth Deferred Token Response (an OAuth working-group draft since September 2026), and the AAuth binding rides the AAuth protocol (an individual draft, at -11). And the standalone Mission Authority Server is not a roadmap item at all: it is a proposed binding requesting the Standards Track, a standalone controller over the OAuth binding’s Mission data model that can serve as 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 51-document catalog in one table, with these adoption labels on every row.

What you will operate

The blueprint is complete 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 Mission 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 deterministic function from a validated Intent and the registry’s facts to an Authority Set, with no discretion left for decision time. A model’s output can enter only as a recorded input, kept with the model’s identifier and version, that refuses or narrows. It never supplies or widens an entry, and a replay uses the retained output instead of rerunning the model.

One boundary keeps the word mechanical honest. The function consumes structured members only: the Intent’s purpose and target_resources, and any top-level authorization_details proposal submitted beside it, which proposal_hash commits as submitted. The Intent’s human-readable task_bounds bind at disclosure: they are what the Approver reads beside the derived authority, never what the function parses, and the AS derives the same set whatever they say. A bound the PDP must enforce enters as structure, in a proposed authorization_details entry’s machine-actionable constraints the shaper may translate from the request’s words and the AS only ever narrows (narrowing mode), or in the configured rule itself, authored by a human who read the same words (configured-mapping mode). “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 against a deployment-maintained index, every Mission derived under it enumerable and suspendable as a class; Mission Management does not yet standardize selection by policy version. 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.

Adjusting policy from evidence

Review decision and execution records, consumption where it is metered, approval workload, denials, exceptions, and the three derivation rates above on a regular cadence, joined to the Missions and policy versions that produced them. An issuance-only deployment has approval, issuance, and lifecycle evidence. Action-level conclusions need execution telemetry that can be reliably joined to the Mission, which ordinary resource or broker logs may provide. Missing coverage limits what the review can conclude.

Authorized policy can suspend a Mission through the lifecycle surfaces, and narrow one where the deployment runs the Evaluate-only containment profile. Evidence never authorizes a broader grant by itself: a human consents to a broader template or ceiling, or approves a policy change, and later activations still follow the applicable approval and lifecycle rules. Inside an envelope a human already consented to, policy may adjudicate eligible instances and successors. A new policy version does not enlarge an existing Mission’s committed Authority Set.

The review applies to every class. It can tighten high-consequence paths but never replaces their pre-action controls, because approving fast and reconciling later is tuned wrong for irreversible verbs. The ceiling review is the control plane’s reconciler for this evidence. Fleet-wide consumption and denial queries, selection by derivation policy version, and comparing consumption with the time a Mission has left have no standard form yet; a deployment-maintained index can serve recall locally.

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 AIMS, a WIMSE working-group 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 large family from one author is what working groups reflexively distrust: the proposed standardization surface is three layers, the informative Architecture (the model), the normative Substrate Requirements (the binding-neutral kernel contract), and the OAuth issuance binding. Everything else, the runtime profiles included, is companion work on its own timeline 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, client instance identification, and attester endorsement exist as proposed 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 AIMS, 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 profile, walk with the Runtime-Enforced level, and run with the Governed and High-Assurance Agent levels where the risk warrants them.

Ship the reference security architecture, and add the agent-specific assurance pieces when the system is actually running agents. It is the smallest interoperable surface that makes the approved task first-class, and its deployments are what should decide how the rest hardens. 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.