---
title: "Agents Need a Corporate Card, Not a Blank Check"
date: "2026-07-02T09:00:00-07:00"
lastmod: "2026-07-02T09:00:00-07:00"
description: "Enterprises already run a mature delegated-authority architecture for humans. It is called expense governance. The corporate-card pattern maps, control by control, onto what agent authorization is missing, and the places where the analogy breaks are the build list."
summary: "Nobody hands a new hire the company checkbook. In a mature spend program, they get an instrument bound to an approved purpose, checked at each transaction, metered against a budget, and frozen when the reason for the spend goes away. Agent credentials today are blank checks with expiry dates. This post walks the expense-governance loop end to end, maps each control onto agent authority, and is honest about the five places the analogy breaks. Each break is something the agent stack still has to build."
slug: "agents-need-a-corporate-card-not-a-blank-check"
tags:
  - "Agentic Identity"
  - "Delegated Authority"
  - "IAM"
  - "OAuth"
  - "Authorization"
  - "Security Architecture"
---


A new hire starts on Monday. She is trusted, vetted, and hired precisely
because she has good judgment. Nobody hands her the company checkbook.

In a mature spend program, she gets an instrument with a boundary: a
corporate card, a virtual card, or a travel approval that controls what
the card can do. It has a limit. It works for travel and software, not
for jewelry. It draws against a budget someone approved for a reason,
and it can die the day she leaves or the project ends. Inside those
bounds, nobody reviews every purchase in advance. She is expected to
make smart decisions inside a risk boundary, and the boundary does the
worrying.

Now look at how the same company deploys an AI agent. It provisions an
agent identity, grants it credentials with broad standing authority, and
leaves them standing indefinitely. The credential might be an OAuth
token, an API key, a workload identity, or a cloud service principal.
The shape is the same everywhere. There is no purpose attached to the
credential, no budget it draws against, no per-action check, and nothing
that ends when the reason for the work goes away.

> An agent credential today is a blank check with an expiry date.

The strange part is that enterprises already run a mature
delegated-authority system for humans. They did not build it as an IAM
system. They built it as expense governance, and almost nobody calls it
what it is: an operating delegated-authority architecture. This post
walks that architecture end to end and maps it onto the authority gap
explored in the [Power of Attorney](/series/you-dont-give-agents-credentials-you-grant-them-power-of-attorney/),
[Mission Shaping](/series/mission-shaping/), and
[Mission-Bound Authorization](/series/mission-bound-authorization/)
arguments. Then it is honest about where the analogy breaks, because the
breaks are the build list.

# The Authorization Architecture Nobody Calls One

Follow one trip through a modern spend system.

An engineer needs to attend a conference. She does not email the CFO.
She fills out an intake form: destination, dates, business reason,
estimated cost. Say $3,400 for a cloud conference. The form will not let her
submit "some conferences, whatever it costs." If the cost center is
missing, it asks. The form structures the request. It approves nothing.

Her manager approves the trip against a delegation-of-authority matrix.
Managers approve to $5,000. Directors to $50,000. The numbers differ at
every company, tuned to its risk appetite and how much it trusts its
people. The pattern does not. The approval is recorded: who approved,
what they saw, when.

Here is the step everyone overlooks. The engineer asked for a *trip*.
Finance derived the *controls*: a $3,400 limit, travel and lodging
merchant categories, valid November 29 through December 5. She proposed
the trip. She did not define the authority. Finance derived the
authority from the approved trip.

> A corporate card is not permission to spend. It is a bounded
> projection of an approved purpose, checked at every swipe.

Then the card does the enforcing. Every swipe is authorized in real
time against current state. Is the card active? Is the limit remaining?
Is the merchant category allowed? A steakhouse works. A casino declines.
Nobody predicted the specific restaurant in advance, and nobody had to.
Judgment operates inside the boundary. The boundary is checked at the
edge, every time. Enterprises already run this pattern for APIs. An API
gateway evaluates authentication, quotas, scopes, and policy on every
request. The agent gap is not the idea of per-request enforcement. It is
the absence of a first-class approved task for that enforcement to
evaluate against: is this action still inside the mission?

Notice what the swipe check did not do. It did not page her manager.
Corporate cards are deliberately low-friction. Nobody asks permission to
buy lunch, because permission happened earlier and the boundary carries
it forward.

> The goal of delegated authority is not to ask permission more often.
> It is to ask permission less often, with better boundaries.

That is the analogy, and no more. Corporate cards do not make employees
trustworthy, prevent every bad purchase, or eliminate reconciliation.
They make delegated spend governable. The claim for agents is the same:
autonomy becomes acceptable only when the instrument is a projection of
an approved purpose, each consequential action is checked at the edge,
and the instrument stops working when the purpose ends.

The rest of the loop is just as deliberate. The budget meters down with
each transaction. A big purchase above her threshold needs a second,
specific approval no matter how much budget remains. If she needs more
than was approved, she cannot raise her own limit. She submits a new
request and someone with sufficient authority grants a new one. If the
conference is cancelled mid-trip, the card freezes while it is still in
her wallet. And every transaction carries the project code, so an
auditor can pull one thread and see the whole trip: the request, the
approval, every swipe, the reconciliation.

Really large commitments never touch her card at all. A $200,000
contract goes through procurement, and accounts payable executes the
payment after its own checks. For the spend that matters most, the
person doing the work never holds the payment instrument.

# The Same Loop, Control by Control

Every control in that loop answers a question that agent authorization
is currently answering badly or not at all.

| Expense governance | Agent authority |
| --- | --- |
| Intake form structures the request, approves nothing | Shaping turns a prompt into a structured, reviewable task proposal |
| Requester never writes her own limit | Authority is derived from the approved task, not requested by the agent |
| Approver narrows: "$2,500, no business class" | Approval that can reduce a proposal without restarting it |
| Card network authorizes every swipe against current state | Per-action runtime check against the live task, not just a valid token |
| Merchant category codes, vendor-locked virtual cards | Action and parameter binding, not broad standing scopes |
| Budget drawdown, per-transaction caps | Metered consumption bounds on the task's authority |
| Card freezes when the trip is cancelled | Revoking the task stops the work, independent of token lifetimes |
| Limit increase requires a fresh approval | Widening authority is a new approval, never self-service |
| DOA matrix: managers to $5k, directors to $50k | Progressive ceilings that bound what policy may grant without a human |
| Contractor gets her own card on the same project code | Sub-agents get narrower, separately revocable authority, never the parent's credential |
| Procurement and AP execute the largest payments | For the highest-consequence actions, the agent never holds the credential |
| Project code on every transaction | One task identifier joining every action across systems for audit |

Two rows deserve emphasis, because they carry the safety argument.

**The card network is the load-bearing layer.** A card number with no
authorization network behind it is just a promise. The limit, the
categories, and the freeze all become real at the moment of the swipe,
or they are not real at all. The agent equivalent is the per-action
runtime check, and the same logic applies. A purpose-labeled token that
nothing checks at the point of use is bookkeeping, not a boundary.

**The freeze works because the card is not the authority.** When the
trip is cancelled, nobody hunts down the physical card. The instrument
in her wallet keeps existing. It just stops working, because the thing
it projects from was terminated. Agent systems mostly have this
backwards today. The token *is* the authority, so ending the work means
finding every token, every cached connection, every sub-agent that
still holds one. [Sessions Are Not Missions](/notes/sessions-are-not-missions/)
makes the runtime version of this argument: the engineer still being on
the trip does not mean the trip is still approved.

# Where the Analogy Breaks

An analogy this convenient should be distrusted on schedule. It breaks
in five places, and each break marks work the agent stack cannot borrow
from the expense world.

**Money is one-dimensional. Authority is typed.** Every card
transaction is the same verb: move money to a counterparty. Purchases
differ in amount and merchant, and the damage is denominated in the
same unit as the control, which is exactly what makes a scalar limit
work. Agent actions are not purchases. An agent is doing things, not
buying things. Its actions are different verbs entirely (read, send,
delete, sign, deploy), and their consequences share no common
denominator. A $50 mistake and a $50,000 mistake sit on one scale.
Deleting a record and emailing a customer do not. So agent authority
has to be typed, which resources, which actions, which parameters,
under which conditions, and classified by consequence rather than by
merchant. Vendor-locked, single-use virtual cards show the direction of
travel, an instrument bound to one counterparty and one amount. But
agent authorization needs that specificity as the norm, not as the
premium feature.

**There is no card network for agent actions.** This is the deep one.
Card-accepting merchants route through common authorization rails, so
one issuer decision can reach the point of sale. Agent actions cross API
providers, SaaS tenants, and tool servers that share no common
enforcement fabric. Each resource validates its own tokens on its own
schedule and learns nothing when the task behind them ends. Put another
way, card payments run on two infrastructures: issuance rails and
transaction-time authorization rails. OAuth gives enterprises widely
deployed delegation and token issuance rails, but not a universal
action-time authorization fabric across resource servers. Agent systems
have pieces of the first and no equivalent of the second. The
[Mission-Bound Authorization series](/series/mission-bound-authorization/)
is, in effect, a proposal for common task state and enforcement
contracts: an approved task as a first-class object that issuance,
enforcement, and revocation all consult, so that terminating it can reach
the places where the mission was projected.

**There are no chargebacks for un-send.** Most spend is compensable.
Refunds, reversals, and chargebacks form a mature unwinding system
with its own rails. Agent actions include sent messages, deleted
records, signed commitments, and published data, where no issuer can
claw the effect back. The expense world gets to be casual about
mid-flight cancellation because money can usually be put back.
Agent systems have to plan the unwinding before the action runs,
because often it cannot be.

**Employees fear the expense report. Agents fear nothing.** Expense
governance quietly leans on accountability. The traveler knows the
reconciliation is coming, and deterrence fills the gaps the controls
miss. An agent has no career to protect, and worse, its judgment can be
rewritten mid-task by content it reads. No sign in a shop window has
ever prompt-injected a human into buying a forklift. Accountability
deters people. It only records agents, unless it feeds a runtime
boundary. This is why the runtime check has to carry more weight for
agents than the card network carries for people. Deterrence is not
available as a compensating control.

**Spend is centralized. Risk and trust are not.** Expense governance
works partly because one function owns it. Finance sets the tiers,
issues the instruments, and runs the reconciliation, and everyone
accepts that. Authority in most organizations is the opposite. Every
application owner, platform team, and resource owner sets its own
rules, and no single function owns what agents may do. The lesson to
carry over is narrower than it first appears. The card system
centralizes the *record*, not the *decision*. The issuer enforces the
issuer-side bounds while every merchant still runs its own fraud
checks, and a permit from one never overrides the other. Agent
authority can follow the same split. Centralize the approved task so
there is one thing to approve, observe, and terminate. Leave each
resource authoritative for its own policy. What cannot stay distributed
is the record itself, and some function will have to own it the way
finance owns the budget. That is an organizational bill, not just a
protocol one.

# The Uncomfortable Comparison

Read the mapping table again, top to bottom, and notice what it implies.
A mature finance organization runs some version of every row. Purpose
attached to each dollar of authority. Derived limits. Real-time,
per-transaction enforcement. Fast, possession-independent freeze. Fresh
approval to widen anything. Audit joins on one identifier.

For agents, many deployments still run few of them. The agent holds
broad scopes granted at integration time, exercises them at machine speed
against systems that mostly see token validity, and keeps working until a
credential happens to expire.

> The gap is not a missing product feature. It is a missing object.

The expense system works because the *approved purpose* is a first-class
record that every control consults: the intake form proposes it, the
approval creates it, the card projects it, the network enforces it, the
freeze terminates it, and the project code joins everything back to it.
Agent infrastructure has tokens, sessions, and logs. It does not yet
have the thing they should all be projections of. That is the argument
the [Mission Shaping](/series/mission-shaping/) and
[Mission-Bound Authorization](/series/mission-bound-authorization/)
series make in protocol terms.

In Mission-Bound Authorization terms, the mapping is compact enough to
carry:

| Expense world | Agent world |
| --- | --- |
| Trip | Mission |
| Intake form | Shaping |
| Corporate card | Bounded instrument / credential projection |
| Card network | Runtime enforcement |
| Budget and limits | Metered authority bounds |
| Merchant category | Action and parameter constraints |
| Limit increase | Expansion by fresh approval |
| Project code | Mission identifier |
| Expense report | Audit evidence |

The card program works because those objects are distinct and tied
together.

# The Bar Is Not Exotic

The useful thing about this analogy is that it sets the bar at
"ordinary." None of the expense controls above are considered advanced.
They are what any competent finance organization does by default,
because the alternative, handing out blank checks and reading the
statements afterward, is obviously negligent.

So when evaluating an agent platform, apply the corporate-card test:

- Where is the approved purpose recorded, and who approved it?
- Who derived the agent's limits, and can the agent widen them itself?
- What checks each action at the moment it runs, against what state?
- When the reason for the work ends, what stops, and how fast?
- Can a sub-agent spend the parent's authority, or does it get its own?
- Can an auditor pull one identifier and see the whole task?

If the answers would be unacceptable for a corporate card program, they
are unacceptable for an agent that can touch the same systems, move
faster than any employee, and be talked into things by the documents it
reads.

Give agents what you give people you trust: real autonomy, a real
boundary, and an instrument that stops working the moment the mission
ends.

Enterprises already know how to delegate authority safely. They do it
every day, at global scale, with a piece of plastic. The surprise is not
that agents need a new security model. The surprise is that we forgot we
already built most of one.

Stop issuing blank checks.