AI Agents Need More Than One Approval Gate to Spend Money

An office-supply agent notices that a finance team is low on black toner. It checks the approved catalog, finds the cartridge bought last quarter, confirms that the quoted price remains within policy, and prepares an order against the same cost center.

That purchase may not need a person. Replacing the usual supplier with a marketplace seller does. So does accepting a cheaper cartridge with a different product identifier, adding expedited shipping that pushes the order over its limit, or enrolling in an automatic replenishment plan.

A single approval gate cannot express those differences. It either interrupts every toner order, which removes much of the value of automation, or grants broad authority that the agent can apply in circumstances its operator did not anticipate. Tool-calling agents, which can submit structured requests to payment, procurement, and billing systems, make a narrower policy practical: approve the financial state change, not the entire agent run.

Start with the action, not the agent

Teams often begin with an agent-level rule such as “the purchasing agent may spend up to $500.” That limit is incomplete. It does not say whether $500 applies per item, per transaction, per day, or across repeated retries. It also says nothing about the vendor, payment method, contract term, shipping destination, or whether the purchase creates recurring charges.

The toner workflow needs a policy decision immediately before each consequential tool call. The agent can search catalogs, compare compatible products, read inventory records, and draft an order without moving money. When it asks the procurement system to create or submit a purchase order, a separate policy service evaluates a structured action containing the amount, vendor identifier, item identifier, cost center, delivery address, recurrence terms, and requested execution time.

The model should not decide whether its own request complies. Language models can interpret an instruction differently after a conversation grows long, and prompt text is difficult to audit as a durable control. Put spending rules in deterministic code or a policy engine, meaning software that returns the same allow, deny, or approval result for the same recorded inputs.

Keep the model’s role narrow. It proposes an action and explains its reasoning in plain language. The policy service checks authoritative fields. The purchasing tool executes only after receiving a signed decision tied to that exact request.

Build a map of financial state changes

A reusable approval map classifies what the agent is changing, then adds conditions that raise or lower the required authority. Amount matters, but it should sit beside vendor status, recurrence, reversibility, and cumulative exposure.

Here is an illustrative map for the office-supply agent. The dollar thresholds are examples to replace with limits drawn from the organization’s own purchasing policy and loss tolerance.

| Requested action | Agent may execute | Human approval required | Default fallback | |---|---|---|---| | Purchase from an approved vendor | Same catalog item, approved address, within a low per-order and daily limit | Price exceeds either limit, item changes, or shipping becomes exceptional | Save a draft order | | Add or change a vendor | Never on the basis of model judgment alone | Vendor identity, payment destination, and onboarding checks are verified | Keep the existing vendor or stop | | Request a refund | Agent may prepare evidence and submit within a defined return policy | Refund changes destination, includes a fee, or requires accepting store credit | Open a review task | | Renew a subscription | Only for a preapproved month-to-month service within a renewal ceiling | Annual term, price change, seat increase, altered terms, or new auto-renewal | Let the renewal pause or expire according to policy | | Cancel a purchase or subscription | Allowed before a known cutoff when no penalty applies | Cancellation carries a fee, affects dependent services, or cannot be restored promptly | Escalate before the cutoff |

The map distinguishes a familiar toner reorder from a changed commercial relationship. A new vendor is not merely another purchase field. An attacker who alters bank details, a seller whose identity has not been checked, or a marketplace listing that disappears after checkout can create losses that an ordinary refund path will not repair.

Cumulative exposure also closes a common loophole. If the agent may place a $100 order, five separate calls should not silently create $500 of authority. The policy service must aggregate settled, pending, and recently attempted transactions over a defined window, while an idempotency key, a unique identifier used to recognize retries, prevents the same approved order from being charged twice.

Separate reversible preparation from irreversible execution

Reversibility is not a label the model should infer from a button name. It is a property of the connected system, including deadlines, fees, settlement delays, and downstream effects.

The toner agent can usually reverse a draft purchase order by deleting it. A submitted order may remain cancelable for a short period, but that depends on the vendor’s fulfillment state. Once shipped, “cancel” may become a return request that ties up funds, incurs shipping costs, and requires someone to receive the package. A refund is therefore a new workflow, not proof that the original purchase was harmless.

Design permissions around that sequence. Let the agent perform broad read operations and create drafts. Narrow its ability to submit, capture payment, change payout details, accept amended terms, or waive a claim. If a tool does not expose the state needed to tell whether an action remains reversible, treat execution as approval-required rather than trusting the agent’s estimate.

Subscriptions need similar treatment because the immediate charge understates the commitment. A low monthly price can become material when the agent adds seats or accepts an annual term, while a renewal may preserve access to records or integrations that other workflows depend on. The policy input should include billing cadence, renewal date, notice deadline, seat count, current price, proposed price, and cancellation consequences. Missing fields should stop execution.

Make approval narrow and executable

A useful approval is an object the system can enforce, not a message saying “looks good.” It should bind the approver’s decision to the action type, maximum amount, currency, vendor, item or service, payment account, recurrence terms, and expiration time. Any material change invalidates it.

Suppose the toner agent requests approval for an order from the established supplier. After approval, the vendor raises the price or the agent substitutes a different cartridge. The purchasing tool must reject the stale approval because the submitted parameters no longer match. The agent can then draft a revised request, showing the changed fields rather than asking the person to reread the entire run.

This design costs time. A policy lookup adds another system call, and human review can miss a shipping cutoff or renewal deadline. The alternative is not zero latency, however; it is unbounded discretion or constant interruption. Teams can reduce delay by routing approvals according to cost center and action type, setting expiration windows that reflect the business deadline, and allowing designated backups without broadening the agent’s underlying permissions.

Approval interfaces should show the proposed state change first. For the toner order, that means the amount, supplier, product, delivery location, and reason the request crossed policy. The model’s narrative can follow, but it must not replace source records from the catalog, contract system, or payment tool.

Record outcomes, including denied attempts

The audit trail should join the full chain: the agent’s proposed action, policy inputs, policy version, decision, approver if any, exact tool arguments, tool response, and later refund or cancellation. Logs that preserve only the conversation cannot establish which parameters reached the payment system.

Denied and abandoned requests matter too. Repeated attempts just below a threshold may reveal a loop, a poorly specified task, or deliberate threshold splitting. A purchase that fails at the vendor but remains marked as pending can cause the agent to retry elsewhere, turning one toner request into duplicate orders from different sellers.

Reconcile the agent’s record against the financial system after execution. The tool may time out after the vendor accepted the order, leaving the agent uncertain about the result. Its fallback should query by idempotency key or order reference before retrying. If the external system offers no reliable lookup, send the case to a person rather than guessing.

Test these paths before raising limits. Run the toner workflow with a changed vendor identifier, a price increase after approval, a duplicate callback, a missing renewal date, and a refund that can only return store credit. The useful result is not that the agent completes every scenario. It is that each scenario stops, continues, or escalates at the boundary the policy intended.

Questions people ask

Can an

AI agent make a purchase without asking me first?

Yes, if a separate policy permits the exact transaction and the payment or procurement tool enforces that decision. Unattended purchases should stay within defined limits for vendor, amount, item, destination, and cumulative spending. Missing or changed fields should produce a draft or escalation rather than broader discretion.

Should refunds use the same approval limit as purchases?

Usually not. A refund may look reversible, yet it can redirect value, accept store credit, incur return fees, or close a dispute. Give the agent permission to collect evidence and prepare the request, then base execution on refund destination, amount, deadline, and any rights or fees being surrendered.

How should an agent handle subscription renewals?

Treat a renewal as a new commitment evaluated before the notice deadline. The policy should compare price, billing cadence, term, seat count, auto-renewal status, and cancellation consequences with the approved baseline. If the service changed terms or the system cannot retrieve them, the agent should route the renewal for review.

What should happen when a payment tool times out?

The agent should check the payment or procurement system for the transaction before retrying, using an idempotency key or order reference. A timeout does not prove that the charge failed. If the external system cannot confirm the result, pause the workflow and escalate with the attempted parameters and tool response.