Building Mission-Bound Authorization

Chapter 3 of Mission-Bound Authorization, the handbook: the implementation. Each control at wire depth.

This is the practice chapter. The Designing Mission-Bound Authorization chapter establishes the architecture: the Mission object, the five laws, the substrate-neutral framework, and the crawl-walk-run adoption path. Read it first, or at least The Mission Is the Missing Abstraction, because every part here assumes the object it defines. And one sentence governs everything this chapter builds:

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

The decisive control is Part 3, runtime enforcement. The other four make its decision meaningful: the approval creates the bounds, the authority projects them, the lifecycle keeps them fresh, and the audit makes the decision accountable.

The handbook in one line: the card chapter teaches the model, the architecture chapter names the object and the laws, this chapter builds the controls, the validation chapter holds the result against outside framings, and the Field Reference is the appendix for all of it. Every part here adds one control to the handbook’s running example, Alice’s Q3 board packet, and the wire appendix shows the same example as bytes.

One table maps this chapter to the rest of the handbook:

The five parts

Each part here takes one control of the governance loop and carries it at implementation depth: the invariants, the wire surfaces, the failure modes, and the drafts that own them. The loop is the same one What the Corporate Card Already Solved teaches before any protocol appears, and each part opens the room the card chapter toured:

Part 1: From a Request to an Approved Mission

The approval.

Shaping proposes, the Authorization Server validates and narrows, Consent Evidence commits the disclosure as rendered, and deferred approval with revision handles decisions that arrive late or come back narrower.

• Question: How does an open-ended request become an approval record an auditor and PDP can trust?
• Laws: Attribution and Containment
• The card room: You Approve What You Were Shown
• Read: From a Request to an Approved Mission

Part 2: Mission-Bound Authority

Instances, actors, and delegation.

The mission claim rides tokens bound to attested instances, actor chains keep every hop attributable, and delegated work gets explicit, narrower, separately revocable authority.

• Question: How does bounded authority attach to authenticated instances and flow to delegates without becoming ambient inheritance?
• Laws: Attribution and Narrowing
• The card room: The Contractor Gets Their Own Card
• Read: Mission-Bound Authority: Instances, Actors, and Delegation

Part 3: Mission-Bound Runtime Enforcement

The load-bearing safety layer.

A PEP obtains a permit from a PDP for each consequential action, parameter-bound, metered, fail-closed, with AuthZEN as the concrete binding.

• Question: How do you prevent an active Mission from becoming ambient authority?
• Laws: Containment
• The card room: The Network Approves Every Transaction
• Read: Mission-Bound Runtime Enforcement

Part 4: Mission Lifecycle and Change

Observe, revoke, grow, complete.

Status for fail-closed freshness with Signals as the push complement, Expansion for governed growth, and completion’s monotonic narrowing carried by the Status suite.

• Question: How does the approved task remain governable after the first token is issued?
• Laws: Durability, Narrowing, and Termination
• The card room: Canceling the Card Doesn’t Stop the Charges
• Read: Mission Lifecycle and Change

Part 5: The Agent Runtime and Audit

Sessions are not authority.

The harness stops work when the Mission does, orchestration unwinds what is in flight, and SCITT audit makes the evidence tamper-evident.

• Question: How do the guarantees survive a real long-running agent?
• Laws: Durability, Attribution, and Termination
• The card room: Canceling the Card Doesn’t Stop the Charges
• Read: The Agent Runtime and Audit

Where to go next

Every part here builds a control. What comes next is holding the result up to the light.

• Continue: the validation chapter holds what this chapter builds against the lethal trifecta, the Laws of AIdentity, the OWASP threat taxonomy, the compliance frameworks, and the OAuth community’s own gap catalog.
• Alongside this chapter: Mission-Bound Authorization on the Wire is the running example as verified protocol exhibits, from the PAR submission to the status check that stops the resume, and Least-Privilege MCP Tool Calls Need a Mission applies the model at the boundary most agent builders already own.
• The appendix: for definitions, the litmus test, the object model, the adversary model, the test vector, and the full draft catalog, the Field Reference is the citable appendix for the whole handbook.
• The cover: the handbook’s cover maps the introduction, the chapters, and where to start by role.
• The argument: issues on the draft repository are where disagreement lands, and the drafts move when it does.