Every agent-purchasing demo runs the same transaction: a merchant you chose, an amount you expected, a person watching the screen. That one goes fine and tells you almost nothing. The purchases that cost money come after it, made by the same agent on a slightly different input, at a merchant nobody listed, for an amount nobody bounded, at 3am with no one awake to see it.

Agent spending is a distribution. Below is the shape of the tail, the four axes it runs along, and what your system should do on each with nobody in the room.

Why does the second purchase behave differently from the first?

Because you chose the first one and the agent draws the rest. You picked the demo merchant and the demo amount. In production both come from whatever the agent reads that morning, running the same code with the same credentials against a different input. The second purchase is the first observation from a distribution whose shape you don't know yet.

Engineers carry this instinct everywhere else. Nobody sizes a queue for the average message. Purchasing gets treated differently because it looks like a workflow with one path through it, and that framing hides the tail.

[Hallucinated purchases](/blog/ai-agent-hallucinated-purchases) covers one draw from the distribution, where an agent buys a thing that doesn't exist from a vendor it invented. The design question is the curve.

What does the tail look like?

Four axes, and an agent can travel any of them without a bug: a merchant nobody listed, an amount far outside its normal range, the same purchase repeated in a tight loop, and a purchase made while the person who asked is asleep. None of that needs a jailbreak or a stolen credential. A correct agent doing its job produces all four.

| Tail case | Why the demo missed it | What you want with no person present |

|---|---|---|

| A merchant the agent found itself | You picked the test merchant | Purchases outside your categories blocked or escalated for approval at the authorization moment |

| An amount far outside the normal range | Every test purchase was the same size | A ceiling per purchase, and a person above the threshold you choose |

| The same purchase repeated in a tight loop | The test ran once | A cap that binds across the whole run, on top of the per-purchase ceiling |

| A purchase made at 3am | Someone was watching the screen | An approval that waits for a person, on a default you picked |

Every row is a purchase your own policy would have caught if somebody had been asked, and one the agent had no reason to skip.

What should happen at 3am?

The purchase should be blocked or escalated for approval while the merchant is still waiting on an answer, and the escalation should sit there until a person responds. A control that depends on somebody noticing runs during working hours. Your agents run the rest of the time, which is most of the reason you deployed them.

The failure here is a default nobody chose. When an approval reaches no one, something still decides what happens next, and if you didn't pick that behaviour it's whatever your code does when a timer expires. A $40 purchase that waits until morning costs you a morning. A $40,000 purchase that clears itself at 3am costs you $40,000.

Decide the stop case in advance too, for the run you want halted mid-flight without a config change. [A kill switch for agent spending](/blog/revoke-agent-spending-kill-switch) is the version you can test on a Tuesday.

How do you test for the second purchase?

Run the same agent against inputs you didn't write. Take a week of production requests, replay them with the purchase leg pointed somewhere harmless, and read the results as a distribution: how many distinct merchants showed up, the largest single amount, and how often the same purchase came around twice. A happy-path demo answers none of those.

The other half of the work is where the check lives. Per-merchant and per-tool checks cover what you predicted, which is the set that excludes every tail case by construction. A purchasing instrument scoped to one agent covers every merchant that accepts it, including the ones the agent turns up by itself.

Shatale issues agent-scoped virtual cards with your policy enforced at the authorization moment, human approval above the thresholds you set, and an immutable per-agent record of every decision, approvals included. A purchase outside policy is blocked or escalated for approval while the merchant is still waiting. The median purchase and the tail purchase run on the same card, so they take the same path.

What to ask

FAQ

Why do unexpected AI agent purchases happen when the agent isn't broken?

The agent picks the merchant and the amount from whatever it reads at run time, and your test picked both by hand. A working agent given a different input produces a different purchase, which is the behaviour you deployed it for. Most unexpected purchases come out of a system doing its job on an input nobody anticipated, so they survive a clean test suite.

What limits should I set before an agent's first purchase?

Set a ceiling per purchase and a cap across a run, name the merchant categories the agent may use, and pick the amount above which a person has to approve. Then decide what happens when that approval reaches nobody, because something will happen either way. Write the numbers down first, or you'll be arguing about a charge instead of a policy.

How do I stop an agent from repeating the same purchase?

Cap spending across the whole run rather than per transaction, so ten copies of an allowed $200 purchase reach a limit the first copy didn't. Then decide whether the eleventh attempt is blocked or escalated to a person for approval. A loop is an ordinary failure for anything that retries on error, so plan for it.

Does an approval workflow slow every purchase down?

Only above the threshold you set. Purchases inside policy clear at the authorization moment with nobody involved, and the ones above your threshold wait for a person. The trade is a slow $40,000 purchase against a fast one you read about on next month's statement. Most teams put the threshold where a mistake stops being annoying and starts being a phone call.

---

For the timing half, [catching a purchase at authorization versus finding it in reconciliation](/blog/authorization-time-control-vs-reconciliation) covers what each can still do about the money. Early access is free for publishers.

Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).