Designing Mission-Bound Authorization

Chapter 2 of Mission-Bound Authorization, the handbook: the architecture. The object, the laws, and the build order.

This is the architecture chapter, and the spine of the handbook: the card chapter teaches the model, this chapter names the object, the laws, and the control-plane reading, the practice chapter builds each control, the validation chapter holds the result against outside framings, the concluding chapter, Weighing Mission-Bound Authorization, carries the model beyond its bindings, and the Field Reference is the appendix. The cover carries the introduction, the chapter map, and where to start by role.

The problem, in one screen

Agents do not just need identity. They need a governed task object. Tokens say what authority exists. Sessions say the work continued. Policy decision points (PDPs) decide single requests. None of them sizes authority to the task, and none says whether the approved task still exists. The result is the two failures every agent deployment fears: standing credentials that can do far more than the work in front of them, which is why most agents are still read-only, and credentials that keep working after the work is gone. Both are one gap, and it is the one this handbook exists to close: agent auth today can prove who is acting and what credential they hold. It cannot prove the work is still authorized. The Mission is that object: approved before execution, bounded in authority, observable in state, enforced on every consequential action, and terminable the moment the reason for the work ends. And one sentence keeps the whole handbook honest:

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

The industry knows how to authenticate an AI agent. AI Agent Authentication and Authorization (draft-klrc-aiagent-auth) composes WIMSE, OAuth, and SPIFFE into a best-practices path for agent identity, credentials, and authorization. And in Section 9.1 it names the thing every agent actually runs on:

The Mission is the task or objective the Agent will pursue… The process through which the mission is translated into authorization requirements is out of scope of this specification.

This handbook is that process. It defines what the Mission is, why it is the missing abstraction, how the model stands on its own beyond OAuth, and what to build first, in what order.

The timing is not incidental. Agents crossed from drafting to executing, holding credentials that outlive any human attention span. The best-practices document the industry is converging on names the Mission and leaves its translation out of scope. AuthZEN reached Final in January 2026, giving per-request decisions a standard wire. MCP made explicit the tool boundary where enforcement has to land. Every layer around the missing one has hardened, which is exactly when the missing one becomes the bottleneck.

The gap is easy to feel, and one scene is the running example the whole handbook returns to. Alice approves an agent to prepare the Q3 board packet. At 23:00 the board meeting is cancelled, and the reason for the agent’s work disappears with it. At 02:00 the agent’s harness wakes to resume drafting the packet. Every credential in its session is still valid. Every scope still matches. The agent is authenticated exactly as the best practices prescribe. 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.

Run the scene again with a Mission in place. The cancellation at 23:00 becomes one revocation at the Authorization Server. The resume at 02:00 fails the Mission state check before a single token is presented. The Reference walks this example end to end, the wire appendix shows it as bytes, and every part of the practice chapter adds one control to it.

The vocabulary

Mission-based authorization is the category, and it governs the approved task, not just the credential, session, or individual request. Mission-Bound Authorization is this handbook’s concrete instance of it, with OAuth 2.0 as the flagship binding. The vocabulary has a strict hierarchy, and every post uses it precisely:

The core idea is that simple. A Mission is the durable, approval-backed governance object for the task, and tokens, policy decisions, sub-agents, lifecycle events, and audit evidence all bind back to it.

The missing layer

Enterprise architecture has names for its layers. Identity says who exists. Authentication proves who is present. Authorization permits a request. Policy holds the rules. Transport moves the bytes. 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. Human-driven software papered over that gap with presence, workflow, and domain approval objects, the purchase order, the change ticket, none of which traveled across systems, because a person at a keyboard naturally terminates their own intent. Autonomous agents remove the person, and the gap becomes the failure mode.

The largest claim in this handbook is not the Mission. It is that delegated authority management is a missing layer of the stack, and the Mission is one implementation of it.

The decisive distinction from every task-shaped record nearby, a workflow instance, a case, a ticket, a trace, is not the fields. The Mission is the authorization root object: authority is derived from it, execution is enforced against it, and lifecycle and evidence join on it. A record that does none of those is a work item, whatever it carries.

The history of how the gap stayed invisible is a companion of its own: every generation answered its era’s question, and the purpose question stayed implicit because a person supplied the answer for free.

Five familiar failures make the gap concrete, and each one is the same missing object seen from a different angle:

Three objections arrive immediately, and each has a one-line answer.

• Isn’t this just scopes? A scope names requested authority. It does not own the task’s lifecycle.
• Isn’t this just a PDP? A PDP evaluates single requests. It needs the approved task as an input, and no standard layer supplies that object.
• Isn’t this just sessions? A session proves continuity, never authority.

The rest of the alternatives get the same treatment in the Reference: the competitive landscape is the row-by-row case for why existing answers are not enough on their own, and the common objections carry the sharper pushbacks. The layer’s four functions (authority compilation, projection, containment, and continuity) and their vocabulary live in What Survives Without OAuth and the Reference.

The control plane for delegated authority

Infrastructure keeps solving this class of problem the same way. When a kind of change becomes too fast and too consequential for people to supervise directly, the industry stops guarding individual actions and builds a control plane: one layer that holds desired state, with a data plane reconciled against it. Networking did it when configuration outgrew the command line. Compute did it when fleets outgrew runbooks, and declarative desired state with reconciliation became the operating model. Identity built one for human access: the IdP became the control plane for login, and governance systems became the control plane for entitlements.

Agent work already has its data plane. Tokens move, sessions persist, PDPs answer one request at a time, and tools execute. What it lacks is the layer above: nothing holds the desired state of the work itself, what was approved, within what bounds, and whether it still stands. The Mission layer is that control plane, and the machinery this handbook specifies reads naturally in those terms:

• The Mission record is desired state: the approved task, its Authority Set, and its lifecycle.
• Issuance and the runtime gate are the data plane consulting it: the two chokepoints where credentials and actions reconcile against what was approved.
• The freshness dial is propagation: how fast a control-plane change reaches the data plane, priced per class in the revocation matrix and published as a bound.
• The discovery loop is reconciliation for authority: when the work needs more than desired state grants, the agent does not improvise. It proposes a change to desired state, and approval commits it.
• Evidence is the control plane’s record: every decision joins on the object the control plane owns.

The structural mapping carries the full table, from desired state to the fleet API, and the disciplines that keep the framing honest.

This is the control plane this site’s earlier arcs kept arriving at: the Power of Attorney series built its four components and called authority governance the next control plane, and the Mission Shaping series set its operating goal as a control plane that remains governable when the semantic model is wrong. The handbook is that layer specified: the object, the laws, the wire.

Read the read-only ceiling in these terms too. The ceiling is what operating without a control plane feels like: no bounded desired state to reconcile against, so the only safe posture is denying the data plane its writes. Write access you can defend is data-plane authority with a control plane above it.

Identity was the control plane for human access. The Mission layer is the control plane for delegated authority.

The five laws of delegated authority

The layer has invariants that hold on any substrate, and every post in this handbook is an enforcement mechanism for one or more of them.

1. Durability. Authority must outlive credentials. The approved task is durable. Tokens are its short-lived projections, and governing the projection is not governing the task.
2. Attribution. Every action must remain attributable. The user, the acting instance, and the delegation chain stay distinct on every hop, and the approval record commits exactly what the approver was shown. Anything less collapses audit and containment into one blurry principal.
3. Narrowing. Authority can only narrow as work fans out. Every derivation, delegation, and attenuation is a subset of what was approved. Widening is a fresh approval, never an inference.
4. Termination. Revocation must end authority, not merely tokens. Ending the task stops future derivation and future reliance everywhere, and only a currently active task permits either.
5. Containment. Execution must continuously remain inside approved purpose. Each consequential action is checked against the current task at the point of use, because approval is a moment and the work is a span.

The names are how the laws travel. Across every post in this work, “Durability” always means Law 1 and “Containment” always means Law 5, so a reader never has to remember which number was which.

One design stance sits beneath all five, inherited from the Mission Shaping series that preceded this handbook: survivable incorrectness. The agent is probabilistic, so it will sometimes be wrong (hallucinated, injected, or misaligned), and no semantic model of its intent stays complete at the scale and openness of real deployments. The architecture therefore assumes incorrectness and builds so that wrong is survivable, on two arms. The input arm is least exposure: everything the agent sees can steer it, so bound what it may see as deliberately as what it may do. The action arm is the laws above and the runtime gate that enforces them: everything it does is checked against committed authority, so a steered agent cannot reach past what was approved. The action arm has wire surfaces behind it. The exposure arm is discipline whose enforcement surfaces are still young, and the essay carries that boundary honestly.

The laws are the handbook’s backbone, and the claim they force is the thesis: satisfy all five and you have built mission-based authorization, whatever you call the object. Drop one and you have a gap, whatever else you built. The Reference’s landscape runs every alternative against them and names the law each one breaks.

The laws are also the card chapter’s five rules, restated for any substrate, and From the Card to the Architecture argues that mapping rather than asserting it. Each post proves the laws it owns, and each opens by naming them:

The claim gate. The laws compress into the one artifact to remember. A system may claim mission-based authorization only if it has all six:

1. an approved task object,
2. authority derived from that task,
3. narrow-only delegation as work fans out,
4. per-action runtime enforcement,
5. observable lifecycle state, and
6. evidence that joins on the Mission’s identity.

If you keep one structure from this page, keep the claim gate. The five laws are why it is right, and every other structure in this handbook (the card chapter’s five rules, the framework’s verb spine, the assurance levels) is a view of these six properties, never a seventh thing to memorize. The Reference’s litmus test expands each property and names what fails it, and the vendor test turns the six properties into the questions to ask anyone selling one.

The protocol MVP

This handbook is deliberately biased toward a minimum viable deployment, because the gap Section 9.1 names is closable today and the rest should be earned through iteration. The adoption wedge is four pieces:

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

The new work is the Mission object and the binding rules. Everything underneath already shipped: every normative dependency in the wedge is a ratified OAuth RFC or a finalized OpenID specification, so there is nothing to wait for. The Mission-Bound profiles themselves remain proposed Internet-Drafts, and the claim is about the substrate under them. That is a claim about dependencies, not about the drafts themselves: the profiles are individual Internet-Drafts whose wire details are still moving, so design against the laws and the architecture, and pilot the wire. For AI agents, Consent Evidence and the harness profile are the recommended additions, because an agent’s approval surface and its resume path are where the guarantees otherwise lapse.

And the wedge meets the estate where it is: not every resource checks Mission state. Enforcement lands at chokepoints the platform already controls, and the coarse end of the freshness dial, state-gated issuance with short-lived tokens, reaches legacy resources exactly as they are, with revocation honestly bounded by the token lifetime.

Everything else about adoption lives in one place. Adopting Mission-Bound Authorization stages the path (crawl, walk, run), carries the Mission Assurance Levels, and covers the standalone Mission Authority Server binding for deployments that cannot change their Authorization Server. The Reference’s implementation checklist turns the wedge into a checkable claim.

The canonical picture

One diagram for the whole model: the six stages, and the actors that own each. The Reference carries the same diagram for citation.

The user’s request is shaped into an Intent, the Mission Issuer derives and renders the authority, the approval commits the Mission, tokens bound to the agent instance project it, the PEP and PDP enforce each consequential action against current state, the lifecycle surfaces keep that state fresh for enforcement and for the harness, and every decision, transition, and outcome lands as evidence an auditor can join on one identifier.

The parts and companions

Part 1: From the Card to the Architecture

The joint between the mental model and the protocol.

Part 1 translates What the Corporate Card Already Solved into architecture: each of the card chapter’s five rules becomes a law of delegated authority, the corporate-card test becomes the claim gate, and the build lists that close each card post name the draft clusters that fill them.

• Question: How does the card-world mental model map onto the architecture, precisely?
• Laws: all five, in both languages
• Read: From the Card to the Architecture

Part 2: The Mission

The missing abstraction, and the layer klrc leaves open.

Part 2 defines the Mission and the issuance core: Mission Intent, Authority Set, the approval event, intent_hash and authority_hash, the mission token claim, the narrow-only subset rule, and state-gated issuance. It places the Mission as the third layer above authentication and instance identity.

• Question: What is the approved task, and how does OAuth authority bind back to it?
• Laws: 1 and 3
• Read: The Mission Is the Missing Abstraction

Part 3: Adopting Mission-Bound Authorization

Crawl, walk, run.

Part 3 stages the build. Crawl is the issuance core and its kill switch, honestly labeled governance rather than safety. Walk is the protocol MVP, per-action enforcement and Status freshness on ratified substrate. Run is the climb through the Governed and High-Assurance Agent levels, with the roadmap, the ecosystem to compose with, the operational surfaces you will own, and the pieces the community still has to standardize.

• Question: What do I build now, and what comes next?
• Laws: the levels operationalize all five
• Read: Adopting Mission-Bound Authorization
• Applied: Least-Privilege MCP Tool Calls Need a Mission

Companion: The Question Authorization Never Answered

The history. Why every generation stopped one question short.

Passwords answered who, sessions answered continuity, RBAC answered administration, OAuth answered delegation, and fine-grained authorization answered the per-request decision. The question none of them answered, why does this authority exist and does it still, stayed implicit because the purpose object was a person. The history that makes the missing layer inevitable rather than novel, with usage control as the theory that named it twenty years early.

• Question: Why did sixty years of authorization never make purpose first-class, and what changed?
• Read: The Question Authorization Never Answered

Companion: Least Exposure

The input arm. Bound what the agent may see.

An agent can make only the exact calls it is authorized to make and still be turned by what it was allowed to read. The companion generalizes the discipline: every context source (retrieval, memory, tool catalogs, secrets, responses) is an exposure point the approved task should scope, for the same reason the calls are.

• Question: What may the agent be shown while deciding what to do?
• Stance: the input arm of survivable incorrectness, beside the laws’ action arm
• Read: Least Exposure Is Broader Than Least Privilege

The Reference and Glossary

The appendix. Link it, quote it, cite it.

The Reference carries the citable definitions so the posts can carry the argument: the citation kit, the six-property litmus test, the object model with a concrete record, the lifecycle states, the competitive landscape, the implementation checklist and honest-claim format, the adversary model, the glossary, a reproducible test vector, the full draft family at a glance, and the running example walked end to end.

• Question: What is mission-based authorization, precisely?
• Read: Mission-Based Authorization: The Field Reference

Where to go next

The deeper material lives with its owner, and each post links its own drafts inline.

• Continue: the practice chapter builds each control this chapter names, at wire depth, part by part.
• The conclusion: Chapter 5, Weighing Mission-Bound Authorization carries the model beyond its bindings, the control plane for delegated authority, and the wagers.
• The appendix: the Field Reference carries the citation kit, the litmus test, the landscape, and the glossary that defines every term in one line.
• The cover: the handbook’s cover carries the introduction, the chapter map, and the reading paths, from the one-post budget to the build-and-evaluate cuts.
• The argument: issues on the draft repository take technical disagreement, and the drafts move with it.