Mission-Bound Authorization
The handbook: a missing authorization layer for AI agents. The intuition, the architecture, the implementation, and the validation, in four chapters.
Agent authentication has matured fast: workload identity, attested instances, scoped tokens. Authorization has not kept up with the one fact that matters, because agent auth today can prove who is acting and what credential they hold. It cannot prove the work is still authorized. This handbook is the missing layer built out in full: the Mission, a durable record of the approved task, with every token, policy decision, delegation, lifecycle event, and audit record bound back to it. One scene runs through the whole handbook as its running example: Alice approves an agent to prepare the Q3 board packet, the meeting is cancelled at 23:00, and at 02:00 every credential still works.
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.
The Essentials
Three short artifacts, each built to be linked and reused:
| The essentials | The job |
|---|---|
| The case | Why the category exists, in five minutes |
| The vendor test | How to evaluate any claim, in six questions |
| The blueprint | What to build first: the walk stage of the staged path |
The Chapters
Four chapters, read in this order at the depth your role needs, with the Field Reference as the appendix:
| 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 | Proving Mission-Bound Authorization | The validation: the model held against four outside framings, from the lethal trifecta to the EU AI Act |
| 5 | The Field Reference | The appendix: definitions, tests, vectors, citations |
Where to Start
- New to the problem? Start with Chapter 1, and if you read only one post, read its fifteen-minute flagship, Agents Need a Corporate Card, Not a Blank Check.
- Architect or standards reader? Chapter 2 names the object, the five laws, and the build order, and carries the canonical picture.
- 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 the lethal trifecta, the Laws of AIdentity, the OWASP threat taxonomy, and the compliance frameworks.
- Evaluating a vendor claim? Ask the vendor test’s six questions.
- Citing or defining the category? The Field Reference is the citable appendix, with how to cite this handbook.
Reading Paths
Seven pages own seven jobs. Start where your question lives:
| Page | Job |
|---|---|
| This cover | The front door: the essentials, the chapters, where to start |
| The architecture chapter | The model and your path through it |
| The Reference | Cite the category, the laws, and the claim format |
| The Mission | The core argument for the primitive |
| Enforcement (practice chapter) | Evaluate enforcement |
| Adopting | Plan adoption, crawl to run |
| The Architecture draft | The model on its own terms, for spec-first readers |
Only reading one thing? Read Mission-Bound Runtime Enforcement, the practice chapter’s enforcement part. Only reading four? The architecture chapter, that enforcement part, Adopting Mission-Bound Authorization, and the Field Reference. New to the acronyms? The Reference’s glossary defines every term in one line. And for anything you need to hand to someone else, the essentials above are built to travel.
To orient:
- Want the intuition first: read Agents Need a Corporate Card, Not a Blank Check, the fifteen-minute flagship that walks the whole loop, then From the Card to the Architecture, the joint between that mental model and the architecture. The rest of the card chapter takes each control deep.
- Building agents, not identity systems? Read the corporate card for the model, the agent runtime for what your harness must do, then the MCP application post for the boundary you already own.
- Sharing this with leadership? Send the corporate card with the architecture chapter’s problem in one screen. The five laws and the vendor test are the two artifacts to paste into the deck.
- Coming from draft-klrc-aiagent-auth: read The Mission Is the Missing Abstraction, then the practice chapter’s Mission-Bound Authority for how the Mission binds to the agent identities that draft establishes.
- Coming from IGA or PAM: the Reference’s landscape and objections say precisely what the just-in-time-elevation and access-request analogies miss.
To build or evaluate:
- Ship the protocol MVP: read The Mission Is the Missing Abstraction, then Adopting Mission-Bound Authorization for the staged blueprint, then the practice chapter for each control.
- Want the bytes: the wire appendix is the running example as protocol exhibits, from the PAR submission to the status check that stops the resume.
- Your Authorization Server is a product you cannot extend? The Mission Authority Server is the standalone binding and the adoption bridge for that case, and The Mission Framework carries the trade it makes.
- Think this is just claims in tokens? Read Mission-Bound Runtime Enforcement first. It is where a mission-bound token stops being metadata and becomes an enforced boundary.
- Think there is a simpler answer? The competitive landscape takes each alternative seriously, row by row, and names the law each one breaks and when it is enough on its own.
- Evaluating a deployment or vendor claim: ask the vendor test’s six questions, then verify against the implementation checklist and require the claim sentence.
- Citing or defining the category: link the Reference directly, and The Mission Model when the question is what the primitive is rather than whether a system qualifies.
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.