Give Agents Spending Rules, Not a Card

The short version: An agent should never receive general permission to spend just because it can hold a card credential. Give it a policy envelope: approved payees and purposes, per-transaction and period limits, an approval ladder, mandatory receipts, reconciliation, and an automatic stop when reality differs from the request.

The prompt for this is not theoretical. An August 2 Radar signal surfaced a project positioning itself around payment controls for AI agents. The useful operator response is not to endorse a particular product from one listing. It is to write the financial authority model before another connector makes payments feel like an ordinary tool call.

Financial authority is not token cost

I already argue that token budgets need an owner, and the detailed economics should be reviewed as cost per completed task. Those controls answer questions about inference: which model ran, how much context it used, how many retries occurred, and whether the finished work justified the compute bill.

Financial authority answers a different question: what value may leave the company because an agent initiated an action? A £2 model run can attempt a £2,000 purchase. A £200 research run can have no permission to spend a penny. Combining those ledgers creates a dangerous illusion that a cheap run is a low-risk run. It is not. Compute cost and cash-movement authority need separate owners, thresholds, logs, and escalation paths.

The seven fields in a spending envelope

1. Purpose. Name the job the payment completes: renew an approved tool, buy a pre-authorized data file, or book travel tied to a named event. “Business expense” is not a purpose.

2. Payee. Use an allowlist of merchant IDs or verified bank details. A familiar display name is not enough when the destination account can change.

3. Amount. Set a single-transaction ceiling and a cumulative ceiling. My conservative starting rule for a new workflow is no autonomous payment above £100 and no more than £500 in a rolling seven-day period.

4. Frequency. State whether the job may pay once, monthly, or once per unique order. The payment service should reject a duplicate idempotency key rather than trusting the agent to remember.

5. Approval. Name the human who can approve an exception, the evidence they receive, and how long that approval remains valid.

6. Receipt. Require an invoice or order record, the policy version applied, the run ID, and the business object that caused the purchase.

7. Stop condition. Freeze the workflow after a declined policy check, a payee mismatch, a missing receipt, or two reconciliation exceptions in one period.

This is blast-radius discipline expressed in finance. Least privilege should describe amounts and destinations, not only whether a tool technically has write access.

A £4,440 failure that a token cap would miss

Imagine an event-planning agent asked to reserve a £1,480 venue. The booking endpoint times out after the charge succeeds, so the agent retries twice. Its model and tool usage stay under £3. The workflow looks efficient on an AI-cost dashboard, yet the company now has three reservations and £4,440 committed.

A proper envelope blocks the first request because it exceeds the autonomous ceiling. If a human approves £1,480, the approval binds to one merchant, one amount range, one event ID, and one idempotency key. A retry checks the existing payment state before creating another charge. The next morning, reconciliation compares the approved intent, the processor record, and the accounting entry. None of that belongs in prompt prose alone.

Refunds, credits, and cancellations need separate authority. An agent allowed to buy from an approved merchant should not automatically be allowed to redirect a refund, accept store credit, or change the beneficiary. Route money back to the original payment method by default, bind cancellations to the original order ID, and send any changed destination to a human. Otherwise the recovery path becomes an unreviewed second payment rail.

Use an approval ladder, not a binary switch

• Observe: the agent prepares a payment request but cannot submit it.

• Recommend: it chooses from approved options and attaches evidence for a human.

• Execute within bounds: it may pay allowlisted merchants below both limits.

• Exception approval: any new payee, unusual category, or higher amount requires a named approver.

• Lock: mismatches suspend the credential and create an incident, not another retry.

Promotion between levels should follow clean reconciled transactions, not confidence in a demo. I would require at least 30 consecutive, correctly reconciled low-value transactions before considering a higher ceiling, and I would raise only one dimension at a time. A larger amount and a broader merchant list should never ship in the same change.

The weekly review belongs with finance and operations

The workflow owner should review attempted, approved, blocked, reversed, duplicated, and unreconciled payments by policy version. Finance owns the ledger and exception classification. Security owns credential storage and revocation. The business owner confirms that the purchase produced the intended outcome. One dashboard may show all three, but one vague “AI owner” should not absorb all three accountabilities.

Keep the blocked attempts. They are not noise; they show where the agent misunderstands the job or where the policy no longer matches reality. Turn material incidents into failure receipts: what was attempted, which control contained it, what escaped, and which test now prevents a repeat.

This is the next maturity step for AI agents for operators. The operator-first promise behind AI Operator becomes credible when autonomy is specific enough to revoke. Do not hand the agent a card and hope the model behaves. Hand it a small financial constitution that the payment rail enforces even when the model does not.