---
title: "Agents Need a Corporate Card, Not a Blank Check"
date: "2026-07-22T04:30:00-07:00"
lastmod: "2026-07-22T04:30: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 part 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"
series:
  - "what-the-corporate-card-already-solved"
---


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.

Put that in card terms. It is a card with no spending limit, no
expiry that matters, and a single merchant category that covers
everything. Nobody would run finance on that card. Most agent
deployments run on nothing else.

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

The failure mode is not autonomy. It is the blank check.

> Credentials are projections, not authority.

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 part
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/)
and [Mission Shaping](/series/mission-shaping/) 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 issuer 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 |
| The issuer 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.

**Transaction-time authorization is the load-bearing layer.** A card
number with no authorization rails 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. The plastic is replaceable. The
governance record is the asset. 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.

# The card was rebuilt a decade ago

If the loop above sounds like an idealized finance department, look at
what actually happened to the corporate card in the last ten years.

The incumbent model was the blank check with better paperwork: standing
plastic issued at hire, merchant-category guesswork for control, and a
month-end expense report as the enforcement moment. Everyone knew the
report was audit, not control. The money was already gone.

Then spend platforms like Ramp and Brex rebuilt the instrument, and the
rebuild is a checklist of this part's loop. The request became the
approval workflow. The approval mints the card, a virtual instrument
scoped to the vendor, the amount, and the purpose it was approved for.
Policy moved from the report to the authorization, so the out-of-policy
purchase declines at the register instead of surfacing three weeks
later. Receipts match at transaction time, the project code is native,
and the single-use card retires itself when the purchase completes.

And it won. Finance teams did not adopt purpose-issued cards because
auditors made them. They adopted them because the rebuilt loop gave
more control and less friction at the same time, the trade this part
keeps insisting is available. The market priced the argument.

That is the uncomfortable part for agent infrastructure. Agent
credentials today are the incumbent model: standing authority issued at
integration time, category-level guesswork for scope, and logs as the
enforcement moment. And the market's verdict on that shape is already
visible: agents get read access and a human keeps the writes, because
nobody can price the risk of the incumbent model at machine speed. The
card world looked at exactly that shape, rebuilt it, and was rewarded.
The transition the rest of this chapter maps is not speculative. In
the domain that had the choice, it already happened.

# 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
the issuer's transaction-time 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. What the
agent world needs, in effect, is 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 build list from the whole loop: purpose, projection, per-action checks, task-tied delegation, and endings that reach everywhere the authority went.

# 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.

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.

And none of this is an indictment of the identity stack. OAuth and its
siblings were built for a world that never needed expense semantics:
applications were static, sessions were short, permissions were
predefined at registration, and a human sat at the keyboard for every
consequential moment. The human was the governance system. Purpose,
budget, and endings all lived in someone's head, enforced by presence.
Agents kept the credential shape and removed the person, and the
controls that were never needed became the controls that are missing.

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 issuer 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/) series makes in
protocol terms.

The mapping is compact enough to carry:

| Expense world | Agent world |
| --- | --- |
| Trip | The approved mission |
| Intake form | Structuring the request |
| Corporate card | Bounded instrument / credential projection |
| Issuer authorization | Per-action enforcement |
| Budget and limits | Metered authority bounds |
| Merchant category | Action and parameter constraints |
| Limit increase | A fresh approval, never an edit |
| Project code | One task identifier |
| Expense report | Audit evidence |

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

The last thing the analogy does is set the bar, and the bar is "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, narrower grant?
- 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.

The four posts that follow open each room of this loop:
[the approval](/notes/you-approve-what-you-were-shown/) that binds what
the approver was shown,
[the contractor's card](/notes/the-contractor-gets-their-own-card/)
that narrows instead of borrowing,
[the network](/notes/the-network-approves-every-transaction/) that
approves every transaction rather than trusting the card, and
[the ending](/notes/canceling-the-card-doesnt-stop-the-charges/) that
actually ends.