---
title: "From the Card to the Architecture"
date: "2026-06-06T09:45:00-07:00"
lastmod: "2026-06-06T09:45:00-07:00"
description: "The corporate-card series taught a governance loop with no protocol in sight. This post 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 post is the joint between that mental model and this series\u0026rsquo; 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:
  - "mission-bound-authorization"
---


{{< spine steps="intent,mission,authority,enforcement" >}}

{{< 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 post 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 series 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 arc first.** The translation reads on its own, and each section links the card post it translates. But the arc 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 post 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/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 post 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 arc closes the same way, with the places the analogy breaks and the build list those breaks imply.

This series is the build. The card series 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 post 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 arc first, this post will feel like recognition. If you did not, it works as a fast tour of the whole model, and the arc is waiting when you want the version with no protocol in sight.

# The Five Rules Become Five Laws

The card series distills each post into one rule, stated in the card's language. This series states the same invariants for any substrate and calls them the [five laws of delegated authority](/series/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, not authority | 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 series 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 series 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 what was proposed and what was approved. 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-bound-authorization-reference/#the-mission-object-model) is the precise form with a concrete record.

To make it concrete, run the arc'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 publication runs the same loop on its own scenario, Alice's Q3 board packet, and the [Reference walks that one end to end](/notes/mission-bound-authorization-reference/#the-running-example-end-to-end). Two stories, one object.

# The Corporate-Card Test Becomes the Claim Gate

The card series ends with a diagnostic: [five questions](/series/what-the-corporate-card-already-solved/#the-corporate-card-test) to ask any agent platform, with the standard that answers unacceptable for a card program are unacceptable for an agent. This series carries the same diagnostic in architecture form, the claim gate: a system may claim mission-based authorization only if it has an approved task object, authority derived from that task, tokens and decisions bound to the task, per-action runtime enforcement, observable lifecycle state, and evidence that joins on the Mission's identity.

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-bound-authorization-reference/#what-counts-the-litmus-test) expands each property and names what fails it, and the [what-not-to-claim list](/notes/mission-bound-authorization-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 arc 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/mission-approval-integrity/) 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-sub-agents-and-delegation/) 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-profile/) 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 experimental 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/mission-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 arc'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 arc 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 what was proposed and what was approved, 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 [The Mission Framework](/notes/the-mission-framework-and-the-blueprint/) carries that split.

# Where This Leaves You

The card series' closing sentence was a promise: the protocol work is the translation, stated in standards terms. This post is the map of that translation, and the rest of this series walks it. [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/) defines the object. [The Mission Framework](/notes/the-mission-framework-and-the-blueprint/) states the model beyond OAuth. [Adopting Mission-Bound Authorization](/notes/adopting-mission-bound-authorization/) stages the build, crawl, walk, run. And when you are ready for wire-level depth, the [Building Mission-Bound Authorization](/series/building-mission-bound-authorization/) series 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.**