---
title: "You Approve What You Were Shown"
date: "2026-06-05T10:00:00-07:00"
lastmod: "2026-06-05T10:00:00-07:00"
description: "An approval is not a feeling of assent. It is a decision bound to a specific disclosure: the request as the approver saw it, at the moment they saw it. Spend systems learned this, payment regulation made it explicit, and agent systems need it before any agent takes its first action."
summary: "A manager approves a conference request on their phone between meetings. Months later, the only defensible answer to \u0026lsquo;what did you approve?\u0026rsquo; is the request as rendered on that screen. This post walks the anatomy of a real approval: requests that are proposals and nothing more, reviewers who narrow instead of denying, decisions that take days without losing their place, and the disclosure that binds. Payments turned that last idea into regulation. Then the honest part: three places the analogy breaks for AI agents, and what each break demands."
slug: "you-approve-what-you-were-shown"
tags:
  - "Agentic Identity"
  - "Delegated Authority"
  - "IAM"
  - "Authorization"
  - "Security Architecture"
series:
  - "what-the-corporate-card-already-solved"
---


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](/notes/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.