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, Mission Shaping, and 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.

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 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 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 and Mission-Bound Authorization series make in protocol terms.

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

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.