Shatale ships four things: agent-scoped virtual cards, your spending policy enforced at the authorization moment, human approval workflows above the thresholds you set, and an immutable per-agent record of every decision. That's the product. We don't build the agent, we don't run the model behind it, we don't sell you what it buys, and we have no view on whether it should have bought it.
"Control plane" is doing heavy lifting in agent-payments marketing, and most uses of it have no edges. This piece puts edges on ours.
What is a control plane for AI agent payments?
A control plane is the layer that decides whether a specific purchase may proceed, and keeps the record of that decision. It sits between the agent that wants to spend and the rails that move the money. It holds the limits, the merchant categories, the time windows and the approval thresholds. It doesn't move money and it doesn't choose the purchase.
The term comes from networking, where the control plane decides where traffic goes and the data plane carries it. Payments divide the same way. Card rails move the money, agent frameworks move the intent, and the control plane answers whether a given attempt clears while the merchant is still waiting on the authorization.
What sits inside the boundary?
Four things. Agent-scoped virtual cards, so each agent carries its own instrument rather than a copy of the company card. Your policy enforced at the authorization moment, so a purchase outside it is blocked or escalated for approval before it clears. Human approval workflows above the thresholds you set. And an immutable per-agent record of every decision.
A scoped card with a $200 limit and one merchant category can't book a $4,000 flight, no matter what the agent decides. That's the whole mechanic, and it's why the boundary stays this small.
What do we deliberately not build?
Six categories of work sit outside our boundary, and we don't intend to enter them. We're not the agent framework and we're not the model provider. We're not the merchant, and we're not a procurement suite or an expense-management system. We're not a fraud network, and we don't decide what your agent should want to buy.
| What the control plane answers | What it leaves to other systems |
|---|---|
| May this purchase clear, at this amount and this merchant, right now | What the agent should want to buy, and why |
| Which agent holds this instrument, and what it may spend | Which model is reasoning behind that agent |
| Does a person sign off before it clears, and who | Whether that vendor was the right vendor |
| What happened, in a record nobody can edit afterwards | Coding the expense and closing the month |
Procurement and expense management are the two most common confusions, and both sit on the far side of the transaction from us. Procurement decides which vendors you may buy from before anyone spends anything. Expense management reads what already happened and files it. We work at the moment in between. Authorization-time control versus reconciliation covers that gap.
Fraud detection is a different job. A fraud network asks whether the party holding a card is who they claim to be, using patterns from a population far larger than yours. We assume the agent is exactly who it says it is, and ask whether this purchase falls inside the policy you wrote.
We're not your identity provider either. Which agent is calling, and under whose authority, is being worked on by the MCP identity effort and by the card networks at the merchant edge. The split between identity, authorization and audit covers who owns which part.
The last boundary is the one buyers find strangest. If your research agent concludes it needs a $180 dataset, that came from your prompts and your own business logic. We answer whether the purchase falls inside the limit, the merchant category, the time window and the approval threshold you set. Outside those lines it's blocked or escalated to a person for approval.
Why keep the boundary this narrow?
Because a control that also tries to be the catalogue stops working the moment your agent buys somewhere the catalogue never listed, which is the entire reason you deployed an agent. A purchasing instrument scoped to a single agent covers every merchant that accepts it, including the ones the agent finds on its own. Per-merchant control doesn't compose. A card does.
The second reason is that a stated boundary can be tested. A reviewer can ask what happens at the edge of it and get an answer that doesn't move between calls. A vendor whose scope grows with every question has no edge to test.
There's a cost here and you should price it in. You'll need other products for procurement approvals, expense coding and identity. We'd rather you run several that each hold at their edges than one that holds nowhere.
Where is the category heading?
Toward shared answers on how an agent identifies itself to a merchant, and on what a regulator gets to see afterwards. That work is happening at standards venues rather than inside any single vendor, and none of it is settled. We'll implement what settles. We won't claim a position on questions the industry hasn't closed.
Two things you'll hear described as control-plane features belong in that column rather than this one. Portable policy is the first: a spending rule you write once and have honoured by whichever rail your agent uses. Agent-to-agent purchasing is the second. Both are open questions in the category, and nothing here is a commitment to either.
What to ask
- Which layer does this product own, and which does it assume you already run?
- At what moment in the transaction is my spending policy evaluated?
- If an agent attempts a purchase outside policy, is it blocked, escalated to a person for approval, or logged for me to find later?
- Does the control hold at a merchant this vendor has never integrated with?
- Who can read the per-agent record, and can anyone edit it afterwards?
FAQ
What is a control plane for AI agent payments?
The layer that decides whether a specific agent purchase may proceed, and keeps the record of that decision. It holds the spending limits, the merchant categories, the time windows and the approval thresholds, and it answers while the merchant is still waiting on the authorization. It doesn't move the money and it doesn't choose the purchase.
Is a control plane the same as expense management?
No. Expense management reads transactions that already happened and files them, so its earliest possible action arrives after the money moved. A control plane answers at the moment the purchase is attempted, which is when something outside policy can still be blocked or escalated to a person for approval.
Does Shatale decide what my agent buys?
No. What your agent wants to buy comes from your prompts and your own business logic, and we have no view on it. We answer whether a given purchase falls inside the limit, the merchant category, the time window and the approval threshold you set for that agent. Outside those lines, a purchase is blocked or escalated for approval.
What does Shatale not build?
We're not the agent framework, the model provider, the merchant, a procurement suite, an expense-management system, a fraud network or an identity provider. We ship agent-scoped virtual cards, policy enforced at the authorization moment, human approval workflows and immutable audit trails. Anything past those four is where the category is heading, and we don't present it as something we ship.
For where the rest of these layers sit and who occupies them, the map of agentic commerce covers the vendors on either side of this boundary. 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).