A manager approves a conference request on her phone, in the elevator, between meetings. Four months later an auditor asks what she approved.

The only defensible answer is not “a trip, roughly.” It is the request as it was rendered on that screen, at that moment: the destination, the dates, the $3,400 estimate, the cost center, the attached quote. If the approval means anything at all, it means that. Not what the requester intended. Not what the system stored somewhere else. What the approver was shown.

The approval binds the disclosure, not the intent.

Expense systems learned this the hard way, and the whole anatomy of a real approval follows from it. AI agents are about to need every part of that anatomy, because an agent’s first consequential action should sit downstream of an approval worth auditing, and today it mostly sits downstream of a checkbox granted at integration time. This post walks the approval the way the spend world actually runs it. No protocol is required to understand the control.

The Request Is a Proposal, and Nothing More

Agents Need a Corporate Card, Not a Blank Check made the first point: the engineer fills out the intake form, and the form approves nothing. Three properties of that form deserve a closer look, because each one is doing security work that is easy to miss.

The form structures the request. “Some conferences, whatever it costs” does not submit. The free-text wish becomes a bounded, reviewable proposal: this event, these dates, this estimate. Structure is what makes review possible at all. You cannot meaningfully approve a vibe.

The form fails closed on ambiguity. Missing cost center? It asks. It does not guess, and it especially does not guess generously. A request system that resolved every ambiguity in the requester’s favor would be an escalation engine wearing a form’s clothing.

The requester never writes her own limit. She describes the trip. Finance derives the controls. The person asking and the function bounding are different parties by design, because a request that specifies its own authority is not a request. It is a demand with paperwork.

Now swap in the agent. The agent’s account of its own task is exactly as trustworthy as the engineer’s account of her own budget needs, which is to say it is a proposal from an interested party. Something has to structure it, refuse to guess generously on its behalf, and derive the bounds from the task rather than accept them from the requester. None of that is exotic. It is intake, and it is not hypothetical either. The modern spend platforms built their whole product on this shape: the request is the approval workflow, and the approval mints the instrument.

Reviewers Narrow. They Rarely Deny.

Watch what real approvers do. The flight is approved but not the business-class fare. The software purchase is approved for one year, not three. The $2,000 request comes back as $500, try again next quarter. Outright denial is rare. Narrowing is the common case, because the reviewer usually agrees with the task and disagrees with the bounds.

A well-built system honors that. The reviewer trims the request and the requester keeps their place in line. A badly built system offers approve-or-deny only, and the requester refiles from scratch for every trim, which trains everyone involved to ask broad and hope. The approval mechanics quietly shape what people request.

The same is true of time. Real reviews are asynchronous. The request sits in a queue for two days while the approver travels, and nothing about that delay should break the request or tempt anyone to bypass the queue. Systems that cannot wait teach people not to ask.

Both lessons transfer whole. An agent’s task proposal will come back narrowed more often than denied, and the round trip will sometimes take days, because the reviewer is a human with a job. If narrowing means restarting, or waiting means failing, the deployment will route around its own approval step within a month. The approval process has to make the safe path the convenient one, which is the entire trick of the corporate card in one sentence.

The Disclosure Is the Control

Here is the part that sounds like a technicality and is actually the foundation. When the manager approved on her phone, what exactly got approved?

Not the requester’s intent. Not the database row. The approval binds the disclosure: the rendering the approver saw, with the amounts, recipients, and terms it contained at that moment. If the line items quietly change after the approval, the approval does not stretch to cover them. It is void, because the thing she assented to no longer exists. Every serious approval system behaves this way, which is why the request as-reviewed gets snapshotted with the decision, and why “what did the approver see” is answerable years later.

Payments did not leave this to good practice. European payment regulation made it law. Under PSD2’s dynamic-linking rules, when your banking app asks you to approve a payment, it must show you the amount and the payee, and the authorization code it produces is cryptographically bound to that exact amount and that exact payee. Change either one and the approval is worthless. The regulation exists because attackers were changing the transaction between the screen and the wire, and the industry’s answer was to make what-you-see-is-what-you-approve a property of the cryptography rather than a hope about the UI.

That is the bar for agents, and it is not a metaphor. When a human approves an agent’s task, the approval must bind the disclosure that was rendered: this task, these systems, these bounds, this expiry. An approval that binds anything less is a receipt for a conversation. And the disclosure must render the derived bounds, not just the friendly summary, because assent to a summary is assent to whoever wrote the summary.

One more habit worth stealing: the spend world records declines. A denied request is not deleted. It is a decision with a record, because the pattern of what gets declined, and who keeps asking, is exactly what an auditor wants to see. Approval systems that only remember yeses cannot explain their noes.

Where the Analogy Breaks

Three breaks, each one a piece of work the agent stack cannot borrow.

Screens can lie, and agents have more screens. PSD2 could mandate what the payment authorization experience must bind because the regulated payment flow has a narrow job: show the transaction terms and produce a transaction-specific authorization. An agent’s approval can surface in a chat window, a dashboard, an email, a Slack message, each rendered by software with its own bugs and its own trust story. Binding the approval to the disclosure only helps if the disclosure layer itself can be held to account, and that is a build item, not a given. The expense world mostly gets to assume its rendering is honest. The agent world has to prove it, or at least record enough to detect the lie afterward.

Approval fatigue is an annoyance for spend and an attack surface for agents. Rubber-stamping expense requests costs money, and money is mostly compensable, so the expense world tolerates a manager who approves on autopilot. An agent’s actions include the irreversible kind, and any adversary who can generate requests can farm a tired approver. For agents, the fatigue curve is a security boundary. That argues for fewer, better approvals with real bounds, not more prompts, and it is why the approve-every-action model fails at exactly the scale where agents are useful.

The reviewer knows what a conference costs. Decades of trips built priors. A manager can smell a padded estimate, and the delegation matrix encodes the whole company’s sense of what is normal at each level. Nobody has priors for agent tasks yet. What is a “reasonable” scope for an agent that reconciles invoices? Reviewers will be asked to bound tasks they cannot yet sanity-check, which means the early systems must make bounds legible and defaults narrow while the institution learns what normal looks like. The expense world’s matrix took years to tune. The agent world starts at zero.

The build list from this room: a disclosure layer that can be held to account, approvals that survive fatigue, and bounds a reviewer can actually read.

The Approval Is Where Safety Is Cheap

Everything downstream of a bad approval is expensive. Enforcement can only hold the line the approval drew, audit can only replay it, and revocation can only end it. The approval is the one moment where a human with context can still shape what the authority is, which is why the spend world invests its friction there and almost nowhere else.

Approve like it will be read back to you in a deposition, because for agents, it will. If the system cannot replay what the approver saw, it cannot defend what the agent later did.