An agent-scoped virtual card is a payment card issued to one AI agent and to nothing else. It carries its own number, its own spending limit, its own set of permitted merchant categories, and a record of what it bought. Because no second agent and no person shares that number, every charge arrives with an owner already on it. Switch the card off and that one agent stops spending while the rest of what you run carries on.
You have seen both halves of this before. What changes is the unit: the card belongs to software that buys at three in the morning and cannot be asked about a charge on Monday.
What does "agent-scoped" mean in practice?
Agent-scoped means one card, one agent, and a spending policy attached to that pairing before the agent buys anything. The limit, the permitted merchant categories and the approval threshold get set when you issue the card, so who authorised a charge is settled in advance rather than reconstructed from receipts afterwards.
Scope is the whole idea. A card scoped to your research agent covers any merchant that accepts cards, including the data vendor it turns up on its own next Tuesday, because the boundary sits on the instrument rather than on a list of endpoints you predicted.
Shatale issues those cards with your policy enforced at the authorization moment, human approval above the thresholds you pick, and an immutable per-agent record of each decision. A purchase outside policy is blocked or escalated for approval while the merchant is still waiting.
Why doesn't a shared corporate card work here?
A shared number cannot tell you which agent spent the money. When four agents and two people bill the same card, the statement gives you a merchant, an amount and a date, and the buyer's name is in none of them. You recover it by asking around and matching timestamps, after the money left.
That was survivable while the buyers were people. A person remembers being in the building that week. An agent has no memory you can interview, and it can place forty small charges in an hour before anyone opens the statement.
Then there is the off switch. One shared number carries whatever workflows got attached to it over the years, so freezing it to stop a misbehaving agent also stops the invoicing job and the two integrations nobody documented. Cutting one agent off is what a per-agent kill switch is for.
How is this different from a card per employee?
The model is the same and the unit is wrong. Per-employee issuance gives you one holder per card and attribution on the statement, which is the right structure. It assumes a holder who can be asked what happened and who applies judgement to purchases nobody wrote a rule for. An agent does neither.
An employee with a $5,000 monthly limit and a note about approved vendors calls procurement when something feels off. An agent with the same limit spends it exactly as instructed, including when the instruction was wrong and when it came from text on a web page.
| Shared corporate card | Card per employee | Card per agent | |
|---|---|---|---|
| The card belongs to | a team or a department | one person | one agent |
| Who bought this | reconstructed from receipts | on the statement | on the statement |
| The limit covers | whatever the team spends | whatever that person spends | whatever that agent spends |
| Turning it off | stops whatever shares the number | stops one person | stops one agent |
| Who explains an odd charge | whoever remembers | the buyer | the record, because the buyer cannot |
What do you get that you didn't have before?
The charge arrives already attributed, so nobody has to investigate who bought what. The limit travels with the agent, which means it holds at merchants you never listed. And you can switch one agent off while the others keep running, because no other workflow is attached to that number.
The attribution point is easy to hear as better reporting. A per-agent record produced by the system that made the decision answers a different question than a monthly export your analyst reconciles by hand. Control at authorization time versus reconciliation afterwards covers the difference.
The travelling limit decides whether this scales. Say your research agent gets $200 a month at data vendors and anything above $2,000 needs a person to sign off: those numbers came from your finance team rather than from any standard, and they have to hold at whichever vendor the agent picks next, including one nobody had heard of when you set them.
The off switch you will use rarely and value most.
What this doesn't fix
Scoping the card tells you nothing about whether a purchase was a good idea. An agent can buy exactly what its limit allows, from a permitted merchant, and still be wrong about needing it. Policy bounds the damage. It does not supply judgement, and anyone selling you the second thing cannot deliver it.
It also leaves the standards question open. Visa and Mastercard both joined the Agentic Payments Alliance on 18 August 2026, and each runs its own agent scheme: Agent Pay from April 2025, Trusted Agent Protocol from October 2025. None of them sets the amount your agent may spend.
What to ask
- Is a card issued per agent, or per team with the agent's name on the transactions?
- Where does the spending policy live, and can I change a limit without waiting on an engineer?
- At what moment is the policy evaluated: while the merchant waits, or against last month's statement?
- If an agent tries a purchase outside policy, is it blocked, escalated to a person, or logged for me to find later?
- If I revoke one agent's card today, what else stops working?
FAQ
What is an agent-scoped virtual card?
A virtual payment card issued to one AI agent and to nobody else. It carries its own spending limit, its own permitted merchant categories, and a record of what it bought. Because the number is not shared, each charge is attributed as it happens, and revoking the card stops that agent alone.
How is it different from a virtual card for an employee?
The structure is the same and the holder is different. An employee applies judgement to purchases nobody anticipated and can explain an odd charge when finance asks. An agent applies the instruction it was given, including a wrong one. So the limit and the approval threshold get enforced on the card.
Does an agent-scoped card stop an agent buying the wrong thing?
It bounds what an agent can buy and sets where a person has to sign off, which reduces what a bad instruction costs you. It does not judge whether a purchase was sensible. A charge inside the limit, at a permitted merchant, still goes through.
Do I need one card per agent?
One per agent is the point, since a number shared by two agents hands back the attribution problem you issued the card to fix. You issue as agents go into service and revoke as they retire. Sub-agents are where teams usually want finer scoping than they started with.
If your agents are already running on a shared number, moving them onto scoped cards without stopping the work is the sequencing problem to solve first. 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).