Mission-Bound Authorization: The Complete Edition

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 is honest about 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 the load-bearing layer. 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. The agent equivalent is the per-action runtime check, and the same logic applies. 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.

And it won. 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 keeps insisting is available. The market priced the argument.

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 looked at exactly that shape, rebuilt it, and was rewarded. The transition the rest of this chapter maps is not speculative. In the domain that had the choice, it already happened.

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: a first-class approved purpose, bounded projections of it, checks at the moment of use, delegation that stays tied to the task, 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. Purpose attached to each dollar of authority. Derived limits. Real-time, per-transaction enforcement. Fast, possession-independent freeze. Fresh approval to widen anything. Audit joins on one identifier.

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 bar is not exotic

The useful thing about this analogy is that it sets the bar at “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. It is the load-bearing idea of the whole chapter.

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.

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 consumers that actually check it, fast enough to matter. 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 version with no protocol in sight.

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, and the Reference walks that one end to end. Two stories, one object.

The Corporate-Card test becomes the claim gate

The card chapter ends with a diagnostic: five 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: a system may claim mission-based authorization only if it has an approved task object, authority derived from that task, narrow-only delegation as work fans out, per-action runtime enforcement, observable lifecycle state, and evidence that joins on the Mission’s identity.

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 core’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: the Client Instance Assertion and AI Agent Instance Profile for instance identity, the core’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 binding, 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 it is the load-bearing one.

“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 experimental push complement, 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 core plus the shape of the family around it, which is the point: the card chapter’s build lists and this family’s table of contents are the same list, written by two different worlds.

What the analogy could not say

The card chapter is honest about 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, 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.

If you carry one sentence out of the translation, carry this one:

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

The industry’s best-practices path for AI agent identity is taking shape. AI Agent Authentication and Authorization 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 Section 9.1 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. One warning travels with the whole argument, and it is settled in Mission-Bound Runtime Enforcement: a mission-bound token without runtime enforcement is governance metadata, not agent safety. The object defined here earns its keep at the point of use.

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. The largest claim this chapter makes is that delegated authority management is a missing layer, with its own laws and vocabulary, and the Mission is one implementation of it. A system qualifies as mission-based only if it has all six: an approved task object (not a prompt, trace ID, session, or token); authority derived from that task; narrow-only delegation; runtime enforcement against current state; a lifecycle that can expire, revoke, expand, and complete; 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-klrc-aiagent-auth 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, the Client Instance Assertion identifies the specific instance, and the AI Agent Instance Profile adds attested instance identifiers and agent provenance.

What may this instance do, why, for how long, on whose approval? That is the Mission, and it is the layer Section 9.1 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 Agent Authentication and Authorization. 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.

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, issuer, and authority_hash. 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), 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, resources, constraints, expiry), the Authority Set derived from it, its two integrity anchors (intent_hash, authority_hash), a lifecycle state, and its identity (id, issuer). The crucial relationship is that 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.
• 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, and the six-property litmus are in the Reference. The components in full, including what anchors a Mission’s legitimacy when no user is present at approval time, are in the Reference’s object model.

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. Before it, only Intent exists. After it, only the Mission is authoritative.

Three 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 (the post-validation form the user consented to, not the raw prompt). The Intent itself is never edited behind the user’s back. An unrecognized resources entry either refuses the submission or, by deployment policy, is omitted from the derived Authority Set with the partial derivation signaled to the client. 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 core).
3. Authority. The Mission’s canonical Authority Set is projected into tokens that each carry the mission claim (Mission-Bound Authority).
4. Enforcement. A PDP checks each consequential action against the current Mission 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 any agent that touches consequential writes or external side effects, the runtime layer is doing the safety-critical work. That is why the sharpest way to state it is:

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

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.

How much of this a deployment runs is a claimable level, the Mission Assurance Levels, and the taxonomy recurs through the handbook:

The Reference’s implementation checklist turns each level into a checkable claim.

Where the details live

This part is the argument. 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 stages, the glossary, and a reproducible integrity-hash test vector.

Where this leads

This is the framing post. The architecture chapter continues with Adopting Mission-Bound Authorization, the staged build order: the protocol MVP on ratified substrate now, the experimental roadmap as 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 load-bearing safety layer and the heart of the protocol MVP. 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 and signals for observation and revocation, expansion for governed growth, completion for safe narrowing.
• 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 core 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 protocol core, not to the claims: runtime enforcement is required for the protocol MVP, and Consent Evidence and the harness are required for the governed-agent claim. 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 honest answer to “how do I adopt this” is not “all of it”: it is crawl, walk, run, with each stage claimable on its own, honest about what it does not yet deliver, and chosen so that nothing waits on an unratified dependency. The maturity and status claims in this part are as of July 2026, and the Reference carries the reconciliation date the handbook tracks. For substrate independence, the three bindings, and the trade the standalone Mission Authority Server makes, the concluding chapter, Weighing Mission-Bound Authorization, is where the handbook ends.

The stages map onto the Mission Assurance Levels the repository publishes: crawl is the Baseline Issuance level, walk is the Runtime-Enforced level, and run is the climb through Governed and High-Assurance Agent, with the standalone Mission Authority Server as a parallel binding at every level, whether as the estate’s control plane or because the Authorization Server cannot change. The three stages are the path, and the second half of this part is the terrain around it: the ecosystem the protocol MVP composes with, the roadmap beyond the wedge, the operational surfaces you will own, and the pieces the community still has to standardize.

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. It is also expensive, and each compensating control costs more than it looks:

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

You do not need an agent to start

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

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

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

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

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

Crawl: baseline issuance

Crawl is the issuance core alone. Mission Intent submitted through PAR, the approval event that derives and renders the Authority Set, intent_hash and authority_hash committing what was approved, the mission claim on every derived token, state-gated issuance as the kill switch, and the subset rule on every derivation. This is The Mission Is the Missing Abstraction and the core draft, and a minimal conforming deployment fits on one screen.

What crawl buys you is real: every credential carries its purpose, issuance stops the moment the task does, short-lived tokens turn that stop into a real bound (revocation reaches every path within the token lifetime, with no resource changing at all), and audit joins on one identifier. What it does not buy you is the thing the handbook keeps refusing to let anyone claim by accident. Stop here and you hold governance metadata, not agent safety. A mission-bound token that nothing checks at the point of use is bookkeeping, and the what-not-to-claim list says so in writing. Crawl is the right first quarter. It is not a place to live.

And meet the estate where it is. For many enterprises the first agent-credential control already shipped is a credential broker: real credentials moved into a vaulted plane, with agents holding just-in-time, short-lived, sender-constrained leases (the proposed CB4A is the spec-shaped instance). If that is your starting point, crawl starts from an asset rather than zero, and it is one integration away: hold the Mission record at the Authorization Server or the standalone Mission Authority Server, gate every mint on Mission state, and stamp the mission claim on the leases the broker issues. The chokepoint you already deployed becomes the issuance gate, the kill switch reaches every future lease, and the broker’s ledger joins on mission_id. What the broker cannot supply on its own is the object, because a lease is not the task, which is the landscape’s broker row in one line.

Walk: the protocol MVP

Walk is the wedge, and it is where the safety claim becomes real. Two additions:

1. Put a PEP at every consequential boundary and adopt the runtime contract with its AuthZEN binding. The PDP evaluates each action against the live Mission, parameters bound, consumption metered, failures closed. This is Mission-Bound Runtime Enforcement, the runtime draft, and the AuthZEN profile.
2. Serve Status as the freshness source. Revocation is only as fast as consumers learn it. The signed pull surface (or issuer token introspection) is the protocol MVP half of Mission Lifecycle and Change, and it is what makes “only active permits reliance” operational. Where a revocation must bite in seconds, adopt the Signals push as the complement.

The order is the argument. Crawl alone is governance metadata. Walk is what turns the object into a control, and for AI agents the recommended additions come with it: Consent Evidence and the harness, because an agent’s approval surface and its resume path are where the guarantees otherwise lapse (From a Request to an Approved Mission, The Agent Runtime and Audit).

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

The whole walk stage compresses into one recipe:

The same recipe as one reference architecture, each edge numbered by the row it implements:

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

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

Wherever it lands, the PEP has to sit at the last controllable boundary before the effect. An orchestrator check does not replace a resource PEP for a resource the agent can reach directly, and an API gateway does not cover local shell, browser, or file-system effects it never sees.

And the equally opinionated negative. Do not start with Signals, Deferred Approval and Revision, the Mandate, offline attenuation, cross-domain projection, SCITT audit transparency, or the standalone Mission Authority Server unless the estate calls for it: the Authorization Server truly cannot change, or one Mission Issuer must govern many systems at once. Every one of them is on the roadmap for a reason, and none of them is the wedge. Build the recipe above, run it, and let deployment experience tell you which of these you actually need.

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

Why protocol MVP first, stated as reasons rather than modesty:

• Every normative dependency is ratified. The protocol MVP rests on OAuth RFCs and finalized OpenID specifications, including the AuthZEN Authorization API 1.0, which reached Final in January 2026. The Mission-Bound profiles themselves remain proposed Internet-Drafts: the claim is about the substrate under them, not their own status. The one tracked exception, the issuance core’s Internet-Draft reference to the Actor Profile, is confined to its OPTIONAL delegation capability. There is nothing to wait for. The claim is about dependencies, not the profiles themselves: they are individual drafts whose wire details will keep moving with review, which is one more reason the laws and the architecture, not the claim names, are what to design against.
• It is the smallest object that closes the named gap. Section 9.1 of the best practices expects the mission to be translated into authorization requirements and leaves the process out of scope. The protocol MVP is that process: an approved, integrity-anchored task object, authority derived from it, actions enforced against it, state observable for it.
• The roadmap should be earned, not speculated. The experimental extensions encode design bets about asynchronous approval, fan-out, and unwinding. Real protocol MVP deployments are what turn those bets into interfaces worth hardening, and the wagers underneath the whole design are named, with their falsifying evidence, in where this could be wrong.

Not every resource checks Mission state

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

That is a dial, and the estate chooses its settings. At the coarse end, crawl’s state-gated issuance with short-lived tokens is a complete revocation story for the classes below high-consequence: the resource validates ordinary tokens exactly as it does today, and revocation reaches it within the token lifetime, because a non-active Mission derives and refreshes nothing. No resource changes. And the lifecycle suite names this pattern a conforming freshness source, inside the model rather than a concession to it. For many estates, and for most read and reversible-write classes, that published bound is the right first claim. And when the estate’s question becomes scale rather than latency, the Status List is the fleet setting: one signed fetch keeps every enforcement point current.

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

The discipline is only honesty about the setting. High-consequence classes require an active freshness mechanism, so route them through a boundary that has one (the gateway, the MCP host, mediated custody) rather than pretending a TTL is fresh. Publish the bound each path actually runs, and the Reference’s revocation matrix prices every setting. Legacy is not an exception to the model. It is the model’s coarse end, claimed honestly.

Run: governed and beyond

Run is the climb above the wedge, and the levels are one named artifact, the Mission Assurance Levels. Climb them in order, and claim the level you are on:

The levels are also an unlock ladder, and this is the reading that answers the read-only ceiling. In the runtime contract’s own action classes, each level makes a broader class of agent work defensible:

A deployment names its level and its enforcement scope, and the Reference’s implementation checklist is the checkable form of that claim, down to the sentence a vendor should be able to write.

Composing with the ecosystem

The staged path is behind you. From here to the close, this part maps the terrain around it, starting with what the protocol MVP composes with rather than replaces. One stack answers where everything sits, from the substrate up:

AuthZEN standardizes the decision. The runtime profile deliberately specifies invariants rather than a wire, and the AuthZEN binding is the interoperable PEP-to-PDP surface. ARAP turns a denial into a governed request, and the AuthZEN profile marks out_of_authority and action_approval_required denials as requestable so an agent can start narrow and ask for what it discovers it needs. That composition has a name in this handbook: the discovery loop. Deny, request, approve, expand, retry. It is how the open world arrives under governance. A tool or resource discovered at runtime shows up as a requestable denial rather than as an error or an excuse for standing breadth, and the widening lands as a separately approved successor Mission with lineage. The proposed AROP binds that workflow to OAuth completion for the token-side case. The Least-Privilege MCP series walks this per-call stack from the beginning, and the MCP application post shows both of its models becoming projections of one Mission.

Two observations from that series matter for the blueprint, because they name what the ecosystem still lacks:

• Fulfillment is undefined. ARAP standardizes the request, the status, and the re-evaluation, and deliberately not how an approval becomes durable authorization state. Token-resident state fulfills by minting, which AROP binds to OAuth issuance. Store-resident state fulfills by a write no standard defines. When the durable state an approval becomes is a Mission, fulfillment has a governed shape: an in-bounds approval is decision input, and a widening lands as a separately approved successor Mission with lineage.
• The task object is the gap every layer routes around. The denial signals, the decision API, and the approval workflows each standardize an interface inside a single call. None names the work the calls serve. That is the object this chapter proposes, and it is the piece to bring to the standards conversation rather than reinvent per deployment.

The identity substrate composes from below: the best practices for agent authentication, the Actor Profile for delegation chains, and the Client Instance Assertion with the AI Agent Instance Profile for attributable instances. Mission-Bound Authority is the binding between that substrate and the Mission.

Credential custody composes the same way. Credential brokers, with the proposed CB4A as the spec-shaped instance, are the custody fabric that mediated custody and the enforcement-scope statement assume, and the crawl stage shows a broker estate becoming this architecture’s credential plane from the first integration. 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.

The roadmap: the next layer of the problem

The roadmap beyond the wedge has two labels, and the labeling is the design discipline, not a disclaimer. The advanced profiles are stable design to adopt when the use case arrives, and the practice chapter carries them: Deferred Approval (From a Request to an Approved Mission), Expansion and Completion with the fleet Management surface (Mission Lifecycle and Change), Child Delegation and Cross-Domain Projection (Mission-Bound Authority), Audit Transparency (The Agent Runtime and Audit), Intent Shaping (From a Request to an Approved Mission), and the Mandate.

The experimental profiles are for evaluation only. Each extension answers a question the protocol MVP will surface in production, and each is experimental for a stated reason:

Two Standards Track profiles sit beside this table rather than in it, because each tracks an unratified substrate: Deferred Approval rides OAuth Deferred Token Response, and the AAuth binding rides the AAuth protocol. And the standalone Mission Authority Server is not a roadmap item at all: it is Standards Track, the estate control plane of the layer, with the issuance grant as its middle path, estate ASs redeeming MAS-minted grants for Mission-bound, state-gated tokens without moving approval into the AS.

The honest sequencing claim, once more: adopting the protocol MVP first is not settling for less. The protocol MVP produces the deployment experience, the failure cases, and the interoperability pressure that tell us which of these interfaces to harden and how. An experimental extension frozen before that evidence exists would be a guess wearing a MUST.

The Reference’s draft family at a glance is the whole 28-document catalog in one table, with these maturity labels on every row.

What you will operate

The blueprint is honest only if it names the operational surfaces that come with it. Adopting the protocol MVP means owning 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 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.

What the community still has to standardize

A blueprint should also name the pieces nobody owns yet. Six stand out.

• A standard task object. This family proposes one, as individual drafts published for discussion. The gap it fills is now named in the best-practices document, and the per-call standards keep converging on shapes that assume something like it exists. The right venue conversation, whether that is the OAuth working group, AuthZEN, or both, is the next step, and deployment experience is the strongest input anyone can bring to it.
• Approval fulfillment for store-resident state. Every Zanzibar-style store’s write API is product-specific, so the approval-to-state step of ARAP has no interoperable form outside OAuth issuance. A Mission gives the durable state a governed shape, but the write itself still needs a standard.
• Task binding at the tool boundary. The MCP proposals standardize the denial and the brokered approval. Carrying a verifiable task reference through tools/call, so the resource can weigh the call against the approved work, is the natural next step the MCP application post sketches.
• Instance-attested delegation as the default. The actor chain, instance assertion, and agent provenance exist as individual drafts. The mission layer assumes them. Their adoption path is part of this blueprint, not an afterthought, because an unattributable actor makes every downstream guarantee weaker.
• Trust establishment for discovered counterparties. The Mission layer governs whether newly requested authority is inside the approved task. Whether a runtime-discovered issuer, tool server, or its metadata can be trusted at all is the substrate problem beneath it, and the Open-World OAuth series maps that terrain: discovery, issuer trust, sender constraints, and metadata integrity are prerequisites this blueprint composes with rather than solves.
• Exposure control surfaces. Least privilege has standards and least exposure has an essay: bounding what the agent may see is enforced today only at its edges (catalog filtering, egress mediation, the taint rule). Scoping retrieval, memory, and context assembly to the approved task has no interoperable form, and the exposure half of minimal disclosure needs profile work nobody has started.

Where this leaves you

If you arrived from draft-klrc-aiagent-auth, you now have the answer to the question its Section 9.1 leaves open. The Mission is the durable, approval-backed record of the task your authenticated agent pursues, and the adoption of it is staged: crawl with the issuance core, walk with the protocol MVP, run up the Governed and High-Assurance Agent levels as the deployment earns them.

Ship the protocol MVP, and add the agent-specific assurance pieces when the system is actually running agents. Its dependencies already shipped, end to end, it is the smallest interoperable surface that makes the approved task first-class, and it is the version of this architecture that earns the right to harden the rest. The Building Mission-Bound Authorization chapter carries each control at implementation depth, the editor’s copies are public, and the Reference is the citable definition. That experience has a place to land: issues and pull requests on the draft repository are the fastest path into the documents. The gap has a name now. It should have an object.

The Mission Is the Missing Abstraction drew the boundary between Mission Intent (a proposal) and an approved Mission (the governance object). The proposal is untrusted. The Mission is authoritative. 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.)
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, 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 and its narrowing companion Approval Revision, both Standards Track. Deferred Approval tracks an unratified substrate, and Revision is labeled 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, so it is worth stating in the terms of this part before we add anything to it. 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 an {iss, sub} principal, and the litmus test has always said “a human (or authorized policy) approved” rather than naming a person. What the approval event requires is not a human. It is an accountable authority deciding against committed inputs before any authority exists, and two invariants that hold whoever decides:

• 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 approval traces to a human decision at some grain. An authorized policy approver 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. Policy approves the instance. A human approved the policy, and policy_version on the record keeps that chain re-checkable.

Within those invariants, the approval authority is a spectrum the deployment chooses per class. A human approves directly, with Consent Evidence committing the disclosure they saw. An authorized policy approves at machine speed, with the committed inputs and policy_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 approver, the same way content-aware controls compose at the runtime layer: signals, not authorities. The one thing that must not be the sole authority for granting or widening is another model’s generated judgment, because an LLM approver reading attacker-influenced proposals is itself an injection surface. 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 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. A policy approver is still an admission decision, committed and attributable. An agent that widens its own authority is not.

Shaping: proposes only

The issuance core 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 core 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. A shaper that emits them is misusing its role, and the issuance core 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, resources (each an absolute URI), free-text constraints, optional free-text success_criteria (disclosure and audit material only, carrying no machine semantics), an optional purpose, expires_at, optional machine-actionable controls, and an optional proposed_authority array. The shaper proposes resources and describes the desired bounds in free text, and proposed_authority is the one home for any concrete candidate authority it has resolved (actions, structured constraints, delegation facts): an untrusted carrier the Authorization Server only narrows when it derives the Authority Set. The shaper still authors no authority. The Authority Set is the Authorization Server’s product, never the shaper’s input taken at its word.

Fail closed, not open. The interesting design content is what a shaper does when the request is ambiguous. An ambiguity 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 it, and a proposal that broadens on an ambiguity without a matching record is unsound. (The draft says “unsound” deliberately. It is Informational and defines no conformance class.)

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 deployment that wants the Mission record to cite how its proposal was produced can bind the two with an optional shaping_evidence_hash, computed over the suite’s domain-separated {typ, iss, value} envelope exactly as intent_hash and authority_hash are. That hash commits how the proposal was made. 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 resources, pushing out expires_at, or suppressing a stated constraint. 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.

Consent Evidence: the recorded disclosure

The issuance core 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 core would catch it. The Consent Evidence draft (Standards Track) narrows that gap.

It adds two artifacts at the approval event:

• 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, and the intent_hash / authority_hash the disclosure corresponds to. 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 approval-or-decline event, 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:

Consent Evidence commits the structured disclosure the Authorization Server says it rendered. It does not, and cannot, prove what pixels reached the Approver, that the Approver read or understood them, or that the rendering layer was honest.

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 a deployment climbs 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, because a re-render an auditor cannot reproduce exactly is not deterministic, and a reviewer’s narrowing is never an edit in place but a revision with a fresh hash. 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.) Rungs 0 and 1 are the profile’s conformance rungs. The higher rungs are experimental, since each imports a trust infrastructure (attestation, transaction-confirming authenticators) the profile cannot supply, and a deployment claiming Rung 3 SHOULD apply it where the Authority Set carries a high-risk notice class: irreversible actions, external commitments, privileged administration, exhaustible 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.

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.

Deferred and revisable approval

The issuance core records an approval event but treats it 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. One honesty note first. Deferred Approval depends normatively on OAuth Deferred Token Response, which is not yet ratified, and Approval Revision rides the same substrate and is labeled experimental. Synchronous approval is the stable path 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.

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 revisable alongside deferred, and when the Authorization Server can grant only a narrowed version, it extends the authorization_pending response with revision_required, a single-use sender-constrained revision_handle, and (optionally) the rejected_scope and rejected_authorization_details that tell the agent which dimensions were refused. The client pushes a narrowed Mission Intent to PAR with the handle, and keeps polling the same deferral_code. The approval resolves over the narrowed proposal. The client never lost its place, and the stable path without this companion 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 core’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. And the rejected-dimension parameters are not a grant. A client MUST treat revision_required and the refused dimensions as evidence of nothing approved yet.

This is also where the layers start to interlock. The rejected_scope and rejected_authorization_details are precisely 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 MUST compute a fresh consent_rendering_hash for the re-reviewed revision. Prior consent does not transfer to a different Authority Set.

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 approves the Missions it can take, 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 irreversible actions, external commitments, and privileged administration: 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.

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 core. 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 resolves “the audit committee” to the audit-committee reviewer group, and it proposes three resources URIs (the finance, docs, and workflow services) bounded by invariants expressed as free-text constraints: the Q3 2026 fiscal period, the audit-committee recipient, the board-packet deliverable. It bounds the work in time with a expires_at of 2026-10-15T18:00:00Z. What it does not do is author the actions. It proposes resources and describes the desired bounds, and grants nothing. Had “the audit committee” been ambiguous about which group, the shaper would have asked alice rather than guess. It records Shaping Evidence and proposes.

2. The Authorization Server validates and derives. It is the Authorization Server, not the shaper, that turns the proposed resources and free-text constraints into a concrete Authority Set: 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). The shaper’s proposal informed that derivation. The Authorization Server authored every action in it.

3. The approval defers. Because the agent offered deferred revisable, the review need not be synchronous. The Authorization Server returns authorization_pending with a deferral_code and routes the rendered disclosure to alice, who approves on her own schedule while the agent polls. 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 that action, push the narrowed Intent, and keep polling the same deferral_code. Narrowing only, never broadening. 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, so an auditor can later re-render the recorded disclosure and compare it to the authority the agent used. The Authorization Server commits the Mission as msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1, state=active, and issues the Mission-bound token that runtime enforcement will police.

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.

Where this sits in the handbook

This is the Intent step and the integrity of the Mission approval event on the spine. It sits between The Mission Is the Missing Abstraction, which defines the Mission and the issuance core this layer feeds, and Mission-Bound Runtime Enforcement, which is where a Mission-bound token becomes a Mission-bound action, the load-bearing safety layer of the whole chapter.

Everything here happens before any token exists. By the time Mission-Bound Runtime Enforcement is evaluating an action against the current Mission, the questions this part answers, was the proposal honest, was the disclosure faithful, did the approval reflect a real human decision, have already been settled and committed. The later parts carry the approved Mission forward: Mission-Bound Authority, Mission Lifecycle and Change (including Mission Expansion, the widening counterpart to this part’s narrowing-only revisions), and The Agent Runtime and Audit.

The laws this part proves are the quiet ones. An approval binds only what it can replay (Attribution), and enforcement can only hold a boundary the approval actually drew (Containment). This is the one place in the loop where safety is still cheap. Spend the friction here.

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 for a reader arriving from the AI agent auth best practices. That work establishes the agent’s identity, credentials, and delegated user authority, and it expects the mission to have been translated into authorization requirements before the agent requests authorization. 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 three members: id, issuer, and authority_hash. The id and issuer say which governance record this credential serves and who holds it. The authority_hash commits the exact Authority Set the Approver saw, so a Resource Server can verify that the authority the token carries is a subset of what was approved without fetching the record. The token’s authorization_details carry the derived authority itself, and 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. Resources may only narrow (exact match by default, with an opt-in prefix containment form), actions may only shrink, constraints may only tighten. Nothing derived ever exceeds what was approved.
• Sender constraint. Mission-bound tokens are bound to a key with DPoP or mutual TLS, so a stolen token is useless off the instance that earned it. 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 core is the normative detail, and this projection is the anchor of the protocol MVP: it depends only on ratified OAuth mechanics.

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 minimum protocol MVP. A single-instance deployment with no delegation enforces Missions with the core alone, and the core confines its one reference to this substrate, the Actor Profile, to its OPTIONAL delegation capability. 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.
• The Client Instance Assertion identifies the specific client instance behind the shared client_id, with its own key, so instance-level policy and revocation become possible.
• The AI Agent Instance Profile adds what agents specifically need: an attester-minted instance identifier that survives key rotation, and provenance claims for the platform, model, and runtime environment.

The composition is the point. One Mission-bound token can now say: this authority derives from this approved task (mission), exercised by this attested agent instance (instance identifier and provenance), acting for this user (sub) through this delegation chain (act). 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.

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 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 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 honest bet underneath it.

The honesty is about revocation. 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. 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.

In the suite’s adoption order this is advanced: stable design to adopt when the use case arrives, with its dependencies tracked honestly. As of July 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 deployments of the protocol MVP are unaffected by it entirely.

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 core already gives you

Before reaching for new machinery, note what the issuance core already covers. The core 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 submitting a Mission Intent through Pushed Authorization Requests, exactly like a first-party Mission, plus three required things: the parent Mission identifier, a parent_token (a refresh token or other grant bound to the parent Mission), and a child_actor identifying who will hold the child. Critically, the Authorization Server resolves the parent from the parent_token, not from the parent identifier. The identifier is a cross-check and audit value only. Naming a parent you do not control gets you nothing. You have to present a grant for it. 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 request carrying a real parent grant.

Subset authority. Every child authority entry must be a subset of a parent entry under the same narrow-only subset rule the core 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 core’s opt-in prefix containment), 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. That hash is the authority commitment a Resource Server enforces against. 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.

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.

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 a successor grant, 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

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 depends only on ratified OAuth and is the stable path, while offline attenuation is labeled experimental 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 swarm of short-lived extraction workers under it.

The through-line

Fan-out is where the convenient thing and the correct thing diverge most sharply. The convenient thing is to let a sub-agent act because it descends from a parent. It costs nothing, widens nothing on paper, and is wrong. The correct thing is to make the child’s authority explicit, narrower, and bounded by the parent’s lifetime, so that there is no ancestry shortcut to take.

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. Spawning a sub-agent does not create authority. A handle is not a credential. The only way down is an explicit, narrower grant.
• 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. The other five layers exist to make this one trustworthy.

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

That sentence is the handbook’s hardest claim, and this part is where it is enforced rather than asserted.

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.

The gap issuance leaves open

The issuance core 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, authority_hash) and an Authority Set in its authorization_details. A Resource Server validates the token, checks audience and scope, and serves the request. That is governance. 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. A compromised, drifted, or prompt-injected agent can spend the whole Authority Set, with whatever parameters it likes, 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), 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 inputs against the action, and a deny on any one is terminal for that action:

• Authority. The action’s resource and invoked tool identity must be within an applicable authorization_details entry the token carries, or that is otherwise available to the PEP or PDP for that token under the issuance profile (through introspection, when the authority is not inline), under the subset rule. The PEP asserts the capability identity it will invoke. The PDP refuses an identity outside the approved actions. A catalog-sourced capability is further bound to the source-content digest recorded at derivation (covered by authority_hash). If a tool definition is later redefined or poisoned, the current source digest differs from the recorded one and the decision fails closed as capability_drift.
• 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).
• 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.
• 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.

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.

Price the model honestly, 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 the protocol MVP is the wedge: they should come from running systems, not from this page.

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

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.

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 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: the gateway and MCP host give broad coverage cheaply, the Resource Server rows give depth where the objects live, the harness row covers what only the runtime can see, and the broker row exists for the classes where agent compromise is the threat model. The enforcement-scope statement is the honest record of which rows a deployment 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.

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 deployment MUST also define an idempotency key: a re-permit of the same normalized action under the same key is refused, or routed to a fresh action-bound approval, while the prior outcome is unresolved or completed. And these classes MUST carry an execution lease or a published maximum execution duration, so run-to-completion is bounded too.

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

Honesty about the topology is required. 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 stable path.

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

The permit binds the request, not the world. 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. 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. Committing resource version, policy version, and decision time in the permit itself is a candidate for the high-assurance end of what the community still has to standardize.

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. Token lifetime is the bound only for paths outside PDP gating.

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, because a non-active Mission derives and refreshes nothing. 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: issuer token introspection or the Mission Status surface as the fail-closed source, with Lifecycle Signals as push acceleration that falls back to polling when the stream goes quiet (Mission Lifecycle and Change).

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.

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.

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. Mission-bound tokens are sender-constrained. Whoever holds the private key the token’s cnf binds can present the token. Mediated execution uses this. For the classes a deployment mediates, 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).

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: 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 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, all five hold:

1. The sender-constraint key sits in the mediating PEP.
2. Governed work runs under a conforming harness whose published execution-environment scope statement covers the mediated classes, so there is no unmediated path.
3. Each such action requires an action-bound approval.
4. The disclosure the approver decides on is rendered from the bound parameters by a component isolated from the agent, never composed by the agent.
5. The state source is an active freshness mechanism.

Active freshness is already a MUST in the base profile for these classes, and the harness condition makes its no-unmediated-path rule a MUST. 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 may still claim base runtime conformance, but not this.

The decision contract and its AuthZEN binding

The runtime profile 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, and it defines the Mission Receipt, the portable per-action evidence of a material action taken under a Mission, only by its name and minimum binding, deferring the portable schema. It defines what a deployment MUST satisfy when it claims runtime Mission enforcement, and nothing about the bytes on the PEP–PDP wire.

That keeps the contract substrate-independent. But it means two conforming deployments do not thereby interoperate at the PEP–PDP boundary. The interoperable wire surface is supplied by a separate document. The AuthZEN Profile binds the abstract contract to the OpenID AuthZEN Authorization API. The division of labor is strict and worth stating plainly:

The runtime profile 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, actor, credential, parameters, audience, and freshness ride in AuthZEN’s open-ended context object as context.mission, context.actor, and so on. A subtlety the profile is careful about: the approved entry’s resource (the audience URI) is matched against context.audience, not against AuthZEN’s own resource member, which carries the finer-grained object identity used only for resource-policy evaluation.
• Two concrete evidence objects. The runtime profile requires per-action evidence. The AuthZEN profile gives it a shape. Decision Evidence is emitted by the PDP: what it evaluated, integrity-protected with a jws-compact envelope, chained back to the Mission via authority_hash (and intent_hash only when the PDP has direct Mission-record access). The intent_hash rides in neither the mission claim nor introspection, so most deployments anchor on authority_hash alone. Execution Evidence is emitted by the PEP after the outcome is known, linked by decision_id, recording whether the permitted action was attempted, completed, failed, or suppressed. 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 is the settlement input that commits actual use and releases the reservation. The split matters. 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 denial_reason from a closed set (out_of_authority, mission_inactive, stale_state, parameter_violation, quota_exceeded, capability_drift, and the rest), not a transport error. An out_of_authority or action_approval_required denial MAY be marked requestable, composing with the AuthZEN Access Request and Approval Profile 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). For an agent in an open world, this is the front door: a tool or resource discovered mid-task arrives as a requestable denial, the beginning of the discovery loop, not the end of the task.

Bringing the binding in this way is the point. The runtime profile is the architecture, the AuthZEN profile is the interoperability layer, and neither duplicates the other.

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 validation 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 is honest about 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 classes are fully mediated, with the egress channels enumerated. 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 honesty 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. Price that honestly. Content evaluation runs per action at runtime cost, 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.

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 PDP interface, one evidence shape, one set of invariants. Page count is the wrong axis to read priority from.

For any deployment whose agents touch consequential writes or external side effects, the runtime layer is doing the load-bearing safety work, not the governance envelope.

A Mission you cannot enforce at the point of use is an audit trail, not a control. The other five layers exist to make this one trustworthy. The Mission Is the Missing Abstraction gives the durable approved task the PDP evaluates against. From a Request to an Approved Mission makes the approval that anchors it trustworthy. Mission-Bound Authority gives the instance identity and act chain the actor check evaluates. Mission Lifecycle and Change gives the active freshness source the high-consequence classes require. And The Agent Runtime and Audit establishes the mediated execution environment and makes the evidence tamper-evident. Take any one away and the runtime gate gets weaker. That is what it means to be the center of gravity.

Where this sits in the handbook

This is the Enforcement step. The concrete answer is two drafts: the Runtime Enforcement profile (the invariants) and the AuthZEN Profile (the wire binding).

• The Mission (the architecture chapter). The durable approved task and Authority Set the PDP evaluates against.
• Part 1: From a request to an approved Mission. Approval-time integrity: the consent that anchors what the PDP enforces.
• Part 2: Mission-bound authority. The instance identity and act chain the runtime actor check consumes.
• Part 4: Lifecycle and change. Status, signals, and expansion: the active freshness source and the durable home for an approved escalation.
• Part 5: The agent runtime and audit. The mediated execution environment this layer relies on, and tamper-evident evidence.

Least-Privilege MCP Tool Calls Need a Mission walks this enforcement boundary at the MCP tool-call layer.

If you adopt one part beyond the issuance core, adopt this one. Containment is where the other four laws become enforceable, and the permit is where the handbook’s whole argument cashes out: not that the Mission exists, but that every consequential action still belongs to it.

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 core 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 core without changing it, with Status as the suite’s root (it carries the status surface, the lifecycle endpoint, and completion’s discharge chapter) and Signals and Management as its satellites. They are not all at the same maturity. Status is the protocol MVP’s state surface. Signals, its push complement, is stable and OPTIONAL, aligned with the Shared Signals transmitter and receiver model. Expansion and Completion are advanced, stable design 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 core 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, authority_hash, state, and the Mission’s expires_at) 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 core’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 core 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.
• 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. The endpoint authorizes operations against deployment policy (typically revoke to the Subject, Approver, or an administrator, and suspend/resume to administrators), and 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.

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 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. The mapping is only-active (a set bit is the only thing that permits reliance), 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 first. Signals began experimental and has earned the stable label: the profile is Standards Track OPTIONAL, aligned with the Shared Signals transmitter and receiver model, and its dependencies (Security Event Tokens and their delivery) were ratified all along. The design posture survives the promotion. Push is a latency optimization over correctly sized status polling, so the stable 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), and a strictly monotonic per-Mission version counter. 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.

The running example. Take the handbook’s running example, the Prepare the Q3 board packet Mission, msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1 at as.example.com. The board meeting is cancelled while the agent is still drafting, so an admin revokes the Mission mid-draft 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.

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 ordinary Mission creation under the issuance core (a Mission Intent submitted through Pushed Authorization Requests, leading to a fresh approval event) with one binding added. The request is bound to the predecessor’s grant (the client presents the predecessor’s refresh token), so the Issuer adjudicates a successor of a specific predecessor rather than an unrelated new Mission. 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. 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.

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, or cross-domain authority always requires fresh human approval, even within the ceiling. 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_01J9Z2P8BQ4Y3F0V0K9D6Z7M1 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 fresh approval for a successor Mission bound to the predecessor’s grant. 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 does not cost the runtime: the harness rebinds running sessions to the successor, 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: stable design to adopt when the use case arrives, with expires_at, revocation, and the complete verb as the simpler path until then.

The issuance core’s Mission Intent can carry success_criteria: a description of when the task is complete. In the issuance core 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 Status and Lifecycle’s completion chapter supplies the enforceable counterpart: terminal_when, an entry-level completion condition. When the condition fires, the entry is discharged. The Authorization Server stops deriving any token carrying it, exactly as it refuses derivation for a non-active Mission.

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, 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 the moment the task it was granted for completed. 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 once all its entries are discharged, but Completion 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. So a prompt-injected agent has nothing to gain from it. The worst it can do is spend its own authority sooner, which is not an attack. That single property is 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) and why an Authorization Server that cannot determine whether a condition has fired fails closed, treating the entry as possibly discharged and withholding issuance rather than risking authority for a task that may have ended. Like the kill switch, completion is built so that uncertainty resolves toward less authority, never more.

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? And the honest version of the question is sharper: 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 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 irreversible actions, external commitments, and privileged administration to a fresh human approval even inside the ceiling.

Run the numbers instead of the vibe. 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.

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

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 Completion’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 every profile in this part, each resolving uncertainty toward less authority:

• Status treats a missing freshness window as “don’t cache” (re-check rather than rely on a stale state).
• Signals treats a missed event as a freshness failure that triggers a fallback poll, never as “still active.”
• Expansion never widens authority without a fresh consent, and supersession is terminal. There is no implicit rollback that resurrects a predecessor’s authority.
• Completion discharges monotonically and withholds issuance when discharge status is unknown.

That is the through-line. 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 uncertainty as permission.

Where this sits in the handbook

Lifecycle and change is the layer that keeps the Mission true over time. It does not enforce actions. That is Mission-Bound Runtime Enforcement, which consumes the state these profiles expose. Every PDP decision is conditioned on current Mission state, and Status is how the PDP learns it promptly, with Signals accelerating and Completion narrowing what there is to learn. It does not handle fan-out. Mission-Bound Authority covers Child Missions and the cascaded state that Status and Signals forward-reference but do not define. And it does not record the transitions for audit. The Agent Runtime and Audit makes every lifecycle change tamper-evident.

The approval event of The Mission Is the Missing Abstraction and the approval-time integrity of From a Request to an Approved Mission establish what was approved. This part keeps that approval honest as the task runs. A Mission that is revoked stops being relied on, a Mission that grows does so under a fresh approval, and a Mission whose work is done retires its own authority. Observe, revoke, grow, complete. Four verbs that turn a one-time approval into a governed lifecycle.

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? The harness profile binds continuity state to Mission state and re-checks before resuming.
• Unwinding work in flight. A Mission can stop after some steps committed and before others run. What happens to the work already moving? The orchestration profile records, before dispatch, how each step will be unwound.
• 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? The audit profile registers evidence into a transparency log.

All three are OPTIONAL companions to the issuance core, at different maturity, and optional at the protocol layer does not mean optional for the claim: the harness is required for the governed-agent claim, and orchestration and audit are required by the claims that use them. The harness is part of the Governed Agent level’s recommended set. Orchestration is a newer, experimental profile the level 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 rebinds the running session to the successor rather than restarting, 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 id and issuer, the authority_hash when known, 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 irreversible actions, external commitments, and privileged administration, 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. 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 continue the packet draft. The board meeting was cancelled and the Mission revoked at 23:00. The harness re-reads the Mission state 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_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
    "issuer": "https://as.example.com",
    "authority_hash": "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY"
  },
  "session_id": "sess_agent_42",
  "work_item": "draft_board_packet_section_3",
  "state": "revoked",
  "state_source": "signal",
  "decision": "suppress",
  "reason": "mission_not_active",
  "occurred_at": "2026-10-01T02:00:00Z"
}

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 and the unmediated paths excluded from the claim. 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 harness profile adds one more control that no per-action check can: taint tracking. The runtime PDP evaluates each action in isolation. It never sees the session as a whole. 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. (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_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
  "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. 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.

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 ratified 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_01J9Z2P8BQ4Y3F0V0K9D6Z7M1:

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.

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 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, just as the examples above show them. The board meeting is cancelled and the Mission is revoked mid-draft. Because the harness bound the agent’s session, task graph, and queues to Mission state, it finds the Mission no longer active and stops the paused draft work. Session continuity was recoverable, but it was never the authority. Orchestration then unwinds what was in flight. The half-written board-packet doc is a reversible_write, rolled back or compensated per the reversibility class and unwind plan recorded before it ran. And the Mission’s SCITT feed shows one verifiable, append-only history under the single subject (approval → consent evidence → the permitted Q3 financials read → the denied CRM expansion → the revocation), each committed by hash, so the packet’s financial contents never enter 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 Mission Is the Missing Abstraction is the only mandatory core. Everything else is an OPTIONAL companion that layers on without changing it, optional to the core 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, and this part fills out the Governed Agent level:

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 all five conditions of the high-assurance level, and the adoption post’s levels table 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 protocol MVP 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.

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). That is not a contrived worst case. It is what a useful agent task looks like, which is Willison’s real point: the trifecta is not an edge case to avoid but the normal shape of valuable work. The question is not how to avoid assembling it. It is how to hold it safely.

This part is the first proof in the validation chapter: 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, honest 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 reframing is the disagreement with the guardrail industry worth stating plainly. The trifecta is not a prompt-engineering problem or a model-alignment problem. It is an authorization problem: 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 session-level mitigation Willison himself points toward: once untrusted content has entered a session, egress authority is downgraded for the remainder of it. That is deliberately coarse. It is a bar-raiser, not information-flow control, and 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: issuance stops, permits stop, the harness halts the session, and the sub-agents cascade. The trifecta does not have to be defeated forever. It has to be caught once, and end everywhere.

The honest residuals

The handbook’s own adversary model carries these in writing, and this part repeats them because a validation that hides its residuals is marketing.

• 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. Two legs safe was always the advice. The Mission is what turns that advice from a hope about deployments into a property the gate enforces, one typed action at a time.

The strongest validation an architecture can get is a requirements list it did not write. Patrick Parker’s Seven Laws of AIdentity are exactly that: a statement of what agent identity systems must guarantee, derived from the dynamics of delegated, generated action and framed in the lineage of Kim Cameron’s Laws of Identity. Parker’s summary of the shift is one sentence: control moves from login to action, and proof moves from logs to receipts. The question a system must answer is who acted, under whose authority, through what chain, and how can you prove it.

The handbook was derived from a different starting point: the five laws of delegated authority, the invariants any implementation of the missing layer must satisfy. Two independent derivations, one from agent dynamics and one from authority invariants, should meet if the layer they describe is real. This part runs that test, law by law. Where Parker’s law lands on existing handbook machinery, the crosswalk names the control and the draft behind it. Where it lands on something the handbook delegates or declines, the last section says so plainly, because a crosswalk that maps everything perfectly has been fitted, not tested.

The crosswalk

Seven demands, seven answers, and every answer is a control that existed before the crosswalk was drawn, with a draft behind it. That is the difference between validation and retrofit.

Three mappings worth a closer look

Generated intent is the deepest agreement. Parker’s second law is the observation this handbook calls its enemy: registration and token issuance happen before the agent decides what to actually do, so a system that authorizes only the agent will permit operations no human approved. The handbook’s whole shape follows from taking that seriously twice. Interpretation moves to consent time, where the human is present and the disclosure is committed, and then every generated action is still checked at execution time against what was approved, because approval is a moment and the work is a span. Authorize the action, not the instrument, was the card chapter’s rule 4. Parker derived the same sentence from the other end.

Least exposure arrives under its own name. Parker’s fifth law and the handbook’s exposure discipline are the same claim: what an agent can see and hold is an attack surface independent of what it may do, so credentials belong inside mediated execution boundaries and breadth of visibility is a risk to budget, not a convenience to default. Mediated custody is the sharpest instance: for the classes a deployment mediates, the agent cannot leak a credential it never holds.

Proof-carrying action is where the wire details matter. Parker asks for receipts with decision context, delegation evidence, policy snapshots, and tamper detection. The handbook’s evidence family maps piece by piece: Decision Evidence carries the decision context including denials, the act chain is the delegation evidence, policy_version on the record makes the derivation re-checkable against the policy that produced it, the integrity anchors commit what was approved, and SCITT registration makes the whole feed append-only and tamper-evident, committed by hash so the sensitive content stays out of the log. The receipts-not-logs shift Parker names is the same shift the handbook makes when it says audit joins on one identifier or it is archaeology.

Where the handbook delegates or declines

An honest crosswalk names its remainders.

• Necessity is not judged. Parker’s sixth law asks whether every chain participant is necessary, not merely authorized. The handbook verifies identity, provenance, integrity, and subset authority for participants, and bounds fan-out by count and depth. Whether a given sub-agent was needed at all is an orchestration and design judgment the protocol records but does not decide.
• The generator’s identity is evidence, not enforcement. Which model produced a proposal is captured by Shaping Evidence as audit material. The handbook deliberately does not condition authorization on model identity, because a trustworthy model is not a property the authorization layer can verify.
• Policy snapshots are references, not archives. policy_version makes a derivation re-checkable if the deployment retains its policy history. Parker’s full receipt vision, with policy snapshots inline, is a retention discipline the deployment must add.
• Embodied agents are out of scope. Parker’s laws extend to cyber-physical surfaces. The handbook’s bindings are protocol substrates. The laws travel, and the wire profiles for physical actuation do not exist yet, which the substrate requirements draft would govern if someone writes one.

The convergence stands regardless. Parker’s closing question, who acted, under whose authority, through what chain, and how can you prove it, is the vendor test in different words, and the fact that two framings built independently keep producing the same six questions is the point of this chapter: the missing layer is not one proposal’s opinion. It is what everyone finds when they look.

The first two proofs 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 (the February 2025 fifteen-threat version, distilled in December 2025 into the Top 10 for Agentic Applications for 2026, mapped below), fifteen threats spanning single agents, multi-agent systems, and the humans around them, alongside the older Top 10 for LLM Applications. 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, not tested, so this one grades itself with three verdicts and accepts the tally it gets:

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. Threats that attack authority are contained. Threats that attack the model, its memory, or its inputs are bounded, because a fully fooled agent still cannot out-argue a parameter check. Threats that attack layers the handbook never claimed are delegated, by name. And one definition keeps every verdict honest: contained means contained at the authority boundary, never 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 and the oracle line bounds the whole chapter.

The agentic threats, all fifteen

Six contained, nine bounded, none waved away. The tally is the honest shape of an authorization layer: the threats that attack authority (tools, privilege, goals, attribution, identity, rogue delegates) land on machinery built for them, and the threats that attack the model or the humans are capped rather than cured, because capping is what a deterministic gate can truthfully offer.

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 fifteen-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 honestly

The Top 10 for LLM Applications predates the agentic taxonomy and 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:

LLM06 deserves the sentence. OWASP’s mitigations for Excessive Agency read like this handbook’s table of contents: 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 is what happens when that advice stops being a bullet list and becomes one architecture with wire drafts behind it.

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. Approval is a moment, work is a span, and the span is policed against the moment.

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, but authority never does.

What the crosswalk does not claim

• 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 verdicts are only as strong as PEP coverage. An unmediated path is a threat with no verdict at all. The adversary model says this in writing: name your enforcement scope, and count your ATMs.
• The enforcement is structural, not semantic. An in-bounds action can still be a bad idea. The classes where content is the harm belong under action-bound human approval.
• 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.
• Inside the approved scope, a turned agent is still turned. Tight scope and short expiry are what keep that sentence tolerable.

The taxonomy’s own mitigation columns keep converging on the same words: least privilege, human approval, complete mediation, audit trails. Those are adjectives until something turns them into verifiable artifacts. The crosswalk above is what that looks like, and the tally, six contained and nine bounded, is what an honest authorization layer scores against a framing its authors did not choose. For the reviewer holding this list against any other proposal, the vendor test asks the six questions that separate a verdict from a hand-wave.

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: the EU AI Act’s application dates for the high-risk tier have already been deferred once and may move again. The mapping below anchors to the shape of the obligations, which has been stable through the schedule changes: purpose, oversight, records, interrupt.

The crosswalk

Eight obligations, and not one row required machinery invented for this part. That is the test of the by-product claim: a compliance mapping that needs new artifacts is a compliance program, and a mapping onto artifacts that exist for safety reasons is an architecture paying a dividend.

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. Every vendor demo has a stop button. The card chapter’s fifth part, Canceling the Card Doesn’t Stop the Charges, is about why most of them are 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 in full: issuance stops, permits stop within a published freshness bound, the harness halts the session, and the delegation tree cascades. When the regulation says interrupt, the architecture can state, with a number, how long interrupt takes.

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 purpose documentation cannot drift from runtime behavior without the gate noticing the difference. 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.

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

You do not adopt mission-bound authorization to pass an audit. You adopt it so that agents doing real work stay governed, and the audit artifacts fall out, 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. This chapter keeps finding the same six questions because every outside framing, threat model, taxonomy, requirements list, regulation, or gap analysis, is circling the same missing layer.

The first four proofs held the model against a threat model, a requirements framework, a threat taxonomy, and the governance frameworks. This one holds it against the framing that matters most for the venue conversation: the standards community’s own problem statement. 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 nine agent scenarios, performs a gap analysis against OAuth 2.0 and its common extensions, and derives the requirements the gaps imply. It proposes no solution, which is exactly what makes it the right test: a catalog of what is missing, written without this family in mind.

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. 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. And one caution rides along, the same one the whole chapter carries: the catalog is outside, the mapping is ours, and every row cites the machinery so the reading can be re-run.

The ten gaps, answered

Seven answered, two partial or delegated with the remainder stated, and none waved away. The striking thing about the tally is the direction of fit: the catalog was written as a problem statement with no solution in mind, and its requirement list reads like this family’s table of contents. The bridge post made the same observation about the card chapter’s build lists. Two independent catalogs of what is missing, one from expense governance and one from the standards community, keep enumerating the same architecture.

The nine 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 core’s home game. The OS resources case is the harness’s local-PEP slice, with the honest 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. Managed services across organizations are cross-domain projection. 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.

Three gaps worth a closer look

Task-level revocation is the gap the Mission was born for. The catalog calls the lack of it “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 a task today means finding every token, cached connection, and sub-agent that serves it, which is the archaeology the handbook’s whole first chapter dramatizes. The family’s answer is the object itself: the task has an identifier, revocation targets it, and every projection (tokens, permits, sessions, children) dies with it within a published bound. Where the catalog asks for an API, the family answers with an object, because task-level revocation is only coherent if the task exists.

The paradigm mismatch is the admission model, seen from the other side. The catalog’s first gap says agents need a “continuous dialogue” of just-in-time permissions rather than upfront grants, and read carelessly, that sounds like the runtime intent inference this handbook rejects. 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. The dialogue the catalog wants is real, and every turn of it is an admission decision, never the agent granting itself scope mid-flight. The difference between those two readings is the difference between the category and a loophole.

Scope explosion is a consent-grain problem, not a scope-count problem. The catalog’s smart-home scenario generates thousands of per-device scopes and an unusable consent screen, and the instinct is to fix the screen. The family’s answer moves the grain instead: the human approves one Mission whose Authority Set the issuer derives, and the thousand fine-grained entries live inside the derivation, rendered as a legible disclosure rather than a scope list. The consent screen failed because it asked a human to compile authority by hand. The approval event succeeds because the compilation is the issuer’s job, and the human judges the result.

The honest remainders

• The group grant is deliberately not native. A coordinated group in this family is a parent and its children, each attributable, because collapsing members into one shared grant identity would trade Law 2 for convenience. A deployment that truly needs group-shared identity is asking for the thing the contractor post warns about, at fleet scale.
• The OS bridge is real and unbuilt. The harness mediates local side effects, and nothing in the family translates a Mission into OS-native entitlements or sandbox profiles. That is a substrate the ecosystem has not standardized, and the family composes with whatever emerges rather than pretending to supply it.
• The catalog and the family are both individual drafts. The convergence argues that the problem statement and this solution shape belong in the same venue conversation. It does not make either one a standard, and the family’s own maturity labels say which answers are stable design and which are experimental.

The close is the same one every proof in this chapter reaches from a different direction. The catalog asks what OAuth cannot say about an agent’s work: what it is, who approved it, whether it still stands, and how to end it everywhere at once. Those are the six questions and the five laws in requirements clothing, and the fact that the standards community’s own gap analysis keeps arriving there is the strongest evidence yet that the missing layer is not one proposal’s opinion.

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 July 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 the AI agent auth best practices describe is OAuth-shaped. But the object this handbook built is not an OAuth feature, and OAuth is no longer its only binding. The family now carries three: the OAuth core as the flagship, the standalone Mission Authority Server as a peer binding, and an AAuth binding that hosts AAuth’s native mission concept at its Person Server, with Substrate Requirements consolidating what any further binding must provide. 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 missing layer 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: the same object, laws, and lifecycle carried onto a non-OAuth substrate by swapping exactly those accidents, and 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.

Where the model sits operationally is the next part: The Authority Control Plane, the two chokepoints, the three bindings, and the structural mapping 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 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 newer documents extend the pattern space:

• The Mission Authority Server (Standards Track: the estate control plane of the layer, and its PDP join is the family’s newest mechanism) is the standalone binding. A dedicated service implements the Mission Issuer role, derives no tokens, and the PDP joins each ordinary OAuth token to its Mission at the point of use. It serves the Status and lifecycle surfaces itself and is the deployment’s freshness source, and 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 can govern across many Authorization Servers) that also serves as the adoption bridge where the AS cannot yet change. 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, until estate Authorization Servers adopt the issuance grant and redeem MAS-minted grants for Mission-bound, state-gated tokens, restoring the token-layer chokepoint without moving approval into the AS.
• The Mission Mandate (an advanced profile: its dependencies are ratified, and it is design to adopt when the cross-domain proof case arrives) answers that proof question. 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. The embedded binding holds both chokepoints. The standalone binding trades the token-layer chokepoint for zero AS change, and the issuance grant is the join that restores it:

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 protocol MVP, with its dependencies tracked honestly: 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 enforcement adapter contract, the deployment manifest, and the evidence envelope carry the interoperability weight on the list the community still has to standardize.

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 (revised through July 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, mission-aware token choreography, and Person Server governance endpoints. An independent derivation, starting from protocol design rather than authority invariants, landed on the same missing object. The convergence 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. That is the validation chapter’s convergence argument playing out at the protocol layer.

The honest reading of where it stands is the one 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 hosts this model at the Person Server with issuance gating intact, so the two proposals converge instead of forking. 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 five 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 approvers 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 the harness rebinds the running session to the successor Mission. The falsifying evidence: expansion and exception rates that stay high after templates and organizational priors mature.

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 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. The family’s answer is that composition without a shared root loses exactly the properties that matter, cross-audience revocation, cross-hop audit join, integrity anchoring (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, and 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 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.

None of these is a reason to wait, because the wedge is small 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 honest 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, and the portability of its authority 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: crawl with the issuance core, walk with the protocol MVP on ratified substrate, run up the Governed and High-Assurance Agent levels as the deployment earns them. 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.

Ask why the authorization stack looks the way it does and the useful answer is that no one designed it as a whole. It accumulated one problem at a time. Each generation solved the question its era made urgent, then relied on people, applications, and organizational process to supply the rest.

That is not a criticism. It is how infrastructure evolves. It also explains the gap that unattended work exposes: not the total absence of purpose, but the absence of a standard, durable object that tells every relevant boundary why authority exists and whether the approved work is still active.

This is a model history, not a literal timeline. The generations overlap; modern systems use all of them; and each can be extended beyond the job described here. The point is to identify the scaling problem that made each abstraction succeed, and the responsibility it did not need to own.

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 user and the application supplied the immediate context.

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.

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.

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?

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; the added task lifecycle is the Mission-shaped part.

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.

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.

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.

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.

That separation was productive. A purchase order, case record, change ticket, workflow run, or deployment plan could hold purpose inside the system that owned the work. In interactive flows, a person also carried context between systems and stopped taking actions when circumstances changed. 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. The missing layer 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. Unattended, cross-system work changes that trade. It makes stale task state a recurring runtime problem instead of an occasional integration concern.

The experiment that breaks the composition

Consider an illustrative month-long task. Alice 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 Alice’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. The composition is missing an owner for shared undertaking state. The human used to bridge many of those gaps through attention and judgment. Unattended work moves that human off the execution path, while the work continues across hours, actors, and domains.

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 reliance within the deployment’s published freshness bound; effects that already completed still require cancellation, compensation, or review.

The handbook develops that object and its five laws: the governing record is independent of credential lifetime; actions remain attributable; derived authority only narrows; non-active state stops reliance within scope and freshness bounds; and 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. They make its absence harder to tolerate.

Identity now covers people, clients, and attested workloads, while authorization can decide whether a particular request is permitted. Unattended work creates a reason to standardize the next answer: what approved undertaking governs this authority, and does it still?

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 one leg of its trifecta-containment claim, beside an enforced default-taint rule that no paraphrase sheds and full mediation of every egress channel.)

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 draft and no interoperable form anywhere in the ecosystem, 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 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 closes the gap. 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:

1
2
3
4
5
6
7
8
9

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

Note what the shaper does not author. It proposes resources and free-text constraints, and when it has concrete candidate authority to offer, that rides in the Intent’s optional proposed_authority member as untrusted input the Authorization Server only narrows. The consented Authority Set is always the AS’s derivation, never the proposal itself. The Intent is closed at the top level, so an unknown member is rejected rather than smuggled through, and optional success_criteria may ride along as disclosure material with no machine effect. 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" }
  }
]

The approved Mission Intent itself stays on the Mission record at mission.issuer. Consumers learn Mission state through introspection, the Mission Status operation, 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 runtime layer binds it to the source-content digest recorded at derivation, such as an operation in a captured MCP tools/list snapshot. 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 that derives no tokens, with the PDP joining each ordinary OAuth token to its Mission at the point of use. That mode buys governance and per-action enforcement without Mission-bound credentials or issuance gating, and runtime enforcement over every consequential path is what makes it hold.

The pipeline with a Mission in scope

The per-call pipeline from the 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 the audience-relevant Authority Set entry, 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, reverifies parameter bindings, and writes Decision Evidence (and, for high-consequence classes, Execution Evidence) 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 action_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. That division of concerns is the point:

That is why the Mission composes with both token-side and resource-side authorization. It does not pick one enforcement style or act as the grant itself. It gives both styles the same governed task and Authority Set to project from.

Does a Mission violate the lethal trifecta?

The lethal trifecta for agents is the combination of three capabilities in one execution loop:

1. Access to private or sensitive data.
2. Exposure to untrusted content that can influence the agent.
3. Ability to cause external side effects or exfiltrate data.

The board-packet agent can easily touch all three. It reads confidential finance data, ingests public filings or partner documents, and sends notifications or publishes a packet. A Mission profile must not pretend that naming the task makes that safe.

The answer is that a Mission does not inherently violate the lethal trifecta, but the authority attached to a badly designed Mission can package it. If the Authority Set grants broad private-data reads, untrusted-web access, and external write authority as one undifferentiated bundle, naming the task has not reduced the risk.

The useful posture does the opposite. It gives the Authorization Server, Resource Servers, PDPs, and egress controls a common object for splitting and governing the bundle:

The runtime profile’s lethal-trifecta boundary treats this as a first-order design constraint, and Mission-Bound Runtime Enforcement is honest about the limits: the defense is as strong as PEP-placement completeness, and per-action checks are not information-flow control.

The design rule is simple. A Mission may describe a task that spans all three elements, but it must not grant all three as ambient authority. Private reads, untrusted inputs, and external writes need to remain separately typed, separately evaluated, and separately auditable under the same canonical Mission.

How Missions compose with AuthZEN

The two models compose with the AuthZEN Access Request and Approval Profile at different enforcement points, exactly as Closing the Gaps laid out for the per-call case. Token-side, a requestable denial at the AS can trigger an Access Request, and a fresh authorization decision can later issue a Mission-bound token. Resource-side, a requestable denial at the PDP can trigger an Access Request, after which the MCP server reevaluates before executing. Approval is input to a new decision in both cases. It is never itself an access grant, and a durable grant is committed as a successor Mission. The AuthZEN profile defines the Mission-specific composition points, including the closed denial-reason set and the two evidence objects.

Comparison with AAuth

The two models name where authorization lands on the OAuth substrate. AAuth reaches the same question from a clean-slate agent substrate, and it carries a task object natively. The agent proposes a mission to its Person Server, the approved mission is bound by hash, and the agent presents a mission reference on each call. AAuth Now Has a Mission Layer reads that design in depth.

The Reference’s landscape classifies the AAuth mission as a sibling instance of the same category rather than a competitor. The interesting question is shared governance when a deployment spans both substrates, and the current draft family states the substrate primitives a further binding must supply without yet specifying cross-substrate projection. What both families already agree on is the operating rule: carry authority when it must travel, evaluate locally when context must stay local, and bind both to the durable approved task when work spans calls, tools, or domains.

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_01J9Z2P8BQ4Y3F0V0K9D6Z7M1 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 in the approved resources or 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 denial_reason: 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 bound to the Mission, the authority_hash, the policy-view version, 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. Expansion is an ordinary Mission creation bound to the predecessor’s grant, so the client presents the predecessor’s refresh token and 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_01J9Z2P8BQ4Y3F0V0K9D6Z7M1 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 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 core 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, the Protocol MVP.
• When revocation must bite faster than token expiry, add Mission Status 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 AS-optional peer binding: governance and per-action enforcement with ordinary tokens, at the cost of issuance gating.
• 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: the definition, the terminology, the one-sentence Mission, the five laws with their violations, the numbers, the layer vocabulary, the protocol MVP formula, the honest deployment claim, the what-not-to-claim list, the revocation statement and its matrix, the vendor test, and the canonical picture, each written to be copied whole, with Mission-Bound Authorization on the Wire as the companion exhibits. The litmus test and everything deeper follow. This page tracks the draft family’s editor’s copies as of July 11, 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 three substrate bindings with OAuth 2.0 as the flagship.

The vocabulary has a strict hierarchy:

A mission-based authorization system has a durable approved task object, derives authority from it, checks consequential actions against it, 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 the hard truth that keeps it honest:

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

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, then binds tokens, runtime decisions, delegation, lifecycle, and audit back to that object.

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 the durable, integrity-anchored, lifecycle-governed governance object for a user-approved task. 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 operationalizes them as the Architecture document’s seven Mission Invariants: the five laws plus two wire-level mechanics, enforcement fails closed, and the integrity anchors commit what was approved rather than prove its semantics.

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 numbers

The handbook counts several things, and each count has one job:

The six questions are the six properties in interview form, and the laws are what the 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 protocol MVP formula

Protocol MVP = issuance core + runtime enforcement + AuthZEN binding + a freshness source (Status, or issuer introspection)

Every dependency in the formula is a ratified OAuth RFC or a finalized OpenID specification, with one tracked exception scoped out of the wedge: the issuance core’s single Internet-Draft reference, the Actor Profile, is confined to its OPTIONAL delegation capability. Lifecycle Signals, the stable push complement, sits outside the formula. The architecture chapter carries the adoption-wedge argument, and Adopting Mission-Bound Authorization carries the staged build order.

The honest deployment claim

A conformance claim names its assurance level and its enforcement scope, and every line can be verified against the implementation checklist below. The architecture’s Mission Deployment Profile is the spec-level form of this claim: a publishable manifest of level, binding, state sources, PEP coverage, custody, evidence, and residual_risks. The coverage split is the load-bearing part: 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 agent safety. It is governance metadata until a PEP checks each consequential action against it.
• 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:

The vendor test

The test is its own page, built to be linked and pasted into an evaluation: The Mission-Based Authorization Vendor Test. Six questions, the litmus property each one probes, and what failing answers sound like. A vendor that passes all six should be able to write the honest deployment claim above, and the implementation checklist is how you verify it.

The canonical picture

One diagram for the whole model: the six stages, and the actors that own 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 (stages), the checkable claim (checklist), what it does not solve (non-goals), the glossary, 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 mandate, 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 flagship binding is OAuth 2.0, where authority is derived as Rich Authorization Requests and the token binding is the mission claim. The standalone Mission Authority Server and AAuth bindings carry the same object on other substrates. 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 hosts the same governance object at the AAuth Person Server, and Mission Substrate Requirements consolidates what any further binding must provide. The reference model is the six properties. OAuth is the flagship binding of it.

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 accountable approver (the user in the common case, an authorized policy tracing to one otherwise) decides against committed inputs, 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

A system is mission-based only if it has all six:

1. Approved task object: a durable record of the task a human (or authorized policy) approved. 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. Runtime enforcement: consequential actions are checked against the current task state at the point of use, not just at issuance.
5. Lifecycle: the task can expire, be revoked, expand (via fresh approval), and complete. Only an active task permits reliance.
6. Evidence: decisions and lifecycle events bind back to the task, so audit can reconstruct it.

Drop any one and you have something weaker: scopes without a task, sessions without approval, a PDP without an approved object, or a claim without enforcement.

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

The authority ceiling, immutable after approval:

• Authority Set: the maximum grantable authority derived from the Intent, committed by authority_hash. Authority is one component of the Mission, not the whole.
• 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). Token Exchange never creates a child Mission, 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.

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, so a lifecycle transition moves the state and its version, never a hash. 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 ceiling under the subset rule, with its own lifecycle bounded by the parent’s.

“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 Authority Set.

The subset rule, compactly. 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 precision keeps the rule honest. 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.

 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

{
  "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "purpose": "urn:example:mission:board-packet",
    "resources": ["https://finance.example.com",
      "https://docs.example.com",
      "https://workflow.example.com"],
    "constraints": ["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:jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE",
  "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" },
  "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 in the mission claim alongside authority_hash. subject and approver are {iss, sub} pairs, authoritative for principal equality, and they may differ when an administrator approves on a user’s behalf. The record also carries its issuance context: the agent’s client_id, the policy_version the Authority Set was derived under (so a derivation can be re-checked), 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 core 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 (core): approved. Derivation and reliance permitted.
• revoked (core): terminated by user, admin, or policy. Terminal.
• expired (core): 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 discharge condition 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.

Where the Mission record lives

By default, the Mission record lives at the substrate’s state authority. On the OAuth substrate that is the Authorization Server, which validates Intents, runs approval events, stores the record, and gates issuance on its state. The substrate-local default keeps the minimum profile coherent, since a deployment can claim the Baseline Issuance level without introducing a new server component.

The Mission Authority Server (MAS) is the standalone binding, the AS-optional mode: 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 is a standalone service that 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, state-gated tokens without moving approval into the AS, so one canonical Mission record gates credentials minted across many issuers.

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 precise sense in which the category is forced rather than preferred. 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. The one row that breaks none is not an alternative but an instance.

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.

Minimum viable mission-based authorization

The smallest useful deployment, and the path up:

• 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, not action-time defense.
• 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 turns governance metadata into agent safety.
• Stage 4: Lifecycle. Signals, expansion, and completion: 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.

Most AI agents that touch private data, untrusted content, or external side effects need at least Stage 3, and Stages 5–6 for fan-out and full governance. Stages 1–2 alone are not enough for consequential autonomy.

The stages roll up into the four claimable Mission Assurance Levels, one line each:

Naming the Baseline level is honest. Claiming the category from it is not: Baseline alone cannot pass the six-property litmus, whose runtime-enforcement property arrives one level up.

The level is one axis. The binding (OAuth AS, standalone Mission Authority Server, or AAuth Person Server) is orthogonal, and a deployment names both. Read the levels as an unlock ladder too: Baseline governs the read-only pilot, Runtime-Enforced makes reversible writes defensible (the read-only ceiling breaks here), Governed Agent makes unattended operation and delegation defensible, and High-Assurance covers the irreversible, external-commitment, and privileged classes. 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 the protocol MVP, with the deeper treatments linked.

Conformance is 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 this:

This deployment claims the Runtime-Enforced level (the protocol MVP) for the finance, docs, and workflow APIs, with PEP coverage at MCP tools/call and the resource APIs, Mission Status freshness within 30 seconds, push revocation for the workflow domain through the Signals profile, and no runtime-enforcement claim for direct shell egress.

Every clause maps to a row above and can be verified. A claim that cannot be written in this form is not a conformance claim. It is marketing. The honest deployment claim in the citation kit is the same claim as a reusable template, and 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 core already keeps the token-side claim a reference (id, issuer, authority_hash), never the Intent’s contents, and deployments should hold that line: resource servers and intermediate PEPs need the identifier and anchors, 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 honest 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 unprotected, 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 all load-bearing 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 approved, governed task (durable, lifecycle-owned).
• Authority Set: the derived, grantable authority the Mission bounds.
• Projection: any substrate-specific, audience-bounded credential or assertion derived from the 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 → Authority Set → Mission → Projection → Runtime Decision → Evidence. The state authority derives the Authority Set from the validated Intent before consent, the approved Mission commits both, 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":{"constraints":["Q3 2026","Example Corp","confidential"],"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"]}}

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":{"constraints":["Q3 2026","Example Corp","confidential"],"expires_at":"2026-10-15T18:00:00Z","goal":"Prepare the Q3 board packet for the audit committee","purpose":"urn:example:mission:board-packet","resources":["https://finance.example.com","https://docs.example.com","https://workflow.example.com"]}}' \
  | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '='
# => jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE

So intent_hash = sha-256:jjx06KDh_TpWYhzSAvzEBH_lMz32eRj1tjgjNvt-crE. 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.

Glossary

Intent step

• Mission Shaper: a client-side component that turns a prompt or trigger into a candidate Mission Intent. Proposes only. Grants no authority.
• Mission Intent: the structured proposal: goal, resources, and expires_at (required), with optional constraints, proposed_authority, success_criteria, purpose, and controls. Closed at the top level: unknown members are rejected, and machine-actionable extensions ride in controls. Submitted via the mission_intent parameter through PAR.
• Shaping Evidence: an optional record of how the proposal was produced. Audit material, not authority.

Mission step

• Approval event: the AS validates the Intent and derives the Authority Set, the Approver consents to the rendered Intent + derived Authority Set, and the AS commits the anchors and creates the Mission active, atomically.
• Authorization Server (Mission Issuer): holds the Mission record, derives authority, runs the approval event, gates issuance.
• mission claim: the object on every issued token: id, issuer, authority_hash, plus the OPTIONAL expires_at the issuance grant profile defines.
• intent_hash: canonical hash of the approved Mission Intent.
• Consent Evidence / consent_rendering_hash: a companion artifact committing the structured disclosure the AS recorded as rendered (not the pixels, not comprehension).
• Subject / Approver: {iss, sub} principals: the user the task is for, and the principal who approved it. They may differ. The Approver may be a human or an authorized policy authority, and a non-human approval traces to a human-consented ceiling or policy (who may approve).

Authority step

• Authority Set: the maximum authority committed by authority_hash, as mission_resource_access entries (resource, actions, constraints, per-entry delegation), plus any other RFC 9396 types a deployment registers.
• authority_hash: canonical hash of the Authority Set.
• authorization_details: the RFC 9396 wire shape for derived authority.
• act chain: the RFC 8693 actor chain. A delegated token carries the same mission claim with subset authority.

Enforcement step

• PEP / PDP: the Policy Enforcement Point obtains a permit from the Policy Decision Point before each consequential action. The PDP evaluates against the live Mission.
• parameter_digest: binds a permit to concrete request parameters, closing the time-of-check-to-time-of-use gap.
• Decision Evidence / Execution Evidence: per-decision and per-outcome audit records.

Lifecycle, roles, delegation

• Core states active / revoked / expired. Companion states suspended / completed (Status), superseded (Expansion), and cascaded (Child Delegation). Unknown states are treated as non-active.
• Mission Status (pull, signed, mission_id-keyed) and Lifecycle Signals (SET events, delivered push or poll). Expansion widens via a fresh approval that supersedes the predecessor. Completion / terminal_when is monotonic, per-entry discharge.
• Child Mission: a strict-subset Mission a parent authorizes for a sub-agent, with cascade revocation. Offline attenuation: minting a narrower child token off the AS hot path, kept safe by the runtime re-checking Mission state.

The handbook’s named artifacts

• The five laws: Durability, Attribution, Narrowing, Termination, and Containment, the layer’s substrate-neutral invariants, quoted above.
• The claim gate / litmus test: the six properties a system must have to claim mission-based authorization, expanded above.
• The vendor test: the same six properties as questions to ask a vendor, with what failing answers sound like.
• The protocol MVP: the adoption wedge, per the formula: issuance core, runtime enforcement, AuthZEN binding, and Status.
• The Mission Assurance Levels: Baseline Issuance, Runtime-Enforced (the protocol MVP), Governed Agent, and High-Assurance Agent, with the binding (OAuth AS, standalone Mission Authority Server, or AAuth Person Server) as the orthogonal axis, staged as crawl, walk, run in Adopting Mission-Bound Authorization, and read as an unlock ladder: each level makes a broader class of write authority defensible.
• The control plane for delegated authority: the operational reading of the layer: the Mission record is desired state, issuance and the runtime gate are the data plane consulting it, the freshness dial is propagation, and the discovery loop is reconciliation for authority. The strategic case is in the architecture chapter, and the structural mapping is the Authority Control Plane part.
• The read-only ceiling: the posture most estates start from (read-only agents, humans approving or executing the writes, permanent pilots), what it costs, and the graduation path off it, named in Adopting.
• The discovery loop: deny, request, approve, expand, retry: how the open world arrives under governance, named in Adopting.
• Survivable incorrectness: the design stance beneath the laws, inherited from the Mission Shaping series: assume the agent will sometimes be wrong and keep the system governable when it is, with least exposure as the input arm and the laws and runtime gate as the action arm.
• Least exposure: bound what the agent may see as deliberately as what it may do, the exposure discipline whose enforceable slice today is the edges the trifecta-containment claim names.
• The honest deployment claim: the claim template naming level, enforcement scope, freshness, evidence, and exclusions, published at spec level as the architecture’s Mission Deployment Profile.
• Open world: the deployment condition the architecture assumes: tools and resources discovered at runtime rather than pre-registered, trust relationships that form after authorization time, delegation to actors unknown at approval, untrusted content in the working set, and authorization decisions made with incomplete knowledge of what the task will need. The Open-World OAuth series is the published treatment, and the discovery loop is how the open world arrives under governance.

The running example, end to end

The handbook follows one task. This is the canonical walkthrough, each part picks up its step, and Mission-Bound Authorization on the Wire shows the same steps as actual protocol exhibits.

Scenario. Alice asks an agent: “Put together the Q3 board packet for the audit committee and let them know it’s ready.” The Mission’s Authority Set is query_financials (finance, Q3 2026), create_doc (docs, board-packet template), and notify_reviewer (workflow, audit-committee group), bounded to an expiry.

1. Derive. The AS validates and narrows the Intent and derives the Authority Set it will ask Alice to approve. (The Mission)
2. Approve. The AS renders the validated Intent + derived Authority Set. Alice consents. The AS commits intent_hash and authority_hash and creates the Mission active, atomically. (Approval integrity)
3. Issue. The agent gets a Mission-bound token carrying the mission claim. (The Mission)
4. Permit a read. The agent reads Q3 financials. The PDP permits query_financials against the live Mission. (Runtime enforcement)
5. Gate a write. Drafting the document is a write. The create_doc permit is bound to concrete parameters and checked at the point of use. (Runtime enforcement)
6. Attempt expansion. Mid-task the agent decides it “needs” CRM customer data (outside the Authority Set). It cannot widen in place. Widening requires a fresh approval (a successor Mission). (Lifecycle)
7. Deny the expansion. Policy declines the CRM expansion. The original Mission is untouched and the agent does not get CRM access. (Lifecycle)
8. Delegate, narrowed. A sub-agent gathers the financials under a Child Mission scoped to query_financials only, expiry ≤ parent, no create_doc or notify_reviewer. (Delegation)
9. Revoke. The board meeting is cancelled. An admin revokes the Mission. Status reports the new state and the Signals push announces it. All further derivation stops, and the child transitions to the terminal cascaded state. (Delegation, Lifecycle)
10. Stop the work. The harness, which bound the session and queue to Mission state, halts the paused draft (session continuity is not authority), and orchestration unwinds the half-written document. (Agent runtime)
11. Reconstruct. The SCITT audit feed for this Mission shows one verifiable, append-only history (approval → consent → the permitted read → the denied CRM expansion → revocation), committed by hash so the financial contents stay out of the log. (Agent runtime)

And run the ending the other way, because most Missions do not die, they finish. No cancellation: the sub-agent returns the financials, the packet is published, and the notice goes to the audit committee. Each entry’s terminal_when condition fires as its step completes (Completion), so create_doc and notify_reviewer retire themselves, the Mission closes as completed, and the same evidence feed reads clean end to end: proposed, approved, exercised inside bounds, finished. Alice got her packet, and the deployment can prove exactly how.

That is the whole category in one task: an approved object, authority derived from it, every consequential action checked against it, delegation that only narrows, a lifecycle that can stop it or let it finish, and evidence that reconstructs it either way.

What this replaces, and what it does not

Mission-based authorization adds one object. It does not displace the stack around it.

• Not OAuth. The Mission rides OAuth issuance, exchange, and sender constraint. The core is an OAuth profile, not a successor.
• Not AuthZEN or your PDP. The runtime contract binds to the AuthZEN Authorization API. The Mission is a new input to the decision, not a new decision engine.
• Not resource policy. The resource stays authoritative for its own objects. A Mission permit is an upper bound, never a command.
• Not session management. The harness keeps owning execution continuity. It consults Mission state before resuming, and that is the whole change.
• Not model alignment. Nothing here makes an LLM’s reasoning trustworthy. The Mission bounds what a drifted or injected agent can reach, and the runtime layer enforces the bound.

What it adds is the piece those layers keep routing around: the governed task object they all bind to. The objections below answer the sharper versions of “isn’t this just X.”

Common objections

The recurring pushbacks live on their own page, built to be linked into the thread where the objection was raised: Common Objections to Mission-Based Authorization. The answers, for the people who run today’s control planes, organized by the plane the reader operates, from “isn’t this just RAR” and “we run Zero Trust” through the state tax, the consent screen, and the standing agent, each with the short answer and where the long one lives.

The draft family at a glance

Every part links its drafts inline. This table is the whole family in one place. All of these are individual Internet-Drafts published as editor’s copies and proposed for discussion. None is adopted by a working group. The names reflect the architecture: substrate-neutral profiles carry draft-mcguinness-mission-* names, while the OAuth bindings keep oauth in the name and “for OAuth 2.0” in the title.

The Maturity column follows the repository’s adoption order. Adopt first is the Architecture and the core. Minimum is what agents that act add for the Runtime-Enforced level, the protocol MVP. Recommended is what AI agents add for the Governed Agent level. By binding profiles carry the standalone Mission Authority Server, the issuance grant join, the AAuth Person Server, and the substrate requirements, adopted where the estate calls for them. Advanced profiles are stable design to adopt when the use case arrives. Experimental profiles are for evaluation only: each depends on an unratified substrate or defines a newer, less-exercised model, and each names a stable path to prefer where one exists.

For AI agents, the README is explicit that consent evidence and the harness are not optional extras. They are the Recommended maturity, the Governed Agent level.

How to cite this handbook

Link the piece that matches what you are referencing:

• The whole handbook: the cover, the front door with the introduction and the chapter map.
• The category and definition: this Reference.
• The evaluation tool and the blueprint: the vendor test (Appendix D), and the blueprint.
• The mental model for non-specialists: What the Corporate Card Already Solved.
• The missing layer and its laws: the five laws of delegated authority above, or the architecture chapter for the full argument.
• The argument for why the Mission is the missing object: The Mission Is the Missing Abstraction.
• The primitive’s definition, roles, and name: the object model, trust boundaries and roles, and why “Mission”, on this page.
• The safety claim (runtime is load-bearing): Mission-Bound Runtime Enforcement.
• The adoption path (crawl, walk, run): Adopting Mission-Bound Authorization.
• The OAuth wire implementation: the draft family.
• The MCP application: Least-Privilege MCP Tool Calls Need a Mission.
• The wire exhibits: Mission-Bound Authorization on the Wire.
• To discuss or object: issues on the draft repository.

One-line definition to quote:

Mission-based authorization is the layer between user intent and per-request authorization. It makes the approved task a first-class governance object, then binds credentials, runtime decisions, delegation, lifecycle, and audit back to it.

A note on requirement language

The handbook quotes requirement keywords such as MUST, SHOULD, and MAY with their BCP 14 meanings (RFC 2119, RFC 8174) when they appear in all capitals. Conformance applies to the profile section each requirement appears in. The drafts are the normative text.

The architecture chapter carries the argument, the Building Mission-Bound Authorization chapter carries the controls this appendix accompanies, and the Field Reference carries the definitions. This appendix carries the bytes: the running example, Alice’s Q3 board packet, as the protocol exhibits an implementer would actually see. Exhibits follow the draft family’s editor’s copies as of July 11, 2026, and the drafts are the normative text. Standard OAuth parameters that carry no Mission semantics are elided. Identifiers, keys, and digests are illustrative, with two exceptions: intent_hash and authority_hash reproduce byte for byte from the test vector, and the two parameter_digest values are real SHA-256 digests over the JCS form of the parameter objects the exhibits name.

1. The proposal: Mission Intent via PAR

The shaper turned Alice’s request into a candidate Mission Intent (From a Request to an Approved Mission), and the client submits it through a Pushed Authorization Request. The mission_intent parameter value is the UTF-8 JSON serialization of the Intent object, form-encoded on the wire. Decoded:

1
2
3
4
5
6
7
8
9

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

The client never sends authorization_details alongside mission_intent. It proposes a task. The Authorization Server derives the authority.

2. The pivot: the approved record

The Authorization Server validates the Intent, derives the Authority Set (query_financials, create_doc, notify_reviewer), renders the disclosure, and on Alice’s approval commits the Mission atomically. The concrete record lives in the Reference. The two anchors it commits are the ones every later exhibit carries:

3. The projection: a Mission-bound token

The agent asks for authority to read the financials. Issuance is a derivation, gated on the Mission being active, and the response echoes the narrowed grant and the mission_id reference:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...",
  "token_type": "DPoP",
  "expires_in": 300,
  "mission_id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } }
  ]
}

The decoded access-token claims carry the projection: a subset of the Authority Set, a sender-constraint key, and the mission claim that binds the credential back to the governance record. The token’s exp is minutes away. The Mission’s expires_at is weeks away. That asymmetry is the Durability law.

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

{
  "iss": "https://as.example.com",
  "sub": "alice@example.com",
  "aud": "https://finance.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1790787780,
  "exp": 1790788080,
  "jti": "at_3Vq8nK2xT6mR9sY1pZ4d",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } }
  ],
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "mission": {
    "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY"
  }
}

4. The gate: an AuthZEN permit, bound to parameters

The packet is drafted and the agent notifies the audit committee. The notify is externally visible, so the PEP at workflow.example.com asks the PDP before acting (Mission-Bound Runtime Enforcement, AuthZEN binding). The Mission, actor, credential, parameters, and freshness ride in context, and because the PEP supplies state, the freshness object is required with it:

 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

{
  "subject": {
    "type": "user",
    "id": "alice@example.com",
    "properties": { "iss": "https://login.example.com" }
  },
  "resource": {
    "type": "notification",
    "id": "notif_board_packet_q3"
  },
  "action": { "name": "notify_reviewer" },
  "context": {
    "mission": {
      "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
      "issuer": "https://as.example.com",
      "authority_hash":
        "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY",
      "state": "active",
      "policy_version": "deploy-policy:v17"
    },
    "actor": { "client_id": "s6BhdRkqt3" },
    "credential": {
      "issuer": "https://as.example.com",
      "expires_at": "2026-09-30T18:09:00Z"
    },
    "parameters": {
      "group": "audit-committee",
      "message": "Q3 board packet is ready for review"
    },
    "parameter_digest":
      "sha-256:DCTAlrBUhQwW_t1EDxHCjdNkLbrT_Bc6nCLYkQubRU4",
    "audience": "https://workflow.example.com",
    "freshness": {
      "mode": "fresh",
      "freshness_at": "2026-09-30T18:05:00Z"
    }
  }
}

The permit comes back bound to exactly those parameters, with a single-use decision identifier because the action is externally visible:

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

{
  "decision": true,
  "context": {
    "decision_id": "dec_2FpQ8kV5nR1tX7mB4sJ9eL6wYc",
    "action_class": "external_commitment",
    "class_source": "deployment",
    "parameter_digest":
      "sha-256:DCTAlrBUhQwW_t1EDxHCjdNkLbrT_Bc6nCLYkQubRU4",
    "policy_view_id":
      "sha-256:CMcisP1vVPsdDxWs336YmmKoBLFgMro1SYVJJEK4sV8",
    "permit_expires_at": "2026-09-30T18:06:00Z",
    "single_use": true
  }
}

The executing PEP recomputes the digest against the parameters it is about to use. Change the message after the permit and the digest mismatches. That is the TOCTOU gap, closed.

5. The refusal: parameter_violation

Steered by a prompt-injected document, the agent tries the same notify (same message) against a different audience, the press-list group. The Authority Set’s constraint names audit-committee, so the evaluation succeeds and the decision is no:

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

{
  "decision": false,
  "context": {
    "decision_id": "dec_6JwN3xT9rQ4mV8kP1sB5eZ2yLd",
    "denial_reason": "parameter_violation",
    "action_class": "external_commitment",
    "class_source": "deployment",
    "parameter_digest":
      "sha-256:_0sG_Vm6EFHvqL5MMNYp-iL1KXXW5CGMr3NLXcXbKrc",
    "policy_view_id":
      "sha-256:CMcisP1vVPsdDxWs336YmmKoBLFgMro1SYVJJEK4sV8"
  }
}

A denial is a successful evaluation, not a transport error, and it lands in the evidence trail with the same decision_id discipline as a permit.

6. The stop: revocation by mission_id

At 23:00 the board meeting is cancelled and an administrator ends the task at the lifecycle endpoint (Mission Lifecycle and Change). One authenticated call, keyed by the Mission, touching no token:

1
2
3
4
5
6
7
8
9

POST /as/mission/lifecycle HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...

mission_id=msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1
&operation=revoke
&reason=Board+meeting+cancelled
&nonce=nonce_8Y3vN0sM6tP1xR9bQ5

7. The announcement: a lifecycle event

Subscribed consumers learn the transition through the experimental Signals push, a Security Event Token whose strictly monotonic version makes replayed or reordered events harmless. Decoded:

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

{
  "iss": "https://as.example.com",
  "aud": "https://workflow.example.com",
  "jti": "set_5R8wQ2kN7mX4vT1pB6zJ3e",
  "iat": 1790809200,
  "sub_id": {
    "format": "opaque",
    "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1"
  },
  "events": {
    "https://schemas.karlmcguinness.com/mission/lifecycle-change": {
      "mission": {
        "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
        "issuer": "https://as.example.com"
      },
      "state": "revoked",
      "prior_state": "active",
      "version": 2,
      "committed_at": "2026-09-30T23:00:00Z"
    }
  }
}

8. The check that stops the resume

At 02:00 the harness wakes to continue the draft and, before dispatching anything, establishes current Mission state (The Agent Runtime and Audit). It needs state, not audience-scoped authority, so it omits audience and the AS addresses the state-only response to the requester. The signed Status response says the one thing no credential in the session can: the approved task no longer exists.

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

{
  "iss": "https://as.example.com",
  "aud": "client_board-packet-agent",
  "sub": "client_board-packet-agent",
  "nonce": "nonce_K9pV4nT2sR7mB1xQ",
  "iat": 1790820005,
  "exp": 1790820065,
  "mission": {
    "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY",
    "state": "revoked",
    "expires_at": "2026-10-15T18:00:00Z",
    "fresh_until": "2026-10-01T02:01:05Z"
  }
}