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:

PartThe controlThe card roomLaws
1. From a Request to an Approved MissionThe approvalYou Approve What You Were ShownAttribution, Containment
2. Mission-Bound AuthorityThe delegationThe Contractor Gets Their Own CardAttribution, Narrowing
3. Mission-Bound Runtime EnforcementThe enforcementThe Network Approves Every TransactionContainment
4. Mission Lifecycle and ChangeThe lifecycleCanceling the Card Doesn’t Stop the ChargesDurability, Narrowing, Termination
5. The Agent Runtime and AuditThe runtimeCanceling the Card Doesn’t Stop the ChargesDurability, 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:

  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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.