Approve a merchant and you've covered one merchant. Your agent's value is the supplier it turns up on Tuesday that nobody had heard of on Monday. A control surface you extend once per merchant is behind the agent from the day it starts working properly, and falls further behind the better it gets. Adding another entry doesn't close that gap, because the gap is a property of where the control lives.
Here's how to tell the two apart, and which parts of your setup do which job.
Why don't per-merchant controls compose?
Because each control applies to the endpoint it was configured for. Approve ten suppliers and you have ten controls. What you don't have is a bound on what the agent spends in total. The eleventh purchase, at a merchant nobody listed, sits outside all ten of them.
Per-supplier limits are the right design for the world they came from, where a person raised the requisition weeks before the first invoice. Supplier-network procurement suites work that way because procurement worked that way, and agents break the assumption underneath it: that the merchant is known before the money is needed. A model that plans a purchase at 03:00 and executes four seconds later has no step where a person types in supplier details.
The protocol layer has the same shape. Mastercard's Agent Pay, Visa's Trusted Agent Protocol, the Agentic Commerce Protocol, x402, AP2: each covers the merchants that implement it. Seven venues are writing pieces of this as of August 2026, and the merchant your agent finds is covered only if it speaks the one you built against.
What happens when your agent finds a supplier nobody onboarded?
One of three things. The purchase fails and the agent waits for a person to clear the supplier, which removes most of the reason you deployed it. Somebody hands it the card the team already uses, so the bound becomes the company credit limit. Or it clears on an instrument scoped to that agent, inside bounds you set before the supplier existed.
Make it concrete. Say your research agent is pricing ocean freight, and the only source for 2019 port-call records is a four-person outfit in Rotterdam that charges 340 euros and takes a card. No contract, no supplier record, and nobody is raising a procurement ticket for 340 euros. The data is legitimate and the agent is right to want it. [Research agents paying for data](/blog/research-agents-paying-for-data) hit this constantly, because the useful sources are small and the small ones are never on anyone's approved list.
The second outcome is the dangerous one and the common one. Somebody gets tired of the tickets and decides 340 euros isn't worth the process, hands the agent the card the team already uses, and now the limit on that agent is whatever the company's credit line happens to be, with the record of what it bought mixed into everyone else's statement. [Moving off shared cards](/blog/migrate-shared-cards-to-scoped-delegation) is usually a reaction to that rather than a plan.
Where does the control live?
In one of two places: the integration with a specific merchant, or the instrument the agent pays with. Controls in the integration cover the merchants you configured. Controls in the instrument cover every merchant that accepts it, including ones discovered at runtime, because the policy travels with the card.
| | Control per merchant or integration | Control in the instrument |
|---|---|---|
| A merchant nobody configured | out of scope until someone adds it | in scope if the merchant accepts the card |
| Work per new merchant | one setup, in every system that holds a limit | none |
| Who moves first | a person, before the agent can buy | nobody, the policy is already there |
| Where the policy lives | spread across each integration | one place, scoped to one agent |
| Where the decision record lives | in each platform's own log, in its own format | one immutable per-agent record |
| If the protocol you built on loses | rebuild the control along with the integration | the card never depended on it |
Read the bottom row before you sign anything. A control that lives inside an integration with one protocol gets rebuilt when your merchants pick a different one in 2028. The same seam runs through [identity, authorization and audit](/blog/agent-identity-vs-authorization-vs-audit): a valid credential at an unlisted merchant is still a purchase somebody has to bound.
What does scoping the instrument to one agent give you?
A bound on that agent's money that holds at merchants you've never seen. Shatale issues agent-scoped virtual cards with your policy enforced at the authorization moment, human approval workflows above the thresholds you set, and an immutable per-agent record of every decision. A purchase outside policy is blocked or escalated for approval while the merchant is still waiting.
It doesn't do the other half of the job, and a vendor who won't say so is worth pressing. A card bounds the money. It doesn't judge the counterparty. The Rotterdam outfit's provenance story could be terrible, and a 340-euro charge inside your bounds clears without anyone reading who they are.
That's the genuine strength of the approach this piece argues against. A supplier allowlist is counterparty diligence: somebody looked at the company, ran the sanctions screening, read the terms. A merchant category code carries none of that.
So run both, and be clear which does which. The allowlist decides who your company will buy from at all. The instrument decides how much this agent can spend and who signs off above the line. Letting the allowlist carry the second job is how you end up with ten controls and no budget.
What to ask
- If our agent buys from a merchant we've never configured, what happens?
- How much work is one new merchant, and who does it?
- Where does our spending policy live, and can we change it without a deploy?
- If a purchase falls outside policy, is it blocked, escalated to a person, or logged for us to read next month?
- Which protocol is this control built on, and what do we rebuild if our merchants pick a different one?
FAQ
Why don't per-merchant spending controls cover every purchase?
Each control applies to the merchant it was configured for. Ten approved suppliers give you ten controls and no limit on the eleventh purchase. An agent that finds its own sources keeps producing merchants nobody configured, so the gap grows with the agent's usefulness instead of shrinking as you add entries.
Can an AI agent buy from a supplier we haven't onboarded?
Through a procurement platform, no: the supplier has to exist in the system first. On an agent-scoped card, yes, if the purchase sits inside the bounds you set for that agent. The amount, the category, the time window and the approval threshold apply at a merchant you've never seen.
What's the difference between per-integration controls and instrument-scoped controls?
Per-integration controls sit between you and one merchant or one protocol, and cover that endpoint only. Instrument-scoped controls sit in the card and cover every merchant that accepts it. The test is an unplanned merchant: the first fails closed until someone adds a configuration, the second applies the policy you wrote.
Do agent-scoped cards replace supplier vetting?
No. A card bounds the amount, the category, the timing and who approves above a threshold. It won't tell you whether the company on the other side is one you should buy from. Supplier vetting answers who; the card answers how much and under whose sign-off. Run both.
---
[Authorization-time control against reconciliation](/blog/authorization-time-control-vs-reconciliation) takes the same argument to the timing question. 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).