Mission-Bound Authorization

The handbook: a missing authorization layer for AI agents. The intuition, the architecture, the implementation, the validation, and the conclusion, in five chapters.

Agent authentication has matured fast: workload identity, attested instances, scoped tokens. Authorization has not kept up, and enterprises feel it as two fears. The loud one is blast radius. Ask why agents are still read-only and the answer is a picture: a probabilistic model one hallucinated filter away from deleting real customers, holding a service account allowed to delete any of them. It is not hypothetical. In July 2025 a coding agent deleted a production database during an explicit code freeze. The published account blames missing environment separation and instructions the agent ignored, and that is the diagnosis this handbook starts from: instructions are not authority, and on the published accounts the credential the agent held permitted the deletion it performed. A credential sized for the integration rather than the task cannot answer the question every enterprise asked next, which is what else it could have deleted. So the agent gets read access, a human keeps the writes, and the pilot stays a pilot.

The quieter fear needs no hallucination at all. Suppose the authority were perfectly right-sized: Alice approves an agent to prepare the Q3 board packet, and at 23:00 the meeting is cancelled, taking the reason for the work with it. At 02:00 the agent’s runtime wakes and resumes its queued work on the packet. Every credential in its session is still valid. Every scope still matches. The agent is authenticated exactly as the best practices prescribe, and by every rule the stack knows how to check, the work should continue. The one fact that should stop it is a fact no standard layer can represent. The approved task no longer exists. That scene is the handbook’s running example, and the two fears are one gap:

Agent auth today can prove who is acting and what credential they hold. It cannot prove the work is still authorized.

Look at what each layer of the stack actually answers. Identity says who exists. Authentication proves who is present. Tokens say what authority was granted. Sessions say the runtime survived. A policy decision point evaluates one request at a time. A token can be fresh while the purpose is dead, because none of them owns the question an autonomous agent runs on: what was approved, by whom, within what bounds, until when, and whether it is still in force. Human-driven software leaned on presence, workflow, and domain approval objects, (the purchase order, the change ticket) for task continuity, and none of it traveled across systems: a person at a keyboard naturally terminates their own intent. Agents remove the person, and the gap becomes the failure mode.

The gap even has a name in the document the industry is converging on. draft-ietf-wimse-aims, the WIMSE working group’s AI Identity Management System, names the Mission as “the task or objective the Agent will pursue” and then declares the process of translating it into authorization requirements out of scope. It does not yet have an object. And the timing is not incidental: AuthZEN went Final in January 2026, MCP made explicit the tool boundary where enforcement has to land, and agents crossed from drafting to executing, in an open world where tools are discovered rather than configured. Every layer around the missing one has hardened, which is exactly when the missing one becomes the bottleneck, and the history of how it stayed missing is its own short story.

This handbook is the missing layer built out in full: the Mission, a durable record of the approved task, with authority right-sized from it, every consequential action (one with external visibility or effect) checked against it, the working set the agent is shown scoped by it, and every token, policy decision, delegation, lifecycle event, and audit record bound back to it. The layer has five laws, Durability, Attribution, Narrowing, Termination, and Containment, and every chapter is an enforcement mechanism for them. Deployments adopt the machine in bundles, the Mission Assurance Levels, taken in adoption order. Each bundle makes a broader class of agent work defensible to grant, starting with writes outside the high-consequence classes (irreversible actions, external commitments, and privileged administration) whose bounds the receiving Resource Server enforces, and a deployment adopts the bundle its risk warrants and stops there. An estate’s claims are made per path, so it can run issuance gating on some paths and runtime enforcement on others. And one picture carries the whole machine, from proposal to evidence, with the Field Reference walking it stage by stage:

Be precise about what that buys. The architecture establishes that an approved task record exists and remains active, that the actor and the requested action fit the authority and constraints the record committed, and that enforcement saw sufficiently fresh state: the requested action remains within the active, approved task boundary the system recorded. It does not establish that a permitted action truly advances what the human meant. Mission compliance is evaluated against the approved representation of purpose, not against an independent oracle of human intent, and that is why shaping, disclosure integrity, authority derivation, and runtime enforcement each carry real weight.

The whole argument compresses to one line:

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

Mission-based authorization is the category: authorization governed by an approved-task object, whoever builds it, and the vendor test holds any claimant to it. Mission-Bound Authorization is this handbook’s architecture and draft family for the category, and the Mission is its object.

Operationally, the layer reads as the control plane for delegated authority. Identity has a control plane and credentials have one. The approved task does not, and this is it: the Mission control point (in OAuth, the Mission Issuer) holds the desired state (the approved task, its authority, its lifecycle), and tokens, policy enforcement points (PEPs), and policy decision points (PDPs) are the data plane that acts within it. The structural mapping and the architecture chapter’s strategic reading carry the full case.

What this is not

• Not a replacement for OAuth, workload identity, or your PDP. The Mission is a new input to layers that keep their jobs. TLS did not replace TCP, and OAuth did not replace HTTP: each filled the layer beneath it left open, and so does the Mission.
• Not a way to make the agent’s reasoning trustworthy. It makes the agent’s incorrectness survivable.
• Not a token format. A Mission-bound token is as strong as the Resource Server that enforces its bounds. Per-action, parameter-level, and state-aware checks come from runtime enforcement.
• Not a task tracker. The Mission is an authorization object with an approval, a lifecycle, and evidence, not a work item.
• Not a system where the agent’s own words size its authority. The shaper proposes, the issuer derives, the approver decides, and nothing the agent can influence widens authority beyond what the approver accepts. A compromised shaper can propose badly, never grant broadly.
• Not a label a vendor can claim without obligations. The claim gate splits four and two: four properties admit the category, two more back the action-time defense claim, and the vendor test asks all six. The gate is the handbook’s own bar for the category and is stricter than the drafts’ substrate contract: a binding can meet that contract and still fail the gate.

The chapters

Five chapters, read in this order at the depth your role needs, with six appendices behind them:

Three companions ride alongside the chapters, each linked from the chapter it serves:

In the complete edition, the history essay opens the book as its prologue, Least Exposure follows Chapter 3’s runtime part, and the MCP essay closes the chapters as a builders’ case study.

The complete edition is the whole handbook as one continuous, print-ready page, with a Markdown rendition alongside.

Behind the handbook is the Mission-Bound Authorization draft family, a family of proposed Internet-Drafts with editor’s copies for every profile the chapters cite. The repository also carries a reference implementation built on the OAuth binding, with a requirement-level conformance ledger and a proposed issuance-only reference deployment: a Mission-aware Authorization Server and Resource Servers that need not be Mission-aware. And if you think the model is wrong somewhere, the issues on the draft repository are where the argument lands.

The bet of the handbook: agents graduate from pilots when the approved task becomes an object the stack can hold. The prize is write access you can defend. The rest of this page is the router: where to start by role, and the deeper reading paths.

Where to start

This cover is the introduction. A chapter takes from twenty minutes to two hours, and the Reference is for looking things up, not reading through. Start where your role does:

• New to the problem? Chapter 1’s fifteen-minute flagship, Agents Need a Corporate Card, Not a Blank Check, makes the case entirely in card terms, and From the Card to the Architecture is the joint between it and the architecture: about 25 minutes together.
• Executive or product leader? Send Chapter 1, about 40 minutes and written for the people who will never read a spec. Its first part ends with the six-question corporate-card test to put to any agent platform. Paste the problem in one screen and the five laws into the deck.
• Deciding whether agents can move past read-only? Adopting names the ceiling and where it breaks: writes outside the high-consequence classes whose bounds the receiving Resource Server enforces are defensible from the first adoption bundle, and parameter-bound writes from Runtime-Enforced. Its adoption sheet sets the bundles side by side. Read it with the ceiling and not every resource checks Mission state to see what changes on the paths you want to govern, about 10 minutes in all.
• Architect or standards reader? Chapter 2 names the object, the laws, and the build order, and Chapter 5 carries the model beyond its bindings and the wagers: about 60 and 20 minutes.
• Implementer? Start from the blueprint, then Chapter 3 for each control at wire depth, with the wire appendix for the bytes: about two hours in all, most of it Chapter 3.
• Running a security review? Chapter 4 holds the model against five outside framings, from the lethal trifecta to an OAuth agent authorization gap catalog, in about 50 minutes.
• Evaluating a vendor claim? Ask the vendor test’s six questions (a five-minute read), then verify against the implementation checklist, and ask for the demonstration that settles it: show me one denied action where the token was valid but the Mission’s state, bounds, parameters, or delegation chain made the action impermissible.
• Citing or defining the category? The Field Reference is the citable appendix, with how to cite this handbook; it runs about 50 minutes end to end but is built for lookup.

Reading paths

The deeper routes. Only reading one thing? Read Mission-Bound Runtime Enforcement, where each consequential action is checked against the Mission’s current state and bounds at the point of use, in about 35 minutes. New to the acronyms? The glossary defines every term in one line.

• Building agents, not identity systems? The corporate card for the model, the agent runtime for what your harness must do, and the MCP application for the boundary you already own: about 50 minutes for the three.
• Coming from draft-ietf-wimse-aims: The Mission Is the Missing Abstraction first, then Mission-Bound Authority for how the Mission binds to the agent identities that draft establishes: about 35 minutes.
• Coming from IGA or PAM: the landscape and the objections name what the access-request and elevation analogies miss, and you do not need an agent to start is the affirmative case: task-bound grants that expire instead of standing entitlements. About 20 minutes for all three.
• Your Authorization Server is a product you cannot extend? Start with the Mission Authority Server, a standalone controller over the OAuth binding’s Mission data model that records and governs Missions beside the Authorization Servers you already run, and The Authority Control Plane carries the trade it makes in about six minutes.
• Think there is a simpler answer? The competitive landscape takes each alternative row by row and names the law it breaks and when it is enough on its own, in about five minutes.