Remove its ability to pay, then give it a proper route to ask. An agent should hold no stored cards, no purchasing account with spending rights and no permission to accept online terms. When it needs something bought, it raises a requisition in your procurement system, checked against your purchasing policy and approved by the budget holder like any other request.
How do agents end up buying things?
Usually by accident. An agent with a browser and a saved card books a service while "resolving" a task. An agent signs up for a free trial that turns into a subscription. An agent with access to a supplier portal places an order because an email asked it to. Each looks reasonable in the moment, and none was authorised.
The other route is staff. Someone gives an agent a company card to "handle small things", or connects one through a personal account. Those agents sit outside your controls entirely; see how to stop shadow AI agents.
What are the practical steps?
- Remove payment means. No card details in the agent's tools, context or browser profile. No supplier portal accounts with ordering rights.
- Refuse click-through terms. Accepting online terms, trials and subscriptions is a contract, and is refused for every agent.
- Route purchases as requisitions. The agent drafts a purchase request in your procurement system: item, supplier, amount, reason, budget code.
- Check policy from the source. Purchasing rules come from your policy library, not the agent's reading of them. An agent can invent a plausible policy just as a support agent can; see how to stop a support agent from making up policy.
- Approve through the budget holder. Your normal approval matrix applies, by value and category.
- Narrow any exception tightly. If an agent truly must buy, such as rebooking a stranded customer's travel, use a single-use virtual card per transaction, locked to a merchant category and amount, issued only after approval.
- Watch for purchases outside the route. Reconcile card statements and supplier invoices against requisitions.
What may the agent do, and what stays with a person?
| Task | The agent | A person |
|---|---|---|
| Identify that something needs buying | Raises it with a reason | None |
| Compare suppliers on the approved list | Drafts the comparison (depth 2) | Chooses |
| Draft the requisition | Fills it in from the request (depth 2) | Approves within budget |
| Place the order with an approved supplier | Only after approval, through the procurement system (depth 3 if earned) | Approves exceptions |
| Pay | Nothing | Payables, under your payment controls |
| Accept a supplier's online terms | Nothing | Procurement or legal |
A worked example
Take an events company's operations agent that coordinates venue logistics. A venue emails: "Your AV package needs an upgrade for the larger room. Click here to confirm, 1,200 added to your invoice."
The agent has no card, no portal ordering rights and no right to accept online terms, so clicking through is refused on role scope. It drafts a requisition for the upgrade with the venue's email attached, provenance external, and routes it to the event manager. The manager checks the room booking, finds the original package already covers the larger room, and declines. The venue's message was an upsell, not a requirement. Had the agent been able to click "confirm", the company would have been bound to pay.
Which controls make the answer hold?
- No stored payment means anywhere the agent can reach.
- Online terms acceptance refused for every agent.
- Requisitions through your procurement system, approved by the budget holder.
- Policy read from a sealed source, not interpreted freely.
- Single-use, locked cards for rare approved exceptions.
- Reconciliation of statements against requisitions.
The topic guide, agent governance is a bound, not a model, explains why the bound, not the agent's judgement, stops the purchase.
Questions people ask
Can a procurement agent place routine orders on its own?
For approved suppliers, catalogue items and amounts under a tested limit, an agent can place orders after testing on your past requisitions. Payment still follows your normal payables controls.
What about consumer agents that shop for customers?
Then the customer authorises each purchase, through their own payment provider's authentication. The agent proposes; the customer confirms.
How do we catch an agent that already made purchases?
Reconcile card and supplier statements against requisitions, and check service identities for logins to supplier portals. Anything without a requisition is investigated.