---
title: "From the Card to the Architecture"
date: "2026-07-22T05:30:00-07:00"
lastmod: "2026-07-22T05:30:00-07:00"
description: "The corporate-card chapter taught a governance loop with no protocol in sight. This part is the translation: each of its five rules becomes a law of delegated authority, the corporate-card test becomes the claim gate, and every place the analogy broke becomes a named piece of the draft family."
summary: "What the Corporate Card Already Solved walked a working delegated-authority architecture one control at a time and never mentioned a protocol. This part is the joint between that mental model and this chapter\u0026rsquo;s architecture. The five rules the card world taught become the five laws of delegated authority, stated for any substrate. The corporate-card test becomes the claim gate a vendor claim must pass. And the build lists that closed each card post, the things the agent stack cannot borrow from the expense world, turn out to enumerate the draft family: disclosure integrity, field-speed narrowing, checkpoints per boundary, endings that propagate, and a record that earns trust without a bank."
slug: "from-the-card-to-the-architecture"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Intent-Based Authorization"
  - "Internet-Draft"
series:
  - "designing-mission-bound-authorization"
---


{{< tldr >}}

- **The move.** [What the Corporate Card Already Solved](/series/what-the-corporate-card-already-solved/) taught the governance loop with no protocol in sight. This part translates it: [each rule becomes a law](#the-five-rules-become-five-laws), [the mapping table becomes an object](#the-mapping-table-becomes-an-object), [the corporate-card test becomes the claim gate](#the-corporate-card-test-becomes-the-claim-gate), and [each build list names a draft cluster](#the-build-lists-name-the-draft-family).
- **The one-sentence version.** The card chapter ends every post with a build list, the things the agent stack cannot borrow from the expense world. This draft family is that build list, itemized.
- **You do not need the card chapter first.** The translation reads on its own, and each section links the card post it translates. But the card chapter is the fastest way to hold the whole model, and it is written for the people who will never read a spec.
- **The card analogy.** This part is the card analogy, run in reverse: from the loop finance already operates to the object and protocol surfaces agents need.
- **The laws.** All [five laws of delegated authority](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority) appear here in both forms, card language and architecture language, with the mapping argued rather than asserted.
- **Spec (editor's copy).** [An Architecture for Mission-Bound Authorization](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-architecture.html), the document that states the model the way this part arrives at it.

**Reading path.** ~9 minutes start to finish. Read in order.

{{< /tldr >}}

# Overview

[What the Corporate Card Already Solved](/series/what-the-corporate-card-already-solved/) makes one claim across five posts: enterprise finance independently discovered the governance architecture that agent authorization now requires, and proved it at global scale. An instrument issued for an approved purpose, an approval bound to what the approver was shown, delegation that only narrows, a network that authorizes every transaction, and endings that actually end. Every post in that chapter closes the same way, with the places the analogy breaks and the build list those breaks imply.

This chapter is the build. The card chapter deliberately never says what the protocol work looks like, because the loop needs no standard to be understood or even operated. But the translation into standards terms is real work with real choices, and this part is the joint between the two: what each card rule becomes when it is stated for any kind of authority, what the mapping table becomes when it is made into an object, and which drafts answer which break. If you read the card chapter first, this part will feel like recognition. If you did not, it works as a fast tour of the whole model, and the card chapter is waiting when you want the protocol-free version.

# The five rules become five laws

The card chapter distills each post into one rule, stated in the card's language. This chapter states the same invariants for any substrate and calls them the [five laws of delegated authority](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority), because they hold whether the authority is money, API calls, or signatures, and whether the substrate is OAuth or something else. The mapping is close but not decorative, and the two places it bends are worth the look.

| The card rule | The law it becomes |
| --- | --- |
| Credentials are projections of authority, not its durable source | 1. Durability: authority must outlive credentials |
| The approval binds the disclosure, not the intent | 2. Attribution: the approval record commits what was shown, and every action stays attributable |
| Delegation narrows, or it contaminates | 3. Narrowing: authority can only narrow as work fans out |
| Authorize the action, not the instrument | 5. Containment: execution must continuously remain inside approved purpose |
| Ending the credential is not ending the arrangement | 4. Termination: revocation must end authority, not merely tokens |

**Rule 1 is Durability seen from the wallet.** The [card post](/notes/agents-need-a-corporate-card-not-a-blank-check/) argues that the plastic is replaceable and the governance record is the asset. The law states the consequence: the approved task is the durable object, tokens are its short-lived projections, and governing the projection is not governing the task.

**Rule 2 is Attribution's second clause.** [You Approve What You Were Shown](/notes/you-approve-what-you-were-shown/) binds the approval to the rendered disclosure, and the architecture writes that into Attribution itself: the approval record commits exactly what the approver was shown, because an approval nobody can replay makes attribution collapse into archaeology. The same clause is the precondition for Containment, because "inside approved purpose" only means something if what was approved is committed precisely. The approval that binds the disclosure is what gives enforcement a boundary worth holding.

**Rule 3 and its law match exactly.** [The Contractor Gets Their Own Card](/notes/the-contractor-gets-their-own-card/) is Narrowing with a renovation project attached: every derivation is a subset of what was approved, and widening is a fresh approval, never an inference.

**Rules 4 and 5 swap numbers, and the swap is the reading order.** The card chapter teaches enforcement before endings because that is how you meet the system at the register. The laws number revocation before continuous execution because that is the dependency order: [ending the arrangement](/notes/canceling-the-card-doesnt-stop-the-charges/) (Termination) is what the per-action check (Containment) consults. [The network post's](/notes/the-network-approves-every-transaction/) freeze that declines the next swipe is both laws operating in one moment: revocation ended the authority, and the transaction-time check is how the ending became real at the edge.

# The mapping table becomes an object

The card chapter compresses its whole translation into one table, trip to approved mission, intake form to structured request, card network to per-action enforcement. Read that table again and notice what every row on the agent side has in common. Each one is a projection of, or a consultation of, a single record that agent infrastructure does not have: the approved task itself.

That record is the Mission, and making it first-class is the whole architectural move. The trip becomes the Mission record, with an identifier, an issuer, and integrity anchors committing the approved task and the authority derived from it. The intake form becomes Intent shaping. Finance deriving the controls becomes authority derivation, producing the Authority Set the approval commits. The card becomes the mission-bound token, a bounded projection that carries the Mission's identity. The network becomes the enforcement checkpoint asking, per action, whether this call with these parameters is still inside the approved task. The freeze becomes revocation of the Mission with an observable state surface. The project code becomes the `mission_id` joining every decision and event. [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/) makes this argument in full, and the [Reference's object model](/notes/mission-based-authorization-field-reference/#the-mission-object-model) is the precise form with a concrete record.

To make it concrete, run the card chapter's own scenario through the object once. The engineer's conference trip becomes a Mission record: the intake form's output is the Mission Intent, finance's derived controls (the $3,400 limit, the travel and lodging categories, the November 29 through December 5 window) are the Authority Set, the manager's sign-off is the approval event that commits both under integrity anchors, the card in her wallet is a mission-bound token carrying the record's identity, and the project code on every transaction is the `mission_id` on every decision. The protocol side of this handbook runs the same loop on its own scenario, Alice's Q3 board packet, and the [Reference walks that one end to end](/notes/mission-based-authorization-field-reference/#the-running-example-end-to-end). Two stories, one object.

# The Corporate-Card test becomes the claim gate

The card chapter ends with a diagnostic: [the corporate-card test](/series/what-the-corporate-card-already-solved/#the-corporate-card-test), the questions to ask any agent platform, with the standard that answers unacceptable for a card program are unacceptable for an agent. This chapter carries the same diagnostic in architecture form, the claim gate, split where the family's conformance splits: a system is mission-based when it has an approved task object, authority derived from that task, narrow-only delegation as work fans out, and observable lifecycle state, and it may claim action-time defense only when per-action runtime enforcement and evidence that joins on the Mission's identity hold as well.

Line them up and the correspondence is one-to-one. "What approved purpose is this authority projected from" is the approved task object and the derivation. "What exact disclosure did the approver see" is the integrity anchors and approval evidence. "Can delegated authority only narrow" is the subset rule. "What authorizes each consequential action at the moment of use" is runtime enforcement. "What actually stops when the work ends" is lifecycle state and the bindings that consult it. The [Reference's litmus test](/notes/mission-based-authorization-field-reference/#what-counts-the-litmus-test) expands each property and names what fails it, and the [what-not-to-claim list](/notes/mission-based-authorization-field-reference/#what-not-to-claim) is the same discipline pointed at this proposal itself.

# The build lists name the draft family

Here is the part that makes the card chapter more than a teaching device. Each card post closes with a build list, the work the agent stack cannot borrow because the expense world never needed it. Collect those lists and they enumerate the draft family, cluster by cluster.

**"A disclosure layer that can be held to account, approvals that survive fatigue, and bounds a reviewer can actually read"** (from [the approval post](/notes/you-approve-what-you-were-shown/)) is the approval-integrity cluster: [Mission Intent Shaping](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-shaping.html) structures the proposal, [Mission Consent Evidence](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html) makes the rendered disclosure replayable, and the issuance core's rendering of derived bounds is what gives the reviewer something legible to narrow. [From a Request to an Approved Mission](/notes/from-a-request-to-an-approved-mission/) carries the cluster.

**"Identity for every copy of the helper, field-speed delegation that provably narrows, and a subset rule for authority that is a shape rather than a number"** (from [the contractor post](/notes/the-contractor-gets-their-own-card/)) is the delegation cluster: the [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) and [AI Agent Instance Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/) for instance identity, the core's narrow-only subset rule defined over typed Authority Set entries, [Mission Child Delegation](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-child-delegation.html) for separately revocable helpers, and [Mission Offline Attenuation](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-attenuation.html) as the experimental answer to fan-out at machine speed. [Mission-Bound Authority](/notes/mission-bound-authority/) carries the cluster.

**"A checkpoint at every boundary you claim, a named list of the boundaries you do not, and checks sized to consequence rather than latency"** (from [the network post](/notes/the-network-approves-every-transaction/)) is the enforcement cluster: [Mission-Bound Runtime Enforcement](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-runtime.html) with its [AuthZEN binding](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authzen.html), action classification for consequence-sized checks, and the enforcement-scope statement that names the ATMs in writing. [Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/) carries the cluster, and it is the load-bearing one.

**"An ending someone can check, continuity machinery that checks it, and a record that earns trust without a bank behind it"** (from [the endings post](/notes/canceling-the-card-doesnt-stop-the-charges/)) is the lifecycle and runtime cluster: [Mission Status](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-status.html) as the checkable ending with [Lifecycle Signals](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-signals.html) as its push complement, the [harness profile](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-harness.html) teaching the continuity machinery to check before it resumes, and [Mission Audit Transparency](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-audit.html) earning trust structurally, through verifiable evidence rather than an issuer's ledger. [Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/) and [The Agent Runtime and Audit](/notes/the-agent-runtime-and-audit/) carry the cluster.

**And the whole-loop build list from [the card post itself](/notes/agents-need-a-corporate-card-not-a-blank-check/)**, a first-class approved purpose, bounded projections, checks at the moment of use, delegation tied to the task, endings that reach everywhere the authority went, is not a cluster. It is the [issuance core](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html) plus the shape of the family around it, which is the point: the card chapter's build lists and this family's table of contents are the same list, written by two different worlds.

# What the analogy could not say

The card chapter is honest about where it breaks, and the breaks became build items above. But a few of the architecture's commitments have no card-world articulation at all, and they are worth naming so the translation is not oversold.

- **The integrity anchors.** No card program cryptographically commits the approved trip. The Mission's `intent_hash` and `authority_hash` bind the approved task and the authority derived from it, so that "what did the approver see" has an answer that survives a hostile audit rather than a cooperative one.
- **The missing network is a design input, not a footnote.** The card world's transaction-time decision rides rails that already reach every merchant. The architecture has to state where checkpoints live, what a deployment's enforcement scope is, and how state stays fresh without any common fabric, which is why Status, the freshness rules, and the enforcement-scope statement are normative surfaces rather than operational advice.
- **Cross-domain projection.** A card works at any merchant because the network is global. One Mission honored in another trust domain requires machinery the card world never had to invent, and it gets its own draft rather than a hand wave.
- **The substrate-neutral framework.** The card story is one world. The architecture separates the laws from their OAuth realization on purpose, so the model survives the substrate argument, and [What Survives Without OAuth](/notes/what-survives-without-oauth/) carries that split.

# Where this leaves you

The card chapter's closing sentence was a promise: the protocol work is the translation, stated in standards terms. This part is the map of that translation, and the rest of this chapter walks it. [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/) defines the object. [Adopting Mission-Bound Authorization](/notes/adopting-mission-bound-authorization/) stages the build, crawl, walk, run. [Weighing Mission-Bound Authorization](/series/weighing-mission-bound-authorization/), the concluding chapter, states the model beyond OAuth. And when you are ready for wire-level depth, the [Building Mission-Bound Authorization](/series/building-mission-bound-authorization/) chapter carries each control at implementation depth, one card room at a time.

If you carry one sentence out of the translation, carry this one:

> **Identity says who. Credentials say what may be accessed. The Mission says what the work is, who approved it, and when it ends.**