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 drafting. 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-klrc-aiagent-auth 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 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 claimable steps, the Mission Assurance Levels, each of which makes a broader class of write authority defensible. And one picture carries the whole machine, from proposal to evidence, with the Field Reference walking it stage by stage:
OAuth AS] M[("Mission record
intent_hash, authority_hash,
state")] end subgraph S3["Authority"] AG[Agent instance
+ act chain] end subgraph S4["Enforcement"] PEP[PEP] PDP[PDP] RS[Resource Server] end subgraph S5["Lifecycle"] ST[Status pull /
Signals push] H[Harness] end subgraph S6["Evidence"] AUD([Auditor]) end U --> SH SH -->|Mission Intent via PAR| MI MI -->|renders derived authority| U U -->|approves| MI MI --> M M -->|state-gated issuance,
mission-bound token| AG AG -->|action + parameters| PEP PEP -->|evaluate| PDP PDP -->|permit / deny| PEP PEP --> RS PDP -.->|current state| ST ST -.-> M ST --> H H -.->|stop on non-active| AG M -->|lifecycle events| AUD PDP -->|decision evidence| AUD PEP -->|execution evidence| AUD
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 Issuer holds the desired state (the approved task, its authority, its lifecycle), and tokens, PEPs, and 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 without runtime enforcement is governance metadata, not agent safety.
- 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 can widen authority. 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 substrate properties admit the category, two more back the action-time defense claim, and the vendor test asks all six.
The chapters
Five chapters, read in this order at the depth your role needs, with six appendices behind them:
| The chapters | The job | |
|---|---|---|
| 1 | What the Corporate Card Already Solved | The intuition: the whole model through expense governance, no protocol in sight |
| 2 | Designing Mission-Bound Authorization | The architecture: the object, the laws, and the build order |
| 3 | Building Mission-Bound Authorization | The implementation: each control at wire depth |
| 4 | Testing Mission-Bound Authorization | The validation: the model held against five outside framings, from the lethal trifecta to the OAuth community’s own gap catalog |
| 5 | Weighing Mission-Bound Authorization | The conclusion: the model beyond its bindings, the control plane for delegated authority, and the wagers named |
| A | The Field Reference | Appendix A: definitions, tests, vectors, citations |
| B | Mission-Bound Authorization on the Wire | Appendix B: the running example as verified protocol exhibits |
| C | Common Objections to Mission-Based Authorization | Appendix C: the recurring objections, answered with residuals named |
| D | The Mission-Based Authorization Vendor Test | Appendix D: the evaluation tool, six questions with the failing answers named |
| E | The Standards Map | Appendix E: OAuth, WIMSE, and OpenID mapped to the architecture, with the deltas and substitution hazards named |
| F | The Glossary | Appendix F: the vocabulary in one table, A to Z, every term linking its canonical home |
Three companions ride alongside the chapters, each linked from the chapter it serves:
| The companions | The job |
|---|---|
| The Question Authorization Never Answered | The history: why every generation stopped one question short, and why unattended work forces it |
| Least Exposure Is Broader Than Least Privilege | The input arm: bound what the agent may see |
| Least-Privilege MCP Tool Calls Need a Mission | The model applied at the tool boundary agent builders already own |
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. 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 an evening, 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.
- Executive or product leader? Send Chapter 1, written for the people who will never read a spec, and 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 stages the graduation, level by level.
- 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.
- Implementer? Start from the blueprint, then Chapter 3 for each control at wire depth, with the wire appendix for the bytes.
- Running a security review? Chapter 4 holds the model against five outside framings, from the lethal trifecta to the OAuth community’s own gap catalog.
- Evaluating a vendor claim? Ask the vendor test’s six questions, 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.
Reading paths
The deeper routes. Only reading one thing? Read Mission-Bound Runtime Enforcement, where a mission-bound token stops being metadata and becomes an enforced boundary. 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.
- Coming from draft-klrc-aiagent-auth: The Mission Is the Missing Abstraction first, then Mission-Bound Authority for how the Mission binds to the agent identities that draft establishes.
- 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.
- Your Authorization Server is a product you cannot extend? The Mission Authority Server is the standalone binding, and The Authority Control Plane carries the trade it makes.
- 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.