Mission-Bound Authorization: The Complete Edition

Stand at any enforcement boundary and ask the question in this essay’s title. A resource server holds a valid token. A policy engine holds a permitted request. A session store holds an authenticated continuation. Now ask what work this is, who approved it, and whether it is still on. Every layer answers a question adjacent to that one, and in most estates none of them answers it.

Ask why, and the useful answer is that no one designed the authorization stack as a whole. It accumulated one problem at a time. Each generation solved the question its era made urgent, and deferred the question above, because someone else was always carrying the answer: the person at the keyboard, the application’s workflow table, the ticket in the queue. Infrastructure usually evolves that way, and this is a model history rather than a literal timeline, since the generations overlap and modern systems run all of them at once. The point is to name the scaling problem that made each abstraction succeed, the carrier that let it defer the undertaking, and the moment the deferral stopped working.

Every generation answered its era’s question

Passwords answered who may enter. Shared systems needed to distinguish users, and password authentication helped bind an interaction to a principal. The credential did not describe an undertaking. It did not need to: the person at the terminal was the carrier, holding the purpose in their head and stopping when the work was done.

Capabilities answered delegation by possession. Dennis and Van Horn (1966) described the capability: an unforgeable reference that carries its own authority, so whoever holds it may use it and pass it on. The tradition made narrowing the native operation of delegation, and macaroons (2014) brought it to web credentials, with caveats that “attenuate and contextually confine when, where, by who, and for what purpose” a service should authorize requests. A caveat can name a purpose. It does not make the undertaking an object with an owner and a lifecycle that other boundaries consult: the authority travels with the holder, and the person who handed it out carries the reason it should stop.

Sessions answered continuity. The web split one interaction across many stateless requests, so sessions carried authenticated context from one request to the next. A session says that these requests belong to the same authenticated interaction. It does not prove that the person is still attentive or explain what the interaction is trying to accomplish, because the person is presumed present, and presence is the carrier. The session grain later gained a cross-domain stop signal: OpenID’s Shared Signals Framework and its Continuous Access Evaluation Profile (1.0, 2025) let one party tell another that a session or credential changed state so the receiver can end it. That answers whether the session is still on, and the work the session serves still has no state of its own.

RBAC answered administration. Enterprises could not manage permissions one user at a time, so roles associated permissions with organizational responsibilities. NIST’s early RBAC work described the administrative advantage directly: users receive permissions through roles and can change assignments without rewriting the underlying access structure (Ferraiolo, Cugini, and Kuhn, 1995). A role is therefore usually sized to a responsibility or job function, not one bounded undertaking. The undertaking had its own carrier: the job itself, with a manager, a process, and a paper trail deciding what the role-holder should actually be doing today.

Federation answered trust across organizations. Enterprises needed one login to reach many providers, so SAML and later OpenID Connect standardized the assertion: a signed, minutes-lived statement of who authenticated, with what attributes, at what strength. The undertaking appears nowhere in that trust infrastructure, because the assertion opens a session on the far side, and the person inside that session carries the why across the boundary in their own head.

OAuth answered limited API authority. Applications needed a way to access protected resources without collecting every user’s password. OAuth 2.0 standardized how a client obtains and presents authorization, with access tokens representing particular scopes and durations. It also included client-only authority through the client credentials grant. OAuth’s core question is not simply “who delegated?” It is broader: what authorization may this client present to this resource server? OAuth is also the one generation where the approval visibly happened: a human saw a consent screen and said yes. Then the base protocol kept the authority and discarded the event. The scopes survive on the token, what was shown and agreed to does not, and the person who consented becomes the carrier of what they meant by it.

UMA answered asynchronous resource sharing. User-Managed Access (UMA) 2.0 extended OAuth so a requesting party’s client could use a permission ticket to seek a requesting party token (RPT) for protected-resource access asynchronously from the resource owner’s authorization. The authorization server evaluates resource-owner policy conditions and requesting-party claims, and can manage access grants over time. UMA therefore removed the assumption that the resource owner must be present when access is requested.

That makes UMA important prior art, not a near miss to dismiss. Its governed object is a requested or granted set of permissions to protected resources. Policy condition setting is deployment-defined, and the specification does not make a multi-step undertaking the common root for authority derivation, delegation where supported, execution state, and evidence across all systems participating in the work. A deployment can add those semantics around UMA, and the added task lifecycle is the Mission-shaped part.

Two later standards come closer still. GNAP (RFC 9635, 2024) makes the grant a negotiated object at the authorization server: a client can continue, modify, or revoke an ongoing grant request, so access has a lifecycle both sides share. Transaction Tokens, an OAuth working-group draft awaiting its write-up, carry an authorization context through a call chain inside one trust domain, with the transaction’s purpose scoped as narrowly as possible and context that stays immutable along the chain. GNAP gives the grant a lifecycle, and Transaction Tokens carry purpose across hops, but neither makes the approved undertaking the governed object: a GNAP grant governs access, and a transaction token lives for one request inside one domain.

Workload identity answered which software is acting. Cloud and container platforms could not safely identify workloads with shared, manually provisioned secrets. Workload identity systems bind a runtime process to a verifiable software identity and issue credentials without requiring the workload to manage a long-lived secret. SPIFFE’s Workload API, for example, supplies X.509 or JWT identity documents to an identified workload, while SPIRE can select the identity from attested process and platform attributes.

That is a major step for attribution and credential hygiene. It still answers which workload, not which approved undertaking. One workload identity may execute thousands of tasks, and one task may fan out across many workload identities. The active IETF WIMSE working group is addressing how workload identity technologies compose across multiple systems. Task approval and lifecycle remain a separate authorization concern. And here the carrier begins to thin, because a workload has no head to hold the purpose in.

Fine-grained authorization answered the request. Scopes and roles were too coarse for many estates, so ABAC, ReBAC, policy engines, and externalized decision services made the request itself the decision unit. NIST’s ABAC definition allows policy to evaluate subject, object, operation, and environment attributes. A policy decision point can answer whether this request is permitted with great precision, but it can evaluate only the context it receives. It does not inherently own the approval, lifecycle, or cross-domain distribution of an undertaking. It evaluates what it is handed, and something else must carry the undertaking to the boundary.

Lay the abstractions out and the remaining responsibility becomes visible:

The claim is not that these layers cannot carry purpose. XACML’s privacy profile, for example, defines an explicit action:purpose attribute. ABAC can evaluate a purpose, ticket, or task identifier as an environment attribute. The unresolved architectural question is who creates that state, binds approval and authority to it, keeps it current, and makes it available across every boundary included in the claim.

The second stack

The why was never missing from the enterprise. It was in the other stack.

Alongside the authorization stack, every organization runs a work stack: purchase orders, change tickets, case records, workflow runs, access requests and their approvals. That stack has always held exactly what the authorization stack lacks: what was asked for, who approved it, what it covers, and when it ends. A change ticket has a scope and a window. A purchase order has an amount and a counterparty. An access request has an approver and a justification.

Outside a few regulated domains, the two stacks never merged. The work stack’s records are not enforceable objects: nothing at a resource server consults the ticket before honoring the token that was provisioned because of it. The authorization stack’s artifacts are enforceable but carry no undertaking: the token outlives the change window it was granted for. The join between them was human process. Someone read the ticket, provisioned the grant, and was supposed to remember to remove it, and every access recertification campaign since is the cost of that join.

Seen from this history, the Mission is the merger the two stacks have owed each other for decades: the work stack’s record given the authorization stack’s enforceability, approval-backed state that boundaries consult rather than paperwork that boundaries trust someone else to have checked.

Why OAuth stopped where it did

It is tempting to read OAuth’s silence about a generic task lifecycle as an oversight. It is better understood as a protocol boundary.

OAuth standardized authorization grants, token issuance, scopes, durations, and resource-server access. It did not try to standardize the semantics of every workflow an API might serve. Later work expanded the model in important directions. UMA made authorization asynchronous with respect to the resource owner and policy-driven across protected resources. Rich Authorization Requests, for example, can represent a specific payment amount, creditor, and set of actions. But each API defines the meaning of those details, and RFC 9396 explicitly leaves their combination and comparison to the API and authorization server. Rich authority is not automatically a durable, shared task lifecycle.

One branch of OAuth did build the object, inside one domain. Open banking needed a customer’s approval of a specific account access or payment to outlast the tokens that carried it, so the UK Open Banking APIs have the client first create a consent resource at the bank. The resource has its own identifier and a status (awaiting authorisation, authorised, rejected), the customer authorizes that intent, the client can delete it, and the bank’s security profile treats the intent’s authorized state separately from token expiry. Australia’s Consumer Data Right returns a cdr_arrangement_id with the tokens and defines an arrangement revocation endpoint, and OpenID’s Grant Management gives a general grant an identifier a client can query and revoke. These are approved-intent objects with a lifecycle and tokens bound to them, deployed across national ecosystems. Each lives inside one data holder’s authorization server, with a schema its domain fixes, governing access to that holder’s resources. The Mission generalizes the pattern across resource servers, sub-agents, delegation, and runtime checks.

That separation was productive: the work stack held the purpose, the person carried it between systems, and OAuth did not need to become a workflow protocol to succeed.

The limitation appears when work crosses the walls that held its context. A private task table can govern one platform well. It cannot govern a resource server, sub-agent, credential broker, or partner domain that never receives its state. What has no standard form is therefore not “purpose” in the abstract. It is interoperable, approval-backed task state at the boundaries that rely on it.

The theory arrived early

The idea of continuing authorization is not new. In 2004, Park and Sandhu’s UCONABC usage-control model generalized access control to include authorizations, obligations, conditions, ongoing decisions, and mutable attributes. UCON recognized that authorization need not be a one-time gate: relevant state can change during use, and a decision may need to change with it.

That prior art matters for two reasons. First, ongoing evaluation and mutable authorization state should not be presented as inventions of agent security. Second, continuing decisions alone do not identify the governed undertaking. A policy engine can repeatedly evaluate current state only after some system defines the state, owns its transitions, and makes it trustworthy to the enforcement point.

Mainstream authorization deployments had practical substitutes: application workflow, tickets, sessions, short-lived credentials, and human operators. Continuous checks also impose state-distribution, availability, latency, and ownership costs, and for twenty years the workaround was cheaper, because a human carrier costs nothing at the protocol layer. Unattended, cross-system work breaks the workaround. It makes stale task state a recurring runtime problem instead of an occasional integration concern, and it removes the person who used to notice.

Integrations broke it first. In April 2022, stolen OAuth user tokens issued to Heroku and Travis CI were used to download data from dozens of GitHub organizations, including private repositories. In August 2025, compromised OAuth tokens from the Salesloft Drift integration were used to steal data from Salesforce instances, and affected organizations were advised to review every third-party integration connected to Drift and revoke and rotate its credentials. In both, the tokens were valid and did what they were scoped to do, and response meant finding and revoking credentials integration by integration, because no record said which work each token served.

The experiment that breaks the composition

Run the composition against one month-long undertaking. Jordan tells an agent to handle the company’s taxes. The agent evaluates filing software, engages a bookkeeping sub-agent, requests documents from a payroll provider, files an extension, waits for a state response, resumes three weeks later, and appeals a rejected form.

Each component can be locally correct. Each provider issues a valid grant. Every resumed session authenticates successfully. Each API accepts only its own documented scopes or authorization details. The bookkeeping sub-agent has an attested workload identity and rotated credentials, and every policy decision is defensible from the inputs it received.

Now ask about the undertaking as a whole. Which approvals authorize the sub-agent to contact the accountant? Which grants belong to this tax engagement rather than another one? Which authority should survive the extension and which should discharge after filing? If Jordan’s business is acquired and the engagement must stop, which active sessions, tokens, queued steps, and derived grants are part of the stop?

An orchestration platform may know the answer in a private workflow record. An IGA or PAM system may hold the approval. An audit system may reconstruct much of it afterward. The problem is that no individual credential, session, role, token, or policy decision necessarily carries the whole relationship, and a remote enforcement point cannot consult state it was never given.

Nothing in the underlying stack has malfunctioned. Every layer answered its own question correctly. What the composition is missing is the one participant whose job was never written down: the person who held the whole engagement in their head, noticed when circumstances changed, and stopped. Unattended work moves that person off the execution path while the work continues across hours, actors, and domains. The carrier is gone, and no layer was ever asked to replace them.

The strongest case for leaving the stack alone combines the pieces that already work. Short-lived tokens bound the exposure but do not know which task they serve. A workflow engine knows the task but keeps that state private to its platform. IGA approves access at provisioning time and reviews it later, not at the moment of use. A human in the loop restores the carrier, and with it the approval load that unattended work exists to remove. Each closes part of the gap, and the objections appendix takes them one at a time.

The missing shared answer

The Mission is this handbook’s proposed answer: a durable, approved, integrity-anchored record of an undertaking and its Authority Set. Credentials project authority from it. Consequential actions are checked against its current state within a declared enforcement scope. Delegation, where supported, cannot exceed the approved Authority Set. A non-active Mission stops new derivation, and stops reliance on each path the deployment governs within that path’s published bound; a path outside Mission enforcement is not reached. Effects that already completed still require cancellation, compensation, or review.

The field has reached the same question from other directions. AIMS, a WIMSE working-group document, names the agent’s mission and leaves its translation into authorization requirements out of scope, and other proposals are converging on the same object. The thesis is wrong if platform-private task state plus short-lived credentials prove enough for work that crosses domains, and Chapter 5 states those wagers, the issuer bet and the revocation bet, with the evidence that would settle them.

The handbook develops that object and its five laws: Durability (the governing record is independent of credential lifetime), Attribution (actions remain attributable), Narrowing (derived authority only narrows), Termination (non-active state stops reliance within scope and freshness bounds), and Containment (consequential actions are checked against the approved Authority Set and current state). Those are deployment obligations, not properties that follow from adding a claim to a token.

This history also explains why the argument is broader than AI. CI pipelines deploy after a merge, scheduled jobs move money at midnight, and infrastructure controllers reconcile systems while teams sleep. Each is unattended work whose purpose often lives in a repository, ticket, or platform-local record while its credentials are sized for an integration.

Agents intensify the problem because their plans change, their work fans out, and untrusted content can steer their choices. They did not create the missing shared state, but they make its absence harder to tolerate.

Identity now covers people, clients, and attested workloads, and authorization can decide whether a particular request is permitted. The question in this essay’s title could always be answered and could always be deferred, because someone was there to carry the answer and no generation had to make it a standard. Unattended work removes that someone, which makes it this generation’s question.

A new hire starts on Monday. She is trusted, vetted, and hired precisely because she has good judgment. Nobody hands her the company checkbook.

In a mature spend program, she gets an instrument with a boundary: a corporate card, a virtual card, or a travel approval that controls what the card can do. It has a limit. It works for travel and software, not for jewelry. It draws against a budget someone approved for a reason, and it can die the day she leaves or the project ends. Inside those bounds, nobody reviews every purchase in advance. She is expected to make smart decisions inside a risk boundary, and the boundary does the worrying.

Now look at how the same company deploys an AI agent. It provisions an agent identity, grants it credentials with broad standing authority, and leaves them standing indefinitely. The credential might be an OAuth token, an API key, a workload identity, or a cloud service principal. The shape is the same everywhere. There is no purpose attached to the credential, no budget it draws against, no per-action check, and nothing that ends when the reason for the work goes away.

Put that in card terms. It is a card with no spending limit, no expiry that matters, and a single merchant category that covers everything. Nobody would run finance on that card. Most agent deployments run on nothing else.

An agent credential today is a blank check with an expiry date.

The failure mode is not autonomy. It is the blank check.

Credentials are projections, not authority.

The strange part is that enterprises already run a mature delegated-authority system for humans. They did not build it as an IAM system. They built it as expense governance, and almost nobody calls it what it is: an operating delegated-authority architecture. This part walks that architecture end to end and maps it onto the authority gap explored in the Power of Attorney and Mission Shaping arguments. Then it names where the analogy breaks, because the breaks are the build list.

The authorization architecture nobody calls one

Follow one trip through a modern spend system.

An engineer needs to attend a conference. She does not email the CFO. She fills out an intake form: destination, dates, business reason, estimated cost. Say $3,400 for a cloud conference. The form will not let her submit “some conferences, whatever it costs.” If the cost center is missing, it asks. The form structures the request. It approves nothing.

Her manager approves the trip against a delegation-of-authority matrix. Managers approve to $5,000. Directors to $50,000. The numbers differ at every company, tuned to its risk appetite and how much it trusts its people. The pattern does not. The approval is recorded: who approved, what they saw, when.

Here is the step everyone overlooks. The engineer asked for a trip. Finance derived the controls: a $3,400 limit, travel and lodging merchant categories, valid November 29 through December 5. She proposed the trip. She did not define the authority. Finance derived the authority from the approved trip.

A corporate card is not permission to spend. It is a bounded projection of an approved purpose, checked at every swipe.

Then the issuer does the enforcing. Every swipe is authorized in real time against current state. Is the card active? Is the limit remaining? Is the merchant category allowed? A steakhouse works. A casino declines. Nobody predicted the specific restaurant in advance, and nobody had to. Judgment operates inside the boundary. The boundary is checked at the edge, every time. Enterprises already run this pattern for APIs. An API gateway evaluates authentication, quotas, scopes, and policy on every request. The agent gap is not the idea of per-request enforcement. It is the absence of a first-class approved task for that enforcement to evaluate against: is this action still inside the mission?

Notice what the swipe check did not do. It did not page her manager. Corporate cards are deliberately low-friction. Nobody asks permission to buy lunch, because permission happened earlier and the boundary carries it forward.

The goal of delegated authority is not to ask permission more often. It is to ask permission less often, with better boundaries.

That is the analogy, and no more. Corporate cards do not make employees trustworthy, prevent every bad purchase, or eliminate reconciliation. They make delegated spend governable. The claim for agents is the same: autonomy becomes acceptable only when the instrument is a projection of an approved purpose, each consequential action is checked at the edge, and the instrument stops working when the purpose ends.

The rest of the loop is just as deliberate. The budget meters down with each transaction. A big purchase above her threshold needs a second, specific approval no matter how much budget remains. If she needs more than was approved, she cannot raise her own limit. She submits a new request and someone with sufficient authority grants a new one. If the conference is cancelled mid-trip, the card freezes while it is still in her wallet. And every transaction carries the project code, so an auditor can pull one thread and see the whole trip: the request, the approval, every swipe, the reconciliation.

Really large commitments never touch her card at all. A $200,000 contract goes through procurement, and accounts payable executes the payment after its own checks. For the spend that matters most, the person doing the work never holds the payment instrument.

The same loop, control by control

Every control in that loop answers a question that agent authorization is currently answering badly or not at all.

Two rows deserve emphasis, because they carry the safety argument.

Transaction-time authorization is what makes the limits real. A card number with no authorization rails behind it is just a promise. The limit, the categories, and the freeze all become real at the moment of the swipe, or they are not real at all. Agents get that moment in two places. The first is the system the agent acts on: when it enforces the limits written into the agent’s credential, the limit and the categories become real where the work happens, which is already enough for the writes those limits cover, short of the highest-consequence actions. The second is a check before each action against the live task, which makes the rest real: the freeze, and the exact amount and counterparty that no credential carries. A purpose-labeled token that nothing checks at the point of use is bookkeeping, not a boundary.

The freeze works because the card is not the authority. When the trip is cancelled, nobody hunts down the physical card. The instrument in her wallet keeps existing. It just stops working, because the thing it projects from was terminated. The plastic is replaceable. The governance record is the asset. Agent systems mostly have this backwards today. The token is the authority, so ending the work means finding every token, every cached connection, every sub-agent that still holds one. Sessions Are Not Missions makes the runtime version of this argument: the engineer still being on the trip does not mean the trip is still approved.

The card was rebuilt a decade ago

If the loop above sounds like an idealized finance department, look at what actually happened to the corporate card in the last ten years.

The incumbent model was the blank check with better paperwork: standing plastic issued at hire, merchant-category guesswork for control, and a month-end expense report as the enforcement moment. Everyone knew the report was audit, not control. The money was already gone.

Then spend platforms like Ramp and Brex rebuilt the instrument, and the rebuild is a checklist of this part’s loop. The request became the approval workflow. The approval mints the card, a virtual instrument scoped to the vendor, the amount, and the purpose it was approved for. Policy moved from the report to the authorization, so the out-of-policy purchase declines at the register instead of surfacing three weeks later. Receipts match at transaction time, the project code is native, and the single-use card retires itself when the purchase completes.

Finance teams did not adopt purpose-issued cards because auditors made them. They adopted them because the rebuilt loop gave more control and less friction at the same time, the trade this part describes for agents.

That is the uncomfortable part for agent infrastructure. Agent credentials today are the incumbent model: standing authority issued at integration time, category-level guesswork for scope, and logs as the enforcement moment. And the market’s verdict on that shape is already visible: agents get read access and a human keeps the writes, because nobody can price the risk of the incumbent model at machine speed. The card world faced exactly that shape and rebuilt it, and the rest of this chapter maps the same rebuild for agents.

Where the analogy breaks

An analogy this convenient should be distrusted on schedule. It breaks in five places, and each break marks work the agent stack cannot borrow from the expense world.

Money is one-dimensional. Authority is typed. Every card transaction is the same verb: move money to a counterparty. Purchases differ in amount and merchant, and the damage is denominated in the same unit as the control, which is exactly what makes a scalar limit work. Agent actions are not purchases. An agent is doing things, not buying things. Its actions are different verbs entirely (read, send, delete, sign, deploy), and their consequences share no common denominator. A $50 mistake and a $50,000 mistake sit on one scale. Deleting a record and emailing a customer do not. So agent authority has to be typed (which resources, which actions, which parameters, under which conditions) and classified by consequence rather than by merchant. Vendor-locked, single-use virtual cards show the direction of travel, an instrument bound to one counterparty and one amount. But agent authorization needs that specificity as the norm, not as the premium feature.

There is no card network for agent actions. This is the deep one. Card-accepting merchants route through common authorization rails, so the issuer’s transaction-time decision can reach the point of sale. Agent actions cross API providers, SaaS tenants, and tool servers that share no common enforcement fabric. Each resource validates its own tokens on its own schedule and learns nothing when the task behind them ends. Put another way, card payments run on two infrastructures: issuance rails and transaction-time authorization rails. OAuth gives enterprises widely deployed delegation and token issuance rails, but not a universal action-time authorization fabric across resource servers. Agent systems have pieces of the first and no equivalent of the second. What the agent world needs, in effect, is common task state and enforcement contracts: an approved task as a first-class object that issuance, enforcement, and revocation all consult, so that terminating it can reach the places where the mission was projected.

There are no chargebacks for un-send. Most spend is compensable. Refunds, reversals, and chargebacks form a mature unwinding system with its own rails. Agent actions include sent messages, deleted records, signed commitments, and published data, where no issuer can claw the effect back. The expense world gets to be casual about mid-flight cancellation because money can usually be put back. Agent systems have to plan the unwinding before the action runs, because often it cannot be.

Employees fear the expense report. Agents fear nothing. Expense governance quietly leans on accountability. The traveler knows the reconciliation is coming, and deterrence fills the gaps the controls miss. An agent has no career to protect, and worse, its judgment can be rewritten mid-task by content it reads. No sign in a shop window has ever prompt-injected a human into buying a forklift. Accountability deters people. It only records agents, unless it feeds a runtime boundary. This is why the runtime check has to carry more weight for agents than the card network carries for people. Deterrence is not available as a compensating control.

Spend is centralized. Risk and trust are not. Expense governance works partly because one function owns it. Finance sets the tiers, issues the instruments, and runs the reconciliation, and everyone accepts that. Authority in most organizations is the opposite. Every application owner, platform team, and resource owner sets its own rules, and no single function owns what agents may do. The lesson to carry over is narrower than it first appears. The card system centralizes the record, not the decision. The issuer enforces the issuer-side bounds while every merchant still runs its own fraud checks, and a permit from one never overrides the other. Agent authority can follow the same split. Centralize the approved task so there is one thing to approve, observe, and terminate. Leave each resource authoritative for its own policy. What cannot stay distributed is the record itself, and some function will have to own it the way finance owns the budget. That is an organizational bill, not just a protocol one.

The build list from the whole loop: purpose, projection, per-action checks, task-tied delegation, and endings that reach everywhere the authority went.

The uncomfortable comparison

Read the mapping table again, top to bottom, and notice what it implies: a mature finance organization runs some version of every row.

For agents, many deployments still run few of them. The agent holds broad scopes granted at integration time, exercises them at machine speed against systems that mostly see token validity, and keeps working until a credential happens to expire.

The gap is not a missing product feature. It is a missing object.

And none of this is an indictment of the identity stack. OAuth and its siblings were built for a world that never needed expense semantics: applications were static, sessions were short, permissions were predefined at registration, and a human sat at the keyboard for every consequential moment. The human was the governance system. Purpose, budget, and endings all lived in someone’s head, enforced by presence. Agents kept the credential shape and removed the person, and the controls that were never needed became the controls that are missing.

The expense system works because the approved purpose is a first-class record that every control consults: the intake form proposes it, the approval creates it, the card projects it, the issuer enforces it, the freeze terminates it, and the project code joins everything back to it. Agent infrastructure has tokens, sessions, and logs. It does not yet have the thing they should all be projections of. That is the argument the Mission Shaping series makes in protocol terms.

The mapping is compact enough to carry:

The card program works because those objects are distinct and tied together.

The last thing the analogy does is set the bar, and the bar is “ordinary.” None of the expense controls above are considered advanced. They are what any competent finance organization does by default, because the alternative, handing out blank checks and reading the statements afterward, is obviously negligent.

So when evaluating an agent platform, apply the corporate-card test:

• Where is the approved purpose recorded, and who approved it?
• Who derived the agent’s limits, and can the agent widen them itself?
• What checks each action at the moment it runs, against what state?
• When the reason for the work ends, what stops, and how fast?
• Can a sub-agent spend the parent’s authority, or does it get its own, narrower grant?
• Can an auditor pull one identifier and see the whole task?

If the answers would be unacceptable for a corporate card program, they are unacceptable for an agent that can touch the same systems, move faster than any employee, and be talked into things by the documents it reads.

Give agents what you give people you trust: real autonomy, a real boundary, and an instrument that stops working the moment the mission ends.

Enterprises already know how to delegate authority safely. They do it every day, at global scale, with a piece of plastic. The surprise is not that agents need a new security model. The surprise is that we forgot we already built most of one.

Stop issuing blank checks.

The four posts that follow open each room of this loop: the approval that binds what the approver was shown, the contractor’s card that narrows instead of borrowing, the network that approves every transaction rather than trusting the card, and the ending that actually ends.

A manager approves a conference request on her phone, in the elevator, between meetings. Four months later an auditor asks what she approved.

The only defensible answer is not “a trip, roughly.” It is the request as it was rendered on that screen, at that moment: the destination, the dates, the $3,400 estimate, the cost center, the attached quote. If the approval means anything at all, it means that. Not what the requester intended. Not what the system stored somewhere else. What the approver was shown.

The approval binds the disclosure, not the intent.

Expense systems learned this the hard way, and the whole anatomy of a real approval follows from it. AI agents are about to need every part of that anatomy, because an agent’s first consequential action should sit downstream of an approval worth auditing, and today it mostly sits downstream of a checkbox granted at integration time. This part walks the approval the way the spend world actually runs it. No protocol is required to understand the control.

The request is a proposal, and nothing more

Agents Need a Corporate Card, Not a Blank Check made the first point: the engineer fills out the intake form, and the form approves nothing. Three properties of that form deserve a closer look, because each one is doing security work that is easy to miss.

The form structures the request. “Some conferences, whatever it costs” does not submit. The free-text wish becomes a bounded, reviewable proposal: this event, these dates, this estimate. Structure is what makes review possible at all. You cannot meaningfully approve a vibe.

The form fails closed on ambiguity. Missing cost center? It asks. It does not guess, and it especially does not guess generously. A request system that resolved every ambiguity in the requester’s favor would be an escalation engine wearing a form’s clothing.

The requester never writes her own limit. She describes the trip. Finance derives the controls. The person asking and the function bounding are different parties by design, because a request that specifies its own authority is not a request. It is a demand with paperwork.

Now swap in the agent. The agent’s account of its own task is exactly as trustworthy as the engineer’s account of her own budget needs, which is to say it is a proposal from an interested party. Something has to structure it, refuse to guess generously on its behalf, and derive the bounds from the task rather than accept them from the requester. None of that is exotic. It is intake, and it is not hypothetical either. The modern spend platforms built their whole product on this shape: the request is the approval workflow, and the approval mints the instrument.

Reviewers narrow. They rarely deny.

Watch what real approvers do. The flight is approved but not the business-class fare. The software purchase is approved for one year, not three. The $2,000 request comes back as $500, try again next quarter. Outright denial is rare. Narrowing is the common case, because the reviewer usually agrees with the task and disagrees with the bounds.

A well-built system honors that. The reviewer trims the request and the requester keeps their place in line. A badly built system offers approve-or-deny only, and the requester refiles from scratch for every trim, which trains everyone involved to ask broad and hope. The approval mechanics quietly shape what people request.

The same is true of time. Real reviews are asynchronous. The request sits in a queue for two days while the approver travels, and nothing about that delay should break the request or tempt anyone to bypass the queue. Systems that cannot wait teach people not to ask.

Both lessons transfer whole. An agent’s task proposal will come back narrowed more often than denied, and the round trip will sometimes take days, because the reviewer is a human with a job. If narrowing means restarting, or waiting means failing, the deployment will route around its own approval step within a month. The approval process has to make the safe path the convenient one, which is the entire trick of the corporate card in one sentence.

The disclosure is the control

Here is the part that sounds like a technicality and is actually the foundation. When the manager approved on her phone, what exactly got approved?

Not the requester’s intent. Not the database row. The approval binds the disclosure: the rendering the approver saw, with the amounts, recipients, and terms it contained at that moment. If the line items quietly change after the approval, the approval does not stretch to cover them. It is void, because the thing she assented to no longer exists. Every serious approval system behaves this way, which is why the request as-reviewed gets snapshotted with the decision, and why “what did the approver see” is answerable years later.

Payments did not leave this to good practice. European payment regulation made it law. Under PSD2’s dynamic-linking rules, when your banking app asks you to approve a payment, it must show you the amount and the payee, and the authorization code it produces is cryptographically bound to that exact amount and that exact payee. Change either one and the approval is worthless. The regulation exists because attackers were changing the transaction between the screen and the wire, and the industry’s answer was to make what-you-see-is-what-you-approve a property of the cryptography rather than a hope about the UI.

That is the bar for agents, and it is not a metaphor. When a human approves an agent’s task, the approval must bind the disclosure that was rendered: this task, these systems, these bounds, this expiry. An approval that binds anything less is a receipt for a conversation. And the disclosure must render the derived bounds, not just the friendly summary, because assent to a summary is assent to whoever wrote the summary.

One more habit worth stealing: the spend world records declines. A denied request is not deleted. It is a decision with a record, because the pattern of what gets declined, and who keeps asking, is exactly what an auditor wants to see. Approval systems that only remember yeses cannot explain their noes.

Where the analogy breaks

Three breaks, each one a piece of work the agent stack cannot borrow.

Screens can lie, and agents have more screens. PSD2 could mandate what the payment authorization experience must bind because the regulated payment flow has a narrow job: show the transaction terms and produce a transaction-specific authorization. An agent’s approval can surface in a chat window, a dashboard, an email, a Slack message, each rendered by software with its own bugs and its own trust story. Binding the approval to the disclosure only helps if the disclosure layer itself can be held to account, and that is a build item, not a given. The expense world mostly gets to assume its rendering is honest. The agent world has to prove it, or at least record enough to detect the lie afterward.

Approval fatigue is an annoyance for spend and an attack surface for agents. Rubber-stamping expense requests costs money, and money is mostly compensable, so the expense world tolerates a manager who approves on autopilot. An agent’s actions include the irreversible kind, and any adversary who can generate requests can farm a tired approver. For agents, the fatigue curve is a security boundary. That argues for fewer, better approvals with real bounds, not more prompts, and it is why the approve-every-action model fails at exactly the scale where agents are useful.

The reviewer knows what a conference costs. Decades of trips built priors. A manager can smell a padded estimate, and the delegation matrix encodes the whole company’s sense of what is normal at each level. Nobody has priors for agent tasks yet. What is a “reasonable” scope for an agent that reconciles invoices? Reviewers will be asked to bound tasks they cannot yet sanity-check, which means the early systems must make bounds legible and defaults narrow while the institution learns what normal looks like. The expense world’s matrix took years to tune. The agent world starts at zero.

The build list from this room: a disclosure layer that can be held to account, approvals that survive fatigue, and bounds a reviewer can actually read.

The approval is where safety is cheap

Everything downstream of a bad approval is expensive. Enforcement can only hold the line the approval drew, audit can only replay it, and revocation can only end it. The approval is the one moment where a human with context can still shape what the authority is, which is why the spend world invests its friction there and almost nowhere else.

Approve like it will be read back to you in a deposition, because for agents, it will. If the system cannot replay what the approver saw, it cannot defend what the agent later did.

Crunch week on the renovation project. The contractor needs to buy materials this afternoon, the purchasing process takes two days, and the project manager does the obvious thing. She hands him her card. Just this once.

Everything about it is convenient. No forms, no waiting, the work keeps moving. And everything about it is wrong, in ways every finance team can recite from memory. The statement will say she bought whatever he buys. Her limit, tuned to her role, is now backing his judgment. If the card number leaks from his pocket, her card dies and her month gets complicated. And when the project ends, nothing about that card changes, because the card never knew it was working for the project at all.

The failure is not that the contractor is untrustworthy. He may be excellent. The failure is that the authority arrangement is wrong: borrowed instead of granted, broad instead of narrowed, attributed to the wrong person, and immortal with respect to the work it was supposed to serve.

Delegation narrows, or it contaminates.

AI agents hit this exact fork dozens of times a day, because agents spawn helpers. A research sub-agent, an extraction worker, a reviewer, each needing some slice of authority to do its piece. And the convenient thing is always the same thing the project manager did: hand the helper the credentials already in hand. This part is about why the spend world refuses that convenience, and how.

Borrowing is the default because borrowing is free

Be honest about why the card got lent. The right path had friction and the wrong path had none. The parent’s credential is already there, already works, and requires nobody’s involvement. That asymmetry, not malice, is why borrowed authority is the default failure mode of every delegation system ever built.

A mature card program does not win by lecturing project managers. It wins by making the right thing nearly as cheap as the wrong thing. Issuing a contractor card takes minutes, not days. The moment the sanctioned path costs two days while the unsanctioned path costs nothing, the program has designed its own bypass.

The agent version is sharper, because for agents the borrowed path is not just convenient. It is invisible. A sub-agent spawned inside the parent’s process inherits the parent’s credentials by simple physics, by being in the same memory with the same connections. Nobody decides to lend anything. The lending is the default state of the runtime, and an explicit grant has to be built to exist at all.

What the right version looks like

The contractor gets his own card, and five properties come with it. Each one fixes a specific thing the borrowed card broke.

His own name. The statement now says who actually spent. When a charge looks wrong, the question “who did this” has an answer that does not require interviewing the project manager about her wallet. Attribution is not bureaucracy. It is the difference between an audit and an interrogation.

A lower limit, on the same project code. His card draws against the same approved project budget, but bounded to his slice: materials, say $2,000, this month. The delegation narrowed. In a well-run program it always narrows. The contractor’s card should not be able to do more than the project it serves, because his authority is carved from the project’s, not conjured beside it.

Issued, never copied. His card came from the program, through a request the program saw. He could not manufacture it from the project manager’s card number, and she could not create it by handing over plastic. Every delegation is visible to the issuer at the moment it happens, which is precisely the property the borrowed card destroyed.

It dies with the project. When the project closes, every card on that project code stops working at once, hers, his, all of them. Nobody collects plastic from wallets. Nothing depends on the contractor remembering to stop. The cards were always projections of the project, so ending the project ends them, transitively, wherever they are.

The program caps the count. Here is the subtle one. Twenty contractors with $500 cards is a different risk than one contractor with a $10,000 card, even though the arithmetic looks similar. Breadth is its own exposure: more instruments in the field, more places to leak, more judgment operating in parallel. So the program does not just bound each card. It bounds how many cards a project may have open, and whether a contractor may sponsor cards for his own subcontractors at all. Depth limits do not control breadth. Breadth gets its own limit.

Swap in the agent and the mapping is one-to-one. The sub-agent gets its own explicit grant, narrower than the parent’s, issued through a path the system can see, attributed to the sub-agent itself, dead the moment the parent’s task ends, with the fan-out counted and capped. Spawning a helper is a runtime event. Authorizing one is a governance event. The whole discipline is refusing to let the first stand in for the second.

Where the analogy breaks

Three breaks, and each is a build item the card world never needed.

Cards have one holder. Agents have a thousand copies. A contractor card names a human, and there is exactly one of him. An agent is software. The “contractor” may be forty concurrent instances of the same worker, spun up and torn down in minutes, all legitimately acting under the same delegation. The expense world never had to ask which copy of the contractor was at the register, and its instruments carry no answer. Agent delegation needs identity for instances, not just for roles, or every one of those forty workers is indistinguishable in the record and in the containment.

Every card comes from the issuer. There is no field-expedient way to mint a narrower card from your own card, and for plastic that is fine, because delegation happens at human speed. Agent swarms delegate at machine speed, hundreds of narrow grants per minute, and a round trip to the issuer for each one becomes the bottleneck that tempts everyone back to credential-sharing. The agent world genuinely needs what the card world rarely has to expose: a way to derive narrower authority in the field that still cannot exceed the parent and still dies with it. That is new machinery with sharp edges, and it only works if the narrowing is provable and the kill switch still reaches it.

The contractor’s limit is a number. The agent’s is a shape. A card’s delegation collapses to amount, category, and dates, because money is one-dimensional. An agent helper’s slice is which actions on which systems with which parameters, a shape, not a scalar. “Narrower” is easy to verify for $2,000 against $10,000. It has to be defined before it can be verified for “may read the financials but not notify anyone.” The card world’s subset rule comes free with arithmetic. The agent world has to specify its subset rule, and everything downstream depends on getting it right.

The build list from this room: identity for every copy of the helper, field-speed delegation that provably narrows, and a subset rule for authority that is a shape rather than a number.

The rule that survives the breaks

Strip the plastic away and one rule remains, and it is the whole post. A helper’s authority is granted, narrower, named, and mortal, or it is contagion. The project manager’s card in the contractor’s pocket is the same object as the parent agent’s token in the sub-agent’s memory: authority that arrived by proximity instead of by decision.

The spend world beat this by making the granted path cheap and the borrowed path unnecessary. The agent world has to do the same thing at machine speed, which is harder and less optional, because agents fork faster than any project ever staffed up. The rule is usable today: make the granted path cheaper than borrowing, or borrowing will be the architecture.

A card declines at the register. Mild embarrassment, a tap of a different card, everyone moves on. Nobody calls the police. Nobody even remembers it by lunch.

That boring little moment is the most important design fact in payments. The decline is not a failure of the system. It is the system, doing the one thing it exists to do: deciding this transaction, right now, on current information, and saying no without drama. Payments normalized the no. Declines are so routine that merchants print decline handling into their training and cardholders carry a backup, and the entire arrangement works precisely because saying no is cheap, instant, and unremarkable.

Hold that thought, because agent systems mostly lack it. For most agent deployments today, the only no is at the front door, when credentials are granted. Past the door, a valid token is a yes to everything inside its scope for as long as it lives. This part is about the payments alternative: authorize the transaction, not the card. The rest of the chapter depends on it.

Authorize the action, not the instrument.

One precision up front: strictly, the network routes the request and the issuer decides it. This chapter says “the network” for the decision system the merchant sees, and the argument survives either name, because the point is that the decision never lives in the card.

The plastic proves almost nothing

Start with what the card in your hand actually establishes: very little, and the industry knows it. The number on the front is a routing hint that has leaked too many times to treat as secret. What separates a card-present transaction from fraud is the chip, which computes a fresh cryptographic proof for each transaction, evidence that the physical card is here, now, for this purchase. Card-not-present transactions, where a number alone suffices, are where the fraud lives, and everyone prices them accordingly.

The lesson is not about chips. It is that a mature authorization system never confuses holding the instrument with being entitled to this use of it. Possession is one input. The decision happens elsewhere, per use. Agent systems that treat a presented token as the whole decision are running a card-not-present economy and hoping.

The authorization is specific, or it is nothing

Watch what a single authorization actually contains. Not “this card may spend.” This card, this amount, this merchant, this moment, judged against current state: is the card active, is the limit sufficient, is the category allowed. Change any input and it is a different decision. That specificity is not pedantry. It is what makes the authorization mean something.

The hotel hold makes the point physical. At check-in, the desk authorizes $600, a hold, an authorization bound to an amount. If the minibar raises the bill to $750, the hotel cannot ride the old authorization. It asks again, for the new number. Authorization of an operation was never authorization of whatever parameters the operation later turns out to have. Payments builds that rule into the rails, because the gap between what was approved and what gets executed is exactly where the fraud crawls in.

And the state is current state. Freeze your card in the banking app and the very next swipe declines, at a register on the other side of the planet, seconds later. The instrument in the wallet did not change. The decision consults the source of truth, every time, and so the freeze is real everywhere at once. The newest card programs push even policy into this moment, so the out-of-policy purchase declines at the register instead of surfacing in a month-end report.

Notice what that makes the approval. Not a moment, a standing question that every swipe re-asks. The card that worked at lunch declines at dinner, and the reasons live entirely outside the card: the budget hit zero, the project closed, the employee gave notice, the vendor got blocked. Approval is continuously revalidated against the current state of the business, not the state on the day the card was issued.

The agent translation is direct. A consequential action needs a fresh decision that binds the actual parameters, the who, the what, the how much, checked against the current state of the approved task, not against the fact that a credential exists. And the deployment needs declines to be what they are in payments: a normal, cheap, recorded signal that shapes behavior, not an exception that pages someone. An agent told no should handle it the way a traveler does, with a fallback and a record, not a crash.

The ATM is the honest part

Now the part of the card world that gets left out of the brochure. Walk to an ATM, withdraw $200, and the network’s writ ends at the mouth of the machine. The cash buys whatever it buys. No merchant category, no per-transaction authorization, no decline. The most tightly governed payment instrument on earth has a built-in exit into ungoverned space.

Here is what makes the card world mature rather than naive: it says so, in writing. Cash advances get their own lower limits, their own fees, sometimes an outright block, and serious expense policies name cash because everyone knows the receipts get fuzzy there. The program does not pretend the ATM away. It names the path it cannot see, bounds what can flow through it, and treats receipts from that side with appropriate suspicion.

Every agent deployment has ATMs. The debug shell. The direct database connection. The egress route nobody proxies. The tool that shells out. An agent platform that claims its per-action checks cover “everything” is describing a world with no cash in it, and it is wrong the moment someone looks. The honest posture is the card program’s posture: put the checkpoint on every path you can, name the paths you cannot, bound them separately, and treat what happens there as unverified. A security claim that does not name its ATMs is marketing.

The cardholder can be hypnotized

One more difference hides inside the fraud model, and it is the deepest one. Card fraud assumes the enemy is outside: a thief with a stolen number, a skimmer, a counterfeit. The cardholder is presumed honest, occasionally careless. Nearly every control in payments points outward, and the deterrent, that the statement is coming and the cardholder will dispute what they did not do, points at the thief too.

The agent’s situation is stranger. The agent is the cardholder, and the agent’s judgment can be rewritten mid-purchase by the content it reads. A poisoned document is a shop window that reaches into the shopper. The agent then walks to the register as itself, presents its own legitimate credential, and buys exactly what the attacker wanted, inside its authorized limits if the attacker is careful. No stolen card. No counterfeit. The holder was turned.

This is why the per-transaction check has to carry more weight for agents than the network carries for people, and why the check must bind parameters rather than trust the requester’s framing. There is no deterrent to lean on and no honest-cardholder assumption to fall back to. The nearest human analogy is not card fraud at all. It is the trusted agent under a power of attorney who acts against the principal, which is why the law surrounds attorneys-in-fact with duties, witnesses, and revocation, and why agents need the runtime equivalent.

The network also knows that fraud is rarely one bad swipe. It is many normal ones, which is why cards carry velocity limits and cumulative caps alongside the per-transaction decision. The agent version is the same: per-transaction checks alone cannot stop individually valid steps from composing into an outcome no one approved, so the approval covers the bounded work first, every action is then judged against that boundary, and the Mission’s consumption bounds are the velocity limit’s descendant.

Where the analogy breaks

There is no common network. A card payment that uses the card instrument has to traverse card-acceptance rails, so the issuer’s transaction-time decision can reach the accepting edge by design. Agent actions cross APIs, tenants, and tools that share no common fabric, so per-action authorization is not a subscription you turn on. It is a checkpoint you place, boundary by boundary, and your coverage is exactly the set of boundaries you actually placed it on. The ATM paragraph is not optional garnish for agents. It is most of the document.

The risk math is different. The network tolerates false approvals, prices fraud as a percentage, and claws money back later, because money comes back. Agent actions include the kind that do not: the sent message, the deleted record, the signed commitment. A system tuned to payments-style risk, approve fast and reconcile later, is tuned wrong for irreversible verbs. For those, the check must be strict before the act, because there is no later.

Milliseconds hide the cost. Payments authorizes in tens of milliseconds because decades and billions went into exactly that problem, for one transaction shape. Per-action checks for agents span wildly different actions and will not be free on day one. The temptation will be to skip the check where latency hurts, and the card world’s answer applies: the check runs at the moments that matter, sized to the consequence, and where it truly cannot run, that path gets named with the ATMs.

The build list from this room: a checkpoint at every boundary you claim, a named list of the boundaries you do not, and checks sized to consequence rather than latency.

The sentence that survives

Possession of the card was never the control. The decision at the moment of use was, is, and will be, and everything else in the arrangement, the limits, the freeze, the statement, only becomes real at that moment. Agents need that moment built for them, in a world with no network, no honest cardholder, and more than one ATM. The register is open now, and every consequential action is a swipe.

You cancel a card. The issuer confirms. The plastic is dead.

Next month the gym bills you anyway, on the replacement card’s number, which you never gave it. Nothing malfunctioned. The network’s account updater service forwarded your new number to merchants that bill you on file, because continuity of billing is a feature that took real engineering, and it worked perfectly. You ended the instrument. The arrangement sailed on, because no part of the system recorded that the arrangement itself was supposed to end.

Ending the credential is not ending the arrangement.

Notice the causality in a governed program. The reason ends first, and the credential dies because the reason did: the trip is cancelled, so the card freezes. In most agent systems the causality is missing entirely. The reason ends and nothing notices, because nothing recorded that the credential existed for a reason at all.

Every hard truth about ending delegated authority is in that gym charge. Credentials are easy to kill. The work they were feeding is not, because the work has its own momentum: standing arrangements, charges in flight, helpers mid-task, and systems that were built, carefully and correctly, to keep things running. Payments has spent decades building machinery for endings anyway. This part walks that machinery, because AI agents need every piece of it, and mostly have none.

Endings come in kinds

The card world refuses to treat “make it stop” as one operation, and the distinctions all carry.

The freeze is a pause. Something looks wrong, so you freeze the card from the app. Every authorization declines, instantly, but nothing is torn down. Unfreeze and life resumes. The freeze exists because the most common emergency is uncertainty, and uncertainty needs a reversible answer. A system whose only stop is destruction teaches its operators to hesitate.

The cancellation is terminal. The card is dead, forever, and everything that depended on it must be re-established deliberately or not at all.

The expiry is a clock. Cards die on schedule whether or not anyone remembers them, the backstop for every arrangement that outlived its attention.

And completion is the ending standing cards do badly. The trip ends, the project closes, and the card simply continues, still valid, still standing authority, until an expiry or an audit catches it. Standing instruments that outlive their purpose are the expense world’s chronic disease, and its cure is the single-use virtual card: an instrument bound to one purchase that retires itself the moment the purchase completes. The authority ends because the work did, with no one lifting a finger. The modern spend programs have already made that the default, and it is the right default for agents too: authority that expires with the task, not with the calendar.

One more rule hides in the limit increase. When you genuinely need more, an issuer can raise your limit in place, and a well-run corporate program deliberately resists making that the default. It issues a new instrument for the new need, freshly approved and freshly scoped, because an instrument whose bounds drift upward in place slowly stops meaning anything. What was approved should stay what is in force, and growth should have a paper trail of its own.

Authorized is not settled

Cancel a card mid-month and look closely at the statement. Some charges are finished. Some are pending, authorized days ago, settling now. One is a hotel hold that will simply evaporate. The card world runs on the distinction between a transaction that was approved and a transaction that actually happened, and every ending has to reckon with the space between them.

That space is a taxonomy, and it transfers whole. When the task stops, its work in flight is in one of four states. Not yet submitted, so kill it. Authorized but not executed, so release it. Executed, so it is real and no cancellation reaches it. And the ugly one: unknown, submitted somewhere and unconfirmed, which honest systems route to a human instead of guessing. Payments never pretends an in-flight charge is simply gone because the card died. Agent systems that treat task termination as a boolean are pretending exactly that, and the pretending shows up later, in the audit.

And un-spending is governed. When a charge must actually come back, you do not reach into the merchant’s account and take it. You dispute it: a process with evidence requirements, deadlines, categories, and an adjudicator. The undo is itself a controlled operation, because an undo is money moving, and money moving is exactly the thing the whole system governs. The agent parallel is sharp. Compensating a half-finished task, the reversing entry, the retraction email, the rollback, is itself consequential work, and a terminated task must not become a back door for ungoverned “cleanup.” If the undo is not governed, the attacker’s easiest move is to get something canceled.

The statement joins everything

At the end of the month one document reconciles the whole story. The statement pulls every authorization, settlement, credit, and dispute, and on a corporate program every line carries the project code, so an auditor pulls one thread and the entire arrangement unspools: the request, the approval, the cards issued, every transaction each one made, the freeze, the disputes, the final balance.

Notice what makes that possible. It is not diligence. It is that every event, from the first approval to the last chargeback, was stamped with the same identifier at the moment it happened. Nobody reconstructs the trip from timestamps and vibes. The join key was built in. Agent systems that plan to assemble the story later, from logs scattered across every system the agent touched, are planning an archaeology project. The statement works because the story was joined as it was written.

Where the analogy breaks

The big one runs backward. Everywhere else in this chapter, the card world is ahead and agents need to catch up. Here the analogy inverts. Card freezes work quickly because online card authorizations consult issuer-controlled state, one state change, checked at the accepting edge. Agent credentials are built to work offline, verified locally, on purpose, for speed, which means there is no equivalent switch. Ending an agent task means building the machinery the card world got for free: a place where the task’s state lives, and either consumers that actually check it, fast enough to matter, or credentials short-lived enough that stopping their issuance ends them in time. Anyone who assumes revocation just works, the way a card freeze just works, has imported the analogy’s easiest property into the one place it does not apply.

Even the network leaks on purpose. The gym charge was not a bug. Account updating and merchant-initiated billing are continuity features, built because most cancellations are card replacements, not relationship endings, and continuity is usually what the customer wants. The lesson generalizes: every mature system grows features whose whole job is to keep things running, and those features cannot tell a routine ending from a revocation unless something records the difference. The agent version is the harness that helpfully resumes a suspended workflow, the retry queue, the cached connection, each one a little account updater, faithfully continuing an arrangement whose reason is gone. Continuity machinery must be taught to check whether the arrangement still stands, or it will defeat every ending you build.

You trust the issuer’s statement. The whole reconciliation story rests on one institution’s ledger, and you accept it because the issuer and card program sit inside a regulated, audited operating model. Agent tasks cross companies and clouds that share no such institution. There is no issuer whose statement everyone accepts, which means the agent world’s statement has to earn trust structurally, evidence that can be verified rather than vouched for. That is a genuinely new build, with no expense-world part number.

The build list from this room: an ending someone can check, continuity machinery that checks it, and a record that earns trust without a bank behind it.

The loop, closed

One loop, five posts. The card bound the instrument to an approved purpose. The approval bound what was shown. The contractor’s card narrowed authority without borrowing it. The issuer made every use a fresh decision. And the ending, the hardest part, turned out to be a system of its own: pauses, terminations, self-retiring instruments, in-flight states, governed undo, and a statement that joins the whole story to one code.

None of it is exotic. It is what a competent finance organization does by default, for money, because the alternative is negligence with a paper trail. Agents exercise authority that is broader than money, faster than any traveler, and easier to fool than any cardholder. The failure mode is not autonomy. It is the blank check. The bar the expense world sets is the floor.

The protocol work is the translation. The loop itself needs no standard. You can start running it today.

What the Corporate Card Already Solved makes one claim across five posts: enterprise finance independently discovered the governance architecture that agent authorization now requires, and proved it at global scale. An instrument issued for an approved purpose, an approval bound to what the approver was shown, delegation that only narrows, a network that authorizes every transaction, and endings that actually end. Every post in that chapter closes the same way, with the places the analogy breaks and the build list those breaks imply.

This chapter is the build. The card chapter deliberately never says what the protocol work looks like, because the loop needs no standard to be understood or even operated. But the translation into standards terms is real work with real choices, and this part is the joint between the two: what each card rule becomes when it is stated for any kind of authority, what the mapping table becomes when it is made into an object, and which drafts answer which break. If you read the card chapter first, this part will feel like recognition. If you did not, it works as a fast tour of the whole model, and the card chapter is waiting when you want the protocol-free version.

The five rules become five laws

The card chapter distills each post into one rule, stated in the card’s language. This chapter states the same invariants for any substrate and calls them the five laws of delegated authority, because they hold whether the authority is money, API calls, or signatures, and whether the substrate is OAuth or something else. The mapping is close but not decorative, and the two places it bends are worth the look.

Rule 1 is Durability seen from the wallet. The card post argues that the plastic is replaceable and the governance record is the asset. The law states the consequence: the approved task is the durable object, tokens are its short-lived projections, and governing the projection is not governing the task.

Rule 2 is Attribution’s second clause. You Approve What You Were Shown binds the approval to the rendered disclosure, and the architecture writes that into Attribution itself: the approval record commits exactly what the approver was shown, because an approval nobody can replay makes attribution collapse into archaeology. The same clause is the precondition for Containment, because “inside approved purpose” only means something if what was approved is committed precisely. The approval that binds the disclosure is what gives enforcement a boundary worth holding.

Rule 3 and its law match exactly. The Contractor Gets Their Own Card is Narrowing with a renovation project attached: every derivation is a subset of what was approved, and widening is a fresh approval, never an inference.

Rules 4 and 5 swap numbers, and the swap is the reading order. The card chapter teaches enforcement before endings because that is how you meet the system at the register. The laws number revocation before continuous execution because that is the dependency order: ending the arrangement (Termination) is what the per-action check (Containment) consults. The network post’s freeze that declines the next swipe is both laws operating in one moment: revocation ended the authority, and the transaction-time check is how the ending became real at the edge.

The mapping table becomes an object

The card chapter compresses its whole translation into one table, trip to approved mission, intake form to structured request, card network to per-action enforcement. Read that table again and notice what every row on the agent side has in common. Each one is a projection of, or a consultation of, a single record that agent infrastructure does not have: the approved task itself.

That record is the Mission, and making it first-class is the whole architectural move. The trip becomes the Mission record, with an identifier, an issuer, and integrity anchors committing the approved task and the authority derived from it. The intake form becomes Intent shaping. Finance deriving the controls becomes authority derivation, producing the Authority Set the approval commits. The card becomes the Mission-bound token, a bounded projection that carries the Mission’s identity. The network becomes the enforcement checkpoint asking, per action, whether this call with these parameters is still inside the approved task. The freeze becomes revocation of the Mission with an observable state surface. The project code becomes the mission_id joining every decision and event. The Mission Is the Missing Abstraction makes this argument in full, and the Reference’s object model is the precise form with a concrete record.

To make it concrete, run the card chapter’s own scenario through the object once. The engineer’s conference trip becomes a Mission record: the intake form’s output is the Mission Intent, finance’s derived controls (the $3,400 limit, the travel and lodging categories, the November 29 through December 5 window) are the Authority Set, the manager’s sign-off is the approval event that commits both under integrity anchors, the card in her wallet is a Mission-bound token carrying the record’s identity, and the project code on every transaction is the mission_id on every decision. The protocol side of this handbook runs the same loop on its own scenario, Alice’s Q3 board packet, told next.

Alice’s night

On the afternoon of September 30, Alice approves an agent to prepare the Q3 board packet for the audit committee. The approval creates a Mission that permits three things: reading the Q3 financials, creating the packet from the board-packet template, and notifying the audit committee. Every token the agent receives is derived from that Mission and lives five minutes. By 18:05 a review draft is ready, the agent notifies the audit committee, and a final pass on the packet waits in its queue for the overnight run.

At 23:00 the board meeting is cancelled. Nothing in the stack notices. A person does, and an administrator revokes the Mission with one call against its identifier, touching no token. At 02:00 the agent’s runtime wakes to run the final pass.

In the handbook’s exhibits that pass would only redraft a packet nobody will read. The harm is clearer in a counterfactual, labeled as one: suppose the approved work had also included sending the finished packet to the full board. At 02:00 the agent would then circulate unreleased Q3 financials for a meeting that no longer exists, with valid credentials, under a task nobody wants. What stops that send depends on the bundle the deployment runs, and each bundle includes the ones before it (the adoption sheet has the full columns):

Chapter 3 runs the same night at wire depth, and the wire appendix shows the bytes, from the approval to the Status response that stops the 02:00 run.

The Corporate-Card test becomes the claim gate

The card chapter ends with a diagnostic: the corporate-card test, the questions to ask any agent platform, with the standard that answers unacceptable for a card program are unacceptable for an agent. This chapter carries the same diagnostic in architecture form, the claim gate, the handbook’s own bar for the category, split four and two: a system is mission-based when it has an approved task object, authority derived from that task, narrow-only delegation as work fans out, and observable lifecycle state, and it may claim action-time defense only when per-action runtime enforcement and evidence that joins on the Mission’s identity hold as well.

Line them up and the correspondence is one-to-one. “What approved purpose is this authority projected from” is the approved task object and the derivation. “What exact disclosure did the approver see” is the integrity anchors and approval evidence. “Can delegated authority only narrow” is the subset rule. “What authorizes each consequential action at the moment of use” is runtime enforcement. “What actually stops when the work ends” is lifecycle state and the bindings that consult it. The Reference’s litmus test expands each property and names what fails it, and the what-not-to-claim list is the same discipline pointed at this proposal itself.

The build lists name the draft family

Here is the part that makes the card chapter more than a teaching device. Each card post closes with a build list, the work the agent stack cannot borrow because the expense world never needed it. Collect those lists and they enumerate the draft family, cluster by cluster.

“A disclosure layer that can be held to account, approvals that survive fatigue, and bounds a reviewer can actually read” (from the approval post) is the approval-integrity cluster: Mission Intent Shaping structures the proposal, Mission Consent Evidence makes the rendered disclosure replayable, and the issuance profile’s rendering of derived bounds is what gives the reviewer something legible to narrow. From a Request to an Approved Mission carries the cluster.

“Identity for every copy of the helper, field-speed delegation that provably narrows, and a subset rule for authority that is a shape rather than a number” (from the contractor post) is the delegation cluster: Client Instance Identification and Client Attester Endorsement for instance identity, the issuance profile’s narrow-only subset rule defined over typed Authority Set entries, Mission Child Delegation for separately revocable helpers, and Mission Offline Attenuation as the experimental answer to fan-out at machine speed. Mission-Bound Authority carries the cluster.

“A checkpoint at every boundary you claim, a named list of the boundaries you do not, and checks sized to consequence rather than latency” (from the network post) is the enforcement cluster: Mission-Bound Runtime Enforcement with its AuthZEN profile, action classification for consequence-sized checks, and the enforcement-scope statement that names the ATMs in writing. Mission-Bound Runtime Enforcement carries the cluster, and the per-action safety claims rest on it.

“An ending someone can check, continuity machinery that checks it, and a record that earns trust without a bank behind it” (from the endings post) is the lifecycle and runtime cluster: Mission Status as the checkable ending, with Lifecycle Signals as its push complement, the Mission Status List for consumers that rely on many Missions at once, and Mission Entry Discharge for ending one entry’s work while the Mission stays active; the harness profile teaching the continuity machinery to check before it resumes; and Mission Audit Transparency earning trust structurally, through verifiable evidence rather than an issuer’s ledger. Mission Lifecycle and Change and The Agent Runtime and Audit carry the cluster.

And the whole-loop build list from the card post itself, a first-class approved purpose, bounded projections, checks at the moment of use, delegation tied to the task, endings that reach everywhere the authority went, is not a cluster. It is the issuance profile plus the shape of the family around it: the card chapter’s build lists map onto this family’s table of contents because the family was designed to supply the same controls.

What the analogy could not say

The card chapter names where it breaks, and the breaks became build items above. But a few of the architecture’s commitments have no card-world articulation at all, and they are worth naming so the translation is not oversold.

• The integrity anchors. No card program cryptographically commits the approved trip. The Mission’s intent_hash and authority_hash bind the approved task and the authority derived from it, proposal_hash binds any authority the client proposed, and Consent Evidence commits what the approver was shown, so that “what did the approver see” has an answer that survives a hostile audit rather than a cooperative one.
• The missing network is a design input, not a footnote. The card world’s transaction-time decision rides rails that already reach every merchant. The architecture has to state where checkpoints live, what a deployment’s enforcement scope is, and how state stays fresh without any common fabric, which is why Status, the freshness rules, and the enforcement-scope statement are normative surfaces rather than operational advice.
• Cross-domain projection. A card works at any merchant because the network is global. One Mission honored in another trust domain requires machinery the card world never had to invent, and it gets its own draft rather than a hand wave.
• The substrate-neutral framework. The card story is one world. The architecture separates the laws from their OAuth realization on purpose, so the model survives the substrate argument, and What Survives Without OAuth carries that split.

Where this leaves you

The card chapter’s closing sentence was a promise: the protocol work is the translation, stated in standards terms. This part is the map of that translation, and the rest of this chapter walks it. The Mission Is the Missing Abstraction defines the object. Adopting Mission-Bound Authorization stages the build, crawl, walk, run. Weighing Mission-Bound Authorization, the concluding chapter, states the model beyond OAuth. And when you are ready for wire-level depth, the Building Mission-Bound Authorization chapter carries each control at implementation depth, one card room at a time.

The industry’s best-practices path for AI agent identity is taking shape. AI Identity Management System (AIMS), now a WIMSE working-group document, composes WIMSE, OAuth, and SPIFFE into a way to provision, credential, and authenticate agents and to delegate user authority to them. And it names the thing all of that identity exists to serve. Its Agent Mission section (Section 10.1 of -00) defines the Mission as “the task or objective the Agent will pursue,” and then draws a line: “The process through which the mission is translated into authorization requirements is out of scope of this specification.”

This part is about what lives on the other side of that line. OAuth represents credential issuance and delegation. It does not represent the durable task those credentials serve. The stack can prove who is acting and what credential they hold. It cannot prove the work is still authorized. Agents need authority that remains bound to a user-approved purpose as work spans tokens, calls, tools, sub-agents, and time. This part argues that the missing object is a Mission: a durable, approval-backed governance object on the OAuth substrate, and the anchor for every other claim the handbook makes. The Mission is not a new way to express authority. Rich Authorization Requests already do that. It is the approved task that authority is derived for, bound to, and gated on.

Mission-based authorization governs the approved task, not just the credential, session, or individual request.

This is more than a category. It is a claim about the shape of the stack. Identity, authentication, authorization, policy, and transport are named layers, and none of them governs delegated authority as an object of its own: what was approved, by whom, within what bounds, until when, and whether it is still in force. Read operationally, the missing layer is a control plane: the Mission record is desired state, issuance and the runtime gate are the data plane consulting it, and the concluding chapter develops that reading in full. The drafts decompose the layer into five deployable packages (Mission Control, Authority Distribution, Runtime Enforcement, Agent Execution Governance, and Evidence and Accountability), so the missing layer is a small set of named components rather than a monolith.

And the layer’s value is context before it is control. A resource that does not itself run the undertaking evaluates each request at perfect local resolution and zero task resolution: it can read the call and never the reason. The Mission carries task-grain context in one form that every independently built component on the path can consult, and that context cuts both ways. It makes an alarming-looking action priceable, a database deletion that is step four of an approved migration whose copy steps already ran, and it makes an innocent-looking one conspicuous, a payroll task’s agent reading the M&A folder. Neither judgment is possible at such a resource, because the why never arrives there.

The largest claim this chapter makes is that delegated authority management is a layer with no standard form, missing not from every estate but from the interoperable stack, with its own laws and vocabulary, and the Mission is one proposed standard form of it. A system qualifies as mission-based with four category properties: an approved task object (not a prompt, trace ID, session, or token), authority derived from that task, narrow-only delegation, and observable lifecycle state (expiry, revocation, completion, and expansion through a successor). It backs an action-time defense claim only with two more: runtime enforcement against current state, and evidence that binds back to the task. The Reference is the citable version of that test. This part makes the case for the object the test is about.

Three layers, one gap

An agent deployment has to answer three different questions, and only two of them have best-practices answers today.

How does the agent authenticate? That is draft-ietf-wimse-aims territory: workload identity, credentials, transport and application authentication, and the OAuth machinery for acting on a user’s behalf.

Which instance is acting, for whom? A platform’s client_id collapses every concurrent agent session into one identity, which defeats per-agent policy, audit attribution, and containment. The Actor Profile makes the delegation chain explicit, Client Instance Identification carries the specific instance’s identifier in its attestation-based client authentication, and Client Attester Endorsement lets the client endorse the attesters that vouch for its instances. Instance evidence identifies no actor by itself, and attributing a token’s use to one instance needs a key unique to that instance.

What may this instance do, why, for how long, on whose approval? That is the Mission, and it is the layer the Agent Mission section leaves open. The first two layers are necessary and not sufficient. A perfectly authenticated, perfectly attributed agent instance holding valid credentials can still be working on a task that no longer exists, with no layer positioned to notice.

Identity says who. Credentials say what may be accessed. The Mission says what the work is, who approved it, and when it ends.

How the argument converged

Several earlier lines of work expose the same structural gap from different directions:

You Don’t Give Agents Credentials, You Grant Them Power of Attorney. Enterprise IAM governs who an agent is and what each call may do. It does not govern whether the mission behind those calls should still be running. Tokens stay valid past the moment approval expired. Policies still pass after intent has changed. Credentials remain secure while the work they authorize has become unauthorized. The breach is structurally invisible because no layer of the stack was built to ask the question. Agents need delegated authority that behaves like a Power of Attorney, not a credential.

Mission Shaping. A user approves an objective, not the authority needed to execute it. Something has to turn that approval into something a control plane can evaluate. In most deployments today that shaping step is implicit, local, or delegated to the agent itself. The model infers its own boundaries and the system trusts it. That is not governance. It is optimism.

Open-World OAuth. OAuth succeeded because its closed-world relationships were known ahead of time. The client knew the AS, the RS knew its issuers, scopes were configured before deployment. Agents push OAuth into an open-world model where tools, Resource Servers, and ASes are discovered at runtime and may not share prior trust. The substrate problem covers protocol mechanics like discovery, resource binding, sender constraints, and metadata integrity. The governance problem is deciding whether newly requested authority is still inside the task the user approved. Fixing the substrate does not fix the governance.

Sessions Are Not Missions. Modern agent harnesses make work durable across restarts, devices, sub-agents, and reconnected tools. That durability is a runtime property, not a governance property. A session can prove the runtime survived. It cannot prove the mission did. The harness that runs the agent is not the layer that owns the mission.

Authorization Is the Other Half of Executable Intent. Evals showed the pattern: take intent expressed in language and compile it into an artifact a machine can execute. That made intent executable for verification, answering whether the agent behaved. Authorization needs the same move at a higher bar, because a grant confers authority rather than evidence, and a grant that is right most of the time is a breach the rest of the time. The compiled artifact on the authorization side needs an approval path, a default that denies, and a lifecycle that ends.

AI Identity Management System. The best-practices convergence itself points here. It gives agents workload identity, credentials, and delegated user authority, then defines the Mission as the task the agent pursues and places the translation of that mission into authorization requirements out of scope. The gap is now named in the document the industry is converging on, a WIMSE working-group draft.

An earlier working series, Mission-Bound OAuth, sketched the durable governance object these lines of work point at. This chapter is the concrete answer. Mission-Bound Authorization makes the task explicit. The Authorization Server holds the Mission, commits its maximum approved authority, and governs its lifecycle. Every derived credential and decision carries a reference to it, and audit joins activity across hops on it.

The Mission as the common object

The Mission lets OAuth token issuance, runtime enforcement, delegation, and audit refer to the same approved task.

• Issuance projects the Mission into every derived token through the mission claim, carrying id and issuer (and optionally the Mission’s expires_at); the integrity anchors stay on the record. A Resource Server relies on the signed token as the AS’s assertion that the carried authority is a subset of the approved set, unless it adopts Approved-Set Verification to check against the complete set. Token issuance is gated on Mission state.
• Runtime enforcement evaluates each consequential action against the current Mission before it happens, and writes decision evidence bound to the Mission.
• Delegation is carried by the RFC 8693 act chain. A delegated token keeps the same mission claim with subset authority and an act chain identifying each actor, so revoking the Mission stops all further derivation for every actor in the chain at once. Already-issued tokens age out within their short lifetimes, or die faster where introspection or runtime checks consult Mission state.
• Lifecycle surfaces let an authorized party revoke the Mission (with suspend, resume, and complete supplied by the Status companion), and let a consumer learn its current state.
• Audit keys on the Mission and its integrity anchors (intent_hash, authority_hash, and proposal_hash where the client proposed authority), making the records tamper-evident and independently verifiable.

Without a Mission, each system carries its own implicit notion of the task. Logs join by approximate timestamps, and stopping the work means finding every credential and execution surface independently. With a Mission, each layer consumes an authenticated projection of one governance record, and revoking or expiring the Mission stops all further derivation of authority for the task at once.

What a Mission contains, and what is not one

Concretely, an approved Mission holds the approved Mission Intent (goal, target resources, purpose, human-readable task bounds, expiry), the Authority Set derived from it, its integrity anchors (intent_hash, authority_hash, and proposal_hash when the client proposed authority), a lifecycle state, and its identity (id, issuer). The Authority Set is one component of the Mission, not the whole. A bundle of permitted actions with no approved task, lifecycle, or evidence is just authority, which OAuth’s authorization_details already gave us without any of this.

That is also the fastest way to see what is not a Mission:

• A token is a short-lived projection. Its jti names the token, not the task.
• A scope or authorization detail expresses authority, not the approved task or its lifecycle.
• A session preserves runtime continuity but commits no authority.
• A consent record proves an approval happened but does not govern the work over time.
• An authorization grant, the consent behind a refresh token, comes close. With Grant Management it is durable, queryable, and revocable, but it records consent to authority, carries no task, no integrity commitment, and no derivation gating. What OAuth does not standardize is an approved-task object whose meaning persists across tokens, actors, audiences, and evidence, which is the Mission, and a deployment can still expose Mission revocation through a grant-management-style API.
• An open-banking consent, such as a UK Open Banking consent resource or an Australian Consumer Data Right arrangement, comes closest: an approved intent with its own identifier and status, bound to tokens and revocable apart from them. It lives at one data holder, with a schema its domain fixes, and governs access to that holder’s resources rather than work that spans resource servers, delegates, and runtime checks.
• A purpose URI labels a task class, with no instance lifecycle.
• A trace or task ID correlates activity but carries no approval or authority.
• A Mandate is a portable, verifiable statement about a Mission, minted by its issuer. Evidence, not a second object, and not a competing primitive.

Each is something the Mission binds to or projects into. None of them is the approved task. The full object model, a concrete JSON record, the six-property litmus, and what anchors a Mission’s legitimacy when no user is present at approval time are in the Reference’s object model.

What it buys one estate

A careful estate can compose much of this inside one administrative domain: policy engines, workflow state, and richer token claims can hold durable task state, join fan-out, narrow authority, and keep audit locally, as the composition bet concedes, and the Architecture claims standardization across bindings and trust domains, not that local systems cannot reach equivalent outcomes. The argument for one estate is this handbook’s. Even one estate crosses product boundaries. The Authorization Server, the API gateway, the MCP servers, the agent platform’s harness, and the audit store usually come from different vendors, and composition holds the task in one of them or in glue code that every other product has to be integrated to. A standard object lets each product consume the same record instead:

This is the composition bet stated for one estate, and it is what a single-domain pilot can test: whether one record, consumed by several products, costs less than the integrations it replaces.

Three objects, three lifecycles

The list above rules out artifacts inside the authorization machinery. Two more objects live outside it, in the deployment’s own systems, and an estate that runs agents under an agent identity system and this layer governs three distinct objects. Each answers a different question, each has its own owner, lifecycle, and revocation, and the model stays clean only while none absorbs another’s job.

Agent identity is the logical agent and, where client instance identification is deployed, the concrete instance. The Mission system consumes it, in the OAuth binding, as the client_id, the client-instance attestation, and validated Instance Context, and defines none of it. Defining agent identity, or the registry that holds it, is an explicit non-goal of this family.

Agent Deployment is the approved behavioral version of the agent: its code, model, system prompt, tool allowlist, data scope, and runtime configuration. A change to any of these is a new Agent Deployment, and which changes require re-approving standing Missions is policy that change governance records (the lifecycle part takes this up). The boundary composes rather than duplicates: the Agent Deployment’s tool allowlist is version-scoped, while the allowed_tools Common Constraint of the Resource Access Profile bounds tools per Mission entry, task-scoped. The name is deliberate. This object is distinct from the Mission Deployment Profile, which is the estate’s published claims manifest, not a property of an agent.

The Mission is this layer’s object: the approved task, its Authority Set, and its lifecycle.

The temptation the separation resists is overloading. A purpose field on the agent’s identity record describes what the agent is for, in general and indefinitely, which is exactly the shape of standing authority this handbook exists to retire. The Mission carries why this authority exists now, for this task, until this work ends. Keep the who durable and the why bounded.

Authorization then composes conjunctively across the three lifecycles. A decision can depend on agent state, Mission state, and credential validity, and each gates independently: a valid credential never overrides a revoked agent or a non-active Mission, and a live agent under an active Mission still fails on an expired credential. The Reference carries the working integration, what the Mission system consumes from an agent registry and the combined stack the two control planes form, and the architecture draft’s Agent Identity, Agent Deployment, and Mission section is the informative statement.

Mission, Intent, Plan, Execution

Four related concepts appear around a user-approved task. Keeping them separate prevents the Mission from becoming a vague name for every artifact in the system.

A Mission can outlive multiple plans and execution attempts. Plans and execution draw from its authority and can only narrow it. Re-planning is therefore free: the agent can observe, re-plan, and retry inside the bounds without any authorization event, because plans grant nothing, and a plan that discovers it needs authority the Mission lacks engages the discovery loop rather than editing the Mission. The Intent can be edited or refused before approval. The Plan describes how the agent intends to act but commits nothing. Execution events reference the Mission. Revoking it stops future derivation and, where state is checked, future execution. It does not undo completed actions.

This separation prevents three mistakes: treating the Mission Intent as already approved, treating an agent plan as authority, and treating an executed call as the governance object itself.

Mission versus Intent

The Mission and Mission Intent are not the same object, and conflating them is the most common mistake about this work.

Mission Intent is the proposal. Mission is the approval. The integrity anchors commit the moment of transition.

The transition is one explicit moment, the approval event. The Authorization Server validates the Intent, derives an Authority Set, the user consents to the rendered Intent and derived Authority Set, and the AS records a Mission committed by intent_hash and authority_hash (and by proposal_hash, where the client proposed authority). Before it, only Intent exists. After it, only the Mission is authoritative.

Four consequences matter most:

• Trust. Mission Intent is untrusted input. The client, the shaper, the model behind it, and the raw prompt are all the untrusted plane. The AS’s admission decision is the trust boundary.
• Authority. Intent describes a task. It does not commit authority. Authority is committed only by authority_hash over the Authority Set the AS derives from the Intent. Submitting a broad Intent asks the AS to derive from a broad task. It is not a demand for broad authority.
• Integrity. intent_hash commits the approved Intent, recorded verbatim as the client submitted it and the user approved it (not the raw prompt). The Intent itself is never edited behind the user’s back. An unrecognized target_resources entry is, by deployment policy, either omitted from the derived Authority Set or refused with access_denied; the granted authorization_details in the token response is the authoritative statement of what was granted, and a client that proposed authority compares it against its proposal, which proposal_hash commits. Validation-time narrowing applies to the derived Authority Set (committed by authority_hash). It does not rewrite the Intent.
• Lifecycle. A Mission has exactly one approved Intent for its whole life. Widening means a successor Mission (Mission Lifecycle and Change), not a second Intent.

The full treatment (the approval-event diagram, the remaining consequences, and the precise definitions) is in From a Request to an Approved Mission and the Reference.

Why this makes IBAC practical

Intent-Based Access Control is hard when intent is inferred from agent behavior at enforcement time. A policy decision point (PDP) reconstructing “what did the user want” from a prompt or a trajectory is doing probabilistic interpretation against adversarial input. It becomes practical when enforcement consumes approved intent instead of reconstructing it. The AS checks a structured proposal, the user approves it, and intent_hash and authority_hash commit the result.

The interpretation problem moves to consent time, where the accountable approver is present and the Authorization Server owns admission, instead of to enforcement time, where the agent is adversarial-input territory and the PDP has no approver to ask.

That is the design move that makes IBAC ship.

The intent-to-enforcement spine

The handbook follows one temporal spine, Intent → Mission → Authority → Enforcement:

1. Intent. A prompt or trigger is shaped into a structured Mission Intent. The shaper proposes, it does not grant authority (From a Request to an Approved Mission).
2. Mission. The Authorization Server validates the Intent, derives the Authority Set, and renders that derived set for consent. On approval it records a Mission committed by intent_hash and authority_hash (this part, and the issuance profile).
3. Authority. The approval fixes the Approved Authority Set. Containment and entry discharge only subtract from it, producing the Effective Authority Set, and tokens derived from that set under the subset rule each carry the mission claim (Mission-Bound Authority).
4. Enforcement. A PDP checks each consequential action against the current Mission state and Effective Authority Set and writes per-decision evidence (Mission-Bound Runtime Enforcement).

Each part specifies one or two steps. The spine explains when each concern enters the system. Its object-level companion is the Reference’s canonical sequence, Mission Intent to Authority Set to Mission to Projection to Runtime Decision to Evidence, which names what each transition produces.

Governance and runtime are two halves

Mission governance makes authority auditable, bounded, and revocable. Runtime enforcement is what prevents an active Mission from becoming ambient authority.

The Mission says what was approved, by whom, for how long, and within what bounds. Runtime enforcement decides whether this concrete action, with these parameters, by this actor, at this time, is allowed under those bounds. For parameter-bound writes, bounds finer than the receiving Resource Server enforces, and external side effects, the runtime layer does the safety-critical work.

This is also the lethal-trifecta boundary. The governance object is common, but private-data reads, untrusted-content ingestion, and external side effects stay separately typed and separately evaluated under it, so the Mission never becomes one ambient bundle. The architecture chapter develops both halves.

The Mission Assurance Levels name how much of this a deployment runs. They are adoption bundles, taken in the order deployments build them, and Adopting sets them side by side. In adoption order they are Baseline Issuance, Runtime-Enforced, Governed Agent, and High-Assurance Agent.

The Reference’s implementation checklist turns each bundle into checkable assurance claims, and a relying party compares the claims a deployment can show, not its level.

Where the details live

The affirmative definition of the primitive and the precise, citable definitions live in the Reference:

• The primitive, defined. The canonical decomposition is the Reference’s object model (this part’s “what a Mission contains” is the abbreviated view of it), along with what becomes possible only with a Mission, the trust boundaries and roles, and the defense of the name.
• The citable tests and structures. The Reference carries the six-property litmus and near-miss table, the object model with a concrete record, the lifecycle states, the competitive landscape, the adoption bundles, the glossary, and a reproducible integrity-hash test vector.

Where this leads

The architecture chapter continues with Adopting Mission-Bound Authorization, the staged build order in adoption bundles: the issuance-only floor on the OAuth binding and published RFCs, the Runtime-Enforced bundle above it, and a roadmap of Evaluate-only profiles, held for evaluation until deployments teach us what to harden next. The concluding chapter, Weighing Mission-Bound Authorization, carries the model beyond its bindings and the wagers. From there, the Building Mission-Bound Authorization chapter reads the Mission-Bound Authorization drafts as one layered architecture:

• Part 1: From a request to an approved Mission. Approval-time integrity: turning a prompt into a candidate Intent (shaping), committing the structured consent disclosure the Authorization Server recorded as rendered (consent evidence), and handling async or narrowed approvals (deferred approval and its revision companion).
• Part 2: Mission-bound authority. The bridge from agent identity to Mission authority: the mission claim on tokens bound to attested agent instances, the actor chain, and delegation that only narrows, from act chains to Child Missions to offline attenuation.
• Part 3: Runtime enforcement. The per-action safety layer and the heart of the Runtime-Enforced bundle. Before each consequential action, an enforcement checkpoint (PEP) gets a permit from a PDP that evaluates the action against the current Mission.
• Part 4: Lifecycle and change. State over time: Status, the Status List, and Signals for observation and revocation, expansion for governed growth, and completion and entry discharge for ending the work whole or one entry at a time.
• Part 5: The agent runtime and audit. Binding sessions to Mission state, unwinding in-flight work safely, and tamper-evident, independently verifiable evidence.

The issuance profile defined here stands on its own as the OAuth-substrate baseline. Everything else is an optional companion that layers on it without changing it, and optional means optional to the OAuth binding, not to the claims: the action-time enforcement claim needs runtime enforcement, and the Governed Agent bundle needs Consent Evidence and the harness. Least-Privilege MCP Tool Calls Need a Mission applies the full spine to a concrete MCP deployment.

The so-what is Durability and Narrowing. Authority that outlives credentials and only narrows as work fans out requires something durable for tokens to project from and narrow against, and nothing in the current stack is that thing. Now it has a name, a record, and a kill switch.

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, a working group draft since August 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.

The Mission Is the Missing Abstraction drew the boundary between Mission Intent (a proposal) and an approved Mission (the governance object). The approval event is the single moment of transition, where the Authorization Server validates the Intent, derives an Authority Set, the Approver consents, and the Mission record is committed by intent_hash and authority_hash.

This part is about the integrity of that transition. A request arrives as natural language, or as an upstream trigger, and has to become something the Authorization Server can validate and an Approver can meaningfully consent to. Three things have to hold for the resulting Mission to be trustworthy, and each maps to its own drafts in the suite:

1. The proposal must be honest about what it is. A shaper turns the request into a candidate Mission Intent, and that candidate has to fail closed on ambiguity rather than invent authority. (Shaping, Informational.) Client claims about the Intent, including its originator or presenter, travel as typed evidence the Authorization Server verifies or refuses. (Intent Submission Evidence, requesting Standards Track.)
2. The approval must commit what the Approver was actually shown. Otherwise a faulty rendering layer can display a narrow task while the Mission records a broad one. (Consent Evidence, requesting Standards Track.)
3. The approval must survive a real human review. Reviews are asynchronous, and reviewers approve a narrowed subset far more often than they accept all-or-nothing. (Deferred Approval, requesting Standards Track, and its narrowing companion Approval Revision, Experimental.)

The unifying claim, hammered through every section below, is the one from The Mission Is the Missing Abstraction. None of these three grants authority. Authority is created only by the Authorization Server’s validation and approval. The shaper proposes. Consent evidence records. Deferred approval narrows. They make the approval that does grant authority trustworthy, without ever becoming it.

The boundary, restated

The trust boundary is the whole reason this layer exists. The Mission versus Intent section of the architecture chapter is the canonical treatment. The short version:

Mission Intent is the proposal. Mission is the approval. The integrity anchors commit the moment of transition.

The user’s raw prompt, the shaper, the model behind the shaper, and the candidate Mission Intent are all on the untrusted side. The Authorization Server’s admission decision is the boundary. Before it, only Intent exists. After it, only the Mission is authoritative.

Each of the three drafts in this part strengthens a different edge of this picture. Shaping makes the left box honest and auditable. Consent Evidence makes the middle box reconstructable after the fact. Deferred Approval makes the middle box tolerate a slow, picky human reviewer without losing state. The boundary itself never moves.

Who may approve

The Approver is a role, not a species. On the record it is the consent_principal of the Mission’s approval_basis, an {iss, sub} principal (the record’s approver member is a compatibility alias carrying the same value), and the litmus test has never named a person as the decider. What the approval event requires is an accountable principal deciding against committed inputs before any authority exists. Three roles divide that work: derivation fixes the authority, an adjudicator (the human Approver, or a deterministic, versioned policy acting within a ceiling a human consented to) decides whether this instance activates, and a human stays accountable as the Approver. Two invariants hold whoever adjudicates:

• The proposer is never the approver. The agent, the shaper, and the requesting client sit on the untrusted side of the boundary above, whoever sits on the deciding side. A request that approves itself is not a request.
• Non-human adjudication traces to a human decision at some grain. An adjudicating policy is legitimate because a human consented to the ceiling it enforces or approved the policy it executes, exactly as a manager’s sign-off is legitimate because finance approved the delegation-of-authority matrix behind it. The record can name the policy in approval_basis.adjudication by id and version, so re-running that version over the recorded inputs re-checks the decision.

Within those invariants, the adjudicator is a spectrum the deployment chooses per class. A human approves directly, with Consent Evidence committing the disclosure they saw. A policy adjudicates the activation at machine speed, with the committed inputs and the policy’s recorded version standing where the disclosure stood, which is how a standing agent’s ceiling turns four hundred approvals an hour into policy decisions. Risk and fraud engines compose as decision inputs that inform or narrow either kind of adjudicator, the same way content-aware controls compose at the runtime layer: signals, not authorities. A model’s judgment enters adjudication only as a recorded input to the policy, with the model’s identifier and version: it can refuse an activation or narrow the authority it activates, and it never grants or widens, because a generated approver reading attacker-influenced proposals is itself an injection surface. Neither the policy nor a model input to it gates on the Intent’s prose members, which stay the human Approver’s check. And the floor is the class guard: irreversible actions, external commitments, and privileged administration keep a human in the decision by deployment policy, whatever approves everything else. The runtime part prices these same classes as high-consequence.

That floor names one accountable human, and the singular is a modeling choice worth defending, because four-eyes controls exist precisely so that no principal decides alone. The record commits one accountable Approver for attribution’s sake: a decision everyone signed is a decision no one answers for, and Law 2 needs a name. Joint approval is not lost, it is relocated. An adjudicating policy can require two human sign-offs before the Mission activates, and the quorum is enforced at admission. Every co-signer lands as an assertion in the issuer-signed Approval Governance Record, under the approval_policy (its id, version, and a digest of the retained policy snapshot) that demanded them, joined to the Mission by its approval_event_id. Consent Evidence can present the co-signers’ decisions beside the disclosure as co_approvals, and the governance record stays authoritative. What the model refuses is only the opposite flattening, a record where accountability diffuses across the quorum until it vanishes.

The enemy this section guards is not machine approval. It is agent-inferred authority: the agent granting itself scope mid-flight because no admission decision was required at all. Policy adjudication is still an admission decision, committed and attributable. An agent that widens its own authority is not.

The role, on a screen. The routing is risk-based (production impact and sensitive data pull a manager into the loop), the requester is not the approver, and the panel says why the decision landed here:

Shaping: proposes only

The issuance profile defines the Mission Intent object and how the Authorization Server derives an Authority Set from it. It does not define how a deployment turns “reconcile our Q3 invoices and post any adjustments under $500” into that structured object. That step is the Mission Shaper, and the Shaping draft describes it.

The draft is Informational by deliberate choice. Client-side prompt processing is shaped by deployment policy, model choice, and product ergonomics. No two deployments agree on the transformation, and the interoperable surface is not the transformation but its result, the Mission Intent, which the issuance profile already validates on the wire. So the draft specifies the shaper’s role and trust posture and the behaviors a sound implementation follows, not a portable shaping protocol.

A shaper can be an LLM-assisted function, a deterministic rules engine, a form, or a workflow. Whatever it is, its single rule is propose only:

• It MUST NOT issue, derive, or certify authority. Its output is untrusted client input until the Authorization Server validates and narrows it.
• It MUST NOT emit members that mimic Authorization Server outputs. No mission.id, no intent_hash, no authority_hash, no Authority Set, no lifecycle state. Those are produced by the Authorization Server at and after approval. The issuance profile rejects a Mission Intent carrying any such member with invalid_request rather than silently stripping it.
• A model-based shaper is no exception. The model can draft a proposal. It is never the thing that grants or widens access.

What a sound shaper builds is a Mission Intent with goal, an optional goal_lang, target_resources (each an absolute URI, no wider than what the request referenced), optional free-text task_bounds and success_criteria (disclosure and audit material only, carrying no machine semantics), an optional registered purpose, and expires_at, plus any member a companion the Authorization Server implements defines, such as requested_derivation_limit or a metering bound. The Intent’s top level is closed: the Authorization Server refuses an unknown member with invalid_request. The client submits the Intent through PAR as the intent member of a Submission envelope, and intent_hash commits the intent alone. The Intent carries no authority members. Any concrete candidate authority the shaper has resolved (actions, structured constraints, delegation facts) rides beside the Intent as standard top-level authorization_details: an untrusted carrier, committed by the conditional proposal_hash, that the Authorization Server only narrows when it derives the Authority Set (narrowing mode). Without a proposal, the Authorization Server looks the candidate entries up in a mapping it has configured for the Intent’s purpose or target_resources, then narrows those to policy (configured-mapping mode). Every handbook example uses the mission_resource_access entry type, which the Mission Resource Access Profile defines: a resource matched exactly or by path prefix, its actions, machine-checkable constraints including the registered Common Constraints, a per-entry delegation policy, and the subset algebra that narrows one entry against another. The OAuth binding itself is type-agnostic. Either way, the Authority Set is the Authorization Server’s product, never the shaper’s input taken at its word.

The Submission envelope’s other member, evidence, is where the client backs claims about the Intent: typed Intent Submission Evidence entries naming its originator, an admission or consent decision that applies to it, or the presenter authorized to submit it. The Authorization Server refuses the whole submission with invalid_mission_intent_evidence if an evidence entry has an unsupported type or fails verification. A verified entry is policy input, never authority. Intent-bound evidence must name this exact Intent’s intent_hash, evidence that names a presenter must match the one the exchange authenticated, and the Mission records the verified facts as submission_evidence.

One evidence type the family defines for the originator is Mission Request Provenance. A request intake, isolated from the shaper so the shaper cannot write to it, authenticates the person, captures the instruction before shaping, and signs an assertion binding the originator, the authenticated channel, and the capture time to this Authorization Server, the exact provisional intent_hash, and the presenter. The assertion carries only a keyed digest of the instruction, under a secret that never leaves the intake, so the Mission records where the request came from as submission_evidence without the Authorization Server learning what it said. Verification establishes the request’s origin. It does not establish that the Intent interprets the request faithfully, and it is never approval or authority.

Fail closed, not open. An ambiguity in the request is material when resolving it one way rather than another would change the Authority Set, the action class, the actor, the expiry, or the risk posture. For a material ambiguity, a sound shaper does one of three things: request clarification, emit a narrower proposal that excludes the ambiguous authority, or refuse with a reason. What it must not do is silently default a vague goal into a wide proposal. Because the shaper’s internal reasoning is unobservable to the Authorization Server, the draft expresses this through the audit artifact. When a shaper resolves an ambiguity in the broadening direction, Shaping Evidence MUST record the resolution, together with the deployment-policy rule that permitted that default where one did.

Shaping Evidence is that artifact: a record of the inputs, inferences, policy decisions, capability resolutions, ambiguities, and any model trace that produced the proposal. It is audit material, not authority, and never an input the derivation consumes. A Resource Server or PDP MUST NOT use it to permit an action. A client that wants the approval to cite how its proposal was produced can send a shaping_evidence_hash, computed over the suite’s domain-separated {typ, iss, value} envelope exactly as intent_hash and authority_hash are, as the mission_shaping_evidence_hash parameter of the PAR request. An Authorization Server that implements Consent Evidence records the value unchanged in the Consent Disclosure, where consent_rendering_hash commits it. The parameter carries only the hash, not the Shaping Evidence, so the Authorization Server cannot check the value against it, and the hash is a client-supplied audit commitment, not verified provenance. It confers no authority and proves nothing about the proposal’s correctness.

The threat this contains is silent broadening: a vague request quietly becoming a broad Authority Set, or prompt-injected content in the request expanding target_resources, choosing the wrong purpose, pushing out expires_at, or suppressing a stated bound. The shaper’s defenses (treat all prompt content as data not instructions, use resolved capabilities as a hard allowlist, refuse on injection patterns, record everything) reduce but cannot eliminate the risk. The real defense in depth is downstream. The Approver sees the validated Intent in a disclosure rendered by the Authorization Server, not by the shaper, before authority is bound. Which is exactly what the next section makes verifiable.

Both shaping modes have a natural surface, and neither grants a thing. Generated shaping takes the plain-language request and proposes policy-shaped options with cost, duration, and risk visible:

Authored shaping is the same proposal built by hand: objective, success criteria, allowed and forbidden capabilities, budgets and limits, then submission for approval:

Illustrations of the experience, not normative renderings. On the wire both are the same thing, a Mission Intent submitted for validation, and the compliance both surfaces advertise is a pre-check: the Authorization Server’s derivation and the Approver’s decision still create all the authority there is.

Consent Evidence: the recorded disclosure

The issuance profile commits what was approved, the Mission Intent and the Authority Set, through intent_hash and authority_hash. It deliberately leaves one gap open. It does not commit the consent disclosure the Approver actually saw. A faulty or malicious rendering layer could show a narrower task than the Authority Set really records, and nothing in the issuance profile would catch it. The Consent Evidence draft (requesting Standards Track) narrows that gap.

It adds two artifacts at each human approval, including the consent to a template or ceiling that later instances run under. An instance a policy activates under that standing consent has no disclosure of its own:

• A structured Consent Disclosure object: the task summary (including the rendered expires_at), the rendered authority summary (resources, actions, constraints, delegation, consumption bounds), the material notices for high-risk authority, the Approver and Subject identities, the requesting_client that will wield the authority (the party the Approver most needs to identify to resist consent phishing), and the intent_hash / authority_hash the disclosure corresponds to. When the submission carried Intent Submission Evidence, a submission_provenance_hash commits the verified provenance as part of the disclosure. It is constructed after Authority Set derivation and before approval. If the Authority Set changes afterward, the disclosure is discarded and rebuilt.
• A consent_rendering_hash over that disclosure object (again in the {typ, iss, value} envelope), and a signed Consent Evidence object that records the decision (approved, declined, or narrowed, the last for a review that sent the proposal back for revision), the authentication context, and an integrity envelope (a JWS) over the whole record, bound to the same Mission anchors used for authority.

The precise scope claim matters, and the draft is careful about it:

This profile commits the structured disclosure that the Authorization Server says it rendered, and binds it to the same Mission anchors used for authority.

What no server-side commitment can prove is that the pixels presented to the Approver matched the committed object, that the Approver read or understood it, or that the rendering layer was honest. The draft names that residual rather than hiding it.

What it buys you is a durable, integrity-protected record tying a specific structured disclosure to a specific approval decision and Authority Set, so that any divergence between the recorded disclosure and the authority later enforced becomes detectable in audit. An auditor can re-render the committed disclosure and check it against the Authority Set the agent actually used.

The “what a human perceived” problem is not all-or-nothing, so the draft defines a rendering-assurance ladder of rungs a deployment adopts as far as its threat model needs. Rung 0 commits the disclosure. Rung 1 makes rendering a deterministic function of the disclosure and its template, so an auditor can re-render the intended form. In practice that means the disclosure identifies its template, the template’s version, and the locale it rendered, and commits the template bytes with a rendering_template_digest, because a re-render an auditor cannot reproduce exactly is not deterministic. Rung 2 adds an attestation that an identified, attested renderer produced it. Rung 3 is the what-you-see-is-what-you-sign rung. The Approver’s own authenticator signs the consent_rendering_hash, moving trust from the rendering layer to the Approver’s authenticator. (Rung 4, out-of-band confirmation at execution time, belongs to Mission-Bound Runtime Enforcement.) Rung 0 is the profile’s only conforming floor. Every rung above it is an optional named claim, and Rungs 2 through 4 are additionally experimental, since each imports a trust infrastructure (attestation, transaction-confirming authenticators) the profile cannot supply. A deployment that needs assurance that the Approver’s authenticator confirmed a specific disclosure SHOULD evaluate Rung 3 for its high-risk notice classes: the class-guard classes plus consumption bounds.

Two details are easy to miss and worth keeping. First, declines are recorded too. A declined approval creates no Mission, token, or authority, but Consent Evidence is still recorded, so that coercion, decline-then-reshape fatigue attacks, and rendering confusion cannot be made invisible to audit. Second, the disclosure renders the derived authority, not just the friendly summary. A disclosure that shows a mission_summary without a faithful authority_summary does not conform. The Approver consents to the authority, with the summary as context.

Translation and interrogation: the disclosure as a dialogue

The same draft sets a translation floor, because coverage alone does not make a disclosure readable. A deployment can satisfy every coverage rule and still present the Authority Set as serialized structure that trains the Approver to stop reading, which is the consent-fatigue residual arriving through the rendering layer. So the rendered forms must be natural-language statements of what the agent may do, with each constraint and consumption bound rendered as the bound on a statement (“may not exceed 500 USD in total”), a serialized Authority Set never the primary rendering, and a constraint key the template cannot translate rendered and identified as untranslated rather than omitted. An Approver shown an untranslated bound can decline. One shown nothing cannot. Disclosure is a language problem before it is a rendering problem, and the floor is template-testable: the same template fixtures that catch downgrades should prove the template translates every constraint key and notice class the deployment uses.

The floor is also where ontology ownership becomes visible, because the disclosure renders meaning the issuer does not own. A Common Constraint has registered semantics the template can translate, but a resource-local action means what the resource says it means, and where a substrate lets the resource declare its own operations and consequences (AAuth’s exploratory Rich Resource Requests is this shape), consent composes the resource’s own words and commits them, so the record carries what the resource declared beside what the client asked and what the Approver accepted.

And the disclosure is not take-it-or-leave-it. A faithful disclosure answers what the Mission may do, but the question an Approver actually weighs is often why. Why does a support-ticket task need write access to a finance folder? An Approver who cannot ask guesses, and a guessing Approver decides on the wrong fact. Disclosure Interrogation gives the Approver a question channel before the decision, and the draft is precise about what may answer it. Anything the consent surface presents in its own voice must be drawn from recorded material: Shaping Evidence for why the task motivated an entry, constraint provenance for whose rule a bound is, and identified deployment policy for the Issuer’s own bounds. Where the answer is instead relayed from the requesting agent (AAuth’s clarification chat is exactly this channel), the relayed text is attacker-influenceable, so it is rendered inert and visibly the agent’s, because the same channel that lets an Approver ask why lets a compromised agent argue. An answer grants nothing and amends nothing. An Approver satisfied by an answer approves the same committed authority, and one convinced the authority is wrong declines or requires narrowing through a fresh derivation. The interrogation itself is recorded in Consent Evidence, and the question asked before a decline is the record’s most valuable entry: it preserves which authority the Approver probed and could not accept.

The dialogue, drawn. The question channel with its trust boundary visible: the requester’s answer arrives quarantined as relayed agent text, the grounded answer comes from Shaping Evidence with its citations, and the footer records the whole exchange into Consent Evidence:

The mock keeps the section’s rule: an answer grants nothing and amends nothing, and the Approver who accepts one approves the same committed authority.

Deferred and revisable approval

The issuance profile’s direct approval treats the approval event as immediate. Real human review of an agent’s proposed Mission is not. Two facts go unspecified, and two companion drafts supply them: the Deferred Approval draft makes the approval asynchronous, and the Approval Revision draft lets the reviewer narrow it in place. Deferred Approval depends normatively on OAuth Deferred Token Response, which the OAuth working group adopted in September 2026 and which is still a draft, and Approval Revision rides the same substrate and is labeled Evaluate only. Synchronous approval is the path to start with until that substrate settles.

Reviews are asynchronous. The agent submits a proposed Mission and may wait a long time for a decision. This is deliberately the shape of the request-and-approval workflows an enterprise already runs, so an IGA or ticketing system can drive the decision without new human ritual, and for approval volume the ceiling-and-drawdown model of progressive authorization is the companion answer (Mission Lifecycle and Change). The draft profiles OAuth Deferred Token Response so a Mission approval can be deferred and polled. The client includes deferred among its completion_mode values, the Authorization Server returns authorization_pending with a deferral_code instead of a token, and the client polls until the approval resolves. Deferral changes only the timing of the approval event. The Authority Set, its authority_hash, and the recorded consent are exactly as in a synchronous approval. An agent with no person at hand still runs the authorization code step: no Approver need be present at the authorization endpoint, which may issue the code without user interaction because the code stands for a pending authorization, bound by PKCE or DPoP. The agent redeems it with completion_mode=deferred and polls on the deferral_code until it receives a token, access_denied, or expired_token. The Mission becomes active atomically with the approval, and the client treats every pending response as unapproved. The drafts do not specify how a headless agent drives that front-channel step.

Reviewers narrow. A reviewer commonly approves a subset of the proposed Mission, not the whole thing. Without a way to revise in place, the agent has to abandon the proposal and start over, losing the approval state and any preceding work. The experimental Approval Revision companion adds a revisable mode. The client offers mission_revisable alongside deferred (completion_mode=deferred mission_revisable), and when the Authorization Server can grant only a narrowed version, it extends the authorization_pending response with mission_revision_required, a single-use sender-constrained mission_revision_handle, and (optionally) the mission_rejected_scope and mission_rejected_authorization_details that tell the agent which dimensions were refused. The client pushes a narrowed submission to PAR with the handle, and keeps polling the same deferral_code. A revision whose re-derived Authority Set does not narrow every refused dimension fails with mission_revision_not_narrowing. The approval resolves over the narrowed proposal. The client never lost its place, and without this companion the path is deny-and-resubmit under Deferred Approval alone.

The hard invariant, and the boundary to keep straight, is that this is narrowing only:

A revision can reduce the proposed Mission. It can never broaden it. The Authorization Server verifies the revised Authority Set is a subset of the proposed one under the issuance profile’s subset rule before it re-reviews.

Widening an already approved Mission is a different operation with its own fresh approval, Mission Expansion, which lives in Mission Lifecycle and Change. Deferred Approval and its revision companion govern only how the initial approval is reached over time. A client MUST treat mission_revision_required and the refused dimensions as evidence of nothing approved yet, never as a grant.

The mission_rejected_scope and mission_rejected_authorization_details are also the machine-readable input a shaper consumes to plan the narrowing. Shaping narrows a proposal before submission. Deferred approval narrows it during review. And because a narrowed proposal is a different disclosure, a deployment recording Consent Evidence records the review as a narrowed decision with the refused dimensions, and MUST compute a fresh consent_rendering_hash for the re-reviewed revision. Prior consent does not transfer to a different Authority Set.

The approver’s side of a deferred review, riding their own queue on their own schedule:

Request Changes is the revision channel: the reviewer narrows, the agent keeps polling the same deferral code, and nothing restarts. And the mock’s approve-and-run button compresses two events the wire keeps distinct: approval activates the Mission, and the waiting agent’s poll is what resumes the run.

The fatigue budget

Approval fatigue is not a UX complaint in this architecture. It is a security budget, because the card chapter’s version of this room said the quiet part: any adversary who can generate requests can farm a tired approver, and for agents the requests generate themselves. The handbook’s design answer is grain plus who may approve: machines approve actions, authorized policy adjudicates the Mission activations a consented ceiling already covers, and humans decide what is left, the ceilings, the class-guard classes, and the exceptions. But grain alone just moves the pile. A reviewer rubber-stamping forty Mission disclosures a day is the same failure one level up, and every approval a policy can legitimately take is one the human budget never pays. So the profiles in this part are also the fatigue controls, and they are worth reading that way:

• Shaping is the first control. A disclosure a reviewer can actually read (goal, resources, bounds, expiry, rendered small) is the difference between a decision and a reflex, and a shaper that fails closed on ambiguity keeps the padded, over-broad proposal from ever reaching the queue.
• Deferred approval routes decisions where attention already lives. The review rides the IGA or ticketing workflow the organization already staffs, with its own escalation and its own SLAs, instead of a new interrupt channel nobody owns.
• Revision narrows without restarting. The common case (right task, wrong bounds) costs the reviewer one trim instead of a resubmission cycle that trains requesters to ask broad and approvers to stop reading.
• Ceilings spend one good decision on many small ones. For high-volume and standing work, a pre-consented authority ceiling moves the human decision to the ceiling and its renewal, with the drawdown guard reserving fresh human approval for the classes where fatigue is most dangerous (the standing agent at scale).
• Action-bound approval is rationed by class, not sprinkled. Runtime enforcement reserves the second human decision for the class-guard classes: the friction budget spent at the point of maximum consequence.

And measure it, because a fatigue budget nobody measures is already overspent. Approval latency, deny and revision rates, exception volume, and time-to-decision are governance health metrics, and a queue where every approval lands in four seconds is telling you the disclosures are unreadable, the grain is wrong, or the reviewer has stopped reviewing.

Repeated work can justify a coarser human decision when its bounds are stable and its evidence is reviewable. Revision and deny rates inform that review alongside authority used, exceptions, incidents, and outcomes, and falling rates alone do not show the work is safe: broad permissions or a tired reviewer lower them too. A human decides whether the work belongs under a standing consent:

Both standing consents hold back more than the class guard does. Authority in the high-consequence classes, authority with the external-communication property, and cross-domain authority never activate on policy alone: a drawdown that grants such authority needs a fresh human approval, and a template cannot dispatch a Mission that carries it, so that work takes direct approval. Approving a Mission is separate from approving an action: where a deployment claims agent-compromise resistance, each high-consequence action also needs its own action-bound approval. Templates and progressive drawdown are experimental and Evaluate only in the catalog. They reduce the number of approvals, and the security benefit holds while a human still reviews each standing consent and its exceptions at renewal.

Spent well, the budget looks like this pair. Most work runs at the one-click end, read-only and least-privilege, previewed rather than interrogated:

And the heavy end is reserved for the one percent, where simulation results, blast radius, policy evaluation, and a chain of named approvers spend the friction where the consequence lives:

The tiers printed on these mocks are approval routing, not the Mission Assurance Levels: one is per-Mission friction under one deployment’s policy, the other is how much of the architecture a deployment runs.

How they compose

The three concerns are easiest to see threaded through one task. This is the handbook’s canonical running example. Alice asks her agent, in free text, “Put together the Q3 board packet for the audit committee and let them know it’s ready.” The Mission Is the Missing Abstraction picked up this task at the issuance profile. Here we watch the approval-time integrity around it.

Walking it:

1. Shaping proposes. The shaper turns the open-ended prompt into a bounded candidate Intent. It proposes three target_resources URIs (the finance, docs, and workflow services), matches the request to the registered board-packet purpose (urn:example:mission:board-packet), and states the bounds the request implies as human-readable task_bounds: Q3 2026, Example Corp, confidential. It bounds the work in time with an expires_at of 2026-10-15T18:00:00Z. What it does not do is author the actions: it submits no authorization_details proposal. Had no registered purpose matched, the shaper would have asked alice rather than choose the nearest one. It records Shaping Evidence and proposes.

2. The approval defers. Because the agent offered deferred mission_revisable, the review need not be synchronous. The Authorization Server validates the Intent and returns authorization_pending with a deferral_code, and the agent polls while the review waits for alice.

3. The Authorization Server derives at the approval event. No authority was proposed, so the AS derives the set in configured-mapping mode. The board-packet purpose mapping supplies the current reporting period, template, and reviewer group within the Intent’s target_resources. The AS shows alice the task_bounds beside the result but does not read them. The result is a query_financials action (finance, scoped to Q3 2026), a create_doc action (docs, bound to the board-packet template), and a notify_reviewer action (workflow, targeting the audit-committee group), each a mission_resource_access entry. The shaper’s structured members informed that derivation, as lookup key and bound. The Authorization Server authored every action in it. And derivation is mechanical, happening once at the approval event over the policy and capability catalog in force when alice decides, so a proposal that waits for days is never rendered to her under superseded policy. The rendered disclosure routes to alice, who approves on her own schedule. Had she instead refused the notify_reviewer action (a common reviewer instinct, holding back the external-facing step), the revisable mode would let the agent drop the workflow service from target_resources, push the narrowed submission, and keep polling the same deferral_code. Here she approves the proposal as derived.

4. Consent Evidence commits the surface. The structured disclosure the Authorization Server recorded as rendered (the task summary plus the faithful authority_summary over all three actions) was committed by consent_rendering_hash before approval, and her approval produces a signed Consent Evidence record bound to it. The committed intent_hash and authority_hash are over exactly the Intent and Authority Set she approved. The Authorization Server commits the Mission as msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p, state=active, with a direct approval_basis naming alice as its consent_principal, and issues the Mission-bound token that runtime enforcement will police. Its mission claim names the Mission by id and issuer, and the anchors stay on the record.

The same composition, rendered as an approval surface: the mock walks the identical spine as a reviewer experience, and its printed design principles are this part’s arguments as pixels.

An illustration of the experience, not a normative rendering. The wire truth for the claims and anchors lives in the exhibits, and a conforming disclosure renders the faithful authority_summary this part requires, whatever the pixels around it look like.

The result is an approved Mission whose integrity anchors commit a proposal that was honestly shaped, a disclosure that was faithfully recorded, and an approval that reflected a real human decision, without any of those three steps ever having granted authority. That is the whole job of this layer.

The Mission Is the Missing Abstraction defined the Mission and From a Request to an Approved Mission made its approval trustworthy. This part is where the approved Mission meets the agent identity stack: how authority is projected into tokens, how those tokens stay attributable to a specific agent instance acting for a specific user, and how authority flows down when one agent hands work to another.

The order matters next to AIMS. That work establishes the agent’s identity, credentials, and delegated user authority. Its Section 10.1 names the agent’s mission and leaves the translation of that mission into authorization requirements out of scope. The translation happened in From a Request to an Approved Mission. What this part adds is the binding: the authority that came out of the approval, attached to the identity that draft established, in a form every downstream party can verify.

The projection: how authority rides the token

The Mission lives at the Authorization Server. What travels is a projection. Every token derived under a Mission carries a mission claim with two required members, id and issuer, and an optional expires_at. The id and issuer say which governance record this credential serves and who holds it, and expires_at lets a validator check that the token’s exp stays inside the Mission’s clock. The claim carries no authority_hash and no approval_basis: the anchor commits the complete Authority Set, which a Resource Server holding a narrowed token does not have, so the anchors stay on the record, and an authorized introspection caller can receive authority_hash and the approval basis type. Offline attenuation, below, is the one exception: it puts the root’s authority_hash back on every token in its chain as a lineage anchor. The token’s authorization_details carry the derived authority itself. The Resource Server enforces them, relying on the token’s signature as the Authorization Server’s assertion that they are a subset of what was approved. A Resource Server or PDP that must check that independently adopts Mission Approved-Set Verification: it retrieves the complete set over a channel authenticated to the issuer, recomputes authority_hash, verifies each carried entry as a subset, and fails closed on any mismatch. Its second tier also pins an expected authority_hash obtained independently of that retrieval, which defends against a set substituted after approval. Issuance is gated on Mission state: a Mission that is not active derives nothing, which is the possession-independent kill switch.

Three properties make the projection safe to rely on:

• The subset rule. Every derivation, refresh, exchange, and delegation yields authority that is equal to or narrower than the Mission’s Authority Set, under the subset relation each entry’s type defines. For mission_resource_access, the Resource Access Profile defines it: resources may only narrow (exact match by default, with an opt-in prefix match), actions may only shrink, constraints may only tighten. Nothing derived ever exceeds what was approved.
• Sender constraint. Mission-bound tokens can be bound to a key with DPoP or mutual TLS, and a bound token is useless off the instance that holds its key. The drafts require it where theft does the most damage: a delegated token is bound to the delegate’s own key, a credential that crosses a trust domain is sender-constrained, a refresh token is sender-constrained or rotated, and the runtime layer requires a sender-constrained credential for the high-consequence classes. The primary access token may stay a bearer token for Resource Servers that accept nothing else, at the cost of stolen-token exposure. The high-assurance level in Mission-Bound Runtime Enforcement builds on exactly this property.
• Expiry capping. A derived token’s exp never exceeds the Mission’s expires_at, so the Mission’s clock transitively bounds every credential under it.

The issuance profile is the normative detail, and this projection is the anchor of the reference security architecture: it runs on published OAuth RFCs, with Client Instance Identification needed only for the optional instance-context composition.

Which instance is acting

A projection is only as attributable as the identity it is bound to, and the default OAuth answer is not good enough for agent platforms. A platform runs thousands of concurrent agent instances under one client_id, so every session collapses into one identity at the Resource Server. Per-agent policy, audit attribution, incident response, and abuse containment all defeat themselves at that grain.

None of what follows is required for the Runtime-Enforced minimum. A single-instance deployment with no delegation enforces Missions with the OAuth binding alone, which cites the Actor Profile informatively for its OPTIONAL delegation capability and Client Instance Identification only for the optional instance-context composition. The substrate becomes necessary the moment work is delegated or instances multiply, which for an agent platform is immediately. Three composable profiles fix the attribution, and they are the identity substrate this chapter assumes rather than redefines:

• The Actor Profile standardizes the RFC 8693 act chain across assertion grants and JWT access tokens, so the decision and the audit record both see who is acting for whom, at every hop.
• Client Instance Identification extends attestation-based client authentication to identify the specific client instance behind the shared client_id, so instance-level policy and revocation become possible. Its Instance Context grants no authority, and it identifies no actor: it attributes a presentation to an instance only under a sender-constraint key unique to that instance.
• OAuth 2.0 Client Attester Endorsement lets a client endorse its instance attesters in its client metadata.

The composition is the point. One Mission-bound token can now say: this authority derives from this approved task (mission), presented by this authenticated client instance (Instance Context, attributable under its instance-unique key), acting for this user (sub) through this delegation chain (act). The actor’s identity, and its association with the instance, are established separately from the instance evidence. Identity answers who. The Mission answers what for, and until when. The runtime layer (Mission-Bound Runtime Enforcement) evaluates all of it together on every consequential action.

The swarm: multiplication, not delegation

That composition also settles the swarm. When many instances run the same Mission under one authorized agent identity, nothing is delegated: the same principal is multiplied. Authorization attaches to the shared agent identity, which does not distinguish instances, and attribution stays per instance, because every instance presents its own Client Attestation and verified Instance Context attributes a presentation to an instance only under a key unique to it. Where a deployment implements the Mission’s Agent Deployment pin, every instance also satisfies it. The pin is an architectural pattern, not a wire member: the OAuth binding reserves no Intent member for it and leaves it to a future Agent Deployment Binding profile. An agent identity and an Agent Deployment stay distinct: a profile may map a Deployment version to its own client registration, but nothing requires that mapping.

Late binding is attestation: an instance spun up mid-task joins by authenticating as the shared client with its own Client Attestation, not by receiving a credential from a peer. What bounds the swarm’s aggregate consumption is the Mission-grain budget of Consumption Metering, which every instance shares. A derivation_limit from Mission Derivation Limits is a different control: the issuer’s cap on its own issuance events under the Mission, requested in the Intent as requested_derivation_limit and clamped by policy. It is not a fan-out or concurrency ceiling, because it counts issuance events, not instances. The kills stay separable: revoke one instance’s credentials, deregister the Deployment, or terminate the Mission and end every instance’s authority at once.

The rule that keeps this honest is that the shared identity is an authorization subject, never an attribution subject. The moment instances become indistinguishable in the record, the shared service account is back.

Two hard problems remain once the token is attributable. The authority has to cross authorization domains without losing its binding, and it has to flow down to delegates without becoming ambient. The rest of this part takes them in turn.

Crossing authorization domains

The running example never fit inside one authorization domain. The finance, docs, and workflow systems can each sit behind their own Authorization Server, and a Mission held at one AS is worthless at the others unless something carries it across. The base profile deliberately stops at the issuing AS’s edge. Mission Cross-Domain Projection is the optional capability that crosses it, in exactly one hop. The OAuth binding states this capability’s conformance bar self-contained, citing the companion informatively as the interoperable mechanism.

The model preserves everything the projection already established. The Mission Issuer issues a cross-domain grant under the OAuth identity chaining architecture, with the Identity Assertion Authorization Grant (ID-JAG) as the recommended profile. The grant is short-lived (capped at 300 seconds), sender-constrained, and audience-scoped, carrying only the Authority Set entries relevant to the target domain under the same subset rule that governs every other derivation. The Resource AS validates the grant and mints its own local tokens, and the mission claim rides through unchanged. One Mission, one mission.id and mission.issuer, joining issuance, enforcement, and audit across every domain it touches.

Revocation is where the domains differ. Single-domain revocation is prompt, because the AS that issued a token also honors its revocation. Cross-domain is strictly weaker. The Mission Issuer can stop issuing new grants the moment a Mission is revoked, but it cannot reach a local token another domain already minted, so cross-domain revocation latency is the downstream token lifetime, plus the projection grant’s remaining lifetime where the Resource AS checks no Mission state when it mints from that grant. That is why the draft requires Resource ASes to keep local Mission-bound tokens short-lived, why the grant lifetime is capped, and why the Status and Signals surfaces (Mission Lifecycle and Change) matter across domains. They are built for exactly the consumer that holds a mission_id and no token the issuer ever minted.

Revocation is not the only place the domain boundary bites, and the failure modes are worth naming plainly. The downstream domain may not speak the parent’s authority vocabulary, so entries either translate under a mapping both sides trust or do not cross at all. The downstream AS cannot independently verify the upstream approval’s semantics, only the grant’s signature and shape, so its trust in the projection is trust in the issuing domain. Two domains can disagree about what counts as narrower once constraints are contextual or quantitative, which is the semantic-narrowing boundary the Reference names, and the safe resolution is conservative refusal. And an action can be locally permitted while globally outside the Mission, because the local PDP sees only the projected slice. Those are the reasons the projection is one hop, audience-scoped, and subset-ruled rather than a general federation mechanism, and the portability wager is the bet underneath it.

In the suite’s adoption order this is advanced: a design to adopt when the use case arrives, with its dependencies tracked. As of October 2026, the identity-chaining work it profiles is approved and in the RFC Editor queue, ID-JAG is a working-group document, and the profile should not advance ahead of that substrate. Single-domain Runtime-Enforced deployments are unaffected by it entirely.

Projection carries a Mission across a domain boundary in one hop. The experimental Mission Continuation profile names the wider verb this hop belongs to: how a Mission’s authorization continues, under the same approval and constraints, when the acting identity must be re-established at the next hop or the original credential is gone. The Mission owns the authorization continuity, and an identity-continuity transport carries who is acting: the Identity Continuation Assertion for connected cross-workload hops, async delegation for disconnected work over time, and this projection at the domain boundary. One invariant binds all three: a continuation handle grants nothing. Every continued grant re-passes the Mission’s active gate, so continuity is never authority, and Continue stays distinct from Delegate, which narrows authority to a sub-actor.

Fan-out: the threat of authority by ancestry

A real agent does not stay a single actor. It decomposes the task: a research sub-agent, an extraction worker, a reviewer, each with its own session, queue, and tool handles. Every one of them needs some authority to do its slice, and every one of them is a place where the user’s approved task can quietly turn into more authority than the user ever saw. The Mission Is the Missing Abstraction committed the rule that keeps this from happening. Authority can only narrow. This part makes that rule true across fan-out, across the moment one agent hands work to another.

Here is the failure mode it must prevent. A parent agent, running under an active Mission, spawns a sub-agent. The sub-agent makes a consequential call. Why was it allowed? Because it descended from the parent. It shares the parent’s session, perhaps a cached tool connection, perhaps the parent’s token sitting in shared memory.

That is authority by ancestry, and it is the primary threat the Child Delegation draft names. It is dangerous precisely because it is the convenient default. The harness already has the parent’s credentials in hand, so handing them to a child is a one-liner. Nothing widened on paper. The child is “inside” an active Mission. And yet the user approved a board-packet task, not a board-packet task plus whatever every sub-agent the model decided to spawn can reach with the parent’s full token.

Session continuity is a runtime property. It can prove the sub-agent is part of the same execution. It cannot prove the sub-agent is authorized.

The rule, stated plainly: a child actor needs explicit, narrower authority, not session ancestry. A sub-agent handle is not a credential. Spawning is not delegation. Every mechanism below is a way to give a child explicit authority that is provably a subset of the parent’s and that stops when the parent does, and to make that the only path, so the ancestry shortcut is never available.

What the OAuth binding already gives you

Before reaching for new machinery, note what the issuance profile already covers. The OAuth binding supports delegated Mission-bound tokens. Authority narrows down a delegation chain, and the chain records actor context through RFC 8693 token exchange and the act claim. This is in-Mission delegation. It extends a single Mission’s act chain to additional actors, bounded by each authority entry’s per-entry delegation policy. No new Mission is created. The work is still exercised under the original Mission.

That is the right tool when the delegate does its work within the lifetime and operational control of the delegating flow: a synchronous hand-off, a downstream service call, a delegate that finishes before the parent moves on.

The two mechanisms in this part exist for the case the act chain does not cover: a sub-agent with a durable task of its own. A child with its own queue, its own background jobs, its own harness session, its own audit lifecycle (work that outlives the call frame that spawned it). For that, the child needs more than an entry on someone else’s chain. It needs its own authority handle, or its own narrowed token, depending on the tradeoff you are making.

The act chain is the baseline. The rest of this part is the two new mechanisms. They answer the same question with different cost profiles.

Mechanism 1: the Child Mission

A Child Mission (Mission Child Delegation) is the answer when a sub-agent needs its own durable, separately revocable Mission. It is an ordinary Mission under the issuance profile with two additions: it is created under a parent grant rather than a first-party approval, and its record and tokens carry a parent member that records lineage. It has its own mission_id, its own actor identity, its own lifecycle, and its own act chain that restarts at depth zero. But it cannot outlive, out-broaden, or escape its parent.

Five properties make that true, and they are worth holding together because each closes a different gap.

Explicit creation, never inheritance. A Child Mission is created by an RFC 8693 token exchange at the token endpoint. The subject_token is the parent’s own sender-constrained Mission-bound access token, and the requester proves possession of that token’s confirmation key; a refresh token is refused, because the proof must never ride a reusable bearer credential. The exchange carries the child’s mission_intent envelope, a child_actor identifying who will hold the child, and a required creation_request_id that makes the creation idempotent. Critically, the Authorization Server resolves the parent from the subject_token, not from any identifier. An optional parent identifier is a cross-check and audit value only, refused on a mismatch. Naming a parent you do not control gets you nothing. You have to present the parent’s bound token and prove its key. The response is a child-bound JWT authorization grant that only the named child actor can redeem, as itself, under its own client credential, so child credentials never transit the parent and the parent never holds child tokens. This is what makes “child by session ancestry” impossible. There is no path to a Child Mission that does not run through an explicit, authenticated, back-channel exchange carrying the parent’s own sender-constrained token.

Subset authority. Every child authority entry must be a subset of a parent entry under the same narrow-only subset rule the issuance profile uses for any derived token. The child entry’s resource must be contained in a parent entry’s resource (equal by default, or narrowed under the Resource Access Profile’s opt-in prefix match), its actions must be a subset, and its constraints may only tighten, so an entry may match the parent exactly. The child cannot add a resource, an action, or a constraint relaxation the parent lacks. The per-entry delegation policy must not be broader either: max_depth no greater, allowed_delegates no wider. “Strict” in the strict-subset rule means no relaxation anywhere, not inequality. The Authorization Server computes the child’s authority_hash over the child’s Authority Set and keeps it on the child’s record; the child’s tokens carry the baseline {id, issuer} claim plus the parent member, and a Resource Server enforces their carried authorization_details exactly as it does any Mission-bound token’s. The parent member’s authority_hash is lineage data, not authority. It records which parent commitment the child was derived under, for audit.

Expiry no later than the parent. The child’s expires_at must not be later than the parent’s. Because Mission expiry transitively caps every derived token’s exp, a child can never hand out a token that outlives the parent Mission’s clock.

Fan-out controls. This is the non-obvious one. Depth limits do not control breadth. A parent can authorize many children at the same depth, each a perfect subset, and the aggregate still amplifies authority. Twenty read-only sub-agents are a different risk than one. So child creation is off by default. The on-switch is a children object inside the parent entry’s per-entry delegation member, and an entry whose delegation carries no children permits no child at all (the denial reason is delegation_not_permitted). The children object then carries the controls the issuer must enforce: a cap on concurrently non-terminal children (max_children), a constraint on which actors may receive them (allowed_child_actors), a generation limit (max_child_depth, default 1), and a policy evaluated before each creation (child_creation_policy). An issuer that cannot enforce a control an entry carries refuses creation. Breadth is bounded explicitly, not as a side effect of depth. These are per-Mission figures, and they do not multiply into a lifetime total: max_children counts children alive at once, not children created over the Mission’s life, and a child’s own derivation_limit is set from its own Intent rather than drawn from the parent’s. A finite aggregate bound on a whole subtree holds only where a deployment runs a lineage-keyed budget under Consumption Metering, and an approval that shows these figures must say whether one is enforced.

Cascade revocation. A Child Mission depends on its parent, and “dependent” means every transitive descendant. Any transition of the parent to a non-active state is the cascade trigger. Terminal triggers (parent revoked, expired, completed, superseded, or itself cascaded) stop new derivation under dependent children and drive each child to a terminal cascaded state (distinct from revoked and expired so audit can tell a cascade-terminated child from a directly terminated one). The issuer commits that terminal transition whatever the cascade mode. The mode governs only what consumers must verify in the interim. Cascade is transitive. The children of a cascaded parent cascade in turn, in generation order. And derivation gates on the whole lineage: a child derives nothing while any ancestor, not just its immediate parent, is non-active, so a cascade in progress opens no window. The one reversible trigger is suspended. Derivation stops while the parent is paused, but the children are not terminated, and they return to their prior state when the parent resumes. The through-line: a child dies with its parent.

The running example. The parent Mission for “prepare the Q3 board packet” (Reference and Glossary) holds query_financials, create_doc, and notify_reviewer. The orchestrator spawns a sub-agent just to gather the financials, under a Child Mission whose Authority Set is a strict subset of the parent’s: query_financials only (no create_doc, no notify_reviewer), with expires_at no later than the parent’s and the parent’s Mission id recorded in the child’s parent member. The sub-agent has exactly the read it needs and nothing else. It cannot write the doc or notify anyone. When the board meeting is cancelled and the parent Mission is revoked, the child is cascade-revoked to the terminal cascaded state, fails its next runtime state check, and the sub-agent stops too.

Does creation wait for a human? Only when the deployment requires a fresh human approval. Creation completes in one of three modes. Synchronous creation is the common case: policy adjudicates the creation of a subset of already-approved authority, which the parent entry’s children object must explicitly permit, and the record names the parent’s human Approver as consent_principal under a policy_drawdown basis. Deferred creation answers authorization_pending and the parent polls while a fresh approval runs asynchronously. Interactive creation runs the issuance profile’s PAR ceremony in the front channel. Where a human approves, the basis is direct and that Approver is recorded.

One clean separation worth stating: a Child Mission is not Mission Expansion. Expansion (Mission Lifecycle and Change) creates a successor Mission with broader authority by fresh approval. A Child Mission creates a dependent Mission with narrower authority. They move in opposite directions and must never be conflated. (A superseded parent, in fact, is a terminal cascade trigger. The successor carries a freshly derived Authority Set, so a child that was a subset of the predecessor is not guaranteed to be a subset of the successor. Continuing child work requires explicit re-creation under the successor Mission, which re-runs subset validation.)

Mechanism 2: offline attenuation

The Child Mission puts the Authorization Server on the path of every delegation, which is exactly what you want when you want the issuer to see and own each one. But for deep sub-agent fan-out, the common agent topology, that makes the Authorization Server a per-delegation latency and availability dependency on the execution hot path. Every narrowing is a round-trip to the issuer.

Offline attenuation (Mission Offline Attenuation) removes the issuer from that path. It profiles Attenuating Agent Tokens so that a Mission-bound token holder can mint a narrower child token offline, with no Authorization Server contact. The holder selects a narrower tool and constraint set, increments the delegation depth, signs the child with the key the parent token’s cnf binds, and commits to the parent by hash. The child is valid by its signature chain. (Per-entry delegation policy is enforced by shaping the root at issuance, the one moment the issuer is present in the chain: a non-delegable entry never rides a root that can delegate.)

One caveat the convenience hides: offline minting is unobserved by the issuer. A del_max_depth on the chain caps how deep the narrowing can go, but there is no offline equivalent of the Child Mission’s max_children. Nothing on this path bounds breadth. A holder can mint as many narrower siblings as it likes, unseen by the issuer, so breadth must be bounded by deployment policy rather than by the substrate.

The Mission binding is what makes this safe rather than a new way to leak bearer tokens, and the draft requires three things together:

The mission claim rides the chain unchanged. Every token in the chain, root and every offline-minted descendant, carries the same id, issuer, and authority_hash as the root. A child cannot re-bind to a different Mission or change the lineage anchor. A consumer that sees a link whose mission claim differs from the root’s (or that omits it) must refuse the whole chain, not treat it as a narrower grant. Here authority_hash is purely a lineage anchor. It still commits the root Mission’s Authority Set, while the child’s real authority is its own carried, narrower constraints. (Contrast the Child Mission, where the child computes its own authority_hash. Offline children never do. The root’s rides along.)

The narrowing is verifiable from the carried chain. Because each child carries its parent chain, a consumer holding only the leaf token and its chain can verify that the leaf is a subset of the root (checking signature linkage, capability monotonicity, and depth) without holding the Mission’s full Authority Set. The narrowing proves itself.

The kill switch is delivered by the runtime layer, not the token. This is the point everything else rests on. The attenuation substrate defines no revocation of its own. Once minted, an offline child is valid until its exp, and no issuer can reach it. So the Mission kill switch is not automatic for offline children. It is delivered only by the runtime enforcement layer. On every presentation of a token in the chain, regardless of action class, the consumer must establish that the chain’s Mission is active, within the deployment’s declared freshness bound, from a Mission state source, in addition to verifying the chain and the proof-of-possession. It fails closed when the state source is unreachable, and a cached chain is re-checked on every presentation. A revoked or expired Mission causes refusal of every token in the chain, regardless of any child’s own exp.

When alice revokes the Mission, the next action fails the state check and the whole chain stops, even though no issuer ever saw the children and their tokens have not expired.

This is why offline attenuation is only safe on runtime-enforced paths. It is not available to a deployment that relies on token lifetime alone. Without the runtime state check, an offline chain is ungoverned bearer authority until it ages out, which defeats the entire purpose of binding it to a Mission. A deployment must not accept Mission-bound attenuation tokens on a path that does not enforce current Mission state.

A residual risk survives even all three requirements: a compromised holder key. Whoever holds the parent token’s confirmation key can mint any narrower child offline and unobserved. There is no issuer round-trip to deny. The only bounds are narrow-only (capability monotonicity means the attacker can never broaden authority) and the runtime layer re-checking Mission state on every action, so revoking the Mission still stops every child the compromised holder minted. The compromise can fan out narrower children, but it cannot widen authority or evade the kill switch.

Choosing which to use

The zeroth question comes before the choice: is this delegation at all? A homogeneous swarm, many instances under the same authorized agent identity executing the same Mission with the same authority, needs neither mechanism. That is multiplication, not delegation: no act hop, no child, no attenuation, just per-instance tokens under the shared identity. The mechanisms below are for the cases where a different principal acts or authority must narrow per delegate.

Both mechanisms narrow. Neither widens. The choice between them is a tradeoff between central control and scale, and the suite offers offline attenuation alongside Authorization-Server-mediated delegation, not instead of it.

The decision is not “which is more secure.” Both rest on the same narrow-only rule and the same kill switch. For the Child Mission, cascade revocation propagates from the issuer, which commits the terminal transition in every mode, while the experimental bounded_staleness and status_required modes push an interim parent-state check onto the consumer. For offline attenuation, the runtime layer re-checks state at use. The decision is where you can afford to spend a round-trip. If you want the issuer to observe and own every delegation, and the latency is acceptable, mediate it. If issuer round-trips are the bottleneck on a deep fan-out, mint offline and let the runtime layer carry the kill switch.

Maturity is a decision factor too. AS-mediated delegation runs on published OAuth RFCs (token exchange and the JWT-bearer grant) and is the path to start with, while offline attenuation is labeled Evaluate only because its substrate, Attenuating Agent Tokens, is an in-progress draft. Adopt it for evaluation. And a single deployment can do both: a Child Mission for the durable reviewer sub-agent, offline attenuation for the sharded extraction workers under it, each narrowed to its own slice, and no delegation machinery at all for the homogeneous instances that simply multiply.

That deployment, drawn. Every edge names its mechanism, what narrows on it, and what bounds it, and no edge widens:

Read the edges, not the boxes. Three different mechanisms, one invariant: everything below alice’s approval is a subset of it, and ending M ends the graph.

The through-line

Three invariants hold across both mechanisms, and they are the same three that have held since The Mission Is the Missing Abstraction:

• Authority can only narrow. A child is a strict subset of its parent: by subset validation at the issuer for a Child Mission, by capability monotonicity on the chain for offline attenuation. Neither path can broaden. Widening is Expansion (Mission Lifecycle and Change), a fresh approval, not a delegation.
• Delegation never widens. A handle is not a credential, and spawning is not delegation: authority moves down only by an explicit, narrower grant, never by ancestry.
• A child is bounded by the parent and dies with it. Cascade revocation for a Child Mission (issuer-committed in every mode, consumer-checked in the interim under the experimental bounded_staleness or status_required). The runtime Mission-state check for an offline chain. When the Mission goes non-active, every dependent and every descendant stops.

That last invariant is the whole kill switch, projected onto fan-out. Revoking one Mission stops the parent, its children, and their children at once, whether the issuer minted them or a holder did. The agent runtime and audit is what makes that true inside a running harness. It binds the sub-agent handles, queues, and sessions to Mission state so that “the Mission stopped” actually reaches the work in flight.

The Mission Is the Missing Abstraction made the Mission a durable, approval-backed governance object, and From a Request to an Approved Mission made the approval that creates it trustworthy. Those layers say what was approved, by whom, for how long, and within what bounds. They govern issuance and derivation. They do not evaluate an individual action at the moment it runs.

That is the gap this part closes. Mission governance makes authority auditable and revocable. Runtime enforcement is what prevents an active Mission from becoming ambient authority. It is the Enforcement step on the spine, and it is the center of gravity for the whole chapter.

A Mission-bound token is as strong as the Resource Server that enforces its bounds. Per-action, parameter-level, and state-aware checks come from runtime enforcement.

This part specifies those checks.

The model is one sentence. Within a declared enforcement scope, before each consequential action a Policy Enforcement Point (PEP) obtains a permit from a Policy Decision Point (PDP) that evaluates the action against the current Mission. Everything else in this part is what that sentence requires to actually hold.

Read that sentence for what the decision point actually holds, because it is easy to hear “central PDP” and picture a rules engine pricing bare actions. The decision evaluates the action in its undertaking. The Mission carries context no resource request ever does: the committed why, the approved shape of the authority, and, because evidence joins on the Mission, what the undertaking has already done. “Delete database” in isolation is indistinguishable from catastrophe. “Delete database, inside an approved migration whose copy steps are already in the Mission’s evidence” is a priced, checkable step. And the richer inputs stay deterministic: the anchors and the evidence trail are committed facts, not runtime inferences about intent, which is the line between this model and the intent-guessing it rejects. The history consulted is also first-party: the deployment’s own record of what its decision points permitted and its enforcement points executed. That is a different thing from the audit layer’s caution that a registered record proves inclusion to an outside verifier rather than occurrence. The PDP trusts its own ledger the way any database trusts its own writes.

And the order in that sentence carries more weight than the mechanism. Approve the bounded work, then authorize every consequential action against that approved boundary. Per-action authorization alone cannot prevent individually permitted steps from composing into an outcome no one approved: five reads and one send, each valid in isolation, can be an exfiltration pipeline. The approved boundary bounds that composition only where its bounds are the right kind: a destination the approval never granted stops the send, and the cumulative bounds and single-use permits of Consumption Metering carry the quantitative case. What survives inside the boundary is the flow-level residual the trifecta section prices: per-action checks are not information-flow control, and the harness taint rule is the mitigation, not this gate.

The gap issuance leaves open

The issuance profile is deliberately an issuance-and-derivation layer. Its own security considerations say so. It does not evaluate individual runtime actions, so an active Mission still bounds a set of authority an agent may exercise freely within a token’s lifetime.

Concretely, after the approval event the agent holds Mission-bound access tokens. Each token carries the mission claim (id, issuer, and optionally expires_at) and a subset of the Authority Set in its authorization_details. A Resource Server validates the token, enforces the carried authorization_details it understands, and serves the request. That is governance, and for the bounds the Resource Server enforces it is also a control. The token is bound to a kill switch, and the Authority Set is the maximum the token can ever claim. But between approval and the token’s natural expiry, nothing re-checks each concrete action against the current Mission. A compromised, drifted, or prompt-injected agent can spend the whole Authority Set, with any parameters the Resource Server’s own checks admit, as fast as it likes, until the token ages out or someone revokes the Mission.

The runtime layer delivers exactly the four things the issuance profile names as out of scope, plus enforcement of the constraints it carries but does not evaluate:

1. evaluation of a request’s parameters against the Mission at the point of use.
2. per-action evidence for every consequential action.
3. binding the invoked tool or function identity to the Mission’s approved authority.
4. execution-time re-evaluation that closes the approval-to-execution gap.

And, additionally, the fail-closed treatment of the consumption bounds a Mission carries (max_budget, max_calls, max_duration, max_egress_volume), whose definition and metering mechanics live in the experimental Mission Consumption Metering companion.

Mission-bound tokens bound what authority may exist. This profile, the Mission-Bound Runtime Enforcement draft, defines where and how that authority is re-checked before consequential effects occur.

The runtime model

A PEP sits at each consequential execution boundary. Before the action runs, it obtains a decision from a PDP that evaluates the action against the Mission the acting token is bound to.

Two roles do the work, and the spec defines them so the boundary is unambiguous:

• The PEP is the component that can prevent a consequential action and that obtains and enforces a decision before the action runs. Depending on the action it is a Resource Server, an MCP server, an egress proxy, a workflow engine, or the orchestrator itself.
• The PDP evaluates the action against the Mission and returns permit or deny. Its placement is a deployment choice: co-located with the Mission Issuer, embedded in the Resource Server, a tenant-scoped service, or a shared service. The profile mandates none of these. It requires only that a PEP at each consequential boundary can reach an applicable PDP.

The runtime decision evaluates six required inputs against the action, plus an optional seventh, and a deny on any one is terminal for that action:

• Authority. The action must fall within two bounds. The first is the credential’s authority under the subset rule: an applicable authorization_details entry the token carries, or one available to the PEP or PDP for that token through introspection. The second is the Mission’s current Effective Authority Set, the approved set less any discharge or containment. The PDP never substitutes the approved set for a credential’s narrower authority. A narrowed Mission stays active, so the PDP learns the effective set within the staleness bound from a source that reports narrowing, not lifecycle state alone. The PEP asserts the capability identity it will invoke, and the PDP refuses an identity outside the approved actions. A catalog-sourced capability is further bound to the digest of its definition recorded at derivation (covered by authority_hash). If a tool definition is later redefined or poisoned, the digests differ and the decision fails closed as capability_drift, under the extraction rule Mission Capability Binding owns.
• Resource policy. A Mission-bound permit is an upper bound on authority, not a command to perform the action. Object-level authorization, tenant configuration, legal holds, service invariants, and risk policy still apply. The action fails closed unless both Mission authority and Resource policy permit it.
• Parameters. Every constraints value on the applicable entry is evaluated against the concrete parameters. A constraint the PDP cannot understand or enforce causes refusal, never silent pass-through.
• Actor. When delegation is in effect, the PDP evaluates the authenticated act chain and refuses one that is missing or malformed (the delegation chain is Mission-Bound Authority). client_id (the client that obtained the token) and the immediate actor (the current actor in act, or that client when there is no chain) are distinct inputs, and the PDP never treats client_id alone as the immediate actor when a chain is present.
• Time. The PDP refuses an expired token. Because the issuance profile caps a derived token’s exp at expires_at, the exp check transitively enforces Mission expiry. The mission claim can also carry an OPTIONAL expires_at member, a bounding commitment with no liveness: it never extends reliance, and current state still comes from a freshness source.
• State. The PDP refuses unless the Mission is active. This is the handbook-wide rule made operational. Only active permits reliance, and every other state, recognized or not, is non-active.
• History (optional). A deployment may evaluate policy predicates over the Mission’s prior Decision and Execution Evidence, for example that a named action class has completed. History is a decision input, never a grant, and a required predicate the PDP cannot establish within its staleness bound fails closed.

This is the move that makes Intent-Based Access Control practical. The PDP is not reconstructing “what did the user want” from a prompt at enforcement time. It is checking a concrete action against an approved, integrity-anchored Authority Set. The interpretation already happened at consent time (The Mission Is the Missing Abstraction). Current resource policy stays authoritative for the final permit or deny.

The model has a price, because the decision is on the hot path by design. Every consequential action buys a policy evaluation, and the contract’s cost controls are the classification and the lease: non-consequential work is never gated, consequential reads take a decision without parameter binding, permits for reversible writes amortize across a validity window, and only the high-consequence classes pay for single-use permits and reverification on every execution. What the family does not yet have is deployment-scale performance data, and this handbook will not invent it. A deployment should publish its measured decision latency next to its staleness bound, and the absence of those numbers across the industry is one more reason walk ships first: they should come from running systems, not from this page. The classification bet names the erosion to watch while they arrive: a mediated class list that shrinks release over release while the claim name holds.

Which actions are consequential

The PDP gate is not for every action. Reasoning steps and cache reads have no external visibility and need not be gated. The boundary between consequential and non-consequential is deployment policy. But a deployment must not draw it so loosely that nothing is enforced. The profile defines a default classification a deployment SHOULD adopt, and a floor it MUST observe.

The bottom three rows are the high-consequence classes, where a token-lifetime-wide standing authority is least appropriate and the profile’s strictest requirements attach (action-bound approval, mediated custody, active-state freshness, execution-outcome evidence, all below).

One property cuts across the classes. An external-communication action is a consequential action of any class whose effect carries data to a recipient outside the deployment’s trust boundary: sending a message or mail, posting to an external service, publishing. It names the egress property, not a further class. The action keeps its class and that class’s requirements, and the rules stated over external-communication actions (the taint rule, trifecta containment, egress metering) apply to every action that has the property.

Two guardrails keep classification honest. A Mission’s purpose, or deployment policy, MAY raise an action to a stricter class. A financial-settlement purpose may treat a write as an external commitment. It MUST NOT lower an action below the resource owner’s minimum, and MUST NOT classify an irreversible, external-commitment, or privileged-administration action as non-consequential. A deployment cannot evade enforcement by relabeling a high-consequence action as harmless.

The classes are floors drawn from several consequence dimensions, reversibility, exposure, privilege, commitment, and value, with policy taking the maximum across them, because a read of regulated data is irreversible in the only sense that matters once it leaves. And the same operation can cross classes on its parameters: creating a ten-dollar draft is not releasing a million-dollar transfer.

The table’s gate column applies within the declared runtime-enforcement scope. Outside it, an issuance-gated path claims its published worst-case credential-lifetime bound, including the age of any observation used to mint the credential, and a path outside Mission enforcement gains no Mission revocation guarantee (not every resource checks Mission state). Classification is deployment policy above the floor, with one exception for reads: a read already fully constrained by the token’s audience and resource and the Resource Server’s object-level authorization, with no material effect on the resource set or disclosure risk, need not be classed a consequential read, so the profile does not require every read to reach a PDP. The exception concerns classification only; writes and higher classes are gated as the table requires. Neither classification nor a scope exclusion supports a claim for enforcement the path does not provide.

Where the enforcement point sits

The strongest decision logic is void if the PEP is in the wrong place. The same Mission, PDP, and policy view all fail if the permit is checked somewhere the action can route around. The rules are blunt:

• The PEP MUST be at the last controllable boundary before the action. A permit checked further upstream does not survive parameter changes, retries, or routing that happen after the check.
• A token-issuance decision does not replace execution-time authorization. A token-only Resource Server cannot claim runtime enforcement. The issuance gate is governance. The runtime gate is enforcement.
• A tool-catalog filter does not replace per-call authorization. Filtering a tools/list by the caller’s authority is exposure control. Every consequential tools/call still passes the runtime gate.
• An orchestrator’s internal check does not replace a Resource Server’s PEP. Defense in depth is permitted. Substitution is not.
• If no PEP can prevent the action for a class, the deployment MUST NOT claim runtime enforcement for that class, and must name the classes and execution paths it does mediate.

That last rule is why the profile’s conformance is scoped, not global. A deployment conforms only for the resources, action classes, execution paths, and authorization-detail types named in its enforcement scope. An OAuth-protected API call is gated at the Resource Server, a consequential MCP tools/call at the MCP server, a local file write or payment at the orchestrator, external egress at an egress proxy. Where an action can be reached by an unmediated path (a debug shell, an unsanctioned egress route, a direct connector), the profile is simply not enforced for the classes that path reaches, and the claim must say so.

The claim, as a surface a deployment would actually publish:

The parts worth copying are the first-class exclusions, the token-lifetime bounds on issuance-gated classes rather than a pretense of mediation, and the verification suite. One vocabulary note: the mock’s enforcement levels are this deployment’s own declared strength scale, not the Mission Assurance Levels.

The deployment question underneath is what can be centralized and what must live at each boundary. The PDP centralizes: one decision service (or a small fleet) serves every PEP. The PEPs cannot, because a permit is only as good as its placement:

A real deployment mixes rows, and the enforcement-scope statement records which rows it actually runs.

Closing the TOCTOU gap with parameter binding

A permit for an operation does not authorize arbitrary parameter values. If the PDP permits “write to the ledger” and the agent then changes the amount, the permit must not still hold. This is the time-of-check-to-time-of-use (TOCTOU) gap, and parameter binding closes it.

For consequential writes and the high-consequence classes, the PDP binds its permit to the normalized action parameters through a parameter_digest: the SHA-256 of the RFC 8785 JCS serialization of the normalized parameter object, in the issuance profile’s encoded form. The permit also binds the Mission reference, the token issuer when available, the token audience, sub, client_id, actor context, sender-constraint key, action, resource, the authorizing entry (or an entry digest), the policy-view version, and a tight lifetime control.

The executing PEP, not an upstream component, recomputes the digest against the parameters it is about to use, immediately before acting, and verifies every binding. A mismatch refuses. The permit does not authorize the changed parameters. Two consequences follow:

• A permit cannot be replayed for a different request, because the digest mismatches.
• A permit cannot be reused across boundaries. Bound to a specific audience, resource, tenant, and operation, a decision for one is not reusable at another, which is the confused-deputy defense.

What the PEP checks, and how. The AuthZEN permit echoes only the bindings the PEP enforces at each use: the parameter_digest it recomputes; valid_until, never later than the credential’s expiry, the approval’s approved_until, the state’s valid-through time, or the policy maximum; use_limit, whose consumed-identifier store the PEP keeps; the evaluation-context digest, where Evaluation-Context Binding is claimed; and the action phase, where the operation is a phase of a compound action. A condition the PEP does not recognize invalidates the permit. The other bindings (issuer, audience, sub, client_id, actor, key, entry, and policy view) are not echoed. They hold because the PEP built the request from its own validated credential context, and the requester and the executor must be the same enforcement identity on one mutually authenticated channel: a permit is never relayed to another component as a bearer grant, and a cached permit does not serve a request whose cache key differs. The PDP records the authorizing entry or its digest, the policy view, the audience, and, where it tracks one, the state version in Decision Evidence, for audit rather than for the PEP to compare. The drafts specify no field-by-field comparison for the bindings the permit does not echo.

The lifetime control scales with risk. A reversible write may use a single-use decision identifier or a short window plus an idempotency key. An irreversible action, external commitment, or privileged administration MUST use a single-use decision identifier (a validity window alone does not bound how many times such a permit executes), and consumed identifiers are recorded so any second presentation fails closed. A single-use identifier bounds executions of one permit, not permits for one action, so for a non-idempotent operation in these classes the Operation Profile MUST also define an idempotency key, which identifies one intended execution of one normalized request. The PDP claims the key atomically before it permits. A repeat under the same key and the same operation is duplicate_suppressed: transient while the first outcome is unresolved, terminal once it has completed, with the prior result served by the resource rather than executed again. The same key with a different operation is a terminal idempotency_conflict. An intentional re-execution is a new operation under a new key, which an action-bound approval can authorize as such. The claim needs an exact store (a single serializing PDP or a linearizable shared store), so a deployment whose replicas only converge within a bound cannot make it. And these classes MUST carry an execution lease or a published maximum execution duration, so run-to-completion is bounded too. Idempotency support, reversibility, and the lease an operation needs are resource-declared semantics, stated in the Operation Profile the deployment publishes for each operation so the PDP does not guess. The same profiles mark compound actions: an action that crosses more than one boundary (reserve then commit, draft then send) obtains its own Decision for each consequential phase, each permit binds its phase, and a prepare-phase permit never releases a commit.

The Operation Profile. Normalization is the Operation Profile’s job, so that two implementers of one operation bind the same bytes. The digest is computed directly over the normalized parameter object, with no envelope, under the issuance profile’s canonicalization rules: duplicate members rejected, array order significant, and URIs compared byte for byte. The runtime profile requires each Operation Profile to fix:

A deployment that leaves any of these unstated has not specified that operation’s binding. The drafts define no wire format or registry for Operation Profiles, and they set no unit rule beyond keeping unit and currency conversion out of constraint mappings.

Two limits bound what the digest can promise. The binding is only as strong as canonicalization: where a resource resolves material semantics after receipt, the descriptor the PEP hashes is not the descriptor the resource executes, and the binding is to a phrasing rather than an action. And a single-use identifier guarantees single consumption, not single effect. The repair for both moves the binding to the effect: a resource-prepared descriptor authorized and committed exactly once, or a mediating handler that is the transaction’s system of record.

Consequential reads do not require a digest by default. But a binding floor applies. A read whose parameters select a cross-tenant or cross-audience scope, request a bulk or export-like result, or choose the returned fields or destination MUST bind those parameters. An export is not an ordinary read.

The running example. Take the handbook’s running example, the Prepare the Q3 board packet Mission. A query_financials read against finance.example.com is a consequential read. The PDP permits it against the live Mission, no digest required. A notify_reviewer send against workflow.example.com is consequential and externally visible, so its permit is bound to the concrete recipient, the audit-committee group named in the entry’s constraints. Ask to notify a target outside audit-committee and the action is outside the Authority Set’s constraint. The PDP refuses (parameter_violation) and the PEP fails closed. The interpretation happened at consent time. The gate only checks the concrete action against it.

Metering, and fail-closed on everything else

A Mission can carry cumulative consumption bounds (max_budget, max_calls, max_duration, max_egress_volume), and the issuance layer cannot enforce them because it counts derivations, not actions. The bounds and their metering mechanics are defined by the experimental Mission Consumption Metering companion, while the runtime profile keeps the fail-closed posture: an unknown or unmetered bound on an applicable entry refuses. Under the companion, for each consequential action the PDP performs an atomic reserve-or-charge against the remaining balance, increments the named call counter, or accumulates duration, and refuses when a bound would be exceeded.

Metering is a two-phase exchange, not a single decision-time act. For an action of unknown length the PDP reserves a bounded maximum or issues a duration lease, and after execution the PEP reports the measured outcome so the PDP can commit actual use and release the unused reservation. The Execution Evidence record (below) is that commit-or-release signal, keyed to the permit’s evaluation_id. For irreversible actions and external commitments, a deployment must define whether metering is reserved before execution and committed after success, or committed up front. The hardest moment in the exchange is not the check but the timeout after it, when the permit is spent, the resource has not answered, and committedness is unknowable. Evidence records that outcome as unknown rather than guessed, and the unknown has an owner: a named reconciliation against resource state with a deadline, because an unknown nobody owns becomes a committed effect nobody recorded. Reconciliation can resolve an unknown to committed or failed. What it can never do is admit a new effect under a Mission that has since gone non-active.

The topology is part of the claim. Under a single serializing PDP the check-and-decrement is atomic and the bound is exact. Under distributed PDPs an exact global counter is a distributed-counting problem. Such a deployment must publish the consistency bound it actually operates under (per-PDP sub-budgets, a bounded reconciliation window) and must not advertise exactness it cannot meet. Cumulative-bounds enforcement is a newer model, which is why the companion is experimental, with short expiries and per-action constraint checks as the path to start with.

Enforcement is only meaningful if failure is bounded, so the spec fixes the failure behavior. The pattern is uniform. For consequential actions, when the answer is in doubt, refuse. The rows below are the decisive excerpt. The draft’s failure-mode table is longer (a missing mission claim, an unsupported authorization-detail type, an out-of-authority capability identity, and a Resource policy refusal all refuse the same way).

parameter_digest closes the gap between decision and execution for the request’s own fields, and it cannot freeze the target: a document can be revised, a record reclassified, a query can return a different set by the time the action lands. For high-consequence classes, treat that as a named residual unless the deployment claims the extension below. The permit’s tight lifetime is the bound, a retry re-evaluates rather than replaying a stale permit, and where the resource exposes versions or content digests, bind them as request parameters so the parameter_digest carries them. The runtime core also defines an optional Named Assurance Extension, Evaluation-Context Binding, claimed per mediated class: the Operation Profile declares which resource-resolved facts a decision depends on (a revision, or the enumerated resolved values), the PEP captures them from their authoritative source and commits them in an evaluation_context_digest the permit returns as a condition, and the executing PEP re-resolves and recompares them in the same step as the parameter_digest check. A mismatch suppresses the effect and is recorded as target_drift. A reread and comparison earns the extension’s verified property; the enforced property needs the resource to compare atomically with the effect.

Every refusal, and every permit, produces a runtime evidence record sufficient to reconstruct which path produced it.

Fail-closed and active freshness

The “Mission not active” row above carries the most weight, and it has a subtlety the high-consequence classes turn into a hard requirement. A token alone cannot tell the PDP the Mission’s current state. The token was minted at approval time. So the deployment must define a Mission state source it trusts, and the PDP must refuse a consequential action when it cannot establish, within a published staleness bound, that the Mission is active.

A permit is a lease, not a standing grant. Token TTL, cached Mission status, and policy views are all leases on Mission authority, each valid for a bounded window before it must be refreshed against the state source or fail closed. The staleness bound each enforcement scope publishes carries a latency consequence it must publish with it: for a PDP-gated class, a revocation takes effect, worst case, after the staleness bound plus the permit validity window plus the class’s execution bound. For a path outside PDP gating, the bound is the token lifetime where the token’s minting checked current Mission state, and otherwise the token lifetime plus the age of the state observation it was minted from.

The TTL-only end of that dial is a first-class posture, not a fallback. A path that relies on lifetimes alone verifies with local cryptography and a clock, with no state source to couple to and a worst-case exposure equal to the lifetime by construction. What a lifetime cannot do is suspend, complete, or kill now. The two ends are one mechanism read from opposite sides, because a lifetime relocates the freshness check from the verification path to the issuance path.

Read that as a dial, not a doctrine, because most estates will start at the coarse end and should be met there. Short-lived tokens minted under state-gated issuance are a legitimate setting for the classes below high-consequence: the resource validates tokens exactly as it does today, no PDP call, no Mission awareness, and revocation still reaches it within the token lifetime where every issuance, refresh, and exchange path checks Mission state when it mints. A token minted from an earlier observation, such as a grant redeemed later, adds that observation’s age to its lifetime. A legacy resource that will never evaluate Mission state is served that way, or fronted by a gateway or MCP PEP that carries the per-action check on its behalf. The Reference’s revocation matrix prices every setting on the dial, and Adopting carries the deployment shapes. What the dial never permits is pretending: the high-consequence classes require an active freshness mechanism, and a path whose only bound is token lifetime claims exactly that bound, in writing.

For the high-consequence classes the spec is categorical. The state source MUST be an active freshness mechanism that can reflect a revocation within the staleness bound, queried or pushed independently of the token’s own lifetime. On the OAuth 2.0 profile that is token introspection at the Mission issuer, the Mission Status surface, a Mission Status List whose Status List Token TTL is within the staleness bound (the pull floor for consumers relying on many Missions at once), or Lifecycle Signals (Mission Lifecycle and Change). It must also report any discharge or containment narrowing.

Token-lifetime expiry alone is not an acceptable state source for the high-consequence classes. It bounds staleness only by the token lifetime, so a revoked Mission keeps deriving consequence until tokens age out. That is precisely the ambient-authority gap this profile exists to close.

The runtime draft recommends a default freshness posture per class, adopted absent a documented, consequence-specific analysis:

A deployment justifies any looser value for a high-consequence class in its enforcement-scope statement. These are targets for the freshness of the state a decision reads; the worst-case revocation bound adds the permit and execution windows above. The reference target the drafts repository builds first configures 300 seconds for reads and writes, 60 for external commitments, and 30 for irreversible actions and privileged administration (its deployment record).

This is where the handbook-wide rule “only active permits reliance” stops being a governance statement and becomes a wire requirement. A suspended or revoked Mission produces a runtime denial regardless of policy, and for the actions that matter most, the deployment must be able to learn the revocation fast enough to act on it.

Where the PDP gets the narrowed set. The PDP may evaluate a materialized policy view or the Mission’s recorded authority, but mutable state, including every narrowing of the Effective Authority Set, comes from a state source within the staleness bound, never from that representation. A source that reports only lifecycle state does not qualify, because a narrowed Mission stays active. On the OAuth 2.0 profile the qualifying sources are full Mission Status or introspection carrying containment_version, and Lifecycle Signals carrying the overlay change. A Status request that names an audience returns the entries relevant to that audience after every narrowing. One that omits it is state-only, which is all the harness needs at 02:00 and not enough for a PDP evaluating authority. The AuthZEN profile defines no member that carries the evaluated set.

The high-assurance level

Everything above bounds what any agent can do. The high-assurance level raises the bar for a compromised agent, one that has been prompt-injected or taken over but still presents correct credentials. The issuance and runtime gates do not make the agent trustworthy. They bound what it can do. This level shrinks that bound further by not letting the agent hold the authority whose misuse is unacceptable, and by requiring a fresh independent approval for the highest-consequence acts.

Mediated custody. For any class a deployment mediates, and for every high-consequence class, the acting credential must be sender-constrained, so that only the holder of the private key its cnf binds can present it. For the mediated classes, the PEP holds the sender-constraint private key, not the agent. The agent cannot present the credential directly. To act, it asks the mediating PEP, which runs the decision and only then uses the key. No new token type or wire protocol, just a custody-and-placement property of the existing key. The token is unchanged, the agent remains the principal of record (client_id still attributes the action), and no act entry is added. Two properties follow: a credential exfiltrated from a compromised agent is unusable without the key, and a compromised agent cannot reach a mediated action without passing the per-action check, because it never holds a usable credential for that class. This depends on the agent having no unmediated path to the resource, which the agent harness establishes (The Agent Runtime and Audit).

The drafts do not specify which component makes the token request. In one shape they describe, the PEP is itself the attested instance that obtained the token, with the key generated in the PEP or its HSM, and the declared path scope leaves the agent no token, refresh, or exchange path to a usable credential of its own.

Action-bound approval. The Mission’s approval event consents to the task and its authority bound. It does not consent to a specific action’s concrete parameters. For the high-consequence classes a deployment can require a second, action-bound approval (and an Authority Set entry can demand it through the requires_action_approval Common Constraint the Resource Access Profile defines): a fresh approval bound to the concrete action and parameters the PEP is about to permit, obtained from an independent approver, never self-issued by the agent. Because it is bound to the parameters, it is reverified under the same TOCTOU rules. A parameter change after approval invalidates it. It carries a maximum age the deployment publishes, and may carry an absolute approved_until; past the earlier of the two it is stale and the PEP refuses. The surface that resolves it must not be invocable from the agent’s tool plane or any channel the agent drives: the agent may observe an approval’s state and request one, but never resolve one. The runtime core leaves the workflow that obtains the approval to bindings: the AuthZEN profile composes with ARAP, and the experimental Mission Transaction Authorization profile defines a cross-domain workflow whose transaction token is restricted to its one recorded transaction. However obtained, the approval is decision input, not a bearer grant. The runtime decision stays authoritative, and persisting authority beyond the single action is a Mission Expansion (Mission Lifecycle and Change), not a property of the approval.

“Protects against agent compromise” is a verifiable claim, not a label. A deployment claims agent-compromise-resistant enforcement only when, for the high-consequence classes, four conditions hold:

1. The sender-constraint key is generated and held in the mediating PEP or its HSM, never transferred from the agent. Gateway custody is the shape that realizes this today.
2. Each such action requires an action-bound approval.
3. The disclosure the approver decides on is rendered from the bound parameters by a component isolated from the agent, never composed by the agent.
4. The state source is an active freshness mechanism.

The claim’s fifth term is the path scope: governed work has no unmediated path to the mediated classes, and no token, refresh, or exchange path by which the agent obtains a fresh usable credential for them under a key it controls. No protocol can verify that term, so the deployment declares it in its Enforcement Scope Statement and audits it, with negative tests as the observable check. Each condition is also bound to named evidence: Entity Attestation Tokens for key custody, the isolation boundary, and the measured workload, and signed configuration, service evidence, or audit for the rest, with the scope statement itself attested.

Active freshness is already a MUST in the base profile for these classes. Mediated custody and action-bound approval are the claim’s upgrades from SHOULD to MUST, and the agent-isolated approval rendering is stated only by this claim, so a deployment that skips any of them, or leaves the path scope undeclared, may still claim base runtime conformance, but not this.

What sits outside the agent’s reach. Every guarantee in this part bounds what an untrusted agent can achieve, so each holds only while certain components stay out of the agent’s control. The family’s security model names that trusted base and how each component’s compromise degrades the guarantees. The components this part relies on are:

• the Authorization Server (the Mission Issuer), which derives authority, gates issuance, and is the root of trust;
• the PDP and every PEP, including the mediating PEP that holds the sender-constraint key;
• the Mission state source;
• the harness, which keeps governed work off unmediated paths and enforces the taint rule;
• the consent rendering layer, which shows the Approver what is being approved;
• the access-request and approval workflow, wherever requestable denials or action-bound approvals are used;
• metering state, where consumption metering is used.

The action class comes from resource policy, an operation profile, or a reviewed workflow, never from the agent’s plan. An agent that can reach any of these can move its own bounds.

The decision contract and its AuthZEN profile

The runtime core specifies enforcement invariants, not a wire protocol. It deliberately does not standardize a PDP decision API, an enforcement-scope discovery format, or a Mission Status endpoint. It defines the Mission Receipt, the portable projection of runtime evidence about a material action taken under a Mission, only by its name and minimum binding. It defines what a deployment MUST satisfy when it claims runtime Mission enforcement.

That keeps the contract substrate-independent. But it means two conforming deployments do not thereby interoperate at the PEP–PDP boundary. Three companion documents supply the rest. The OAuth 2.0 profile maps validated token claims and introspection results onto the runtime inputs, names the OAuth mechanisms that observe Mission state, and lets a protected resource publish its classification floors in its metadata. Mission Runtime Evidence defines the records: the Decision Evidence Object, the Execution Evidence Object, the Refusal Record, and the Mission Receipt, so every decision-API binding emits the same ones. And the AuthZEN Profile binds the decision contract to the OpenID AuthZEN Authorization API, as a Decision Base plus six optional feature profiles (Transaction Assurance, Runtime Evidence, Obligations, ARAP, History, and Batch). A deployment using the OAuth profile does not need AuthZEN; the decision API is a separate choice. The division of labor is strict:

The runtime core owns the enforcement semantics. The AuthZEN profile binds the contract to a wire. It does not restate the semantics. It carries only the binding deltas.

Those deltas are:

• Mapping the inputs onto the AuthZEN envelope. The Mission reference, actor, and credential ride in AuthZEN’s context object as context.mission, context.actor, and context.credential, and a PEP-supplied state observation rides as context.mission_state_observation (state, mode, and freshness_at). The normalized parameters and their digest ride as action.properties.parameters and action.properties.parameter_digest, with an idempotency_key where required. The audience rides as resource.properties.audience. The approved entry’s resource URI is matched against that audience, not against the AuthZEN resource object’s type and id, which carry the finer-grained object identity used only for resource-policy evaluation.
• Permits that carry their binding. A permit returns an evaluation_id and its decision conditions: the parameter_digest it is bound to, a valid_until that never outlives the credential, the approval, or the state observation, and use_limit: 1 for the high-consequence classes.
• Three evidence records. The AuthZEN profile’s Runtime Evidence feature profile says which response members flow into the records Mission Runtime Evidence defines. Decision Evidence is emitted by the PDP: what it evaluated, integrity-protected with a jws-compact envelope, and chained back to the Mission by its id and issuer plus either the PDP’s policy_view_id or, for a PDP that evaluates the Mission’s recorded authority directly, authority_hash with the PDP’s own pdp_policy_version. Neither anchor rides on the mission claim, so a PDP records intent_hash only where it has direct Mission-record access. Execution Evidence is emitted by the PEP after the outcome is known, linked by evaluation_id, recording whether the permitted action completed, failed, or was suppressed. The Refusal Record covers a refusal that happens before any PDP decision. Decision (and refusal) evidence is required for every consequential action. The matching Execution Evidence record is a MUST for the high-consequence classes, where it is the basis for one-to-one reconciliation against the permit, and for any duration-metered action, where its measured_duration settles the reservation. Decision Evidence is not proof an action occurred. An auditor must treat orphaned Decision Evidence (a permit with no matching Execution Evidence inside the deployment’s published reconciliation window) as undetermined-outcome or, per deployment policy, as action-attempted, and never as proof of action.
• Carrying denials in an AuthZEN decision. A runtime denial is a successful evaluation, so it is decision: false with a context.reason (out_of_authority, mission_inactive, stale_state, parameter_violation, quota_exceeded, duplicate_suppressed, and the rest), not a transport error, and Decision Evidence records the same value as its denial_reason. The set is extensible by specification, and a consumer treats any value it does not recognize as a deny: capability_drift is one such extension, registered by Mission Capability Binding. A denial can carry a next_action of retry, request, or none. An out_of_authority or approval_required denial MAY be marked requestable with a context.access_request, composing with the AuthZEN working group’s Access Request and Approval Profile (ARAP) so the agent can start narrow and request the authority it discovers it needs. If granted durably, that becomes a Mission Expansion (Mission Lifecycle and Change). A tool or resource an agent discovers mid-task thus arrives as a requestable denial, the start of the discovery loop rather than the end of the task.

The lethal trifecta at execution time

The handbook treats the agent lethal trifecta (private-data access, untrusted-content ingestion, and external-write authority in one loop) as a first-order design constraint, and this section is its canonical treatment at the wire (Splitting the Lethal Trifecta, in the fourth chapter, carries the whole story against the threat model in one place). The governance layers give the common object: the approved task, its bounds, its derivation gate, its audit binding. That is necessary but not sufficient. The runtime layer is what keeps the bundle split at execution time: private reads, untrusted inputs, and external writes stay separately typed, separately evaluated, and separately auditable under the same canonical Mission.

The defense against the dangerous leg (exfiltration) is architectural, not a claim that the agent is injection-proof. External communication is a consequential action, so every attempt is checked against the Authority Set, bound to parameters, metered, and (under mediated custody) made unreachable to an agent that does not hold the egress credential. The injected agent cannot widen the authority the gate checks against.

The profile names two limits. First, the defense is exactly as strong as PEP-placement completeness. Every channel an agent runtime offers (DNS, logs, error strings, a write another process reads) must be mediated, and the profile gates the channels routed through a PEP but cannot prove a deployment enumerated them all. Second, it provides no information-flow control. Each action is evaluated in isolation, so a sequence of individually-authorized steps can compose into an exfiltration no single check catches. A coarse session-level mitigation (downgrading egress authority once untrusted content has entered a session) lives at the harness layer, and raises the bar without being information-flow control. The profile names the composite as a claim: trifecta containment holds only when least exposure is applied, the harness taint rule is enforced rather than advisory (under its default-taint polarity, a parameter in a tainted session that cannot be affirmatively traced to a trusted source stays tainted, so paraphrase sheds nothing), and the external-communication and external-commitment actions are fully mediated, with the egress channels enumerated. Like the agent-compromise claim, it requires execution-environment attestation of the Enforcement Scope Statement. Where the decision binding carries taint context, the PDP enforces the rule and fails closed when the context is missing. The generalization of that discipline, bounding what the agent may see as deliberately as what it may do, is Least Exposure Is Broader Than Least Privilege.

The same discipline applies to the structural-versus-semantic line. Everything this profile enforces is structural: typed actions, bound parameters, metered consumption, current state. None of it can judge whether an in-bounds email body leaks intellectual property. A deployment that wants semantic evaluation in the loop has a place to put it: the decision contract’s context carries deployment-defined inputs, so DLP verdicts, content classifications, or an LLM judge’s assessment of whether an action’s content fits the Mission can ride into the PDP alongside the structural checks. The profile fixes how one composes: the verdict enters the decision as Resource policy and only ever narrows, and its rubric is the recorded Mission Intent, verifiable against intent_hash, not a free-floating policy. The bill is real: content evaluation runs per action, and a judge model reading attacker-influenced content is itself a prompt-injection surface. The structural floor is what the profile can promise deterministically. Semantic controls layer above it at the deployment’s option, raise the bar, and inherit none of its determinism, which is why the classes where content is the harm belong under action-bound approval rather than under a smarter policy engine.

One tension in that assignment deserves its own paragraph, because two of this handbook’s commitments collide on it. For an agent whose primary job is external communication, routing the content-harm classes through action-bound approval degenerates to human-per-send, the exact posture the fatigue budget rejects as a security boundary. What the model actually offers that agent is narrower structure, not more approvals: recipients and destinations bound at admission so the structural check carries the volume, the taint downgrade for the sessions that touched untrusted content, content verdicts composing as narrowing inputs, and action-bound approval spent only where content is the harm and the volume is low. One caveat rides with the recipient bound: an entry naming audit-committee binds the group’s identity, not its membership, and membership is state another system owns. A deployment that pins enumerated recipients at derivation for its high-consequence classes buys the bound it thinks it has. One that resolves the group at send time should say so in its enforcement-scope statement, because the residual is real.

Why this is the center of gravity

Read the handbook and you will find more posts about the governance envelope than about runtime. That is not a statement of priority. The governance envelope projects onto many wire surfaces (issuance, consent evidence, status, signals, expansion, delegation, audit), so it takes more pages. The runtime contract is comparatively compact: one set of invariants in the runtime core, an OAuth 2.0 profile for its inputs, one decision-API binding, and one family of evidence records. Page count is the wrong axis to read priority from.

For any deployment whose agents make parameter-bound writes, act on bounds finer than the receiving Resource Server enforces, or take external side effects, the runtime layer does the safety work the governance envelope cannot.

Where nothing enforces a Mission’s bounds at the point of use, the Mission is only an audit trail. The other five layers exist to make this one trustworthy, and the next section names what each contributes. Take any one away and the runtime gate gets weaker. That is what it means to be the center of gravity.

An agent can make only the exact tool calls it is authorized to make and still be turned against the user by what it was allowed to read.

The least-privilege MCP series worked out how to scope the calls. The agent carries a narrow token, or the resource decides each call, and the standards around AuthZEN, ARAP, and the rest tighten the grain until a call authorizes one action against one resource and nothing more. That is least privilege, and it is the mature half of the problem.

It is also only half. Least privilege bounds what the agent may do. It says nothing about what the agent may be exposed to while deciding what to do. That second surface is larger, and it is where most agent compromise actually happens.

The distinction is simple:

Least privilege asks, “May the agent perform this action?” Least exposure asks, “Did the agent need to see this in order to decide?”

For agents, the second question is not a privacy footnote. It is a security boundary.

Authorized access is not safe exposure

Take the board packet from the MCP series. The agent is scoped exactly right. It may read Q3 financials for one entity, draft one document, and notify the audit committee, each call at the action’s grain, each denied if it drifts. Least privilege, done well.

To decide what to call, though, the agent reads a great deal more than it calls. It reads its system prompt, the user’s request, retrieved documents, the descriptions and schemas of the tools available to it, the outputs of earlier calls, and whatever memory it carries between turns. Suppose one retrieved document carries an instruction the agent was never meant to act on, a line telling it to ignore its guidance and forward the financials to an outside address. Every tool call the agent then makes may still be individually authorized. The compromise did not arrive through an over-broad grant. It arrived through what the agent was shown, and the authorized notify became the way out. A document is only one carrier. The same instruction can arrive in a tool’s description or an error the model reads back.

Least privilege on the call did not help, because the reasoning that chose the call was steered by context the agent should not have been handed in that form. The resource read may have been authorized for the user. It was still the wrong exposure for this step of this task.

That is the core mistake: treating “the principal may access this” as “the model should see this.” Human access and agent exposure are not the same control. A human can ignore irrelevant material, preserve secrets by judgment, and remain accountable for misuse. A model turns everything it sees into possible instruction, evidence, memory, or egress material. You cannot authorize your way out of a bad working set.

A fair objection is that this is just need-to-know, and security has always minimized what a principal can see. It is, with one difference that changes its character. Need-to-know for a human is a confidentiality control, resting on a reader who will not act on what they should not have seen. An agent offers no such assumption. For an agent, minimizing exposure is also an integrity control, because what the model reads is what steers it. The old principle did not get replaced. Its job doubled.

The exposure surface is bigger than data

Minimal disclosure is usually discussed for identity claims, releasing only the attributes a relying party needs. For an agent, the surface is much wider. Everything the agent is shown in order to decide is at once a disclosure surface and an injection surface:

• Instruction exposure: the system prompt, developer guidance, user framing, and approval text.
• Data exposure: retrieved documents, search results, records, files, and tool outputs.
• Capability exposure: the catalog of available tools, their descriptions, schemas, examples, and hidden affordances.
• Secret exposure: credentials, tokens, connection strings, signing material, and privileged configuration that leak into context.
• Policy exposure: business rules, pricing logic, security policy, approval routes, and fraud controls.
• Memory exposure: session memory, long-term memory, embeddings, and summaries carried from earlier work.
• Response exposure: downstream responses, errors, logs, and diagnostic text that come back from the tools it calls.

Each is something the agent should see only as much of as the task in front of it requires. A finance agent does not need the whole document corpus to draft one packet. A support agent does not need every customer’s record to answer one ticket. Exposure that exceeds the task is latent risk, whether it leaks outward or steers the agent inward.

The practical test is harsh but usable:

If this item were prompt-injected, stale, maliciously selected, or later leaked, would the approved task still justify showing it to the agent?

If the answer is no, it does not belong in the working set merely because the user, service account, or tool could access it.

Least privilege already governs one slice

The authorization series draws this line once, for exactly one surface. Filtering tools/list is exposure control, not authorization. Narrowing the catalog an agent can see is worth doing, but it does not decide any call, and the server must still authorize every tools/call. That distinction is least exposure applied to a single surface, the tool catalog.

The move is to generalize it. The tool catalog is one of many things the agent is shown, and the same discipline applies to all of them. Scope the retrieval. Scope the memory. Scope the schemas, the secrets, and the policy text. Show the agent the smallest slice of each that the task justifies, for the same reason the deployment filters the catalog.

That gives a clean rule for system design:

Treat every context source as an exposure point with its own PEP.

The retrieval layer decides which records enter context. The tool host decides which tools and schemas are visible. The memory store decides which past state is eligible. The secret broker decides what never enters context at all. The harness decides what survives across a resume. The egress boundary decides what leaves. A single broad prompt assembly step that grabs everything the principal can reach is the context equivalent of handing the agent a root token.

Untrusted reasoning makes exposure the attack surface

The series is explicit that the model is untrusted reasoning that proposes actions, and that the protocol layer’s job is to govern the invocation, not the reasoning. That framing has a corollary it does not draw out. If the reasoning is untrusted, everything the reasoning is shown can steer it. Exposure is not a privacy nicety layered on top. It is the attack surface itself.

Name the stance underneath, because it is the one the Mission Shaping series set as the operating goal: survivable incorrectness. No system can make the model’s reasoning correct, so the system stays governable when the reasoning is wrong, and that discipline has two arms. The action arm is the authorization half this essay began with, matured into the laws and the runtime gate: a steered agent cannot reach past what was approved. The input arm is this essay’s subject: a wrong model can only be steered by what it was shown and can only leak what it was handed. Not-shown is the input arm’s fail-closed.

Simon Willison’s lethal trifecta names the dangerous combination in one loop: access to private data, exposure to untrusted content, and a way to send data out. Least privilege narrows the permissions on those legs: which data may be read, which tools may run, which egress paths may be used. Least exposure narrows what actually reaches the model: which private data enters the working set, which untrusted content can influence the session, which tool descriptions and responses become part of the reasoning context. Cutting one leg is not safety. An agent with a tiny set of authorized calls is still dangerous if it holds the crown jewels and reads the open web in the same loop.

Exposure, not detection, is therefore the control to lean on. There is no general way to tell whether a retrieved document or a tool description carries an instruction the model will follow, and sanitizing untrusted content is best-effort that injection keeps routing around. What a system can decide deterministically is whether the model is shown the material at all. Not-shown is a guarantee that does not depend on catching the attack first.

This is also why “we log every action” is not enough. Logs tell you which calls happened. They rarely tell you which sentence, retrieval result, memory, or tool description shaped the action. If the exposure path is not governed and recorded, the audit trail starts too late: at the call, after the model has already been steered.

The Mission bounds both

The least-privilege series ends on a missing object. Nothing names the task the calls serve, so no layer can decide whether a given call is still inside the work the user approved. Exposure has the same gap, from the same cause. Nothing scopes what the agent is shown to the task it was approved for, so it is shown whatever its principal happens to have standing access to.

One object closes both. A Mission, the durable record of the approved task the MCP series points toward, is a budget for authority and for disclosure at once. A Mission bounds not only what the agent may do, but what the agent may be exposed to while deciding what to do. Retrieval scoped to the Mission does not surface the acquisition memo that has nothing to do with the board packet. A catalog scoped to the Mission does not offer the external-email tool for a task that only reads and drafts. Memory scoped to the Mission does not import last quarter’s unrelated investigation. A secret scoped to the Mission is used by a broker or PEP, not copied into the prompt.

Context reaches the agent because the approved purpose justifies it, not because the user behind the agent could have opened it by hand.

The enforcement pattern is the same one the Mission work uses for authority, a mediated custody in which the runtime, not the agent, holds what the task needs and releases only what the current step justifies. The agent is handed a working set, not the keys to everything its principal can reach. Least privilege makes the calls narrow. This makes the context narrow. Both are the Mission doing its job. (The runtime enforcement profile now names this normatively. Least exposure is a SHOULD for any Mission-aware runtime and harness. Under the profile’s trifecta-containment claim it becomes a MUST, alongside two other legs: an enforced default-taint rule that no paraphrase sheds, which carves out sends to destinations the Approver named at approval, and mediation of the external-communication and external-commitment actions across an enumerated set of egress channels.)

The residual this discipline cannot remove is composition, and it compounds across Missions through anything durable both can touch, each record compliant alone, which is why exposure ceilings on shared stores are ceiling material rather than per-task settings. And on regulated data the pairing stops being optional: there the composition residual is the breach-notification scenario, and the appetite for it is set by statute, not by the deployment.

One honesty note before the checklist. The authorization half of this discipline has wire surfaces behind it, and the exposure half mostly does not yet. What is enforceable today is the edges: egress mediation, the taint rule, catalog filtering as exposure control. Scoping retrieval, memory, and context assembly to the Mission has no interoperable form anywhere in the ecosystem: the drafts make it a SHOULD-level duty of the runtime and the harness, a MUST only under the trifecta-containment claim, and the architecture leaves its interior to deployment discipline that a deployment declares rather than claims. So treat this essay as design guidance for surfaces nobody has standardized, and treat the community list as naming the gap rather than closing it.

The claim should be checkable. A system that says it runs governed agents should be able to answer:

1. What Mission is this context item justified by?
2. Which exposure point admitted it?
3. Was it private data, untrusted content, capability metadata, memory, policy, or a secret?
4. What downstream actions became riskier because the agent saw it?
5. When the Mission ends, what context, memory, cache, or connection is cleared?

If those answers do not exist, the deployment has least-privilege calls wrapped around an ungoverned working set.

Two halves of one discipline

Least privilege and least exposure are two faces of one discipline, minimal disclosure for agents. One narrows the calls the agent can make. The other narrows the inputs to the reasoning that decides which calls to make. The authorization half is mature. It has models, standards, and a clear place to enforce. The exposure half is mostly still left to prompt hygiene and hope, even though it is the larger surface and the one the lethal trifecta actually exploits.

A well-authorized agent fed the wrong context is still a compromised agent. Least privilege is necessary. Least exposure is the broader principle it lives inside, and the same approved task that bounds one should bound the other.

The short version is the one worth carrying into architecture reviews:

Do not only ask what the agent can call. Ask what the agent can see before it chooses the call.

The Mission Is the Missing Abstraction defined the Mission as a durable governance object and gave it a deliberately small lifecycle: active, revoked, expired, with the rule that only active permits new derivation. That issuance profile is complete on its own. But it observes Mission state only through one channel: the lifetime of the tokens it already issued, plus optional token introspection. A consumer that holds a Mission-bound token and nothing else has no way to ask “is this Mission still good,” and no way to be told that it stopped being good. An authorized operator who wants to pause a Mission has no standardized verb for it. A task that finishes keeps deriving its authority until a clock or a revoke stops it.

This part closes those gaps with the lifecycle suite: optional capabilities layering on the issuance profile without changing it, with Status as the suite’s root (it carries the status surface and the lifecycle endpoint) and the Status List, Signals, Entry Discharge, and Management as its satellites. All of them are proposed individual drafts, and they sit at different points in the handbook’s adoption guidance. Status carries the Runtime-Enforced label: it is that level’s state surface. Signals, its push complement, is OPTIONAL and Advanced, aligned with the Shared Signals transmitter and receiver model. Expansion and Entry Discharge are Advanced, to adopt when the use case arrives, and each has a newer companion noted where it attaches (Progressive Authorization and fleet Management). They answer four questions a long-running task forces:

• Observe: how does a consumer holding only a mission_id learn the current state, and learn it promptly when it changes?
• Revoke: how does an authorized party change the state (terminate, pause, resume)?
• Grow: what happens when the task legitimately needs more authority than was approved?
• Complete: how does authority retire itself safely as the work it was granted for finishes?

The unifying move is the one the handbook framing names as a recurring rule. Only active permits reliance. Every state these profiles add (suspended, completed, superseded) is treated as non-active by any consumer, including one that has never heard of it. That is what lets the lifecycle grow new states without breaking the consumers that predate them. We return to it at the end, because it is the property that makes all four verbs safe.

Observe and revoke: pull and push

The canonical statement first, because every mechanism in this part serves it. Revocation changes the Mission’s authoritative state immediately. Enforcement latency is path-dependent: runtime-gated actions stop within the published freshness bound, new derivation stops when the issuer observes state, and outstanding offline-valid tokens run to expiry unless the path checks Mission state.

The kill switch from The Mission Is the Missing Abstraction is possession-independent. Revoke the Mission at the Authorization Server and no new authority derives for the task. But “no new derivation” only bites at the next derivation event. A Resource Server holding a live access token does not consult the Authorization Server on every call by default. It trusts the token until it expires. So the kill switch is only as fast as the slowest token’s remaining lifetime, unless consumers can learn the current state out of band.

There are exactly two ways to learn current state: ask for it, or be told. The suite provides both.

Status: the pull side

Mission Status and Lifecycle defines the canonical state surface the issuance profile deferred: an operation keyed by mission_id alone. Token introspection answers “is this token’s authorization still good.” The Status operation answers a different question, “what is the state of this Mission,” and answers it for any consumer holding a mission_id, including an auditor or a cross-domain Resource Server that holds no token the Authorization Server issued. The consumer resolves the endpoint from the credential’s mission.issuer and asks.

The answer is signed. A Status response is a JWS, with its own media type (application/mission-status-response+jwt), carrying the mission object (id, issuer, state, the Mission’s expires_at, and a REQUIRED state version, with authority_hash disclosed only to a caller the issuer authorizes for audit or correlation) plus, when the requester names an audience, the audience-scoped Authority Set entries relevant to it. An auditor may omit the audience and get a state-only response with no authorization_details. It is bound to the request by an echoed nonce, to the requester by aud and sub, and to a freshness window by fresh_until, which tells the consumer how long it may cache the reported state before re-checking. The signing matters because the response often outlives the call. An auditor must be able to verify, later, that the issuer really reported revoked at a given moment.

Two design choices in Status are worth pulling out because they are easy to get wrong:

• A mission_id is never a bearer capability. The endpoint authenticates the requester and authorizes it for the specific mission_id and audience. An unknown Mission and a known-but-unauthorized one return indistinguishable responses, so the Status surface cannot be turned into an enumeration oracle for the Mission space.
• The dedicated operation is not RFC 9701. Signed token introspection (RFC 9701) is scoped to token introspection and does not apply to a lookup keyed by mission_id. There is a separate, thinner story for the token-scoped case. The issuance profile’s introspection projection carries the mission state, and this Status profile adds the option of returning that projection as an RFC 9701-signed response. Two surfaces, two signing stories, deliberately not conflated.

Status is also where the explicit lifecycle endpoint lives (the verbs that change state). A management endpoint, distinct from RFC 7009 token revocation, accepts authenticated revoke, suspend, resume, and complete operations and introduces two states the issuance profile did not have:

• suspended: a non-terminal pause. A suspended Mission derives no tokens, but it can be resumed to active. This is the “stop, but don’t tear down” state an operator wants when something looks wrong but is not yet known to be malicious. A suspend may carry a deadline, suspend_until, with an on_expiry of resume or revoke that the issuer applies when the deadline passes, without a further request.
• completed: a terminal state recording that the task finished successfully.

The legal transitions are narrow on purpose: suspend only from active, resume only from suspended, revoke from either, complete from active or suspended (completion is a monotonic narrowing to a terminal state and needs no derivation window, so a suspended Mission need not be resumed first). One rule adjudicates every request: an operation whose resulting state equals the Mission’s current state is an idempotent success, terminal or not, and any other operation against a state it is not legal from is a conflict, not a silent no-op. The endpoint refuses it rather than pretending it worked. resume is the one exception to the idempotent arm: active is also the state a never-suspended Mission holds, so resume against an active Mission is a conflict. A caller deciding over state it may not have refreshed can also send expected_version, the state version it last observed, and the endpoint refuses with stale_version when the Mission has moved on, so a console that has not yet seen a newer resume cannot re-suspend the Mission. The endpoint authorizes operations against deployment policy (typically revoke to the Subject, Approver, or an administrator, and suspend/resume to administrators), and a caller that authenticates with an access token presents a sender-constrained (DPoP- or mTLS-bound) token carrying the mission_lifecycle scope. An unauthorized request gets the same not-found response shape as an unknown Mission, so the management surface is no more of an enumeration oracle than the read surface. Fleet-scale operations are deliberately out of this profile: authenticated Mission enumeration (by subject, client, state, or expiry window) and bulk lifecycle operations with a dry-run-first discipline live in Mission Management, an advanced companion.

Suspension is also priced as an actuator, not only defined as a state. It parks work rather than canceling it, resume re-verifies the facts that admitted the work, and a suspend that destroys days of queued work is a lever responders hesitate to pull and a damage multiplier for whoever games the risk signals into pulling it.

Signals: the push side

Status answers when the consumer asks. But a high-assurance consumer that wants revocation to bite in seconds cannot afford to poll the Status endpoint on every action. That puts the Authorization Server on the hot path of every credential validation. The complement is to be told.

Mission Lifecycle Signals is a profile of the OpenID Shared Signals Framework. When the Mission Issuer commits a lifecycle transition (a revocation, expiry, suspension, completion, or the approval event that activates the Mission), it emits a signed Security Event Token, a mission.lifecycle-change event, delivered either by push (the Issuer pushes the SET to the consumer’s receiver) or by poll (the consumer fetches available SETs). A partner Resource Server subscribed to the stream learns of a cancellation seconds after it happens, well inside the remaining lifetime of any token it holds, and stops honoring the Mission.

Scale is its own consumer. A fleet of enforcement points watching thousands of Missions cannot poll them one by one, and the Mission Status List, its own Advanced companion, is the swarm answer: the Issuer publishes one signed, TTL-bounded bit array covering many Missions, riding the OAuth Status List work now in the RFC Editor queue. Each Mission holds a two-bit value. VALID (0x00) reports active and is the only value that permits reliance; SUSPENDED (0x02) and INVALID (0x01, every terminal state) are non-active, as is any other value, and a consumer that reads anything but VALID re-establishes state at Status before relying again. The list’s TTL is the published staleness bound, and index assignment preserves the anti-oracle property, so holding the list does not let a consumer enumerate the estate’s Missions. One fetch refreshes a fleet.

One maturity note. Signals is a proposed OPTIONAL profile requesting the Standards Track, aligned with the Shared Signals transmitter and receiver model, and its Security Event Token and delivery dependencies are published RFCs. The handbook labels it Advanced, which means adopt it when the use case arrives. Push is a latency optimization over correctly sized status polling, so the default path remains Status sized to the risk, with Signals adopted where a revocation must bite in seconds.

The event carries the new state, the prior_state (except on the initial approval emission, where there is none), the Mission’s own expires_at (so an event-only consumer can fail safe on expiry), and a strictly monotonic per-Mission version counter, the same state version Status reports. An event can also report a narrowing that changes no state: authority_changed is true when an entry discharge or a containment shrinks the Mission’s Effective Authority Set while it stays active, and because the event says nothing about what changed, the consumer re-reads Status. The counter is the part that makes event delivery safe against the network. Events can arrive out of order or be replayed, so the consumer applies a transition only if its version is greater than the last it applied. A stale active event for an older version cannot revive a Mission a newer revoked event already retired. And because delivery is best-effort, a consumer that cannot verify its stream, or that was down and may have missed events, treats its cached state as stale once it exceeds the Issuer’s advertised staleness bound and falls back to polling Status. A missed event is a freshness failure, never “still active.” Signals make revocation prompt. They never make it fail open.

Pull and push are not alternatives so much as two sizes of the same answer. A consumer that checks state occasionally polls Status. A consumer that needs prompt revocation subscribes to Signals and falls back to Status when the stream goes quiet. Both read the same fact, the current state, from the same authoritative issuer.

Both surfaces assume the issuer’s own record is consistent. Mission Control-Plane Consistency, an Advanced companion that defines no endpoint or wire member, makes that testable across replication, partition, and recovery: one serialization order per Mission, no freshness manufactured by re-signing an older observation, no lower state version after a restore, and every committed transition published through durable, repairable fan-out.

The running example. Take the handbook’s running example, the Prepare the Q3 board packet Mission, msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p at as.example.com. At 23:00 the board meeting is cancelled while the agent’s final pass on the packet is still queued, so an admin revokes the Mission at the lifecycle endpoint. A consumer holding only the mission_id (the docs Resource Server, an auditor) learns the new state without holding any token the Issuer can age out. It either asks Mission Status (pull) or receives a mission.lifecycle-change Signal carrying state: revoked (push). Either way the result is the same. query_financials, create_doc, and notify_reviewer all stop deriving at once.

This is the kill switch at the moment of use, everything this section defines on one surface, stated as maximum bounds rather than guarantees: seconds for mediated paths, token lifetime for issuance-gated ones:

Two details worth noticing because they are the spec, not decoration: completed effects are flagged for unwind rather than rolled back, and the test button is the acceptance test made one click: revoke, then watch the next consequential action fail closed.

Between suspension and revocation the family now defines a third, experimental channel: Mission Containment, narrowing a live Mission without ending it. When a declared protected event fires (a tainted read, an anomaly signal, or, from open-world discovery, a routed_to_approval outcome or a tainted Discovery Evidence record), the issuer commits a versioned, removal-only overlay that subtracts capability from the Mission’s Effective Authority Set (the approved set after every issuer-held narrowing, as the Status profile defines it) while the Mission stays active and the approved anchors stay immutable. A derivation that asks only for contained capability fails closed as authority_contained, and removed authority returns only as a fresh approval, a successor under Expansion. Suspension pauses everything and containment removes something: the undertaking keeps running on the authority that was never in question.

Grow: expansion creates a successor

The first recurring rule of the handbook is that authority can only narrow. A derived or delegated token never carries more than the Mission. The subset rule enforces it at every derivation. That is a foundational safety property, but it raises an obvious question. What happens when the task legitimately needs to do something the approved Authority Set does not cover? Mid-task, the Prepare the Q3 board packet agent decides it could enrich the packet by reading CRM customer data, an authority the Approver never granted, outside the Mission’s query_financials/create_doc/notify_reviewer set entirely.

The answer is not to widen the Mission in place. A Mission’s authority is committed at one approval event by authority_hash. Widening it in place would mean the thing the user approved is no longer the thing in force, and authority_hash would no longer commit what is being used. Mission Expansion instead routes growth through a new approval that creates a successor Mission.

An expansion is an RFC 8693 token exchange at the token endpoint that carries the successor’s Mission Intent in mission_intent and leads to a fresh approval event. The subject_token is the predecessor’s own sender-constrained Mission-bound access token, and the client proves possession of that token’s confirmation key, so the Issuer adjudicates a successor of a specific predecessor rather than an unrelated new Mission, and no client can put an expansion in front of an Approver merely by naming another Mission’s identifier. A refresh token is never accepted as the subject_token. The possession proof is an eligibility rule, not an authority path. A deployment that issues only bearer tokens for a Mission forgoes this expansion and reaches succession through a fresh approval that references the continued work, and the management plane’s standing over the predecessor never depends on the possession proof: the proof gates the proposal channel and the supersession trigger, never the authority. The fresh consent is what supplies the broader authority. The successor’s authority comes only from its own approval. Its authority_hash commits exactly the set the Approver saw, never the predecessor’s plus a computed delta. On the successor’s activation, the predecessor transitions atomically to a terminal superseded state and derives nothing further, because two active records for one undertaking are a widening wearing a lifecycle. Supersession is a terminal exit, so it cascades to the predecessor’s live Child Missions: the expansion’s consent disclosure should show how many it will end, and a child still needed is re-created under the successor. The successor carries a predecessor lineage member linking it back, but that member is audit context only. Like every other extra member on the mission claim, it MUST NOT grant or widen authority.

The ask, as the user meets it:

One note on the mock’s compression: in the family’s semantics, approving this ask does not edit the running Mission. It lands as a fresh approval over a successor’s full derived authority, with the predecessor superseded and lineage kept.

Two distinctions keep expansion honest:

• Expansion is not step-up. A request denied because authentication is too weak (an acr/amr shortfall) is satisfied by re-authentication. The Authority Set does not change. A request denied because the authority is not in the active Mission is what expansion addresses. Routing an authentication shortfall through an approval event would surface irrelevant consent and breed approval fatigue. Treating an authority shortfall as a mere re-auth would silently widen nothing. The two are not interchangeable.
• Expansion is a governance operation, not a runtime escalation. It does not undo the subset rule. It is a deliberately heavier, consent-backed path that produces a new governed object the kill switch and audit chain still cover.

For open-ended tasks where stopping the user at every step is impractical, a newer, experimental companion, Mission Progressive Authorization, builds on expansion. At the initial approval the Approver may also consent to an authority ceiling and a drawdown policy, so in-ceiling expansions can be adjudicated by policy rather than a fresh human prompt. The ceiling is broad by construction (it has to cover the open-ended task), but what stays narrow is the active authority any single Mission in the chain yields. Each successor is derived for what is actually needed at that step, independently gated and revocable. The guard is explicit. A drawdown that would grant an irreversible action, an external commitment, privileged administration, external communication (the exfiltration leg), or cross-domain authority always requires fresh human approval, even within the ceiling. So does any drawdown while the predecessor has live Child Missions, because only a human approval can witness the cascade, and any drawdown that overlaps authority an entry discharge or a containment removed from the chain: policy never restores removed authority. Progressive authorization bounds standing-authority exposure. It does not eliminate it, and it is meant to be paired with short successor lifetimes and runtime enforcement.

The running example. The Prepare the Q3 board packet Mission, msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p at as.example.com, cannot read CRM customer data. That authority is outside its Authority Set, and the agent cannot widen the Mission in place. So it requests an expansion: a token exchange that presents the predecessor’s sender-constrained access token and asks for a fresh approval of a successor Mission. The Approver declines. CRM access is out of policy for board-packet preparation. The result is the failsafe one. No CRM access, no successor activates, and the predecessor is untouched and still active, deriving exactly its original three entries. Had the expansion instead been approved, the successor would have activated and the predecessor would have transitioned atomically to superseded, and supersession need not cost the runtime: a harness may rebind running sessions to the successor under freshly derived credentials, so the work continues under the new authority without a restart. Because it was declined, nothing supersedes anything.

Complete: discharge narrows one entry at a time

Expansion is governed growth. Completion is its narrowing counterpart. It is the more important of the two for everyday safety, because the common case is not a task that needs more authority but a task that is done with some of the authority it has. Like Expansion, it is Advanced in the handbook’s adoption guidance, to adopt when the use case arrives, with expires_at, revocation, and the complete verb as the simpler path until then. Its draft also says it is less exercised than issuance and runtime enforcement and that its details may change.

The issuance profile’s Mission Intent can carry success_criteria: a description of when the task is complete. In the issuance profile those criteria are inert (rendered to the Approver, committed to the record, carrying no machine effect). A Mission granted authority to post journal entries “until the Q3 close is finalized” keeps deriving that authority after the close, until a clock or a revoke intervenes. Mission Entry Discharge supplies the enforceable counterpart. It registers terminal_when, an entry-level completion condition carried in a mission_resource_access entry’s constraints, and a discharge operation on the Status lifecycle endpoint that commits a condition’s firing. When the Authorization Server commits a discharge, the entry is discharged: the AS stops deriving any token carrying it, exactly as it refuses derivation for a non-active Mission. The firing is asserted by a resource or event authority, not by whoever may revoke the Mission. A discharge call needs its own mission_discharge scope or an equivalent grant, the AS checks the caller against the authority published for that event type or named by the condition’s discharge_authority, and neither the mission_lifecycle scope nor being the Subject, Approver, or an administrator implies that authority.

The crucial scope detail is that discharge gates at the entry, not the Mission. A multi-resource Mission completes one entry at a time. In the running example, suppose the board meeting is not cancelled and the work finishes instead. The Prepare the Q3 board packet Mission has a query_financials read entry, a create_doc write entry, and a notify_reviewer send entry, the write and send entries each bounded terminal_when their step is done (create_doc once the packet is published, notify_reviewer once the audit committee is told). As each condition fires and the system that observed it (the document system for the publication, the workflow system for the notice) commits it through discharge, the Authorization Server stops deriving that entry (a refresh returns a token carrying only what remains) while the Mission stays active so any remaining entry keeps working. Each authority retired itself once its task completed and the event was reported. No revoke, no clock.

This is distinct from the complete lifecycle verb of the Status profile, and the two should not be blurred. complete is a Mission-level terminal transition to the completed state, driven by an authorized party at the lifecycle endpoint. terminal_when discharge is entry-level. The Mission stays active and keeps deriving its other entries. A deployment that tracks Mission-level completion may move a Mission to completed through that complete operation once all its entries are discharged, but Entry Discharge does not require it. One is “the whole task is finished.” The other is “this part of the authority is spent.”

What makes entry-level discharge safe to expose to an adversarial agent is that it is monotonic. Discharge can only remove an entry’s authority. It can never widen the entry or the Mission, and a committed discharge never reverts: the restriction carries to every successor in the expansion chain, and the retired authority returns only through a fresh human approval that discloses the discharged entry and its condition. So a prompt-injected agent has nothing to gain from it. The worst a forced discharge does is retire authority sooner, which is not an escalation but is a denial of service on the task, and discharge authority is what limits who can force one. Monotonicity is also why discharge composes cleanly with the subset rule: a derived entry carries its parent’s conditions unchanged and may only add more, making it discharge sooner.

Discharge is not fail-closed on the event itself. A discharge takes effect when the Authorization Server commits it, and until then the AS keeps issuing against the entry. A lost or delayed notification is therefore a temporary widening relative to the real-world event, bounded by authenticated at-least-once delivery to an idempotent acknowledgement, by monitoring and reconciliation, and by the Mission’s and its tokens’ own lifetimes. A deployment that needs no issuance while it cannot determine whether a condition fired runs a synchronous status or policy check outside the draft’s baseline. A token issued before the commit stays valid until it expires, unless the consumer checks Mission Status or introspection, which omit the discharged entry, or the runtime layer refuses it at the point of use as authority_discharged.

When the agent changes, not the Mission

One more change surface sits beside the Mission’s own lifecycle, because three objects govern an agent estate and this part’s verbs cover only one of them. The agent’s Agent Deployment, its approved behavioral version (code, model, system prompt, tool allowlist, data scope, runtime configuration), changes on its own cadence and is owned by change governance rather than by the Mission Issuer. Two rules keep the seam honest.

First, which changes require re-approving standing Missions is policy, and it is policy that change governance records rather than a default the platform assumes. A prompt hotfix may be routine. A new model or a widened tool allowlist changes what the Approver actually approved, and a standing Mission whose agent has materially changed is running on an approval that was given to different behavior.

Second, a Mission can be pinned to a specific approved Agent Deployment without that deployment becoming the Mission. The pin is an architectural pattern today, not a wire member: the OAuth binding defines no mechanism that pins a Mission to a deployment class or version and reserves no Intent member for one (the former controls seam is retired). A future Agent Deployment Binding profile would own it, with a committed approval-context pin and presenter-instance evidence checked at every derivation, and would define its own request carriage, record extension, rendering, and fail-closed behavior. The Agent Deployment stays owned by change governance either way.

The standing agent at scale

One shape of agent looks like a counterexample to this whole part: the agent that never finishes. A support-triage agent works four hundred tickets an hour. A SOC agent watches alerts around the clock. There is no board packet that ends, so what do expiry, completion, and successors even mean for it? A sharper version follows: if the Mission just gets renewed forever, is this not the blank check with a renewal ritual? The card chapter already toured this room: the standing arrangement that keeps billing is the expense world’s version, and its lesson was that continuity machinery must be taught to check whether the arrangement still stands.

The answer is the distinction the machinery in this part exists to make. The agent stands. The authority cycles. The standing thing is a charter, consented once as an authority ceiling with a drawdown policy (Progressive Authorization, experimental for exactly this shape of work). The experimental Mission Template companion is the sibling shape for independent dispatches: where progressive draws successors within one chain, a template instantiates independent Missions from one consented template. The working thing is the Mission each unit of work draws under that ceiling: a ticket, a batch of fifty, an investigation, each adjudicated by policy inside the pre-consented bounds, each carrying its own expiry and entries, each discharging what it used as the unit completes. And nothing high-consequence rides the policy path: the drawdown guard routes the class-guard classes, external communication, and cross-domain authority to a fresh human approval even inside the ceiling.

Run the numbers. Four hundred tickets an hour is four hundred small Missions, or forty batch Missions, whose approvals are policy decisions at machine speed. What humans decide is the handful of exceptions a day where the guard fires, and the one decision that matters: the ceiling itself, set and renewed on a governance cadence with the previous cycle’s evidence in front of the reviewer. The human approval load is not four hundred an hour. It is the ceiling review plus the exceptions, which is the fatigue budget spent where it buys safety. The machine load scales the same way: four hundred Missions an hour is also four hundred freshness checks, and the Status List answers them in one fetch. The records have their own bill: four hundred Missions an hour is also four hundred evidence trails, so the ceiling review sets a retention class beside the authority, with completed Missions’ evidence aggregated or aged out on a stated horizon and the minimization rules deciding what each trail carried in the first place.

And the failure mode is named, because a standing charter can decay into exactly what this handbook exists to retire. The tells are checkable: renewals that never narrow, ceilings that only grow, exception approvals trending toward zero because the guard was quietly widened, and discharge that never fires because nothing is scoped tightly enough to complete. The mechanism that forces narrowing is the renewal default: a ceiling renews at the envelope its evidence shows was used, not at its prior breadth, and anything wider is a new approval, not a rollover. A ceiling whose renewals carry no evidence review is a blank check with a calendar. The machinery makes the standing agent governable. Only the governance cadence makes it governed.

The accountable principal has a lifecycle too, and it arrives from the identity provider rather than being assumed. Authority that outlives its approver is one of the oldest failures in the stack, and this layer must not recreate that orphan debt in its own system of record. A leaver event moves the person’s ceilings into a state that admits no new Missions and starts an ownership-transfer clock, running Missions transfer or run out under policy, and a ceiling whose accountable principal no longer exists is a finding, not a curiosity. Signals carry Mission state out to consumers. The same rail carries principal state in.

The rule that makes it safe

The four verbs add three new states to the lifecycle The Mission Is the Missing Abstraction began with. The state diagram now looks like this:

A growing state machine is a liability if every consumer must be upgraded in lockstep to recognize each new state. The Mission lifecycle avoids that with the rule the handbook framing states as one of its two invariants, and which the Reference’s lifecycle-states section records for the issuance profile:

Only active permits reliance. A consumer treats every other value, recognized or not, as non-active.

This is why the new states fail safe. A Resource Server that predates the Status profile has never heard of suspended. When it sees one (in a Status response, in an introspection projection, in a Signals event), it does not need to understand it. It only needs to observe that the value is not active, and refuse. A consumer that predates Expansion treats superseded the same way. The forward-compatibility rule turns “I don’t recognize this state” into “this Mission is not live,” which is precisely the safe interpretation. New lifecycle states therefore extend the system without a flag day.

The one place this “ignore what you don’t recognize” instinct flips is Entry Discharge’s terminal_when, and the difference is worth being precise about. A new state value is safe to ignore because an unrecognized state is treated as non-active. Ignoring it fails closed. But terminal_when is a member, not a state, and it is mandatory to understand. It is essential narrowing a consumer cannot infer from the rest of the entry, so ignoring it would let a discharged entry keep being narrowed, projected, or enforced, failing open. A consumer that does not recognize terminal_when therefore MUST fail closed for that entry. It MUST NOT narrow, delegate, audience-project, or rely on it. Unknown state value, treat as non-active. Unknown terminal_when, refuse the entry. Both resolve toward less authority, by opposite handling.

The same instinct runs through Status, the Status List, Signals, Expansion, and Containment: uncertainty resolves toward less authority. That is the through-line. Entry Discharge keeps it for an unrecognized terminal_when but not for the event itself, because a discharge the Authorization Server has not yet committed leaves the entry live, as the complete section prices. The Mission Is the Missing Abstraction made revocation possession-independent. This part makes the current state itself a first-class surface (observable by pull and push, changeable by authorized parties, growable only through fresh approval, and shrinkable safely as work finishes) without ever giving a consumer a way to read uncertain state as permission.

The layers before this one build the Mission as a governance object. It is approved with integrity (From a Request to an Approved Mission), bound to instances and delegated under a strict subset (Mission-Bound Authority), enforced per action (Mission-Bound Runtime Enforcement), and observed and revoked over its lifecycle (Mission Lifecycle and Change). Each of those guarantees is stated as a contract the Authorization Server, a Policy Decision Point, or a token holder upholds.

A running agent does not honor contracts for free. It is a harness that checkpoints state and resumes after restarts, an orchestrator that sequences many steps over hours, and a producer of signed records that, on their own, only its own auditor can fully trust. Each of those is a place where a stated guarantee can quietly stop holding: the session resumes after the Mission was revoked, the workflow is halfway through a wire transfer when the Mission is suspended, and a signed log can be backdated by whoever holds the signing key.

This part specifies the operational layer that closes those three gaps. It does not introduce a new authority object. It makes the existing one survive a real, long-running, multi-step, possibly-compromised agent. Three drafts answer three questions:

• Sessions are not authority. When an agent recovers a session, what stops it from acting on authority that has since been revoked?
• Unwinding work in flight. A Mission can stop after some steps committed and before others run. What happens to the work already moving?
• Evidence anyone can verify. The suite produces signed evidence at every step, but signed is not tamper-evident. How does a party in another trust domain confirm nothing was dropped or backdated?

All three are OPTIONAL companions to the issuance profile, at different maturity, and optional at the protocol layer does not mean optional for the assurance a deployment states: the harness belongs to the Governed Agent bundle, and orchestration and audit are required by the claims that use them. Orchestration is a newer, experimental profile the bundle grows into as needed. Audit layers onto any level. Together they are what makes the difference between a Mission that is governable in principle and one that is governed in a system that is actually running.

Sessions are not authority

Session continuity is not authority.

The Mission Is the Missing Abstraction drew the line. A session can prove the runtime survived a restart. It cannot prove the Mission survived. The separate note Sessions Are Not Missions made the argument in full. The harness profile turns it into a requirement.

An agent harness exists to make work durable. It checkpoints conversation and planning state, persists a task graph, queues background jobs, caches tool connections and OAuth tokens, and tracks sub-agent handles, so the agent can survive a process restart, a device handoff, a scheduled wake-up, a retry, or an asynchronous tool response. Every one of those is a continuation point, a moment where the harness resumes work it saved earlier. And every one of them is a moment where the authority that justified the work may have ended while the runtime state that carries it did not. A task graph can survive a revoked Mission. A warm connection to a tool server can outlive the condition that authorized it. A child agent can keep running after its parent Mission is suspended. One continuation is deliberate: when a Mission is superseded by an approved successor, the harness may rebind the running session to the successor rather than restarting, deriving fresh credentials under the successor and discarding the predecessor’s, so governed growth keeps the runtime it already has.

The design move is a single one applied everywhere. The harness binds every governed session and task-graph node to a Mission binding: the Mission’s mission_id and issuer, the authority_hash where a companion profile discloses it to the harness, the last-known state and its source, freshness information (when status was last checked and when that check expires), and, for governed work, a required stop policy. The binding grants nothing. It is the pointer that tells the harness which Mission state it must re-establish before it continues. The rule that follows:

Before resuming governed work, the harness MUST establish that the Mission is active within the deployment’s staleness bound, even when the OAuth credentials in the session are still valid.

It establishes that state through one of the lifecycle surfaces from Mission Lifecycle and Change: a Mission Status query, an event-driven state cache fed by Lifecycle Signals, a runtime PDP decision that itself checks current state, or another deployment-defined source with equivalent freshness semantics. If it cannot establish active state, it does not resume. If the state is anything else (revoked, expired, suspended, completed, superseded, or a state a newer profile added that this harness has never heard of), it stops. That last case matters. The harness inherits the suite’s forward-compatibility rule, treating any state other than active as non-active, so an unknown state fails safe rather than slipping through.

“Stop” is not a single action. The harness picks from four stop behaviors based on the Mission state and the action class:

• suppress: do not dispatch the queued or resumable work. Preserve it for audit or operator review.
• pause: hold the work pending an authorized lifecycle transition such as a resume.
• terminate: end the task graph and release its runtime resources.
• handoff: escalate to a human or governance workflow without taking any further governed action.

A revoked or completed Mission means suppress or terminate. A suspended one means pause or suppress. An unknown or stale state means suppress or pause. For the class-guard classes, handoff or orchestration handling (the next section) is preferred over a blunt stop. And a handoff is not open-ended. The review outcome is approve, reject, or expire, a parked item carries a maximum age, and approved work re-enters the resume algorithm, because review approval is not itself a Mission-state check.

The same discipline extends to the things harnesses quietly reuse. A cached credential or tool connection is not evidence the Mission is still active. Before reusing one for governed work, the harness re-checks the Mission and the action. Connections are keyed by Mission, authority hash, audience, actor, and sender-constraint key, so a connection opened for one Mission never becomes ambient authority for another. (The one sanctioned reuse is a connection that carries no authority at all, where every consequential use is separately authorized under the target Mission.) A warm connection to a tool server is not a permit to call a tool. One execution context serves one Mission at a time for consequential work: an instance may be reused, a context may not, because content read under one Mission steering actions under another is the flow-level residual running inside the model’s window, and where multiplexing is unavoidable it is declared and caps the exposure classes the context may hold. And a sub-agent never inherits authority by descending from a parent session. It gets an explicit child-Mission or delegation binding (Mission-Bound Authority), and when the parent Mission goes non-active the harness propagates the stop to dependent children.

A concrete moment, on the handbook’s running example. An agent preparing the Q3 board packet runs as a long-running overnight job, so its session outlives the user’s attention. At 02:00 it resumes a queued task graph to run the final pass on the packet. The board meeting was cancelled and the Mission revoked at 23:00. The harness re-reads the Mission state from Mission Status before dispatching anything, finds revoked, declines to dispatch, marks the cached docs.example.com connection unusable, and emits evidence:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "event_id": "hrn_7pQ4mN9s",
  "event_type": "resume_suppressed",
  "mission": {
    "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
    "issuer": "https://as.example.com",
    "authority_hash": "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY"
  },
  "session_id": "sess_agent_42",
  "work_item": "final_pass_board_packet",
  "state": "revoked",
  "state_source": "status",
  "decision": "suppress",
  "reason": "mission_not_active",
  "occurred_at": "2026-10-01T02:00:05Z"
}

The session was fully recoverable. The authority that justified it was gone. The harness let the Mission, not the session, decide.

The mediated execution environment

The harness profile carries one requirement that does not look like continuity management but is the structural complement to Mission-Bound Runtime Enforcement. Its high-assurance level puts the sender-constraint key in the enforcement point’s custody, not the agent’s, so a compromised agent cannot act off the enforced path. That guarantee is empty if the agent has an off-path route to the resource in the first place (a debug shell, a direct socket, an unsanctioned egress, a connector that skips the gate). Custody is moot if the agent can reach the resource around the PEP.

Establishing the closed environment is the harness’s job. The draft names this Mission Mediation:

For the action classes a deployment mediates, the harness MUST run governed consequential work in an execution environment whose only path to those actions is through the mediating PEP, and MUST NOT leave an unmediated route to a mediated class.

This is where the harness and the runtime profile meet. The runtime layer holds the key. The harness guarantees there is no door without a lock, and the key must not live behind the same door. A deployment claiming compromise-resistant enforcement isolates the mediating PEP and its key custody from the agent-facing harness components, by process, host, or service separation, because a harness that both faces the agent and holds the sender-constraint key defeats mediated custody the moment it is compromised. The claim is also published, not implied. The harness publishes an execution-environment scope statement naming, for each mediated class, the isolation mechanism that confines governed work, the unmediated paths excluded from the claim, and the secondary egress channel classes the environment offers: DNS, log and error output, shared stores and long-term memory, spawned processes, provider-side model context, the inference API, and rendering surfaces that fetch remote references. Each is marked mediated, excluded by the isolation, or outside the claim, and the full enumeration is mandatory where the deployment claims trifecta containment or compromise-resistant enforcement. Verifying that no unmediated path exists is a deployment audit obligation, not a protocol property. A harness that cannot guarantee a closed environment for an action class MUST NOT represent work in that class as runtime-enforced, the same enforcement-scope honesty the runtime profile requires.

The largest off-path route deserves its own paragraph, because for agents it is not an edge case: the code-execution tool. The moment a Mission grants an interpreter, a shell, or a notebook, the agent can write its own client, and a script-level database call does not pass the API-level PEP on its way out. You do not make generated code safe by reading it, and the answer is not a PDP that inspects the script before it runs, which would be the enforcement-time intent inference this handbook rejects. The answer is what the generated code runs inside. Mediated custody keeps credentials out of the sandbox, so the script holds nothing a database would accept. The harness and the egress proxy own the environment’s exits, so effects leave only through mediated paths. And the execution-environment scope statement declares the sandbox and its exclusions, so the claim is checkable rather than assumed. Sandboxing is the price of the interpreter, the same boundary the OWASP part’s T11 verdict prices, and a deployment unwilling to pay it must exclude code execution from its enforcement scope in writing rather than let the API PEP imply coverage it does not have.

The harness profile adds one more control that no per-action check can: taint tracking. The runtime PDP evaluates each action against the undertaking’s committed state, but each action still arrives as one decision: the PDP never sees the session as a whole, the flow of content between calls. The harness does. Once attacker-influenceable content (a fetched document, a tool result, an inbound message) enters a governed session, the session is tainted. The trigger is parameter provenance where the harness can trace it at the data plane, with session-level taint as the fallback, and before a consequential egress that derives from tainted content the harness should require a fresh action-bound approval or downgrade that authority. This is plan-then-execute. Untrusted content may inform the agent’s planning, but it must not, on its own, drive an egress the user never directed. The polarity is fixed in the tainted direction: in a tainted session, a bound parameter the harness cannot affirmatively trace to a trusted source is treated as tainted, so content the agent paraphrases rather than copies never sheds its taint. Taint also survives a trip through memory: a store a governed session can write is not trusted by default, and content read back from a vouched, Mission-writable store inherits the taint of the session that wrote it. One destination class is carved out. A recipient or endpoint the Approver concretely named at approval is pre-consented egress, so a tainted session’s send to exactly that destination needs no fresh approval on taint grounds alone, while parameter binding and the per-action permit still apply. (A deployment may route the taint determination through the PDP instead, where the decision binding carries it, and the PDP fails closed when the context is missing.) The draft is candid that this is a coarse control, not information-flow control. It cannot close within-scope data laundering, but it forces a human or a fresh approval between injected input and an external side effect. Least Exposure Is Broader Than Least Privilege makes the general case: the exposure surface, not just the action surface, is what a Mission should bound.

A harness check never replaces the PEP at the last controllable boundary. The two compose. The harness decides whether a unit of work may continue at all. The runtime layer still gates every consequential action.

Unwinding work in flight

Mission runtime enforcement can refuse the next action. It cannot un-send the last one.

The runtime layer is a gate in front of each action, so revoking a Mission reliably stops everything that has not happened yet. But a long-running workflow is a sequence, and a Mission can stop in the middle of it. After a journal entry posted, before the reviewer was notified. After a payment was dispatched, before anyone can prove it cleared. Denying the next step does nothing about the steps already in motion. Mission termination is not just an access-control denial. It is a question about execution state. The orchestration profile answers it.

The move is to plan the unwinding before the work runs, not to improvise it after a Mission stops. Two pieces make that possible.

First, every consequential step is assigned a reversibility class before it executes:

• read_only: observes data, no external effect. Suppression prevents future exposure, but prior disclosure cannot be undone.
• reversible_write: changes state and has a known compensation that can restore or materially offset it.
• irreversible_action: cannot be reliably undone once completed.
• external_commitment: commits to an external party: a sent message, a started payment, a signature, a filing, an order.
• privileged_administration: changes policy, access, configuration, or security posture.

The last three are deliberately the same-named action classes from Mission-Bound Runtime Enforcement. read_only and reversible_write are the finer distinction this profile adds for the sake of deciding what can be compensated. A step’s reversibility class must be consistent with, and no lower than, the runtime action class for the same operation, and the orchestrator MUST NOT lower it at runtime to dodge review. That is the same can’t-talk-yourself-down floor the runtime layer enforces, and for the same reason. The class comes from a trusted source (resource policy, an operation profile, a reviewed workflow definition). An agent’s plan, model output, or tool description may suggest a class, but it is never the sole authority for lowering one.

Second, before dispatching a consequential step, the orchestrator records an unwind plan for it. The plan states what happens to the step at each phase of trouble: what to do if the Mission is already non-active before the step starts, what to do if it stops while the step is in flight, and, for everything but a pure read, what to do after the step has completed. A worked plan for the riskiest kind of step:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "step_id": "notify_reviewer_audit_committee",
  "mission_id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
  "reversibility": "external_commitment",
  "pre_start_behavior": "human_review",
  "in_flight_behavior": "wait_then_review",
  "post_completion_behavior": "human_review",
  "review_queue": "audit-committee-review",
  "evidence_policy": { "link_runtime_evidence": true, "retain_for": "mission_audit_horizon" }
}

The plan is also committed, not just recorded. The step’s first Orchestration Evidence record carries an unwind_plan_hash over the plan, so an auditor can detect any later alteration of the plan a step ran under. And every member of the plan (the compensation action, the review queue, the safe point) derives from a trusted source. Model output MUST NOT define them.

When the orchestrator learns a Mission is no longer active (from a status poll, a signal, a PDP denial, a harness stop, or an operator), it stops dispatching new steps, suppresses queued work, evaluates every in-flight step, and runs the post-completion behavior for completed steps whose plan requires it. Staleness alone, an active state the orchestrator cannot re-establish within the bound, gets the same stop but never the post-completion behavior, because compensation is itself consequential work and unwinding work nobody stopped is not fail-closed. A narrowing signal (authority_changed at an unchanged active state) is a third trigger: the orchestrator re-reads the Effective Authority Set and re-gates pending steps against it, and never compensates a committed step merely because authority narrowed after it committed. Unwind plans cover workflows built from a reviewed definition; a graph a model composes at runtime falls back to harness stop behavior and runtime gating. The hard part is the in-flight step, and the profile forces the honest distinction:

• not_dispatched: not yet at the PEP or external system. Suppress or pause it.
• dispatched_not_committed: sent, but still cancellable. Attempt cancellation if the plan says so.
• committed: the effect occurred, or the system cannot prove it did not. Apply post-completion behavior.
• unknown: the orchestrator cannot tell whether it committed. Treat it as requiring human review.

That unknown row is the point. Distributed systems frequently cannot prove whether an in-flight action committed, and treating “I don’t know” as “it didn’t happen” is how audit gaps form. For an irreversible action, an external commitment, or a privileged change, an unknown outcome must not be quietly filed as success or as harmless suppression. It goes to review. Cancellation acceptance by an upstream queue is not proof the external action did not occur.

When a completed step does need to be walked back, that compensation is itself governed work. A refund, a reversing entry, a cancellation message. Each can be as consequential as the action it offsets. So the profile refuses to let Mission termination become a backdoor to unauthorized remedial action. Compensation under a Mission that has already gone non-active requires one of exactly two documented authority bases: the resource’s own policy (a remediation the resource authorizes for itself, such as a local rollback) or a narrow, pre-provisioned remedial Mission that is still active. An operator may gate either basis, but operator approval is not itself an authority basis. It does not create authority a PEP would enforce over a terminated Mission. If neither basis applies, the orchestrator does not compensate. It hands off to a human.

Like the harness, the orchestrator does not replace the PEP. A runtime permit obtained just before revocation might still arrive at the PEP afterward. The orchestrator stops dispatching such work, and the PEP still enforces its own permit freshness and Mission-state check. The harness decides whether a unit of work may continue. The orchestrator decides how in-flight workflow state is unwound. The runtime layer gates each action. Three checks, three questions, none subsuming the others.

The containment matrix

Unwinding assumed the stop signal was the Mission’s. In an incident it usually is not, and Mission termination is one control in a larger containment surface. Each kill has a different blast radius and a different owner, and an incident responder needs the whole matrix:

The capability kill’s reach is set per action class and consumer, never by the deployment’s assurance level, and only where the deployment runs the containment profile. A consumer that checks only a token’s signature and expiry gets the new-derivation kill, which also reaches Child Missions the contained entry justifies, while already-minted credentials live out their bounded lifetimes. A consumer gated by a fresh, containment-aware state source at the action (Mission Status, introspection, or a runtime PDP) also denies contained capability under pre-transition tokens, within the staleness, permit, and execution windows. A standalone Mission Authority Server path with no runtime gate gets neither. Mission termination participates in incident response. It does not replace it. Revoking the Mission stops issuance at once where the binding gates it and stops mediated actions within the staleness bound plus the permit window and the class’s execution bound, but it terminates no process and closes no network path. The converse holds too: killing a workload leaves the Mission active, its authority derivable to a replacement instance, unless the Mission is also revoked. A deployment’s incident runbook names which of these controls exist, who may pull each, and, per action class, which capability-kill reach its consumers obtain, and the Mission kill and agent kill rows belong to different objects with different owners, which is exactly why the runbook has to name both.

Evidence anyone can verify

Every layer of this suite signs its evidence. Signed is not the same as tamper-evident.

By the time a Mission completes, the suite has produced a trail: the approval event, every lifecycle transition, the consent rendering the user saw (From a Request to an Approved Mission), the per-action decision and execution evidence (Mission-Bound Runtime Enforcement), and the harness and orchestration evidence from this part. Each record is signed, which makes it attributable and tamper-evident in isolation.

It does not make the record set trustworthy. Whoever holds the signing key can backdate a record, drop an inconvenient one, or show different histories to different auditors. And nothing a relying party holds detects it. A compliance auditor in another company is worse off still. They have only the issuer’s word that its own logs are complete. A bare signature over a narrowed token cannot give a cross-domain party offline confidence that nothing was reordered or omitted.

The audit profile closes that gap by registering Mission evidence into a SCITT Transparency Service. The transparency substrate is not speculative. The SCITT architecture is published as RFC 9943, so this profile builds on a published standard. A producer (the Authorization Server, a PDP, a harness) registers a record as a Signed Statement. The service appends it to a verifiable, non-equivocating log and returns a Receipt that proves inclusion. The Signed Statement plus its Receipt is a Transparent Statement that any party can verify offline. This record was registered, at a committed time, in a log that cannot later drop or reorder it.

Two design choices make it practical, and they are the ones worth carrying out of this section:

The Mission is the statement subject. Every Signed Statement about a Mission uses the same sub, a fixed URI built from the Mission’s issuer and id (<issuer>/missions/<id>). Because the construction is fixed, independent producers in different domains all compute the same subject, and they share one feed when they register with the same Transparency Service, which cross-domain deployments should. An auditor who enumerates that subject (the deployment supplies the enumeration, since the substrate defines no feed query) gets the records that were registered, in order, append-only (approval, consent, decisions, lifecycle), as a single narrative under sub = https://as.example.com/missions/msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p:

Two caveats keep that honest. Transparency proves what was registered, not that everything was, so completeness is only checkable against an expected schedule. A deployment registers on a predictable cadence so an omission stands out as a gap. And “see it identically” holds against equivocation only if you either trust the single Transparency Service not to show different auditors different histories, or register with multiple independent services.

Statements commit by hash, never in the clear. The Signed Statement carries a COSE hash envelope whose payload is the digest of the retained evidence record as issued, not the record itself. A transparency log is append-only and may be widely readable. Nothing in it can be redacted later. So the sensitive task data stays out of the log entirely, retained separately under access control, and a relying party retrieves it and checks it against the committed digest. (Low-entropy records are committed with a retained random salt: a lifecycle transition is guessable, and an unsalted digest of a guessable record can be confirmed by dictionary.) The log proves a specific record was registered at a time. The content is verified out of band. Even the committed metadata leaks, though. The sub construction is fixed and does not expose the Subject directly, but it is a durable per-Mission correlator whose existence and registration cadence are observable in a shared log, so a deployment should weigh whether a Mission’s mere existence and timing are sensitive before registering in a widely readable service, and what its issuer and id reveal.

That split also sharpens what verification means. The profile separates an integrity failure (a bad signature, a bad Receipt, a broken inclusion proof, or a hash that does not match the retrieved evidence) from an audit failure, where the evidence, or a producer or service trust anchor, cannot be retrieved or resolved in the access window. An integrity failure is rejected. Among its causes, only the hash mismatch means the retained record itself was altered. The others mean the statement or the log cannot be trusted. An audit failure means you have proven the record was registered and not reordered but cannot confirm its content, which is not proof of tampering, and must not be treated as such.

The join key deserves one clarification, because every distributed estate already has correlation IDs. A request ID and a Mission ID connect different things. A request ID connects one trace, the hops of a single call as it crosses services, and it dies with the request. The Mission ID connects the body of work: every session, retry, agent, resource server, Child Mission, and lifecycle change the approved task produced, across days and across domains. Tracing tells you what happened to a request. Evidence joined on the Mission tells you what happened to the work, and whether it was still authorized while it happened. That property is verifiable continuity: the approval, the decisions including denials, and the executions shown to belong to one undertaking, not merely threaded by a correlator.

Six questions recur about the evidence layer, and the whole suite answers them in one place:

Two precise notes on what this profile is for, because it is easy to oversell:

This layers onto any level without changing it. It defines no new evidence object. It registers the records the suite already produces. A separate sketch, Mission Evidence Envelope, which the handbook labels Evaluate only, proposes one generic envelope and a payload-type registry that a future evidence kind may register into instead of minting its own media type. It migrates none of the existing records, and its first registered payload type is Intent Admission Evidence. A deployment that keeps its evidence without a Transparency Service is fully conformant and unaffected.

And it buys accountability, not prevention. Transparency makes a registered record impossible to silently backdate, drop, or reorder, and gives a cross-domain party offline verification. It does not make a dishonest producer honest. A producer can still register a false record. Transparency only makes that false record permanent, attributable, and visible to every auditor. And it proves only that a record was registered, not that the action the record describes actually occurred or was authorized. That is the evidence’s own semantics, not something the log can vouch for.

Run the whole Q3 board-packet task through this operational layer and the three checks land in order: the harness finds the revoked Mission and stops the paused draft, orchestration unwinds the half-written doc by its recorded plan, and the SCITT feed shows the one append-only history with the packet’s contents never entering the log.

The six-layer architecture

This is the operational close of the practice chapter, so it is worth seeing the whole implementation stack at once. The handbook specifies one durable object and follows it down a single spine (intent becomes a Mission, the Mission bounds authority, enforcement evaluates each action against it) across six layers:

Read it as layers, not publication order. The issuance profile, the OAuth binding that The Mission Is the Missing Abstraction covers, is the only mandatory layer. Everything else is an OPTIONAL companion that layers on without changing it, optional to the issuance profile and required by the claim that uses it. Parts 1 through 4 each make the Mission trustworthy along one dimension: the approval that creates it, the delegation that fans it out, the action that draws on it, and the state that governs it. This part is different in kind. It does not add a guarantee, it keeps the others from silently lapsing inside a running agent. The harness keeps a recovered session from acting on dead authority. The orchestrator unwinds work the kill switch caught mid-flight. The audit profile makes the whole evidence trail verifiable by someone who trusts none of the producers. They are why the architecture holds up against a long-running, multi-step, possibly-compromised agent rather than only an idealized one.

The handbook frames adoption as the Mission Assurance Levels, adoption bundles taken in the order deployments build them, and this part fills out the Governed Agent bundle:

The Governed Agent level adds consent evidence (From a Request to an Approved Mission) and the harness (this part), growing with delegation, expansion, and orchestration as the use case arrives. Audit transparency layers onto any level. Compromise resistance is not a level of its own: it comes from meeting the four conditions of the high-assurance level with a declared and audited path scope and an attested Enforcement Scope Statement, and the adoption sheet carries the full what-you-get and what-you-do-not-get map for every level.

A deployment with no agentic surface and no cross-hop audit need does not need a Mission layer and should not pay its cost. But for the deployments this chapter is written for (where authorization governs a user-approved durable task that spans many tokens, calls, actors, and a long stretch of time), the through-line is one sentence. The Mission Is the Missing Abstraction argued that the Mission is the missing abstraction because OAuth had no first-class object for the approved task. This part is where that object earns its keep. It is the thing a recovered session must re-check, the thing an in-flight workflow unwinds against, and the subject that ties a Mission’s whole evidence feed together. Session continuity is not authority. The Mission is.

For the full wire-level detail, read the three drafts: Mission-Aware Agent Harnesses, Mission Orchestration and Unwinding, and Mission Audit Transparency. For the full spine applied end to end on a concrete deployment, Least-Privilege MCP Tool Calls Need a Mission walks an MCP server through it. And the story does not end at the operational layer. The concluding chapter maps these layers onto the substrate-neutral framework, and Adopting Mission-Bound Authorization turns them into the staged build: the Runtime-Enforced level to ship now, and the roadmap that needs iteration.

In June 2025, Simon Willison named the pattern that the disclosures keep confirming: an agent that combines access to private data, exposure to untrusted content, and the ability to communicate externally can be turned against its principal by anything it reads. No exploit code required. A poisoned document instructs the agent to gather what it knows and send it out, and the agent complies with its own legitimate credentials. Hold any two legs and you are survivable. Hold all three in one loop and you have built an exfiltration machine that is waiting for its instructions.

The same month, researchers disclosed EchoLeak (CVE-2025-32711), which demonstrated the whole chain against a production system: a single crafted email, invisible to the user, steered Microsoft 365 Copilot into exfiltrating whatever its retrieval scope could reach, with no click required. All three legs, one loop, exactly as named.

Meta’s Agents Rule of Two (October 2025) cites the trifecta and turns it into a design rule: within a session, an agent should satisfy no more than two of processing untrustworthy inputs, accessing sensitive systems or private data, and changing state or communicating externally. Willison welcomed the addition of state change as a property to consider. The handbook composes with the rule: where a task needs all three, the gate checks each consequential action against committed bounds, and the external leg needs a fresh parameter-bound permit.

The handbook’s running example carries all three legs on purpose. Alice’s agent reads Q3 financials (private data), works through source documents to draft the packet (untrusted content), and notifies the audit committee (external communication). This is what a useful agent task looks like, which is Willison’s real point: the trifecta is the normal shape of valuable work, and the question is how to hold it safely.

This part is the chapter’s first crosswalk: run the handbook against the threat model and see what holds. Mission-Bound Runtime Enforcement carries the execution-time contract this part walks. Here the goal is the whole story in one place, residuals included.

The trifecta is an authorization problem

The first thing the handbook does to the trifecta is make it visible. You cannot govern a combination you cannot see, and in most agent stacks the three legs are invisible because every action looks the same to the authorization layer: a valid token calling an API inside its scopes. Reading the financials, reading the poisoned document, and posting to the webhook are indistinguishable events.

The handbook types them. Under one Mission, private reads, untrusted ingestion, and external writes are separately typed action classes, separately evaluated, and separately auditable. The Authority Set says which resources the agent may read and which destinations it may write to, with the parameters bound into the entries. The moment the legs are typed, the trifecta stops being an ambient property of the deployment and becomes a stated fact about one task: this Mission holds all three legs, these are the bounds on each, and here is the approval that accepted that combination.

That makes the trifecta an authorization problem, whatever else it is: which authority is in one loop at the same time, and what checks the combination at the moment it matters.

What each leg gets

Private data gets exposure discipline. The narrow Authority Set bounds which private resources the task may touch at all, and Least Exposure Is Broader Than Least Privilege carries the deeper rule: bound what the agent may see as deliberately as what it may do, because everything it sees can steer it and everything it holds can leak.

Untrusted content gets a taint response. Shaping fails closed on ambiguity so untrusted input cannot quietly widen a proposal, and the harness carries the mitigation Willison himself points toward: an external send or commitment whose bound parameter derives from untrusted content needs a fresh action-bound approval or is suppressed. Where the harness cannot trace a parameter’s provenance, the rule falls back to the whole session once untrusted content has entered it. A destination the Approver named at approval stays reachable without a fresh approval; any other destination keeps the full response. The session fallback is deliberately coarse, and the whole rule is a bar-raiser, not information-flow control. The residuals section says so.

External communication gets the full weight of enforcement. The external leg is where the theft completes, so it carries the strictest class in the runtime contract. Every external write is a consequential action needing a fresh permit from the PDP, evaluated against current Mission state, with the parameters bound: in the running example, notify_reviewer is bound to the audit-committee group, so the poisoned document that says “also send the numbers to this address” produces a parameter_violation denial, not a delivery. Under mediated custody the agent never holds the egress credential at all: the PEP holds the sender-constraint key, so a fully compromised agent cannot present the credential on an unmediated path it does not have. And for the classes where the content itself is the harm, action-bound approval puts a human between the injected instruction and the send.

Why splitting beats guardrails

Everything above shares one property: none of it requires the model to resist the injection. The poisoned document can convince the agent completely, and the agent can walk to the register as itself, and the transaction still fails, because the authority the gate checks against was fixed at approval time and the injected instruction cannot widen it. A guardrail asks the model to recognize manipulation. The split asks the PDP to check a parameter against a committed bound, which is a question with a deterministic answer.

And when containment catches something, Termination finishes the job. A parameter_violation denial is decision evidence joined to the mission_id, the incident playbook revokes the Mission, and the kill switch reaches every projection the deployment governs: issuance stops, permits stop, the harness halts the session, and the sub-agents cascade. Catching the trifecta once is enough to end it on every path the kill switch reaches, within each path’s published freshness bound.

The residuals

The handbook’s own adversary model carries these in writing, and this part repeats them.

• The defense is exactly as strong as PEP coverage. Every channel the runtime offers is a potential fourth leg: DNS, logs, error strings, a file another process reads. The deployment must name its enforcement scope and its unmediated paths. In card language, count your ATMs.
• There is no information-flow control. Each action is evaluated in isolation, so a sequence of individually permitted actions can compose into an exfiltration no single check catches. The harness’s taint downgrade raises the bar without closing this.
• The enforcement is structural, not semantic. An in-bounds send to an approved recipient can still carry content it should not. The classes where content is the harm belong under action-bound human approval, not under a smarter policy engine.
• Inside the approved scope, a turned agent is still turned. The Mission bounds the blast radius. It does not shrink it to zero, which is why scope stays tight and expiry stays short.

Willison’s conclusion was that no reliable prompt-level defense exists, and the handbook agrees from the other direction: the fix is not a smarter model but an authority architecture in which the model’s compromise is survivable, the survivable incorrectness the Mission Shaping series set as the operating goal. Under a Mission, the two-leg advice becomes a property the gate checks on each typed action, within the deployment’s enforcement scope.

This part is the chapter’s second crosswalk, and the one framing built for identity rather than threats. Patrick Parker published The Laws of AIdentity in May 2026 as a proposed framework for delegated agent action, opening from Kim Cameron’s Laws of Identity, and presented it as a keynote at the European Identity and Cloud Conference that month. The laws are not presented as an exhaustive checklist. Each names a dynamic whose violation produces a recognizable failure: confused agency, authorized-but-unintended action, authority laundering, time-of-check/time-of-use drift, cascade exfiltration, action-chain poisoning, or auditability collapse.

That makes the laws a useful test for this handbook. Mission-Bound Authorization starts from the five laws of delegated authority and asks how an approved task can govern authority across credentials, actions, actors, and time. Parker starts from the agent identity fabric and asks what a system must preserve when intent, authority, custody, execution, downstream identity, and proof no longer belong to one actor. The decompositions differ, but they meet around the same control problem.

The overlap is evidence of a real architectural seam. It is not proof that this draft family is the only answer, that the two frameworks were developed independently, or that every conforming Mission deployment satisfies all seven laws. Parker repeatedly describes systems that begin to satisfy a law. The handbook likewise has adoption bundles: Baseline Issuance makes no action-time claim, and Runtime-Enforced, Governed Agent, and High-Assurance Agent add controls in the order deployments build them. A deployment adopts the bundle its risk warrants, and a reader compares the assurance claims it can show, not its level.

This crosswalk therefore asks three questions for each law:

1. Is the requirement represented directly in the Mission model?
2. Does satisfying it require a runtime control, identity substrate, optional profile, or named assurance claim?
3. What part remains a deployment responsibility or an explicit non-goal?

How to read the crosswalk

The coverage labels are deliberately narrower than “answered.”

• Direct means the requirement is native to the Mission object or issuance profile.
• Composed means the answer exists only when Mission-Bound Authorization is combined with its identity, runtime, or evidence profiles.
• Partial means the architecture covers part of the law but leaves a material requirement unstandardized or out of scope.

That distinction matters because the issuance profile and the full reference security architecture make different claims. A Mission-bound token is as strong as the Resource Server that enforces the bounds it carries, and the issuance gate refuses every derivation from a Mission that is not active. Per-action, parameter-level, and state-aware checks come only when a PEP checks each consequential action against current Mission state.

The crosswalk

The table shows substantial convergence, but not seven identical answers: one law maps directly to the Mission model, four require composed identity, runtime, or evidence profiles, and two retain explicit semantic or coverage gaps. That result is more useful than a perfect score because it tells an implementer what must actually be deployed.

What the convergence demonstrates

The laws divide one apparently simple question into four system responsibilities:

No authentication mechanism can answer all four, but that observation should not be turned into a strawman about identity. Parker defines AIdentity broadly as a system of systems that composes identity, delegation, policy, credentials, action surfaces, human ceremonies, and proof. The better conclusion is narrower: agent identity needs an action-governance layer, and Mission-Bound Authorization supplies a concrete candidate for its authority object and runtime contract.

The mapping also tests the handbook’s internal decomposition. The Mission object answers Bounded Agency but not Generated Intent by itself. Runtime enforcement answers action time but not chain attribution by itself. The identity profiles answer who acted but not why the work remained authorized. Evidence proves what a producer recorded but grants no authority. The layers compose because their responsibilities do not collapse into one another.

Three mappings worth a closer look

Generated intent is the deepest agreement. Parker’s second law identifies the category change: the concrete action may not exist when broader authority is granted. The handbook responds at two different moments. At admission, the issuer derives an Authority Set from a structured Mission Intent, and an accountable Approver, or a deterministic policy acting within a ceiling that Approver consented to, decides whether it activates. At execution, a PEP asks a PDP whether the generated action and parameters fit that committed boundary under current state. The first check prevents the agent from inventing its own authority; the second prevents an approved Mission from becoming ambient permission for every action inside a token lifetime.

This is why the architecture cannot stop at a well-shaped prompt or a Mission-bound token. Shaping proposes. Approval establishes the ceiling. Runtime enforcement decides whether a concrete draw against that ceiling is permitted now.

Least exposure is broader than credential safety. Parker includes prompt context, retrieved material, tools, schemas, secrets, and downstream responses in the exposure surface. The handbook reaches that same conclusion: what an agent can observe shapes what it can decide, even when access policy would later deny an action. Its strongest wire-level control is mediated custody. For a mediated class, the PEP, not the agent, holds the sender-constraint key and releases a governed outcome rather than a reusable credential.

But the match has a boundary. The runtime profile can enforce filtered discovery and mediated egress on paths it controls. The broader discipline of purpose-scoped retrieval, memory, and context assembly is not yet an interoperable protocol. Calling Law 5 fully answered would hide exactly the standardization gap the handbook’s own least-exposure chapter names.

Proof-carrying action requires several kinds of proof. Decision Evidence records what the PDP evaluated and whether it permitted or denied the action. Execution Evidence is a separate PEP-produced record of whether a permitted action completed, failed, or was suppressed. The separation prevents a permit from being misread as proof that an action occurred. Both bind back to the Mission, and the integrity anchors commit the approved intent and authority.

Optional SCITT registration adds a different property. It commits a digest of a retained evidence record and produces a receipt that a verifier can check offline. It does not make a false record true, prove that every expected record was registered, or remove the need to retain the evidence and the policy material needed to interpret it. The receipt model is therefore strong, but its claims must stay precise: attributable records, verifiable inclusion, tamper detection, and deterministic joins, not omniscient audit.

Where the crosswalk sharpens

Authorize the action against what? Law 2 requires action-time authorization. The handbook adds that the comparison target must be an approved, committed boundary rather than a fresh inference about what the user probably meant. Runtime context is attacker-influenceable. Semantic alignment can inform a decision, but it cannot widen authority. The enforceable comparison is the Authority Set an accountable Approver accepted, under the policy and current state that apply at execution.

Separate the actor from the behavioral version. Parker’s Split Actor law distinguishes roles in an action chain. The handbook adds a different axis: the Agent Deployment, the versioned bundle of code, model, system prompt, tool allowlist, data scope, and runtime configuration. Instance identity answers which running actor. Deployment identity answers which reviewed behavior was running. The Architecture lets a Mission be pinned to a named Agent Deployment, but the pin is an architectural pattern with no wire member in the OAuth binding: a future Agent Deployment Binding profile would own it, and until one exists, which behavioral changes require re-approving a standing Mission is policy that change governance records.

That is not an eighth actor. It is a change-governance object with its own lifecycle and kill switch, kept separate from both agent identity and the Mission.

Where the handbook delegates or declines

This crosswalk ends with the parts it does not solve.

• Necessity remains a judgment. The architecture can verify that a sub-agent or tool was identified, authorized, within a strict subset, and unchanged from an approved digest. It does not decide whether invoking that participant was necessary. That remains an orchestration, design-review, or policy question.
• Exposure control is incomplete. Credential custody, tool filtering, egress mediation, and the harness taint rule have enforceable surfaces. Purpose-scoped retrieval, memory, and context assembly do not yet have a common wire representation.
• Model provenance is not model trustworthiness. Attested model or deployment identifiers can be verified policy inputs. They do not prove that the model is safe, truthful, or suitable. The authorization layer deliberately bounds behavior instead of certifying the actor’s judgment.
• Policy references require retention. policy_version identifies the derivation policy in force; it does not embed or hash the policy content and is not a promise that the decision can be reproduced later. A deployment that needs Parker’s policy-snapshot property must retain the referenced policy, dependencies, and evaluation inputs.
• Evidence completeness is not automatic. Signatures protect individual records. SCITT can prove inclusion and ordering for records that were registered. Completeness requires an expected registration schedule, reconciliation rules, and, if equivocation is in the threat model, trust in one transparency service or registration with multiple independent services.
• Embodied action is outside the current profiles. Parker explicitly extends the laws to sensors, controllers, actuators, vehicles, and other cyber-physical systems. Mission-Bound Authorization can carry their authority vocabulary, but it does not yet define the safety-envelope, telemetry, or actuator bindings needed to claim coverage.

The literal answer to Parker’s closing question is therefore a composition, not one token. Who acted? The subject, client or attested instance, actor chain, and runtime evidence identify the relevant roles. Under whose authority? The mission claim names the Mission and its issuer; the Mission record carries the Approver, the lifecycle, and the integrity anchors that commit the approved Authority Set. Through what chain? The act chain preserves actor lineage while Mission parentage preserves authority lineage, so delegation does not blur the two. With what proof? Signed Consent, Decision, and Execution Evidence join on the Mission, whose record holds the hashes, with optional transparency receipts strengthening the retained record set.

That is a substantive answer to the authorization-heavy core of the Seven Laws. The crosswalk’s strongest conclusion is not that one draft family has finished AIdentity. It is that Parker’s framework and this handbook, starting from different questions, decompose agent governance into identity, bounded authority, action-time enforcement, custody, and proof. Any deployable system will need those responsibilities to compose without pretending they are the same thing.

The first two crosswalks in this chapter answered a threat model and a requirements framework. This one answers the checklist. When a security team reviews an agent deployment, the framing on the table is usually OWASP’s: the Agentic AI Threats and Mitigations taxonomy from the GenAI Security Project (first published in February 2025 with fifteen threats, revised to version 1.1 in December 2025 with seventeen, and distilled the same month into the Top 10 for Agentic Applications for 2026, mapped below), seventeen threats spanning single agents, multi-agent systems, their protocols and supply chains, and the humans around them, alongside the Top 10 for LLM Applications, now in its 2026 edition. If the handbook cannot state its position against that list, threat by threat, the reviewer is right to treat it as unevaluated.

A crosswalk that claims everything has been fitted to its framing, so this one sorts every threat into three verdicts, each stated as what an attacker can still do:

The distinction that drives most rows is the one the trifecta post established: the authorization layer does not make the model resistant to anything. It makes the model’s compromise survivable, because authority was fixed at approval and every consequential action is checked against it fresh. A verdict follows what the threat attacks. Threats that attack authority are contained. Threats that attack the agent, its memory, its goals, its inputs, or the humans around it are bounded, even where the gate also stops the resulting action from exceeding the committed authority, because the cause is untouched. Threats that attack layers the handbook never claimed are delegated, by name. So contained never means prevented at the cause: a manipulated goal, a misused tool, or a rogue instance can still act inside the committed authority, which is why scope stays tight. Throughout the chapter, the gate checks a committed boundary and never an inferred intent.

The agentic threats, all seventeen

Four contained, twelve bounded, and one delegated. The threats that attack authority itself (tool misuse, privilege, attribution, identity) land on machinery built for them. The threats that attack the agent, its memory, its goals, its protocols, or the humans around it are capped at the action gate: an injected goal or a rogue instance still cannot exceed the committed authority, but the cause is untouched, so those rows are bounded by the chapter’s own rule. The supply chain is another layer’s job.

The 2026 Agentic Top 10, mapped

In December 2025 the same OWASP project distilled its agentic work into the Top 10 for Agentic Applications for 2026 (ASI01 through ASI10), and that list is now the checklist most reviews open with. It compresses cleanly onto the seventeen-threat crosswalk above, so the verdicts carry over rather than multiply:

The tally holds the same shape: the authority-shaped risks land on machinery built for them, and the risks that live in the model, the supply chain, or the human stay bounded or delegated, stated rather than absorbed.

The LLM Top 10, split by layer

The Top 10 for LLM Applications, now in its 2026 edition, mixes layers, which makes it the better test of the delegated verdict. Half of it is not an authorization problem, and saying so is the point:

OWASP’s mitigations for Excessive Agency are to minimize the extensions and their permissions, avoid open-ended functions, require human approval for high-impact actions, enforce authorization in downstream systems rather than trusting the model, and log everything. The handbook specifies each as protocol: authority derived from an approved task, the class guard and action-bound approval, PEP enforcement at the downstream boundary, and evidence joined on the Mission.

Three threats worth a closer look

Intent breaking is the taxonomy’s center, and the handbook’s enemy. T6 is prompt injection grown up: the attacker does not need to breach anything, only to change what the agent is trying to do. Every mitigation that asks the model to notice the manipulation is probabilistic. The handbook’s answer is the same one it gives the trifecta: the injection changed the agent’s mind, and the agent’s mind was never the source of authority. The Mission was committed at approval, the permit is checked at execution, and between those two points there is nothing the injected goal can rewrite. That is also why T6 is bounded rather than contained: the gate does not stop the manipulation, only what the manipulation can reach.

Overwhelming the human in the loop is an argument about grain. T10 is the taxonomy’s sharpest design question, because both naive answers lose: approve every action and fatigue turns humans into rubber stamps, approve nothing and governance is gone. The handbook’s grain is the Mission. A human approves the envelope once, against a committed disclosure, and the per-action volume goes to the PDP, which does not tire. When the work outgrows the envelope, the discovery loop batches the overflow into a governed expansion request instead of a stream of interrupts. The residual is real and stated: at Mission grain, approval fatigue becomes a governance discipline rather than a solved problem, disclosure quality is what stands between an approver and a reflex, and the fatigue budget collects the controls that spend against it.

A rogue agent is an insider, and every agent here is treated as one. T13 assumes the attacker is already inside the system, wearing a legitimate agent. The handbook never trusted that agent more than its paperwork: its authority is a strict subset of its parent’s, its tokens are bound to its attested instance so they do not travel, its consequential actions need permits like everyone else’s, and when it is caught, revocation cascades through the delegation tree it belongs to. The multi-agent threats (T12 through T14) all get the same structural reply: cooperation happens in messages, and messages carry no authority. T13 is bounded for the same reason T6 is: the compromise itself is untouched.

What the crosswalk does not claim

Three of this crosswalk’s ceilings are the trifecta post’s residuals, inherited unchanged. The verdicts are only as strong as PEP coverage, and an unmediated path is a threat with no verdict at all. The enforcement is structural, not semantic. And inside the approved scope, a turned agent is still turned. Two ceilings are this crosswalk’s own.

• Bounded is not prevented. For every bounded row the cause is untouched: the memory is still poisoned, the model is still fooled, the human is still tired. The gate caps what the compromise can reach, and that is the whole claim.
• The delegated rows are real dependencies. Supply chain, poisoning, retrieval security, and sandboxing are layers the handbook composes with and cannot replace. A deployment that skips them has a contained authorization layer inside an uncontained system.

The taxonomy’s own mitigation columns keep naming least privilege, human approval, complete mediation, and audit trails. The crosswalk above shows which of those the handbook turns into verifiable artifacts, and where the gate only caps what an attack can reach. The vendor test carries its six questions from here.

This chapter has held the handbook against a threat model, a requirements framework, and a threat taxonomy. The last framing is the one with auditors behind it. AI governance regimes differ in force, NIST AI RMF is voluntary, the EU AI Act is law, ISO/IEC 42001 is a certifiable management standard, but they converge on one demand: show me. Show me who is accountable for this system. Show me what it is for, and what its limits are. Show me how you observe it, how a human intervenes, and how it stops. Show me the records, and show me they have not been edited.

For most agent deployments the honest answer today is archaeology. The purpose lives in a design document, the authority lives in OAuth scopes that say nothing about purpose, the oversight lives in a dashboard someone checks, and the record is a session transcript that proves what the agent said, not what it was authorized to do. Each obligation gets its own retrofitted artifact, and none of the artifacts constrain the system they describe.

The claim of this part is that the handbook answers the show-me question as a side effect of doing its actual job, because the artifact that enforces is the artifact that documents. That is what by-product means here, and it has a boundary worth stating before the table: this part maps evidence, not compliance. Whether a given agent falls under a given regime, and whether the organization around it meets its process duties, are questions no architecture answers. One more caution, on dates: the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk obligations to December 2, 2027 for Annex III systems and August 2, 2028 for Annex I systems, before the original August 2026 date arrived. Articles 12, 14, and 26 are unchanged, and the mapping below anchors to the shape of the obligations, which held through the schedule change: purpose, oversight, records, interrupt.

The crosswalk

Every row maps to machinery the handbook specifies for enforcement rather than for compliance, which is what by-product means here. The mapping shows that the evidence exists. Whether it satisfies a regime is the question the last section leaves with the deployment.

Three obligations worth a closer look

Article 14’s interrupt is a distributed systems problem, and the card chapter already told the story. The oversight article asks for a human who can intervene or interrupt, including through a stop control. The card chapter’s fifth part, Canceling the Card Doesn’t Stop the Charges, is about why a stop button can be theater: revoking a credential while sessions keep running, caches keep serving, and sub-agents keep working is an interrupt that interrupts nothing. Termination is the handbook’s answer: on each path the deployment governs, issuance stops, permits stop within that path’s published bound, the harness halts the session, and the delegation tree cascades. When the regulation says interrupt, the deployment can state, with a number per path, how long the interrupt takes and which paths it does not reach.

Article 12’s logs are only evidence if they join. A logging obligation quietly assumes the logs can answer questions: who acted, under whose authority, against what approval. A session transcript cannot, because it records utterances, not authority. The handbook’s records are receipts rather than logs: Consent Evidence commits what the approver saw, Decision Evidence commits what the gate decided and why, Execution Evidence commits what happened, all joined on one mission_id, with policy_version making the derivation re-checkable and SCITT making the feed append-only. The practice chapter’s line is the compliance argument in one sentence: audit joins on one identifier, or it is archaeology.

NIST’s Map function wants documented purpose, and documentation drifts. Every regime in the table asks for a statement of intended purpose, and in a conventional stack that statement starts drifting from behavior the day it is written, because nothing operational reads it. The Mission collapses the gap: the document that states the purpose is the object the PDP enforces, so the bounds it commits are the bounds the gate checks, and on the paths the deployment enforces the two cannot drift apart. The prose purpose is checked by the Approver who reads it, and the gate checks only the structured bounds. This is the by-product thesis in a single artifact, and it is the reason the answer to Map is one table row instead of a governance process.

The by-product, rendered. One surface carries this part’s whole claim, with the audit log joined on the Mission’s identifier:

An illustration, not a normative rendering: the artifact behind every row is the evidence family, and what makes the view possible is the join, not the dashboard.

The evidence is itself sensitive

A system that records every approval, decision, and consequential action has built a second data estate, and the posture that keeps it defensible is minimization, not accumulation.

• Collect the decision, not the content. Record the action class, the resource, and the bound parameters a decision turned on, not full user content or model input, unless the content is itself the audited artifact. And no record needs the model’s internal reasoning: the runtime profile explicitly excludes chain-of-thought from enforcement evidence: content that is high-sensitivity and adds no verification value beyond the decision inputs.
• Commit digests, not values. The family’s own integrity pattern extends to its evidence. Where a record needs to prove what a value was, a digest or commitment serves and the raw value stays out of the durable trail, which is what parameter_digest already does at the decision layer.
• Separate the streams. Operational logs and audit-grade evidence have different jobs, audiences, and lifetimes. Verbose debugging data is not retained to the audit horizon and is not committed to a transparency log.
• Classify at production time. Evidence fields carry a sensitivity classification when the record is produced, so access, export, and retention key on the class rather than on a reviewer’s later judgment.
• Audit the audit. Reading a Mission’s evidence is a privileged operation, not a byproduct of holding a Mission reference, and evidence reads are recorded the way the actions they describe were recorded. Access to the audit trail is part of the audit trail.
• Disclose selectively. A party that needs to verify one fact gets a reference and a digest, not the record. The Mandate is this posture made portable.
• Bound retention, and make deletion accountable. Evidence is retained for the declared audit horizon and no longer, and when law or a data-subject request erases a record early, an erasure record makes the deletion itself auditable, so a gap in the trail is distinguishable from tampering.

The normative half lives in the drafts. The audit profile carries these duties, and the Mission Deployment Profile publishes the deployment’s posture beside its guarantees: the field-classification scheme in use, whether evidence access is itself audited, the retention horizon, and the erasure policy. A reviewer reads those members the way they read the enforcement scope, as claims to check rather than virtues to assume.

What compliance still requires

The by-product is the evidence. Everything else stays where it was.

• Classification is judgment. Whether an agent falls in a high-risk category, or in scope for a regime at all, is a legal determination the architecture does not make.
• The process duties stay human. Impact assessments (for AI systems, now standardized in ISO/IEC 42005:2025), operator training and competence, management review, and the org-chart reality behind assigned oversight are organizational obligations. The record makes the assignment legible. It does not make the assignee competent.
• Retention is policy. SCITT makes the evidence feed tamper-evident. How long the deployment keeps it, against Article 26’s retention floor or its own, is a decision the deployment owns.
• Certification is a process, not a property. ISO/IEC 42001 is audited, ISO/IEC 42006:2025 sets the requirements for the bodies that certify it, and the EU AI Act’s high-risk tier has conformity assessment. An architecture can shorten the evidence-gathering to a query. It cannot sit the audit for you.
• The evidence covers what the gate covers. A PEP that mediates half the consequential actions produces records of half the behavior. Enforcement scope bounds evidentiary scope, the same way it bounds every other claim in this handbook.

Mission-bound authorization is adopted so that agents doing real work stay governed, and the audit artifacts fall out of that, because an architecture whose control records are its operating records has nothing separate to prepare. The auditor’s question turns out to be the vendor test on different letterhead: who acted, under whose authority, within what bounds, and how can you prove it.

The first four crosswalks held the model against a threat model, a requirements framework, a threat taxonomy, and the governance frameworks. This one holds it against a candidate problem statement from inside the OAuth conversation. Agent Authorization Use Cases and Gap Analysis is an active individual draft in the OAuth working group’s orbit, written by authors from China Mobile, CNNIC, and Huawei. It catalogs eleven agent scenarios in three categories, runs a gap analysis under each against OAuth 2.0 and its common extensions, and rolls the findings up to six major gaps. Revision 03 (August 25, 2026), the text answered here, adds an opening section naming three core gaps that run through nearly every use case: the authorization context gap, the delegation chain gap, and the mass revocation gap. The editor’s copy runs ahead of the published revision, its issue tracker is where the catalog moves between revisions, and this mapping re-pins at each published revision. The catalog proposes no solution.

The catalog’s first revision developed independently of this family. Later revisions reflect discussion between the efforts: the data-subject requirement echoes an issue filed from this side, and revision 03 acknowledges contributors from those same threads. This mapping evaluates revision 03 on its requirements and does not count that later alignment as independent validation.

The argument here is not a score. Several of the catalog’s gaps need the same connection: an approved task that later credentials, decisions, delegations, and revocations can identify. The Mission proposes that connection. Each enforcement layer still has obligations of its own, and three requirements stay partly open. The crosswalk then maps every row with its source section, so the reading can be checked.

One task, three failures

The catalog’s first use case is a personal assistant. On Monday, Alice asks it to “help me plan a picnic for this Saturday.” It checks her calendar and the weather, researches parks, and on Tuesday afternoon asks for permission to book a spot and add the event to her calendar. Three of the catalog’s gaps appear in that one task.

• The context is lost. Tuesday’s prompt lists scopes like parks.book and calendar.write, and Monday’s instruction is gone. To Alice it reads, in the catalog’s words, “Why does this app want to book a park now?” Her real questions (“Which park did you choose?” “Is there a fee?”) have nowhere to go.
• An action runs with no one approving it. Where the booking falls inside a grant the assistant already holds, no fresh approval triggers at all. “The failure is not a bad consent screen, it is the absence of one.”
• Cancelling the task does not reach its permissions. Alice should be able to say “Cancel the picnic planning” and have every permission and pending action for that task revoked without touching her other tasks. OAuth revokes tokens one at a time, and a task is not a token.

The connection the gaps share

Each failure is the same missing object seen from a different side: nothing in the protocol identifies the approved task, so nothing later can be checked against it. The Mission is that object, a durable record of the approved task with an identifier that later credentials, decisions, delegations, and revocations carry. What it fixes depends on the layer enforcing it.

Context travels with the task. The client submits the Mission Intent through PAR, the Authorization Server validates it, commits it with intent_hash, and renders its goal beside the derived authority when Alice approves. A later request for more authority is an Expansion of that specific Mission, approved with the running Mission in view, and Alice’s questions go through Disclosure Interrogation, answered from recorded material rather than from the agent. Committing the Intent does not prove it faithfully represents what Alice said; her check of the rendered goal and bounds closes that gap.

The consequential action gets its own decision. The catalog’s sixth gap says grant-layer tokens prove potential, never the legitimacy of a specific executed transaction, and asks for parameter-bound, non-repudiable evidence of consent at the moment of execution. That split is the one the family’s runtime layer is built on: authority is the upper bound, the permit is the per-action decision bound to concrete parameters by parameter_digest, and action-bound approval, which the runtime profile says a deployment SHOULD require for the high-consequence classes, is the mechanism that asks. A human makes that decision where the deployment routes it to a human Approver. The executing PEP recomputes the digest and reverifies the approval before the effect commits, which is revision 03’s requirement that execution evidence be verified first, and Runtime Evidence’s evidence properties state what the resulting records prove and under which conditions.

Revocation targets the task. The catalog calls the lack of task-level revocation “a major operational and security failure point,” and the diagnosis is exact: OAuth can revoke a token, and a task is not a token. Revoking the Mission stops it on every path the deployment governs, each within its own bound: an issuance-gated path mints nothing new and its outstanding credentials expire within their lifetime, a runtime-enforced path refuses within its published staleness bound, the harness stops resuming, and Child Missions fall with their parent. A path the deployment excluded from Mission enforcement gets nothing from the revocation, and its enforcement-scope statement says so. Mission Management carries the same stop to a compromised principal’s Missions at once.

Asking for more is an admission decision. The catalog’s first gap says agents need a “continuous dialogue” of just-in-time permissions rather than upfront grants. Read carefully, it is the discovery loop specified as a requirement: start narrow, discover the need, ask through a governed channel, and land the widening as a fresh approval. Every turn of that dialogue is an admission decision, and the agent never grants itself scope mid-flight.

A smart-home approval, worked

The catalog’s smart-home scenario generates per-device scopes until the consent screen is unusable. Moving consent to the task grain reduces that, and it still leaves work: mapping the task to each device’s authority, handling devices discovered later, showing consequential limits plainly, and keeping the disclosure, the derived authority, and the enforced bounds aligned. One bounded approval shows how the pieces fit.

Bob approves a morning-routine Mission. Its target resources are the bedroom lights, the thermostat, and the coffee maker. The derived entries allow dimming the lights, setting the thermostat between 66 and 72°F, and starting the coffee maker, each constrained to weekdays between 6:45 and 7:15. The doors are not named. The disclosure renders those entries as statements, with the time window and the temperature range shown as bounds.

Later the agent finds a smart door lock and tries to unlock it at 7:00. Derivation never produces an entry for a resource the Intent did not name, so the PDP refuses the action as out_of_authority and marks the denial requestable. The agent can ask through the discovery loop, and the request is an Expansion: a fresh approval of a successor Mission that names the lock, unless a ceiling Bob consented to earlier already covers that device class, in which case policy adjudicates the drawdown inside it. The original approval never covered the lock, and Bob did not have to anticipate it for the denial to hold.

The example leaves three questions to each deployment: who maintains the mapping from a routine to device entries (the derivation policy, kept per resource), how the disclosure stays readable as devices multiply (the translation floor), and whether a household accepts one approval per new device (a ceiling over a device class is the family’s answer, and it is experimental).

Where the answer is incomplete

Three requirements the family only partly addresses:

• The human’s own signature at execution. The consent link in the execution chain is the deciding infrastructure’s record of the human decision, not the human’s own signature, so non-repudiation against the recorder needs a user-key-signed confirmation the family composes with rather than defines.
• One budget across administrative domains. Partitioned group authority is native, a parent and its children, each attributable, and collapsing differentiated members into one shared grant identity would still trade Law 2 for convenience, the thing the contractor post warns about at fleet scale. What the catalog asks beyond that, one aggregate constraint consumed consistently by branches in separately administered domains, this family does not define: Consumption Metering bounds cumulative spend under one authority, and cross-domain consistency of that counter is open.
• Trust between strangers. Offline attenuation chains prove their own narrowing and the Status List gives a local revocation decision, but trust bootstrapping between organizations with no prior arrangement is deliberately not claimed: projection is trust-scoped, and the portability wager prices exactly this.

Two the family leaves to other layers, and one caution:

• The data subject. Where an agent touches data about a person who is not the resource owner, a Mission’s approval never substitutes for that person’s consent, and the OAuth binding’s Privacy Considerations now say so. Revision 03 asks for more, a way for the data subject to authorize the access, and that belongs to the resource domain’s own lane, which the binding names and which Mission authority never overrides.
• The OS-native half of the bridge. The harness mediates local side effects under Mission state, and expansion is the agent-subject elevation path, but the family does not specify how a Mission maps into OS-native entitlements, sandbox profiles, or elevation dialogs, and it composes with whatever the platforms define.
• Both are individual drafts. Agreement on requirements argues that the problem statement and this solution shape belong in the same venue conversation. It does not show that this architecture is necessary or sufficient, it makes neither one a standard, and the family’s own maturity labels mark nearly every answer below as experimental or a sketch.

The crosswalk

The verdicts here are simpler than the OWASP post’s, because gaps are not threats. Answered means the gap lands on named machinery with a draft behind it, maturity labeled, and the verdict names the smallest adoption bundle that meets the core of the ask: Baseline Issuance (the OAuth binding alone), Runtime-Enforced, or Governed Agent, or else the extension companion the answer needs beyond them. A companion that only adds to an answer does not change its tag. Partial means the machinery covers most of the ask and the remainder is stated. Delegated means the gap belongs to a layer the family composes with rather than supplies. The catalog is outside, the mapping is ours, and every row cites its source section and the machinery so the reading can be re-run.

The catalog’s summary rolls its findings up to six major gaps, and each use case carries sharper asks beneath them. The table answers both grains: the six major gaps first, in the catalog’s order, with the revocation gap split into its two constructions, then fifteen asks from the use-case analyses. Revision 03’s three core gaps land on rows below: the context gap is the first ask, the delegation chain gap is the multi-hop row, and the mass revocation gap is the two revocation rows.

For reference, the table’s 22 rows record thirteen answered, seven partial, and two delegated. Eight of the thirteen are answered within the adoption bundles, three of them at Baseline Issuance, one on the OAuth binding alone and two with identity drafts it composes with, and five need an extension companion: Expansion for the two rows about authority requested after approval, Mission Management for bulk revocation, and the Resource Access Profile for expressed constraints, with Consumption Metering for cumulative budgets. The rows mix the summary gaps with the detailed asks beneath them, and Answered means named machinery with a draft behind it, not demonstrated interoperability or a validated deployment, so the count is not a coverage score.

The eleven use cases

The catalog’s scenarios each land on a named pattern rather than a new one. The personal assistant and the smart home are Missions with standing charters over consumer resources, and the category does not care that they are not enterprise. The third-party SaaS proxy is the issuance profile’s home game. The first connection with no front channel is mediated custody’s slice of an ungoverned world: a handler holds the static key, each use is permit-bound, and the standalone MAS supplies the governance object the service never built. The OS resources case is the harness’s local-PEP slice, with expansion as the agent-subject elevation path and the OS-native remainder in the table above. Business process automation and the coordinated task group are a parent Mission fanning out through Child Missions. The DNS maintenance agent is the standing agent again, cycling authority under a charter, and revision 03’s ask for a standard DNS authorization type is vocabulary for the DNS community to define, which the Resource Access Profile’s entries carry without defining. Managed services across organizations are cross-domain projection, with each sub-provider or tenant hop narrowing what it received, as a Child Mission where one issuer hosts the hierarchy and through offline attenuation where the hop crosses issuers, and delegation between fully provisioned organizations adds the Mandate and the Status List to it, with the stranger-trust remainder priced in the table. And automated incident response is Mission Management’s reason to exist: enumerate a compromised principal’s active Missions and bulk-revoke, dry-run first, with the kill switch reaching issuance, permits, harnesses, and sub-agents on the paths each of them governs.

A test anyone can run

Approve two tasks for the same agent. Delegate part of one to a sub-agent, then cancel that task while a credential and a permit for it are still outstanding. Each covered enforcement point must identify the canceled work and refuse it within its published bound, a path excluded from Mission enforcement does nothing and its enforcement-scope statement says so, and the other task keeps running. The evidence must show which boundary stopped each attempted action. That is a test this family has to pass, and so should any design that claims to close these gaps.

The Mission is the durable, approval-backed record of the task (The Mission Is the Missing Abstraction), and the chapters before this one made the argument at every altitude: the intuition, the architecture, the wire, the outside framings. This concluding chapter zooms out to the framework those chapters realize, because the model does not depend on OAuth even though the profiles do. If you want the build order first, read Adopting Mission-Bound Authorization and come back. The maturity and status claims here are as of October 2026, and the Reference carries the reconciliation date the handbook tracks.

The framework OAuth carries

OAuth earned its place as the first substrate for one reason: it is where the deployments are. The Authorization Server already exists, the token machinery already works, and the agent identity stack that the WIMSE working group’s AI Identity Management System (AIMS) proposes as best practice is OAuth-shaped: the agent is an OAuth client, and the delegating user is the token’s subject. But the object this handbook built is not an OAuth feature, and OAuth is no longer its only binding. The family now carries five peer bindings: the OAuth binding, the first, on the most deployed infrastructure; the standalone Mission Authority Server, a controller over the OAuth Mission data model where an estate’s Authorization Servers cannot issue Mission-bound tokens; an AAuth binding that hosts AAuth’s native mission concept at its Person Server; and UMA 2.0 and GNAP sketches. The MAS imports the OAuth Mission record, so it is a peer deployment topology rather than an independent model; AAuth is the binding that shows the model does not depend on OAuth. The sketches are the first two bindings authored against Substrate Requirements, which consolidates what any further binding must provide: a contextual-governance kernel every binding supplies, and eight optional capabilities a binding claims through its Mission Substrate Statement. The OAuth binding makes no substrate-conformance claim and instead publishes an informative Mapping Assessment of itself in the same form. The Architecture document states the model on its own terms, and it is the right front door for a newcomer who wants the whole shape before any wire detail.

The coarsest map of the layer is four functions, and they survive any substrate:

These names are built to survive the Mission. If a different object wins the standards conversation, the layer still needs compilation, projection, containment, and continuity, and this handbook is a complete worked example of all four.

The finer decomposition is a verb spine. Each verb answers one question, sits on one trust boundary, and is owned by named documents:

The spine the architecture follows, Intent to Mission to Authority to Enforcement, is the temporal reading of the same map: what happens first when a request arrives. The verb spine is the structural reading: which component owns which question. Both readings survive a substrate change, which is the test of a framework rather than a feature.

Fundamental versus accidental

A sharper version of that test is to ask which of this handbook’s ideas survive if OAuth disappears. The answer is nearly all of them. The layer with no standard form and its five laws. Authority compilation, projection, containment, and continuity. The approved task with an integrity-anchored record and a lifecycle. Approval evidence. Runtime containment at the point of use. Session continuity that is never authority. Those are architectural commitments, not OAuth features.

What is accidental is the realization: PAR as the submission channel, RAR as the Authority Set serialization, the mission claim’s name, the JWS envelopes, Security Event Tokens for signals, the AuthZEN wire shape. Any of those could be swapped without touching a law. The AAuth binding is the existence proof: it carries the kernel (the approval, the Mission reference, the active-state gate, and the ordered mission log) onto a non-OAuth substrate with no new AAuth wire members, by swapping exactly those accidents. It realizes authority in AAuth’s own terms rather than a portable Authority Set: scopes, resource tokens, and optional R3, with AAuth’s two lifecycle states, active and terminated, and the Person Server’s contextual gate as the per-action control on the paths it mediates. The closing part carries what AAuth itself did with the object. That division is why the Architecture document states the model on its own terms and the bindings realize it, and it is the standard to hold any competing proposal to. An alternative that replaces the accidents is a realization. An alternative that drops a law is a gap.

The ontology direction also falls on the accidental side. On OAuth, authority is client-proposed and enumerated: the client asks in types the issuer must understand. On AAuth, the optional Rich Resource Requests (R3) companion, an exploratory individual draft (-00, September 28, 2026), inverts it, with the resource declaring its own operations, meaning, and consequences in a resource-owned vocabulary, and the resource token committing to that declaration by hash. The AAuth binding maps nothing onto R3 operations. Which party proposes the ontology is substrate. What survives is the fundamental beneath both: meaning binds at approval, is enforced at the point of use, and translation across vocabularies never widens. Authority compilation needs a vocabulary source, and the framework does not care which direction it arrives from, only that the record commits it. It is a realization, not a law.

Where the model sits operationally is the next part: The Authority Control Plane, the two chokepoints, the pattern space of bindings, and the structural mapping that platform engineers reach for unprompted.

The model survives without OAuth, and this part is where it sits when OAuth is exactly what you have: the two chokepoints the binding stacks, the pattern space of bindings between them, and the structural reading that platform engineers reach for unprompted.

Two chokepoints, and the patterns they allow

The OAuth binding stacks two independent chokepoints, and the Architecture’s deployment patterns are combinations of them.

Issuance gating acts at the token layer. A revoked or expired Mission stops all further derivation and refresh, and short-lived tokens age out. Runtime enforcement acts at the action layer. Each consequential action is re-checked against current state at the point of use. Together they are strictly stronger than either alone: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer. This split is also the layer’s control-plane contract, mapped in full in the authority control plane below.

Two documents extend the pattern space.

The Mission Authority Server is the standalone binding, proposed for the Standards Track, and the estate control plane for approved-task authority. It is a controller over the OAuth Mission data model: it imports the OAuth binding’s Mission record and issuance profile, so it is a peer deployment topology rather than an independent model. A dedicated service implements the Mission Issuer role and derives no tokens, and the Mission Join connects each ordinary OAuth token to its Mission at the point of use. The MAS serves the Status and lifecycle surfaces itself and is the deployment’s freshness source, and a MAS that claims the optional Expansion and Child Creation capability lets expansion and Child Mission creation ride its own submission surface with an authenticated-client binding in place of token possession.

It is a peer binding with its own rationale, governance deliberately decoupled from token issuance and one Mission Issuer governing across many Authorization Servers, and it is the entry ramp for an estate whose Authorization Servers cannot issue Mission-bound tokens. The trade is explicit: Mission governance and per-action enforcement with zero AS change, at the cost of the token-layer chokepoint. Revoking a Mission in this mode stops nothing at the token layer, so enforcement rests entirely on PEP coverage. The issuance grant is the repair: the MAS mints a grant only for an active Mission, and an estate Authorization Server redeems it for Mission-bound tokens, restoring a token-layer gate without moving approval into the AS. The consuming AS runs in one of two modes. With a Mission-state integration, it checks the Mission at redemption and at every refresh and narrows the tokens to the current Effective Authority Set. Without one, it issues no refresh tokens, relies on the grant’s active-at-minting gate and short token lifetimes, and cannot claim containment- or discharge-aware issuance. Tokens derived under a revoked Mission can then keep working for the grant’s remaining redemption window and clock-skew leeway, plus the issued token’s lifetime, plus that of each further exchange that checks no Mission state, never past the Mission’s expiry. The Mission Mandate is an advanced profile, its external dependencies all published RFCs, a design to adopt when the cross-domain proof case arrives. The question it answers is proof. A Mission’s committed facts live on the record at its issuer, and a party outside that domain cannot verify what was approved short of a token-exchange hop or trust in the issuer’s records. The Mandate is a signed, portable, independently verifiable statement of those facts, minted by the Mission Issuer, with optional selective disclosure. The design line is the one this handbook has drawn everywhere: a Mandate is evidence, not a credential. Presenting one authorizes nothing.

The two bindings, side by side, and the Architecture names the distinction: the embedded binding is a credential-carried security architecture and holds both chokepoints, while the standalone binding is PDP-joined, trading the token-layer chokepoint for zero AS change, with the issuance grant as the join that restores a token-layer gate:

The diagram shows two of the family’s three binding security architectures. The third, context-carried, is the AAuth binding’s: the substrate’s own mission context is the record, and the Reference carries the trio.

The third extension of the pattern space is Mission Cross-Domain Projection, one Mission honored in another trust domain through a single-hop, audience-scoped cross-domain grant. Mission-Bound Authority covers it in full, because the multi-domain agent task is the common case, not the exotic one. It sits with the advanced profiles rather than in the reference security architecture, with its dependencies tracked: the identity-chaining work it profiles is approved and in the RFC Editor queue, and ID-JAG is a working-group document.

The authority control plane

One more reading of the framework earns its place, because platform engineers reach for it unprompted: the layer is the control plane for delegated authority, with the split that vocabulary always implies. The architecture chapter makes the strategic case, and the mapping here is structural, not rhetorical:

The estate view of the same mapping: desired state above, per-action enforcement below, the sync channel between them, and the evidence joining back on the Mission:

Three disciplines keep the framing honest. The noun is scoped: this is the control plane for delegated authority, never an agent control plane, because it governs what an agent may do and never how the agent runs (the harness and the orchestrator keep operations). The category is unchanged: mission-based authorization remains the claim and the six-property litmus remains its gate, and control plane names where the layer sits operationally, not a new name for the layer. And a control plane is only as real as its data-plane contract, which is why the AuthZEN decision wire, the enforcement-scope statement, and the evidence family carry the interoperability weight, with the list the community still has to standardize naming what that contract still lacks at the tool boundary.

The model is stated, and its operational seat is named. What remains is judgment: the outside evidence for the shape, and the bets underneath it. The Convergence and the Wagers closes the handbook with both.

AAuth: the substrate that grew the object

The sharpest evidence for the fundamental-versus-accidental split arrived from outside this family. AAuth is Dick Hardt’s proposed agent-native authorization protocol, an active individual draft (at revision -11, September 25, 2026, and renamed draft-hardt-oauth-aauth-protocol along the way) that departs from OAuth’s redirect model rather than extending it: conversational, signed-request-first, with the Person Server as its governing party. It set out to rebuild agent authorization from a clean sheet, and in an early 2026 revision it grew the object this handbook argues for: a first-class mission layer, with a mission proposal and approval flow, an AAuth-Mission header on the wire (by -11 the reference travels as the mission_s256 claim or parameter, paired with the approving Person Server), mission-aware token choreography, and Person Server governance endpoints.

Name what kind of evidence this is, because it is not what convergence usually means. This author mapped the Mission model onto AAuth before AAuth had a mission layer, AAuth’s author read that work, and the next revision adopted the concept. So this is not independent replication, and the handbook does not claim it. It is adoption, and adoption is its own kind of proof: a protocol designer rebuilding agent authorization from a clean sheet, with his own architecture and every option to solve the gap differently, judged the object necessary enough to build into his protocol’s core. An idea wins two ways, by being found twice or by being adopted once by someone free to say no. This is the second, and it is a sharper test than any crosswalk this handbook grades itself, because the grader was outside. The alignment continues in the details: AAuth’s clarification chat, where an approver questions a proposal before consenting, is the interrogation channel the approval part records in Consent Evidence.

Where it stands is what the analysis works through: AAuth closed the “where is the mission layer” question and left the “what authority does the mission actually confer” question open, and the five laws are the yardstick to hold its model to as it matures: portable containment and lifecycle completeness, rather than mission correlation and governance hooks. The family’s AAuth binding is the constructive answer: it carries this model’s kernel (the approval, the Mission reference, the active-state gate, and the ordered mission log) at the Person Server with no new AAuth wire members, so the two proposals converge instead of forking. Its gating is scoped by access mode: the Person Server gates person-token issuance, PS authorization, and federated authorization, and the binding forbids claiming PS issuance gating for agent-identity and resource-managed access, where the agent calls the resource directly. The deep treatments are published: Mission Architecture on AAuth mapped the model onto the protocol before it had a mission layer, AAuth Now Has a Mission Layer re-ran the comparison after the revision, and Why Mission-Bound OAuth Might Be the Wrong Answer is the standing critique of the OAuth home itself.

The strategic position does not change, and it is worth restating with AAuth in full view: OAuth is the adoption path because it is where the deployments are, AAuth may prove the cleaner native substrate for the agents that come next, and the model, the laws, and the gate are built to survive either outcome. The falsifiable version of that sentence lives below, in where this could be wrong.

Where this could be wrong

An architecture document that only argues for itself is marketing, and an earlier post in this work’s ancestry asked openly whether Mission-Bound OAuth was the wrong answer. That discipline belongs in the handbook too, so here are the six bets most worth doubting, each with the evidence that would falsify it.

The admission-time bet. The model moves interpretation to admission, where an accountable authority, a human or a policy a human consented to, decides against committed inputs before any authority exists (who may approve). If agent work proves more emergent than that, if real tasks discover most of their authority mid-flight, then the discovery loop becomes the hot path instead of the exception, admission becomes the bottleneck no matter who staffs it, and deployments will choose between rubber-stamped ceilings and friction that drives them back to broad grants. Progressive authorization and policy adjudication within a human-consented ceiling are the hedges, and they are young precisely because nobody yet knows the sustainable grain. The price per admission is at least falling: an approved expansion no longer costs a restart, because a harness may rebind the running work to the successor Mission under freshly derived credentials. The falsifying evidence: expansion and exception rates that stay high after templates and organizational priors mature. And the quieter falsifier, because rubber-stamping improves those metrics while losing the bet: approval telemetry showing the decisions stopped being decisions, median time-to-approve collapsing toward the four-second reflex, disclosure interaction going to zero, and narrowing rates falling while approved breadth grows.

The issuer bet. The family puts the Mission at an issuer, the Authorization Server or the standalone MAS, because that is where approval, derivation, and revocation already live. But the work itself lives in harnesses and orchestrators, and the industry could consolidate governance there instead: the runtime platform as the source of truth for the task, with the identity stack reduced to credentials. The MAS binding hedges the deployment topology, not the ownership question. The falsifying evidence: harness vendors shipping proprietary task objects that win adoption without ever touching the token layer.

The revocation bet. The laws price Termination as non-negotiable, and much of the family’s weight, state-gated issuance, Status, the freshness bounds, the offline chain’s state check, is the cost of making revocation reach everything. A capability-native world could decide that short expiry with no refresh is enough, accept the bounded staleness, and skip the central state dependency entirely, trading the kill switch for autonomy and offline verification. If the market accepts that trade at scale, the category as this handbook defines it loses its fourth law to a cheaper approximation. The falsifying evidence: serious deployments running attenuable tokens with no state source and eating the staleness without incident.

The composition bet. The family bets that the approved task must be a first-class object. The alternative is composition: policy engines, workflow state, and richer token claims, wired together carefully, might deliver bounded, revocable, attributable agent work with no new object at all. Inside one administrative domain, a conventional stack does implement durable task state, fan-out joins, persistent narrowing, and audit locally, and the Architecture does not claim otherwise. The family’s answer is that composition without a shared root loses those properties where they cross bindings and trust domains: cross-audience revocation, cross-hop audit join, and integrity anchors every party reads the same way (what becomes possible only with a Mission), but that is an argument, not a deployment result. The falsifying evidence: production estates achieving task-bounded, task-revocable agent authority through composition alone, interoperably, without converging on a shared task object.

The portability bet. The family bets that Mission authority can travel: that the Authority Set, the subset rule, and Mission state can be projected across authorization domains without losing their meaning. Cross-domain reality is harsher. The downstream domain may not speak the parent’s authority vocabulary, may not be able to verify the upstream approval’s semantics, may disagree about what counts as narrower, and may honor an action that is locally permitted and globally outside the Mission. Revocation propagation across administrative boundaries is the same problem wearing its operational face. Cross-Domain Projection and the portable Mandate are the constructive answers, and conservative refusal is the fallback where translation cannot be trusted. The falsifying evidence: cross-domain deployments that abandon authority translation and fall back to local re-approval at every boundary, making the Mission a per-domain object after all.

The classification bet. The runtime gate is priced by the consequential/non-consequential line, and that line is deployment policy with only an extreme-end floor. The bet is that deployments hold the line under latency and cost pressure. The quiet failure is reclassification: consequential classes drifting below the gate because the PDP round-trip hurts, while the claim name never changes. The falsifying evidence: enforcement-scope statements whose mediated class list shrinks release over release while the claim name holds, the classification twin of the admission bet’s rubber-stamp telemetry.

None of these is a reason to wait. The issuance-only floor, Baseline Issuance, needs the OAuth binding and published RFCs and runs on Resource Servers that need not be Mission-aware. The remaining dependency risk sits in the drafts the Runtime-Enforced bundle adds, which the standards map names, none of it blocks the floor, and the laws are cheap to hold even if the bindings move. But a reader deciding how hard to bet should know which parts are invariants and which are wagers, and the split is this: the laws and the claim gate are the invariants. The admission grain, the issuer home, the price of Termination, the necessity of the object itself, the portability of its authority, and the classification line are the wagers, and deployment experience, not this handbook, will settle them.

Where the framework leads

The framework is the map. The build order is the journey, and it is deliberately staged as an adoption order: crawl with the OAuth binding’s issuance-only floor, walk with the Runtime-Enforced bundle where an action class needs a per-action, parameter-bound decision, and run with the Governed Agent and High-Assurance Agent bundles where unattended operation, delegation, or the high-consequence classes call for them. A deployment adopts the bundle its risk warrants and stops there, and a relying party compares the assurance claims a deployment can show, not its level. Adopting Mission-Bound Authorization carries that blueprint, the ecosystem to compose with, the operational surfaces you will own, and the pieces the community still has to standardize.

The so-what of the framework is what it does for the laws. It makes them portable: state them once, realize them per substrate, and hold every competing proposal to the same five.

And that is the handbook’s last word: not a token format, but an object the stack can hold, laws it can enforce, and a claim anyone can test. If a law is wrong, a wager mispriced, or a binding missing, the issues on the draft repository are where the argument moves.

The two models, in brief

An agent preparing a board packet has to make a sequence of tool calls across three MCP servers, each behind its own authorization domain: query_financials on a finance server, create_doc on a document server, notify_reviewer on a workflow server. The user approved the task before the agent started (“prepare the Q3 board packet for the audit committee”), but in today’s systems that approval is application state, not protocol authority. Each call still has to be authorized at the right grain.

There are two natural ways to do that, and the Least-Privilege MCP series walks both in full. Token-side authorization carries the authority in the credential. The agent discovers what the server requires, asks the right Authorization Server for a token narrowed to the action, and presents it. Resource-side authorization keeps the decision at the resource. The MCP server is the Policy Enforcement Point, asks a PDP whether this exact call is allowed, and uses a requestable denial when the missing authority can be requested. Least-Privilege MCP Tool Calls compares the models, and Closing the Gaps covers the standards that make per-call decisions interoperable: AuthZEN for the decision shape, COAZ for the MCP mapping, ARAP for turning a denial into a governed request.

Both authorize one call well. Both share one blind spot. Tokens describe what authority a credential carries. PDP decisions describe whether a specific call is permitted. Neither describes the task the user actually approved. So once the task fans out across three servers and three authorization domains, the authority for it fragments. The user sees repeated approval prompts for fragments of one task. The agent accumulates narrow tokens or pending requests with no shared lifecycle. Audit joins fall back to timestamps and log correlation, and correlation is not governance. The protocol stack has no standard object that names the task. That is the gap this essay closes.

A Mission makes that governed task an explicit protocol object both models can bind to, while each MCP server or Resource AS keeps its own domain semantics and local policy. What that buys, and how it is owned, derived, and enforced, is the rest of this essay.

Board packet before and after

The board-packet example is the whole problem in miniature.

That is the standardization point. Least privilege per call is necessary, but it is not sufficient for agent tasks. The calls need a common object to point back to.

What a Mission fixes

A Mission is that missing object. It is the durable, approval-backed governance object for the task, held at the Authorization Server that approved it and identified everywhere by mission.id and mission.issuer. Tokens and PDP decisions carry or resolve a binding to that record. As the Mission series argues, the missing abstraction is not another credential or evaluation point. It is the governed task those artifacts serve. The precise definitions live in the Reference, and this task is its running example.

The flow is the Mission series’ spine applied at the MCP boundary. A shaper turns the prompt into a structured Mission Intent and proposes it through Pushed Authorization Requests (From a Request to an Approved Mission). The Authorization Server validates the Intent, derives the Authority Set the user will be asked to approve, and renders that derived set for consent. On approval it records the Mission, committed by intent_hash and authority_hash, and issues Mission-bound tokens carrying the mission claim (The Mission Is the Missing Abstraction).

For the board-packet task, the shaper submits this Mission Intent at PAR. The mission_intent parameter carries it inside a Submission envelope, with no Intent Submission Evidence alongside it here, and intent_hash covers only the intent object:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "purpose": "urn:example:mission:board-packet",
    "target_resources": ["https://finance.example.com",
      "https://docs.example.com",
      "https://workflow.example.com"],
    "task_bounds": ["Q3 2026", "Example Corp", "confidential"],
    "expires_at": "2026-10-15T18:00:00Z"
  }
}

Note what the shaper does not author. It names target resources and human-readable task bounds, and any candidate authority it offers rides beside the Intent as standard top-level authorization_details (absent here), untrusted input the Authorization Server only narrows, committed by the conditional proposal_hash. The consented Authority Set is always the AS’s derivation, never the proposal itself, and shaping proposes only carries the member mechanics. The AS derives the authorization_details from the approved Mission and returns the derived array alongside the access token:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

[
  {
    "type": "mission_resource_access",
    "resource": "https://finance.example.com",
    "actions": ["query_financials"],
    "constraints": { "period": "Q3 2026" }
  },
  {
    "type": "mission_resource_access",
    "resource": "https://docs.example.com",
    "actions": ["create_doc"],
    "constraints": { "template": "board-packet" }
  },
  {
    "type": "mission_resource_access",
    "resource": "https://workflow.example.com",
    "actions": ["notify_reviewer"],
    "constraints": { "group": "audit-committee" }
  }
]

Read the two exhibits together and the trust boundary is visible in the bytes. “Q3 2026” is a human-readable task bound in the Intent and structure in the derived entry, and no function parsed one into the other. No authority was proposed, so the AS derives the set in configured-mapping mode: the mapping configured for the board-packet purpose binds the current reporting period (Q3 2026), the board-packet template, and the audit-committee group, within the Intent’s target_resources. The task_bounds are shown to the user beside the result; the AS does not read them, and the Approver’s check that the structure matches the words is what joins them. The derivation policy, concretely carries that boundary in full.

The approved Mission Intent itself stays on the Mission record at mission.issuer. Consumers learn Mission state through introspection, the Mission Status operation, the Mission Status List where one consumer relies on many Missions, or Lifecycle Signals (Mission Lifecycle and Change), never from an unauthenticated request parameter.

The Mission fixes both models because it separates concerns they otherwise conflate. The Authorization Server owns the user-approved task, its integrity anchors, and its lifecycle. The Authority Set is the typed maximum authority derived from that task. Each MCP server or Resource Server owns the domain semantics and local policy for its tools. The validating AS does not have to implement every resource’s policy engine. It validates the Mission Intent against client registration and deployment policy and derives authority only for resources it recognizes. The finance, document, and workflow systems remain authoritative for local resource policy. This division does not remove the ontology problem Least-Privilege MCP Tool Calls names. It makes the boundary and the validation responsibility explicit.

The Mission Intent does not need to carry exact MCP tool names. The Authority Set can describe actions at a grain the AS and the Resource Server can jointly validate, and the Resource Server still maps approved authority to concrete arguments and local policy. Where a deployment wants the approved action pinned to a specific capability, the Mission Capability Binding companion to the runtime layer binds it to the source and content digest recorded at derivation, such as a tool in a captured MCP tools/list snapshot, and verifies it at decision time. If the tool is later redefined or poisoned, the digest mismatch fails closed as capability_drift (Mission-Bound Runtime Enforcement).

One deployment note. The default topology holds the Mission at the Authorization Server. A deployment that cannot change its AS can adopt the Mission Authority Server instead: a standalone Mission Issuer over the OAuth Mission data model that derives no tokens, with the PDP joining each ordinary OAuth token to its Mission at the point of use. On its own that mode trades away Mission-bound credentials and issuance gating, resting entirely on PEP coverage, and The Authority Control Plane prices that trade. The Mission Issuance Grant buys both back at each Authorization Server that redeems its grant for Mission-bound tokens: an AS with a Mission-state integration checks the Mission at redemption and at every refresh, and one without issues no refresh tokens.

The pipeline with a Mission in scope

The per-call pipeline from the MCP series’ first two parts (discover, request or evaluate, authorize or escalate, execute) does not change shape. What each step refers to does. The Mission bootstrap (Intent at PAR, validation, derivation, consent) happens before step 1.

1. Discover. tools/list is filtered against the Mission’s Authority Set projection and local policy. A tool unrelated to the approved task need not appear. This is exposure control, not enforcement. Every consequential tools/call still passes the runtime gate.
2. Request or present. A token-side request presents the Mission-bound credential for the derivation flow. A resource-side call presents the Mission-bound access token to the MCP server. Either way, mission.id and mission.issuer come from a validated artifact or trusted server-side binding.
3. Evaluate. The PDP evaluates the concrete action against two authority bounds, the audience-relevant entry the credential carries and the Mission’s current Effective Authority Set (the approved set after any discharge or containment), and against the concrete parameters, the actor chain, resource policy, and current Mission state, within the deployment’s freshness bound (Mission-Bound Runtime Enforcement).
4. Authorize or escalate. An in-bounds request produces a Mission-bound token or permit without expanding anything. Local policy may still require step-up authentication or an action-bound approval. A request that would broaden committed authority routes to Mission Expansion, which is a fresh approval creating a successor Mission (Mission Lifecycle and Change).
5. Execute. The MCP server enforces the permit at the last controllable boundary and reverifies parameter bindings. The PDP’s Decision Evidence and, for high-consequence classes, the MCP server’s Execution Evidence are bound to the Mission, so records across authorization domains join.

Tool discovery, invocation, and approval

The three authorization problems from Least-Privilege MCP Tool Calls line up cleanly once the Mission is in scope.

Tool discovery. Filtering tools/list against the Mission projection reduces exposure. It does not replace authorization of tools/call.

Tool invocation. Both models now have an object to point at. The Mission-bound token is least-privilege at the token grain and tagged with the task it serves. The PDP decision is least-privilege at the per-call grain and tagged with the same task. Either way, the invocation is bound to a specific user-approved task, not just to a specific resource.

Tool approval. Approval, consent, and access request share one governance surface without having identical lifecycle effects. In-bounds clarification, argument capture, step-up, or an action-bound approval for an action already inside committed authority leaves the Mission unchanged and is recorded in Decision Evidence. A request that would broaden resources, actions, constraints, audience, budget, or lifetime is Mission Expansion. The AuthZEN profile can mark an out_of_authority or approval_required denial as requestable, ARAP carries the request, and a grant lands as a separately approved successor Mission. The approver sees the Mission lineage rather than an isolated tool fragment.

The two models converge on the Mission. One Mission-level approval projects into many tokens and PDP decisions, while resources retain their own policy and interaction requirements.

The Mission is not a global operation vocabulary, and it does not eliminate the need for RAR-type metadata, AuthZEN evaluations, or Resource Server policy. It supplies the shared task handle and lifecycle. Resource domains still define their own semantics. This is the ontology problem and its policy-mapping half by name: the resource owns the meaning, and the governance and policy layers consume it through registered semantics, published metadata, capability digests, and, where the substrate supports it, the resource’s own hash-committed declaration (who owns the meaning is the Reference’s map). That division of concerns is the point:

That is why the Mission composes with both styles: the same governed task and Authority Set to project from, never the grant itself.

Agents do not only call tools

The MCP tool boundary is one place this pattern surfaces. The egress boundary is another. When an agent reaches a destination its egress proxy does not allow, the result today has the same shape as a flat 403 with no machine-actionable recovery, and the same pipeline applies with the proxy as the PEP. A Blocked Agent Is a Captive Client sketches the approval architectures for that boundary.

A Mission ties both boundaries together. Policy at the MCP and egress boundaries derives from the same Mission and Authority Set. In-bounds tool calls and destinations clear without a new Mission-level prompt, subject to local runtime policy. Authority-expanding events at either boundary route to Mission Expansion at mission.issuer. The approver sees one Mission lineage, not unrelated streams of tool and egress approvals. Real agents touch both boundaries on every non-trivial task. The board-packet agent does not only call MCP tools. It also fetches reference data from partner APIs and pulls public reports. The same governance object spanning both boundaries is what keeps the audit trail coherent, and the harness is what guarantees there is no unmediated route around either PEP.

Tracing a denial end to end

The framework above is easier to evaluate against a concrete failure mode than against the happy path. This walkthrough traces one Mission from approval through an out-of-bounds attempt, an expansion request, a user denial, and the resulting audit query. It is the Reference’s running example at the MCP boundary, and each stage names the part that defines the mechanic.

Stage 1, approval. The user asks an agent to prepare the Q3 board packet. The shaper turns the prompt into the Mission Intent shown above and submits it at PAR, recording Shaping Evidence (From a Request to an Approved Mission). The AS validates the Intent, derives the three-entry Authority Set, and renders the derived set for consent. On approval it creates msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p in the active state, committing intent_hash and authority_hash, and issues Mission-bound tokens (The Mission Is the Missing Abstraction).

Stage 2, out-of-bounds attempt. Two hours in, the agent decides the packet needs CRM data on key accounts. CRM is not among the Intent’s target resources or in the Authority Set. The call reaches the CRM MCP server’s PEP, whose PDP finds no mission_resource_access entry covering it and returns decision: false with context.reason set to out_of_authority (Mission-Bound Runtime Enforcement). Because the missing authority is eligible for expansion, the denial is marked requestable with the deployment’s Access Request binding context, and the PDP writes Decision Evidence, which records the same value as denial_reason, bound to the Mission, its decision basis (a policy-view identifier, or the authority_hash with the PDP’s policy version where it evaluates the recorded authority directly), the requested action, and the actor context.

Stage 3, expansion request. The orchestrator uses the requestable-denial context to submit the CRM authority through ARAP, and this deployment realizes the request as a Mission Expansion. Expansion is an RFC 8693 token exchange that carries the successor’s mission_intent and presents the predecessor’s sender-constrained Mission-bound access token as the subject_token (a refresh token is refused, and the possession proof is an eligibility rule, not an authority path), so the AS adjudicates a successor of that specific Mission, obtaining fresh consent on the successor’s full derived authority rather than a delta over the predecessor (Mission Lifecycle and Change).

Stage 4, user denial. The user declines. CRM access is out of policy for board-packet preparation. No successor Mission is created, nothing supersedes anything, and msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p stays active with its original three entries. Subsequent identical attempts remain denied, and a deployment may suppress duplicate prompts with a denial cache.

Stage 5, audit. A week later, a governance reviewer queries the Authorization Server for the Mission’s lifecycle events and the PDP’s evidence store for records bound to mission.id and mission.issuer. The lifecycle records show approval at T0, no successor, and no termination. The evidence records show the permitted finance and workflow operations, the denied CRM attempt, and the denied expansion attached to it. Where the deployment registers evidence into a SCITT Transparency Service, the whole history is one verifiable, append-only feed under the Mission’s subject (The Agent Runtime and Audit). The join is deterministic, not stitched from timestamps. That property has a name the series adopted: verifiable continuity, the approval, the denied attempt, the expansion, and every permitted operation provably one undertaking, which is a different property from the lifecycle continuity that lets parked work survive a disconnect.

That is the answer to the question the MCP series keeps asking. “Did the agent stay within what the user approved?” is answerable only if the protocol knows what was approved. The Mission is that record. The Authority Set and the evidence answer what was allowed and what occurred, and the denial trace shows the whole spine holding under refusal, which is where governance systems usually fall apart.

Where to start building

Start with the per-call foundations from the Closing the Gaps checklist: authorize every tools/call at the MCP server, filter tools/list with the same policy, and adopt the AuthZEN decision shape so denials can become governed requests. Each pays for itself before any Mission machinery arrives. The Mission layer is what makes them compose:

• When approvals must compose across calls, servers, or authorization domains, adopt the issuance profile so both models project from the same task object (The Mission Is the Missing Abstraction), and add the runtime and AuthZEN profiles for the per-action gate and evidence (Mission-Bound Runtime Enforcement). With a freshness source in place, that is the Runtime-Enforced level of the Mission Assurance Levels.
• When revocation must bite faster than token expiry, add Mission Status, the Mission Status List where one gateway relies on many Missions, and Lifecycle Signals as the freshness source (Mission Lifecycle and Change).
• When the approval itself must be trustworthy, add shaping discipline and Consent Evidence (From a Request to an Approved Mission), and the harness for session and egress mediation (The Agent Runtime and Audit).
• When the Authorization Server cannot change, the Mission Authority Server is the standalone controller over the OAuth Mission data model: governance and per-action enforcement with ordinary tokens, at the cost of issuance gating unless an Authorization Server redeems its Mission Issuance Grant for Mission-bound tokens.
• For the full map of levels and maturity, the Mission Assurance Levels in Adopting Mission-Bound Authorization and the draft-family table in the Reference are the current state.

Missions do not replace resource authorization. They organize task identity across calls, servers, authorization domains, and credential substrates. Token-side and resource-side are two OAuth-shaped ways authority reaches enforcement. In either, carry authority when it must travel, evaluate locally when context must stay local, and bind the resulting actions to the Mission when work spans calls, tools, or domains.

This is the standing reference for the Mission-Bound Authorization handbook. It is written to be linked, quoted, and shared. The parts carry the argument. This page carries the definition, the litmus test, the landscape, and the vocabulary. The top of the page is the citation kit, each item written to be copied whole, with Mission-Bound Authorization on the Wire as the companion exhibits. The litmus test and everything deeper follow. Everything here tracks the draft family’s editor’s copies as of October 5, 2026.

Mission-based authorization in brief

Mission-based authorization governs the approved task, not just the credential, session, or individual request.

It is a category, not one product. Mission-Bound Authorization, the draft family this handbook explains, is one concrete instance of it, carried on five peer bindings, with OAuth 2.0 as the first, on the most deployed infrastructure.

The vocabulary has a strict hierarchy:

A mission-based authorization system has a durable approved task object, derives authority from it, lets that authority only narrow, and ends it with the task’s lifecycle. At runtime strength it also checks consequential actions against the task’s current state and binds audit evidence back to it.

Why existing objects are not enough: a token authorizes a request, a session preserves runtime continuity, a scope names requested authority, a task/trace ID correlates activity. None of them is the approved task with a lifecycle that authority is derived from and gated on. That object is the Mission.

The triad that makes it work:

Tokens carry authority. Missions govern purpose. PDPs enforce actions.

And its limit:

A Mission-bound token is as strong as the Resource Server that enforces its bounds. Per-action, parameter-level, and state-aware checks come from runtime enforcement.

The bottom line

Mission-based authorization is the missing layer between user intent and per-request authorization. It makes the approved task a first-class governance object: tokens and delegation derive from it and only narrow, and its lifecycle ends them. At runtime strength, each consequential decision and its evidence bind back to it as well.

And the positioning line, for the slide:

Identity says who. Credentials say what may be accessed. The Mission says what the work is, who approved it, and when it ends.

The Mission, in one sentence

The Mission is a durable, approval-backed governance object for authorization: the approved task, with a lifecycle, that authority is derived for, bound to, and gated on. In a Mission-Bound deployment, credential issuance, runtime decisions, and audit records project from it.

And the questions, laddered, because each generation of the stack answered one and the last never became first-class:

And the shorthand contrasts, for the same slide:

The five laws of delegated authority

The layer’s invariants, stated to be quoted. They hold on any substrate, and the handbook is an enforcement mechanism for all five.

1. Durability. Authority must outlive credentials.
2. Attribution. Every action must remain attributable, and the approval record commits exactly what the approver was shown.
3. Narrowing. Authority can only narrow as work fans out.
4. Termination. Revocation must end authority, not merely tokens.
5. Containment. Execution must continuously remain inside approved purpose.

Each law is easiest to remember by its violation:

The names are stable across the handbook: Durability is always Law 1, Containment is always Law 5. The specification family states them in its own terms, mapped below.

And the design stance beneath all five, inherited from the Mission Shaping series:

Survivable incorrectness: the system remains governable and limits damage even when the agent’s semantics are partial or wrong. Perfect fidelity is not achievable at agent scale. Survivable failure is.

The laws in the drafts’ terms

The specification family states the same ground twice, and neither statement maps one to one onto the laws. The Architecture document’s seven Mission Invariants are the substrate-neutral form. The OAuth binding’s six properties, listed in its Implementation Map, are what token issuance alone establishes; they are a different six from the litmus properties. A reader moving between the handbook and the drafts can translate with this table:

One invariant, only active permits, serves two laws: Termination at issuance and Containment at each decision. No binding property names the actor chain, which the binding carries in RFC 8693’s act claim as attribution.

The numbers

The handbook counts several things, and each count has one job:

The six questions are the six litmus properties in interview form, and the laws are what those properties enforce.

The layer vocabulary

Four functions any implementation of the layer must supply, whatever it names its governance object:

• Authority compilation: approved intent becomes bounded, integrity-anchored authority.
• Authority projection: that authority reaches instances, credentials, domains, and delegates without ever exceeding its source.
• Authority containment: every consequential action is checked against the approved purpose at the point of use.
• Authority continuity: reliance stays conditioned on the current state of the task, across time and across the runtime.

The reference security architecture

Reference security architecture = issuance profile + runtime enforcement + AuthZEN profile + runtime evidence + a freshness source (Status, or issuer introspection)

This is the Runtime-Enforced bundle as a formula, and the sizing is real: a substantial build, not a wedge, measured from the runtime profile’s conformance section rather than from this one line. The issuance-only floor (Baseline Issuance) needs the OAuth binding and published RFCs, and it runs on Resource Servers that need not be Mission-aware. The drafts the Runtime-Enforced bundle adds, which is where the remaining dependency risk sits, are named in the standards map and, document by document, in the adoption sheet; none of them blocks the floor. Lifecycle Signals, the push complement, sits outside the formula. The architecture chapter carries the sizing argument, and Adopting Mission-Bound Authorization carries the staged build order.

The honest deployment claim

A deployment claim names its assurance claims and its enforcement scope, and every line can be verified against the implementation checklist below. The assurance claims are what a relying party compares: approved-record integrity, bounded revocation latency per path, action-time enforcement, parameter-bound enforcement, transaction-grade execution, and the named high-assurance claims, each with a proof obligation an existing profile fixes. The adoption bundle names the documents a deployment runs and the claims that become available with it. The architecture’s Mission Deployment Profile is the spec-level form of this claim: the composition of the per-layer statements the profiles themselves demand, covering level, binding, state sources, PEP coverage, custody, evidence, and residual_risks, with the machine-readable manifest schema named as deferred family work. The coverage split is what a reviewer reads first: which paths are mediated per action, which are issuance-gated only with revocation bounded by the token lifetime, and which are unmediated and named as exclusions.

What not to claim

The negative space of the claim, stated to be quoted:

• A Mission-bound token alone is not action-time defense. A check finer than the bounds its Resource Server enforces needs a PEP on each consequential action. And the OAuth binding’s taxonomy polices the word itself: a token that merely references or carries Mission data without state-gated issuance is not Mission-bound, only Mission-referenced or Mission-derived.
• Status without PEP coverage is not runtime enforcement. Freshness feeds a gate. It does not replace one.
• Signals without a fail-closed state source is not revocation safety. A missed event must read as stale state, never as still active.
• Harness logs without mediated execution paths are not containment. A record of the resume is not a boundary on it.
• Audit transparency is evidence, not prevention. It makes a false record permanent and attributable. It stops nothing.
• A renewed charter is not a governed standing agent. Renewal is a review only when the prior cycle’s record is in front of the reviewer, and a ceiling whose renewals carry no evidence review is a blank check with a calendar.

Revocation, in one statement

Revocation changes the Mission’s authoritative state immediately. Enforcement latency is path-dependent: runtime-gated actions stop within the published freshness bound, new derivation stops when the issuer observes state, and outstanding offline-valid tokens run to expiry unless the path checks Mission state.

When revocation bites

Termination is a law, and its implementation burden lives in this table. Revocation ends authority only where enforcement consults live Mission state within a published bound. What a deployment runs determines what it may claim:

Revocation is also only one kill among seven. The containment matrix places Mission termination beside the capability, agent, Agent Deployment, credential, workload, and egress kills, each with its own blast radius and owner, because revoking a Mission terminates no process and closes no network path.

The canonical picture

One diagram for the whole model: the six stages, and the actors and objects in each.

Everything below is the detail behind the bottom line: what qualifies as mission-based (litmus), how it differs from what you already run (landscape), the smallest useful deployment (the adoption order), the checkable claim (checklist), what it does not solve (non-goals), the glossary (Appendix F), and one worked example.

Mission-based authorization as a category

The field has converged on the same gap from several directions: agent IAM, intent-based access control, capability systems, the lethal trifecta. The shared answer is to elevate the approved task to a first-class object. That move is the category. A system is in the category whether it calls the object a Mission, a charter, or a governed task, and whether it rides on OAuth, on a clean-slate agent protocol, or on something else. The decisive distinction from every task-shaped record nearby is not the fields: the object is the authorization root, with authority derived from it, execution enforced against it, and lifecycle and evidence joined on it. In infrastructure terms the category is the control plane for delegated authority: the layer that holds the desired state of the work, with credentials and enforcement as the data plane reconciled against it.

Identity was the control plane for human access. The Mission layer is the control plane for delegated authority.

The category is not enterprise-shaped either, even though this handbook’s examples deliberately are. A vacation-planning agent’s Mission has the same anatomy as the board packet’s (an approved task, authority derived from it, an expiry, and evidence that joins), and the same is true for the smart-home agent or the assistant booking a dinner. The handbook’s examples stay in the enterprise because that is where the adoption pressure, the estates, and the approval workflows live, not because the object knows the difference.

This handbook is about one instance: Mission-Bound Authorization, the draft family where the object is the Mission and enforcement uses a PEP/PDP contract. Its first binding, on the most deployed infrastructure, is OAuth 2.0, where authority is derived as Rich Authorization Requests and the token binding is the mission claim. Its peers are the standalone Mission Authority Server, a deployment topology over the same OAuth Mission data model; AAuth; and the UMA 2.0 and GNAP sketches, each with its binding’s own authority semantics. Where this page says “mission-based,” it means the category. Where it says “the Mission” or names a draft, it means this instance.

The category does not depend on OAuth. OAuth is the substrate used here because it is the dominant deployment reality, and it already supplies the derivation, exchange, sender-constraint, and revocation machinery a Mission binds to. The family itself now demonstrates the independence: the AAuth binding maps the Mission kernel (approval, the Mission Reference of the approving Person Server and s256, the active-state gate, and the ordered mission log) onto AAuth’s native mission at the Person Server, against AAuth -11 (2026-09-25) and the exploratory R3 -00 (2026-09-28). Authority stays in AAuth’s own scopes, resource tokens, and optional R3, the lifecycle stays active or terminated, and the Person Server gates only person-token issuance, PS authorization, and federated authorization. AAuth Mission Expiry profiles AAuth’s native expires_at, and AAuth Mission Management adds authenticated status and termination. Mission Substrate Requirements consolidates what any further binding must provide, a mandatory contextual-governance kernel plus eight optional capabilities claimed per binding, and the experimental UMA 2.0 sketch is the first binding authored against that contract, with RPT issuance and upgrade gated on Mission state. This handbook’s reference model is the six properties, and OAuth is its first binding.

Mission-based authorization and IBAC

Intent-Based Access Control (IBAC) is the property: authorize by what the user approved, not by what an agent infers at runtime. Mission- based authorization is the mechanism that makes IBAC practical, by moving interpretation to admission, before any authority exists, where an adjudicator (the user in the common case, otherwise a deterministic, versioned policy acting within a ceiling a human consented to) decides against committed inputs with a human accountable as the Approver, and committing the result so enforcement consumes approved intent instead of reconstructing it. The distrust of runtime-stated intent is shared ground now: the proposed CB4A credential broker meets the same threat and resolves it by demoting the agent’s stated justification to audit evidence, excluded from authorization. The Mission resolves it the other way, by making approved intent the authorization root. IBAC is the property. The Mission is the object that carries it.

What counts: the litmus test

The test is this handbook’s category bar, and it splits at two strengths. A system is mission-based at issuance strength, the strength the Baseline Issuance bundle provides, when the first four category properties hold:

1. Approved task object: a durable record of the approved task, activated by a human or by a versioned policy within a ceiling a human consented to, with a human accountable. Not a prompt, trace ID, session, ticket, or token.
2. Authority derivation: credentials and decisions are derived from that approved task, not minted independently of it.
3. Narrow-only delegation: derived authority, child tasks, and sub-agents can only narrow. Exceeding the parent requires a fresh approval.
4. Lifecycle: the task can expire, be revoked, expand (via fresh approval), and complete. Only an active task permits reliance.

It reaches runtime strength, the bar behind any action-time defense claim and behind the action-time assurance claims that become available with the Runtime-Enforced bundle, when two more hold:

5. Runtime enforcement: consequential actions are checked against the current task state at the point of use, not just at issuance.
6. Evidence: decisions and lifecycle events bind back to the task, so audit can reconstruct it. This is verifiable continuity: the approval, the decisions including denials, and the executions can be shown to belong to one undertaking.

Relax any of the first four and the design is not mission-based: scopes without a task, sessions without approval, a PDP without an approved object. Hold the first four without the last two and it is mission-based at issuance strength, and it claims nothing about action-time defense.

The bar is stricter than the drafts’ own substrate contract. Mission Substrate Requirements requires a kernel (a Mission reference, controller and actor binding, approved context, an approval event, an active/non-active gate with bounded reliance, context propagation, and an ordered governance record) and treats structured authority and monotonic derivation as optional capabilities, so a binding can meet the substrate contract and still fail properties 2 to 4.

What looks like a Mission but is not

The object-level version of the same test, useful when someone points at an artifact and asks “is that the Mission?”

What becomes possible only with a Mission

The case for the Mission as a primitive, not just a useful design pattern, is concrete. The following all require a shared, integrity-anchored task object, and none is reliably achievable through disciplined use of existing OAuth primitives alone:

• Cross-audience revocation of a long-running task. Without a shared task identifier, revoking an agent’s work requires hunting credentials at every audience independently. With the Mission, revocation at one state authority terminates future derivation across every audience that ever projected from it.
• Cross-hop audit join on the user-approved task. Without a shared identifier, audit reconstruction stitches per-AS logs by timestamp and client identifier. With the Mission, every record across every audience and substrate joins through mission.id and mission.issuer.
• Cryptographic commitment to the approved record. Without integrity anchors over a canonical Mission Intent and Authority Set, the authority’s record of approval is reconstructed from per-token authorization_details and consent-system logs. With intent_hash and authority_hash, the approved intent and the derived authority are committed at activation and can be checked for later modification, and the Consent Evidence companion’s consent_rendering_hash commits the presented disclosure where that profile is deployed. The hashes do not prove that a renderer displayed those objects faithfully or that a human understood them.
• Lifecycle as an authorization input. Without a Mission state machine, refresh and exchange gate on token validity alone. With a Mission, refresh, exchange, ID-JAG issuance, and PDP decisions all consult Mission state. A suspended or revoked Mission stops future derivation regardless of credential expiry.
• Risk evaluated at the undertaking’s grain, not the call’s. Without the Mission, the resource prices every action in isolation, and “delete database” carries the same risk whether it is a stray action or step four of an approved migration. With the Mission, the decision knows the committed why and the undertaking’s recorded progress, because evidence joins on mission.id, so a precondition like “the copy steps completed” is a checkable fact rather than a hope. The context is committed and recorded, never inferred, and no per-call primitive can supply it, because a resource holds that history only where it runs the workflow itself.
• Governance without changing the issuer. Without a Mission service, a deployment that cannot modify its Authorization Server has no governance object at all. With the Mission Authority Server, the Mission record and its lifecycle live in a standalone service that serves the status and lifecycle surfaces itself, and a PDP joins ordinary tokens to the Mission at the point of use.

Each of these can be approximated with deployment-specific extensions. None is interoperable across vendors without a standardized object. That is the difference between a useful design pattern and a primitive.

The Mission object model

The approved task is a typed object, not a label, and it is an aggregate of three logically separate components plus a stable identity:

The approval commitment, immutable after approval:

• Purpose: an optional task-class URI, not the instance.
• Mission Intent: the structured, approved task description, committed by intent_hash.
• Consent reference: a pointer to the canonical disclosure behind the approval, hashed by the optional Consent Evidence companion so an auditor can verify the stored disclosure has not changed.
• Authorization basis: the approved root the Mission traces to, recorded as approval_basis beside the approver and never folded into the hashes: direct for a human’s own approval, or a standing-consent basis such as template or policy_drawdown, each naming the same accountable human as consent_principal. It also records what activated this instance (activation), who triggered it (activation_actor), and the consented root (root_commitment), and it can name the deciding mechanism (adjudication): the human Approver, or a deterministic, versioned policy acting within a ceiling a human consented to. A model’s judgment enters adjudication only as a recorded input to that policy, and it can refuse or narrow, never grant or widen.
• Authority source: whose authority the approval draws on, recorded immutably as authority_source: user_delegated, service_owned, or organizational (naming its governed policy). The AS verifies the Approver may activate the source and that the derived Authority Set lies within it, distinct checks, because an organizational owner may activate policy without personally holding every operational permission.

The approved authority, immutable after approval:

• Approved Authority Set: the maximum grantable authority derived from the Intent and fixed at the approval event, committed by authority_hash. Authority is one component of the Mission, not the whole. The ceiling the derivation narrows against is itself a composition: the issuer’s derivation policy intersected with the ceiling of the Mission’s authority source (a delegating person’s own authority, a workload’s provisioned authority, or governed organizational policy), because approval activates authority the source already holds, and the Approver needs authority to activate the source, not personal possession of its permissions, while resource-owner and deployment policy stay live checks at each decision point. Where the client proposed authority as top-level authorization_details beside the Intent, the conditional proposal_hash commits the proposal, so the narrowing from proposal to derived set is itself checkable.
• Delegation context: credentials derived for delegated actors stay bounded by the same Mission and preserve authenticated actor context (the RFC 8693 act chain where an adopted profile supplies it). An ordinary Token Exchange (in-Mission delegation or self-exchange down-scoping) derives tokens under the same Mission and never creates a child Mission. A Child Mission comes only from the Child Delegation profile’s child-creation token exchange, and broader authority is a separately approved successor via Mission Expansion.

The lifecycle state, mutable and versioned:

• Lifecycle state: owned by the issuer, with a state version for concurrency control. Only active permits reliance.
• Effective Authority Set: the Approved Authority Set after every issuer-held narrowing the deployment runs, such as containment and entry discharge, has subtracted from it. The Status profile owns it, and a narrowed Mission stays active.

The identity, immutable:

• Identity: id and issuer, the same pair on the record and on the mission claim that every projection carries.

The mutability rules answer the questions the aggregate raises. The hashes commit the approval side and never change afterward. A lifecycle transition changes the state and its version; subtraction changes the Effective Authority Set and its version while leaving the lifecycle state unchanged. Suspension changes reliance, not the approved task. Completion records fulfillment and retires reliance. Widening anything committed is a separately approved successor Mission, never a mutation. And a Child Mission inherits a subset of the parent’s Effective Authority Set under the subset rule, with its own lifecycle bounded by the parent’s.

Authority moves along one path, and no stage holds more than the one before it:

The lifecycle gate sits beside the path: resume reopens a suspended Mission’s gate without changing either set.

“Consent” here names the Mission-layer authorization anchor, the legitimacy source that approved this specific Mission. That is a narrower technical use than GDPR-style data-processing consent, and deployments subject to those regimes still owe their own consent contracts on top. Where no user is present at approval time, the anchor is a prior human-approved template Mission, a standing organizational policy in a formal auditable language, or a verifiable standing delegation from a service owner. LLM inference about organizational intent, runtime configuration supplied by the agent, and pre-existing general-purpose scope grants anchor nothing, because they do not establish authority for a specific Mission.

Everything an agent touches is a projection of this object: a Mission-bound token, a runtime decision, a child Mission, a lifecycle signal, an evidence record. Each carries the Mission reference and derives from, never exceeds, the Effective Authority Set.

The subset rule, compactly, for the mission_resource_access entries every example here uses. The OAuth binding’s own rule is type-agnostic, and the Resource Access Profile defines this type’s comparison. Every derivation, delegation, exchange, and attenuation yields authority that is:

• the same or a narrower resource set (exact match by default, or the opt-in prefix containment),
• the same or a smaller action set,
• the same or tighter constraints,
• expiry no later than the Mission’s expires_at,
• per-entry delegation policy no broader (max_depth no greater, allowed_delegates no wider),
• and the same mission claim, because re-binding to a different Mission is refusal, and crossing a trust domain rides a separately approved, audience-scoped projection.

Widening anything on that list is a fresh approval, never an inference.

One distinction matters. What the machinery tests is representational narrowing: the child’s authority is formally no broader under the comparison relation the entries define. Semantic narrowing, that the child cannot produce effects outside the parent’s approved boundary, is a stronger property that representation alone cannot always prove, especially where constraints are contextual, quantitative, or translated across domain vocabularies. Where the two can diverge, the family’s answer is conservative refusal or a separately approved projection, never an optimistic mapping.

The Mission contains the Authority Set. The Authority Set does not define the Mission. A bundle of permitted actions with no approved task, lifecycle, or evidence is just authority, which OAuth already had.

A concrete Mission record

The running example as a record. Its intent_hash and authority_hash are the ones reproduced byte-for-byte in Reproducible test vector below. No authority was proposed at submission, so the conditional proposal_hash is absent, and the AS derived the set in configured-mapping mode: the mapping for the board-packet purpose binds the current reporting period, the board-packet template, and the audit-committee group, and the AS never reads the task_bounds shown to Alice. The record carries the authorization basis and authority source the OAuth binding requires.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

{
  "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "purpose": "urn:example:mission:board-packet",
    "target_resources": ["https://finance.example.com",
      "https://docs.example.com",
      "https://workflow.example.com"],
    "task_bounds": ["Q3 2026", "Example Corp", "confidential"],
    "expires_at": "2026-10-15T18:00:00Z"
  },
  "authority_set": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } },
    { "type": "mission_resource_access",
      "resource": "https://docs.example.com",
      "actions": ["create_doc"],
      "constraints": { "template": "board-packet" } },
    { "type": "mission_resource_access",
      "resource": "https://workflow.example.com",
      "actions": ["notify_reviewer"],
      "constraints": { "group": "audit-committee" } }
  ],
  "intent_hash":
    "sha-256:yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw",
  "authority_hash":
    "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY",
  "subject": { "iss": "https://login.example.com",
    "sub": "alice@example.com" },
  "approver": { "iss": "https://login.example.com",
    "sub": "alice@example.com" },
  "approval_basis": {
    "type": "direct",
    "consent_principal": { "iss": "https://login.example.com",
      "sub": "alice@example.com" },
    "activation": { "approval_event_id": "ape_5D8wQ1kR7mX2vT4nH6jZ" },
    "activation_actor": { "iss": "https://login.example.com",
      "sub": "alice@example.com" },
    "adjudication": { "kind": "human" },
    "root_commitment":
      "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY"
  },
  "authority_source": { "type": "user_delegated" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "approval_event_id": "ape_5D8wQ1kR7mX2vT4nH6jZ",
  "created_at": "2026-09-30T17:03:00Z",
  "expires_at": "2026-10-15T18:00:00Z"
}

Derived tokens carry the record’s id and issuer, and optionally its expires_at, in the mission claim. The claim carries no authority_hash and no approval_basis: the anchors stay on the record, an authorized introspection caller can receive both, and a Resource Server that must check a token’s authority against the complete approved set adopts Approved-Set Verification. subject and approver are {iss, sub} pairs, authoritative for principal equality, and they may differ when an administrator approves on a user’s behalf. approver is kept as the compatibility alias of approval_basis.consent_principal, the accountable human. Here adjudication is human, and root_commitment, for a direct approval, is the Mission’s own authority_hash. The record also carries its issuance context: the agent’s client_id, the policy_version the Authority Set was derived under (an opaque audit correlator, not a re-derivation promise), the approval_event_id, created_at, and a top-level expires_at mirroring the Intent’s. The consent disclosure the Approver saw is committed separately by the Consent Evidence companion (From a Request to an Approved Mission).

Lifecycle states

The issuer owns the state machine. The OAuth binding defines three states. Companion profiles add more, and the one rule a consumer always applies is that only active permits reliance. Every other state, recognized or not, is treated as non-active, so the model fails safe as it evolves.

• active (issuance profile): approved. Derivation and reliance permitted.
• revoked (issuance profile): terminated by user, admin, or policy. Terminal.
• expired (issuance profile): expires_at passed. Terminal.
• suspended (Status companion): paused. Reversible to active.
• completed (Status companion): finished. Terminal. Legal from active or suspended.
• superseded (Expansion companion): replaced by an approved successor. Terminal.
• cascaded (Child Delegation companion): a child terminated because its parent reached a terminal state. Terminal, and distinct from revoked so audit can tell a cascade from a direct termination.

A consumer that has never heard of suspended, superseded, or cascaded still refuses to rely on them, because they are not active. New states are therefore safe to add. (One exception, by design: an unrecognized entry-level terminal_when condition, which the Entry Discharge companion registers, must fail closed, not be ignored. See Mission Lifecycle and Change.)

Trust boundaries and roles

Mission-Bound Authorization spans multiple parties. Each is trusted for a specific bounded responsibility, and explicitly not trusted for adjacent ones. This is the canonical role map, and the profiles populate it for their substrate.

The division of labor across domains is worth one plain statement. The Mission Issuer governs the approved objective and its global ceilings. The resource authority defines resource-local actions and constraints. The PDP evaluates the intersection of the two. And translation across authority vocabularies is trusted, verified, or separately approved, never assumed.

The most important boundary is the first one: the Mission Shaper is never an authorization component. It produces a proposal the state authority can validate or refuse. Diagrams that place the Shaper inside the authorization trust envelope are wrong.

Agent IAM and the Agent Registry

The division of labor with agent identity is one sentence. Agent IAM preserves who is acting. Mission-Bound Authorization preserves why their authority exists. Neither replaces the other, and the combined stack is the deployment story:

1. The Agent Registry and workload identity authenticate an approved agent instance.
2. The Mission and its derived Authority Set say what sanctioned work that instance carries.
3. Per-hop credentials narrow that authority, audience by audience.
4. The runtime layer enforces each consequential action and its parameters at the point of use.
5. Decision, execution, and lifecycle evidence join on the Mission.

The registry itself is a complementary dependency, not part of the Mission system, and this family defines no agent identity and no registry (three objects, three lifecycles). Where one exists, the Mission Issuer and the PDP consume a small, stable slice of it:

Registry state is a state source like any other. The consuming decision point treats it under the runtime profile’s freshness discipline, with a declared staleness bound, failing closed when the state cannot be established. And the three lifecycles gate conjunctively: all three must be live, and each is checked on its own.

Who owns the meaning

Three layers need three different relationships to a vocabulary none of them owns jointly. The resource owns the ontology: only the finance system knows what query_financials(period, entity) means, which parameters are dangerous, and which constraints its objects can enforce, because it implements the call. Governance needs enough of that meaning to derive and render faithfully, since the Authority Set is derived against resource-defined action semantics and the approval discloses meaning the issuer does not own. Policy needs enough of it to evaluate, since the PDP checks concrete parameters against entries whose semantics the resource defined. The ontology problem is the published statement of why this is hard, and the family answers it with four supply mechanisms rather than one global vocabulary:

The direction matters. OAuth’s inherited ontology is client-proposed: the client asks in types the issuer must understand, which is why a generic multi-tenant issuer struggles with domain meaning. The resource-declared direction inverts it, and where semantics should live is the published treatment. Either direction ends at the same rule: translation across authority vocabularies is trusted, verified, or separately approved, never assumed.

And the asymmetry runs both ways. The resource owns what an action means. The Mission owns why it is happening and where the undertaking stands. A risk decision needs the join, because semantics without purpose prices every delete the same, and purpose without semantics cannot read the call.

Where the Mission record lives

By default, the Mission record lives at the binding’s Mission control point, its state authority. On the OAuth binding that is the Mission Issuer, the Authorization Server, which validates Intents, runs approval events, stores the record, and gates issuance on its state. In AAuth it is the Person Server. The substrate-local default keeps the minimum profile coherent, since a deployment can adopt the Baseline Issuance bundle without introducing a new server component.

The Mission Authority Server (MAS) is the standalone controller over the OAuth Mission data model, the AS-optional mode: a peer deployment topology, not an independent substrate, since it imports the OAuth Mission record and issuance profile. Beyond serving deployments whose Authorization Server cannot yet change, it is the estate control plane for approved-task authority, one Mission Issuer spanning many Authorization Servers, SaaS systems, APIs, and agent runtimes, with an Enterprise Mission Authority Profile above its conformance floor. The MAS implements the Mission Issuer role without being an OAuth AS. It validates Mission Intents, runs approval events, records Missions, operates the lifecycle, and serves Mission state. It derives no tokens. Access tokens remain ordinary OAuth tokens with no mission claim, and a Policy Decision Point joins each presented credential to its Mission at the point of use, enforcing through the runtime profile.

That difference is architectural, not just topological. The MAS mode buys Mission governance and per-action enforcement with no change to the deployment’s Authorization Server, at the cost of Mission-bound credentials and issuance gating. Without that join, revoking a Mission stops nothing at the token layer, so enforcement rests entirely on PEP coverage. The issuance grant is the middle path that restores the token-layer chokepoint: estate Authorization Servers redeem MAS-minted grants for Mission-bound tokens without moving approval into the AS, so one canonical Mission record gates credentials minted across many issuers. A consuming AS with a Mission-state integration projects every redemption and refresh through the Effective Authority Set; one without it relies on the active-at-minting gate alone and issues no refresh tokens, so tokens derived under a revoked Mission can keep working for the grant’s remaining redemption window and clock-skew leeway, plus the issued token’s lifetime, plus that of each further exchange that checks no Mission state, never past the Mission’s expiry.

Competitive landscape

Each of these is real and useful, and none is a substitute for an approved task object. Mission-based authorization composes with them rather than replacing them.

The pattern is consistent. The credential and decision layers are well-served. The approved task is the missing object. Mission-based authorization supplies it and lets the others bind to it: RAR derives from it, the PDP decides against it, sessions and traces reference it. And the “Law it breaks alone” column is the sense in which the category follows from the laws. Used alone, every row breaks at least one of the five laws, so an architecture that satisfies all five contains a Mission-shaped object, whatever it is called, and the one row that breaks none is itself an instance of the category. Because the laws and the object come from the same analysis, the column is a consistency check on the design.

When it is the wrong tool. If there is no durable task to govern (a single user-driven request, a machine-to-machine service credential, a short-lived consumer authorization where the credential lifetime is the task), a Mission adds cost without value. Do not read the standing agent out through this door: a service credential’s work is fixed at integration time, while a standing agent exercises delegated judgment on every unit of work, which is exactly what needs a charter and cycling authority (the standing agent at scale). And do not read small tasks out either: one resource, one approver, and one afternoon is a perfectly formed Mission, because what disqualifies is never size, it is the absence of a durable task. The category earns its keep whenever authorization must outlive a single request and stay bound to a task, however small, and whoever the actor is: a Mission governs a human’s task access as readily as an agent’s. And note that AAuth Mission is itself an instance of this category on a different substrate, not a rival to it. The interesting question there is shared governance across substrates, not which one wins.

Granularity has decision rules, because both failure directions are real: Missions broad enough that ambient authority has merely moved upward, and Missions so fine that approval and evidence volume overwhelm the plane. Work stays in one Mission while the undertaking and its bounds hold. A helper that finishes inside the parent’s flow gets a narrower delegated projection. A durable sub-agent that needs its own observable lifecycle and stop handle gets a Child Mission. The same undertaking needing different bounds gets a successor. A new objective gets a separate Mission, related in evidence. And one high-consequence effect gets an action-bound permit, never a Mission of its own.

The adoption order

The smallest useful deployment, and the order deployments build the rest in. A deployment adopts as far as its risk warrants and stops there:

• Stage 0: Substrate only. Ordinary OAuth, no Mission. Fine for single-request, non-agentic flows.
• Stage 1: Mission-bound issuance. A mission claim on derived tokens, with state-gated issuance: a possession-independent kill switch for future derivation. Audit and derivation control at the grain the Resource Server enforces, not action-time defense. This is the entry point, the issuance-only deployment: only the Authorization Server and the Mission-creating client change. A Resource Server that introspects per request stops honoring a token at its next request once the Mission leaves active, with no Mission-specific code. The deployment claims approved-record integrity and bounded revocation latency.
• Stage 2: State and revocation freshness. Status / introspection so consumers can check current Mission state.
• Stage 3: Runtime enforcement. Per-action PDP checks for consequential actions. This is the stage that adds per-action, parameter-level, and state-aware checks beyond the bounds the receiving Resource Server enforces.
• Stage 4: Lifecycle. Signals, expansion, and entry discharge: prompt revocation, governed growth, and monotonic narrowing.
• Stage 5: Delegation. Child Missions and offline attenuation: strict-subset authority for sub-agents, without ambient inheritance.
• Stage 6: Operational assurance. Harness binding, safe unwinding, and audit transparency.

Stages 1 and 2 cover consequential reads and writes whose bounds the receiving Resource Server enforces. Most AI agents that touch private data, untrusted content, or external side effects also need Stage 3 for the actions whose parameters or state matter, and Stages 5 and 6 for fan-out and full governance.

The stages group into the four Mission Assurance Levels. They are adoption bundles, not a conformance class, an earned label, or a ladder, and a deployment names the bundle it runs. A level does not determine any action class’s containment property. One line each:

Baseline Issuance is in the category at issuance strength, and does not by itself establish an action-time defense claim: the litmus’s four-and-two split.

The bundle is one axis. The binding is orthogonal, and a deployment names both. The bindings are not one security system either: the architecture classifies them as credential-carried (the Mission rides the credential), PDP-joined (the decision point joins ordinary credentials to the record), and context-carried (the substrate’s own mission context is the record), and a deployment names its security architecture, not only its binding.

Custody of the execution environment is the third axis, because assurance follows it. For a harness the enterprise does not run, a third-party SaaS agent or an employee’s consumer assistant, Baseline Issuance still applies to the credentials the estate mints, plus boundary PEPs at its edge, and Runtime-Enforced survives route-scoped: enterprise PEPs in front of enterprise resources enforce at the point of use whoever runs the loop. The Governed Agent bundle binds the harness, so it is out of reach without harness custody, while the high-consequence classes stay reachable per route, because mediated custody holds the key at an enterprise-controlled handler either way. And delivering a usable secret into the agent’s environment is custody transferred, not use mediated. Only the mediated form supports the highest claims.

Read in adoption order, each bundle makes a broader class of agent work defensible to grant. The mapping is informative, and what a bundle grants varies with the binding:

The read-only ceiling breaks at Baseline Issuance for writes whose bounds the Resource Server enforces, and the adoption path carries that reading in full.

The implementation checklist

The claim a deployment makes should be checkable. This is the field checklist for a Runtime-Enforced deployment, with the deeper treatments linked.

Claims are scoped, not global. A deployment that cannot prevent an action class on some path must not claim runtime enforcement for that class, and must name the paths it does mediate. A claim worth trusting reads like the honest deployment claim in the citation kit, each clause mapped to a row above and checkable. A claim that cannot be written in that form is marketing, not an assurance claim. What not to claim is its negative space.

Adversary model

The non-goals below say what this does not solve. This is the complementary view: the adversaries it does constrain, the layer that constrains each, and the residual it leaves. The reasoning is developed across the parts. This table is the consolidated map, and the Mission Security Model draft (Informational) is its spec-level counterpart: the trusted base, the cross-cutting assumptions, and the consequence of each component’s compromise.

The Mission record is itself sensitive

The object that makes agent work governable is also a record of business intent: purpose, targets, constraints, approver identities, and the evidence that joins them. The same mission.id join that makes reconstruction possible is a correlation surface. The OAuth binding already keeps the token-side claim a reference, never the Intent’s contents, and leaves the anchors on the record. Deployments should hold that line: resource servers and intermediate PEPs need the identifier, not the task description. Where a party outside the issuing domain needs some committed facts and not all of them, the Mandate’s selective disclosure is the built tool. The rest is deployment discipline: evidence stores behind the same access control as the systems they describe, retention set deliberately because the evidence chain outlives the task by design, and awareness that a Mission reference projected across domains is a correlation handle in someone else’s logs.

The sober reading: the strong adversary, a fully compromised agent, is contained at the boundary (custody, per-action checks, narrow-only delegation, the kill switch), never by trusting what the agent says. The residual column is the part no claim should paper over.

Threats and non-goals

The Mission is the declared governance envelope, and the runtime layer is what keeps the system survivable when the envelope turns out to be incomplete: a deployment with the object but no runtime layer is protected only as far as its Resource Servers enforce the carried bounds, and one with enforcement but no shared approved object is ungovernable. Mission Shaping Is Not Enough makes that two-layer argument in full. And one sentence bounds the whole claim: Mission compliance is evaluated against the approved representation of purpose, not against an independent oracle of human intent. A sufficiently broad or badly derived Authority Set can permit an action that is syntactically compliant and purpose-inconsistent, which is why shaping, disclosure integrity, authority derivation, and runtime enforcement are each required rather than redundant.

Mission-based authorization is credible because it is precise about its edges. It does not:

• make an LLM’s reasoning trustworthy
• replace resource-local policy (the resource remains authoritative for its own decisions)
• provide full information-flow control
• prove that every side channel has been mediated
• eliminate the need for human step-up on high-risk actions
• make a broad, over-scoped Mission safe (breadth approved is breadth granted)
• lean on deterrence as a compensating control. Human delegation quietly does, because people fear the audit that follows. An agent has no career to protect, and its judgment can be rewritten mid-task by content it reads, so the runtime boundary must carry the weight that deterrence carries for people.

What it does:

It gives policy, credentials, lifecycle, delegation, and audit a common object (the approved task) and a runtime layer that checks each consequential action against it.

The safety properties most people assume from “Mission-bound agents” (action-time defense, prompt revocation, safe unwinding, evidence) come from the runtime and operational layers, not from the mission claim alone.

Noun distinctions

Keep these stable. Do not let “task,” “mission,” “workflow,” and “session” blur.

• Mission Intent: the proposed task (untrusted until validated).
• Mission: the durable, lifecycle-owned record of the approved task; the task itself is the undertaking the record governs.
• Approved Authority Set: the derived, grantable authority the Mission bounds, fixed at the approval event and committed by authority_hash.
• Effective Authority Set: the Approved Authority Set after subtraction by containment and entry discharge, the set derivation and runtime decisions read.
• Projection: any substrate-specific, audience-bounded credential or assertion derived from the Effective Authority Set: a Mission-bound token, an ID-JAG, a downstream grant, or another substrate’s native credential. Every projection carries the Mission reference.
• Mission-bound token: a credential projection carrying the mission claim.
• Runtime decision: a per-action permit or deny.
• Evidence: an audit artifact (approval, consent, decision, lifecycle).
• Harness: the runtime continuity and mediation layer, not authority.

The canonical sequence behind these nouns: Mission Intent → Approved Authority Set → Mission → Effective Authority Set → Projection → Runtime Decision → Evidence. Before consent, the state authority derives the Approved Authority Set in narrowing or configured-mapping mode. The approved Mission commits the Intent and the set, subtraction yields the Effective Authority Set, and every profile specifies one or more of the transitions.

Why “Mission”?

The name was deliberate, and alternatives were considered. Each captured a piece of the object without doing justice to the whole:

• mandate carries political and legal connotations the protocol object does not. A mandate is an instruction. A Mission is a governance container that includes intent, authority, lifecycle, and evidence.
• delegation_context muddles with OAuth’s existing notion of delegation, which sits at the credential layer (one principal authorizing another). The Mission is above credential delegation. Both the original credential and any delegated credential project from the same Mission.
• task_authorization describes a credential, not a governance object. The Mission is what task authorization derives from. Calling the governance object “task authorization” reduces the layer above to the layer below.
• purpose_bound_authorization correctly names one aspect (purpose) but presents the object as a flavor of authorization rather than as the durable container that authorization projects from.
• authorization_context is too generic. “Context” in OAuth-adjacent specifications means many different things. The Mission has a specific structural commitment to integrity, lifecycle, and consent that “context” does not imply.

“Mission” captures the durable, purpose-bound, lifecycle-governed quality of the object without overloading any existing OAuth term. It signals that this is not a refinement of scope, authorization_details, grant, or session, and it implies purpose plus duration plus boundedness in one word, which is what the governance object actually is.

A standards-track adoption could use a more neutral on-the-wire name (the OAuth claim could be mbo or authorization_mission rather than mission) while preserving “Mission” as the conceptual term. The family uses mission as the claim name to keep the conceptual and wire terminology aligned, and deployments may rename if a working-group consensus settles on a different label.

Reproducible test vector

The credibility of this model is its hashing, so here is one anchor you can reproduce byte for byte. Every integrity anchor is a SHA-256 over a domain-separated, issuer-bound envelope ({ "typ", "iss", "value" }), canonicalized with JCS (RFC 8785), encoded as sha-256: followed by base64url with no padding. For intent_hash, typ is mission-intent and value is the approved Mission Intent.

The JCS canonical bytes of the envelope, for the running example, are exactly:

1

{"iss":"https://as.example.com","typ":"mission-intent","value":{"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","target_resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"],"task_bounds":["Q3 2026","Example Corp","confidential"]}}

Hash those bytes and you get the anchor. Reproduce it from a shell:

1
2
3

printf '%s' '{"iss":"https://as.example.com","typ":"mission-intent","value":{"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","target_resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"],"task_bounds":["Q3 2026","Example Corp","confidential"]}}' \
  | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '='
# => yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw

So intent_hash = sha-256:yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw. The same procedure with typ = mission-authority-set and value = the Authority Set array yields authority_hash = sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY.

Two rules make this interoperable: JCS sorts object keys but preserves array order (so the Authority Set’s entry order is part of the canonical form), and the typ value domain-separates the anchors so a digest of one object can never be read as the other. A verifier reproduces the digest from the recorded object alone.