Building Mission-Bound Authorization
This is the practice series. The Mission-Bound Authorization series 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.
The publication in one line: the card series teaches the model, the architecture series names the object and the laws, this series builds the controls, and the Field Reference is the appendix for all of it. Every part here adds one control to the publication’s running example, Alice’s Q3 board packet, and the wire appendix shows the same example as bytes.
One table maps this series to the rest of the publication:
| Part | The control | The card room | Laws |
|---|---|---|---|
| 1. From a Request to an Approved Mission | The approval | You Approve What You Were Shown | Attribution, Containment |
| 2. Mission-Bound Authority | The delegation | The Contractor Gets Their Own Card | Attribution, Narrowing |
| 3. Mission-Bound Runtime Enforcement | The enforcement | The Network Approves Every Transaction | Containment |
| 4. Mission Lifecycle and Change | The lifecycle | Canceling the Card Doesn’t Stop the Charges | Durability, Narrowing, Termination |
| 5. The Agent Runtime and Audit | The runtime | Canceling the Card Doesn’t Stop the Charges | Durability, Attribution, Termination |
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 with no protocol in sight, and each part opens the room the card series toured:
- 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.
- Mission-Bound Authority: Instances, Actors, and Delegation. The 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.
- Mission-Bound Runtime Enforcement. The enforcement, and the load-bearing part. A PEP obtains a permit from a PDP for each consequential action, parameter-bound, metered, fail-closed, with AuthZEN as the concrete binding.
- Mission Lifecycle and Change. The lifecycle. Status for fail-closed freshness with Signals as the experimental push complement, Expansion for governed growth, and Completion for monotonic narrowing. Only an active Mission permits reliance.
- The Agent Runtime and Audit. The runtime. The harness stops work when the Mission does, orchestration unwinds what is in flight, and SCITT audit makes the evidence tamper-evident. Session continuity is never authority.
Two companions ride alongside the parts. 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.
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 both series.