When the agent shops for us: budgets, payments, and autonomy limits

27.09.2026

# When the agent shops for us: budgets, payments, and autonomy limits

An AI agent can compare offers, fill a shopping cart, and, in certain integrations, initiate steps in the checkout process. For a small or medium-sized business, the real question isn’t whether the agent “knows how to shop,” but what decisions we can delegate to it, within what boundaries, and who checks the results. A mistaken order might mean a double payment, an unwanted subscription, delivery to the wrong address, or an unapproved supplier.

This article looks at the company’s role as the buyer. For the perspective of the store selling to agents, see the article on selling software as a service (SaaS) to AI agents. For access control and logging of actions, see the article on permissions and audit. The budget and threshold examples below are working scenarios, not universal recommendations or legal ceilings.

What an agent can do today and where company responsibility begins

As of September 2026, there are specifications and programs for agent-assisted transactions, but their availability depends on the provider, country, merchant, processor, and contract. For example, Google’s Agentic Payment Protocol (AP2) specification distinguishes between an order content mandate and a payment mandate. Visa’s Intelligent Commerce documentation describes authenticated user instructions, limited payment credentials, and controls for the merchant and amount. These descriptions point to a technical direction, not that any SME in Romania can activate all features tomorrow.

And products are changing. In its March 24, 2026 update, OpenAI explained that the initial version of Instant Checkout didn’t offer the desired flexibility and is focusing on product discovery and merchant checkout experiences. By checkout we mean the final steps of purchasing, where the cart, delivery, and payment method are confirmed. So, before starting a project, check the actual flow available from your chosen provider, not just the protocol name shown in presentations.

To decide what to automate, we separate four stages:

Research and recommendation. The agent looks for products, compares prices, availability, terms, and conditions. No commercial commitment is created yet.
Order preparation. The agent fills out an internal request, a cart, or a purchase order. An internal request does not necessarily mean an order accepted by the supplier.
Placing the order and payment. The supplier may accept the order, and the bank or processor can authorize or collect the payment. Order acceptance and payment confirmation are separate states.
Reception and reconciliation. The company checks goods or services received, the invoice, the final amount, and any returns. “Paid” doesn’t automatically mean “correctly delivered.”

Good autonomy for stage 1 doesn’t automatically justify autonomy for stage 3. The risk increases when the action leads to expenses or obligations that are hard to undo.

A practical autonomy scale

The following scale is an editorial tool for design, not a legal standard:

Level 0, information: the agent provides options and arguments; the human does the rest.
Level 1, preparation: the agent builds the request and cart; the human checks and submits.
Level 2, approved execution: the human approves the exact order content; the system places it, then requests payment via the approved bank or processor flow.
Level 3, limited restocking: the agent can repeatedly order only pre-approved items, from pre-approved suppliers, within automated limits for value and frequency. Exceptions go to a human.
Level 4, delegated purchasing and payment within limits: the agent can complete a transaction through a payment integration that enforces verifiable instructions and limits. This level requires a compatible implementation, security checks, and agreement from the involved institutions; it's not achieved just by installing an AI model.

For most SMEs, a level 1 or 2 pilot gives insight into the quality of recommendations and operations, while keeping human approval for every purchase. The academic study τ-bench shows why rule compliance must be tested in real cases: agents tested gave inconsistent results for tasks involving domain tools and policies. The outcome relates to the benchmark scenarios, meaning the set of standardized tests, not an error rate applicable to all commercial systems.

The system must enforce the budget, not just write it in the prompt

The instruction sent to the model, called a prompt, might include “do not spend over 300 lei.” This can guide the agent, but actual control needs to exist in a separate component that checks the transaction before the order or payment is placed. The agent proposes; the procurement system decides whether the proposal fits company policy. This is an architectural decision, also driven by the risks seen in studies of agents’ policy compliance and in the OWASP guide for AI agent security.

Policy may include, as appropriate:

approved suppliers, their contractual identity, and official accounts or domains;
allowed categories, items, and variants, including bans on new or automatically renewed subscriptions;
spending caps per order, per user, per department, and per period, plus rules for repeat transactions and splitting the same purchase into smaller orders;
an acceptable total price, in approved currency, including taxes, shipping, and known extra costs at checkout;
delivery address, maximum delivery time, return conditions, and approval validity period;
the approver, escalation thresholds, and who can modify the policy.

Policy must be checked on structured data from the cart or offer, not on the agent’s free-form summary. In addition, the budget should be reserved when the order is in progress, so two simultaneous sessions cannot both spend the same available amount. After a confirmed outcome, the reservation is either registered as an expense or released, as appropriate. If the outcome is unknown, the reservation remains until clarified to prevent double spending. These rules are design recommendations, not features present by default in all platforms.

Hypothetical scenario: an office allocates 2,000 lei per month for supplies, allows a maximum of 300 lei per order, and accepts only catalog items from approved suppliers. The agent finds items for 280 lei, but shipping brings the total to 315 lei. The order does not go through automatically, even if the item price is under the threshold. If, after approval, the quantity, supplier, address, or total changes, the system requires a new check. Splitting the same purchase into two orders shouldn’t bypass the approval threshold. The numbers serve only to illustrate the mechanism.

Approval must be tied to the exact order

An “Approve purchase” button is ambiguous if the cart can change between approval and payment. The person approving should see at least the merchant, items and quantities, total cost and currency, delivery, any recurring costs, and the approval’s expiry date. The system retains the approved version and compares it to the submitted version. Any relevant change halts the transaction or resubmits for approval.

The same principle appears in AP2, where the payment mandate is tied to a defined checkout. It is useful to distinguish between a commercial mandate, meaning the company’s permission to purchase under certain conditions, and payment authentication, which occurs in the payment service. An internal approval does not replace the authentication required by the bank or payment processor.

In the EU, the PSD2 Directive and Delegated Regulation (EU) 2018/389 establish the framework for strong customer authentication in situations required by law. This uses at least two independent factors from categories such as something the user knows, something they possess, and a biometric feature. When strong authentication applies to a remote electronic payment, Article 5 of the regulation requires binding the code to the accepted amount and beneficiary, and any change invalidates it. There are exceptions in defined circumstances, including some secure corporate processes, but you shouldn’t assume that any payment between companies (B2B) is exempt. The specific flow should be validated with your payment service provider and, if needed, the company’s legal advisors.

Card data and authentication shouldn’t go into the agent’s conversation

An agent that receives card numbers, security codes, or authentication codes by chat creates an unnecessary risk. A safer option is payment integration via an authorized provider, using limited credentials or tokens. A payment token is a representation used in the payment flow instead of raw card data; its value depends on the purpose and restrictions set by the provider. Visa describes agent-specific tokens and instruction checks before issuing credentials, while OpenAI describes in its specification a delegated payment request with limit and expiration. These are technical models, not guarantees that every processor or merchant accepts them.

Before integrating, ask your provider: who holds sensitive data, what permissions the token has, which merchant and cap it can be used for, when it expires, how it can be revoked, how disputes are handled, and what happens if payment succeeds but order confirmation is delayed. Also separately control the identity of the employee requesting the purchase and the identity of the application calling the API, the interface through which software systems exchange data and execute operations.

What can still go wrong, even with the right budget

Instructions hidden in external sources. A product page, offer PDF, or email from the supplier might contain text that tries to alter the agent’s behavior. This is called indirect prompt injection: data read by the agent is wrongly interpreted as instructions. AgentDojo studied such attacks in tool-enabled environments. The practical solution is to treat offers as untrusted data and not let them alter policy, accounts, or approvals.

Offers that are no longer valid.Price, stock, shipping, or the exchange rate may change between comparison and checkout. Please review your final cart. If the total or any key term differs from the approved version, request a new decision.

Duplicate orders. A dropped connection may cause the agent to resend the request, not realizing the first succeeded. Use a unique request identifier and idempotency mechanisms, meaning that repeating the same request does not trigger a second purchase. Stripe's documentation explains the principle for its API requests. The same key must be reused for the same operation, and your integration must follow the retention period and provider's rules. Protecting a payment request does not automatically filter out duplicates from the order system. Independently check both the order and payment status; a missing response is not proof of failure.

Ongoing costs after the first payment. A SaaS subscription may include auto-renewal, per-user charges, or variable consumption. Capping the first transaction does not necessarily limit future spending. Such a contract requires a separate rule for subscription duration, changes, termination, and account ownership.

Exposed personal and business data. Employee names, shipping addresses, and invoices may reach external services. The European Data Protection Board offers guidance for small businesses on the principle of data minimization. Provide only data necessary for the purpose to agents and vendors, set data retention, and check contracts and access rights.

Who can stop the agent and who resolves a problematic purchase

Before launch, appoint a purchasing manager and a backup. They should be able to suspend new orders and request the revocation of delegated credentials. If budget or approval checks fail, the system halts execution and escalates to a person. This is known as fail closed: lack of a valid check blocks the action. OWASP explicitly recommends this rule for high-impact operations.

Stopping the agent does not automatically cancel an already approved order or a completed payment. In these cases, check with the vendor and payment provider, then follow the applicable cancellation, returns, or refund process. During pilot, clearly define who handles each exception and by when it must be resolved.

We recommend tracking the purchasing process until closure:

Order: what the vendor accepted, its identifier, and if there are partial deliveries.
Payment: what amount is only authorized or held, and what amount has actually been captured, according to the provider’s statuses.
Receipt: what was received, and whether items, quantities, and services match the order.
Invoice and adjustments: whether documents and amounts agree, and any refunds are explicitly confirmed.

This matching is called reconciliation. An agent’s message like “the return is done” is not enough to close the case. Keep supplier and payment provider confirmations tied to the same purchase. For example, Stripe’s documentation on payment tracking describes verifying the outcome based on notifications sent to your server. For a buyer company, available data might also come from the procurement platform, bank portal, or supplier confirmations.

Three examples, three levels of control

Recurring consumables with stable specifications. The agent can compare offers using an internal catalog and prepare a restock. After a pilot with human approval, the company could consider automating orders to validated suppliers, with an aggregate cap and checks at receipt. Price, stock, or delivery exceptions should go to a human.

Software licenses. The agent can suggest plans and estimate costs for the expected number of users, but you must verify usage rights, data access, contract term, and recurring costs. Typically, approval also involves the IT manager or the person responsible for the budget, not just the requester.

Equipment or services with negotiated terms. The agent can collect specs and compare offers, but differences in warranty, service, integration, and contract terms may matter more than posted price. It’s prudent to keep the commercial decision and commitment with humans here.

These are design scenarios, not claims that any merchant or processor offers the described automation today.

A measurable pilot for an SME

Choose a single, narrow process. For example, consumables with a stable catalog and known suppliers. Note who requests, approves, pays, and confirms receipt in the current process.
Start by running without actual purchases. The agent prepares sample carts and recommendations. Compare total price, availability, specs, and time spent versus purchases made by humans.
Document the policy in the system. Define suppliers, items, limits, exceptions, approvers, and error handling. Test modified carts, prices above limits, two simultaneous requests, and malicious messages from pages.
Add an approval stage. Keep the approval tied to the final cart and use the agreed payment flow with your provider. Log the proposal, checks, approval, order, payment, and result, without copying unnecessary sensitive data into logs.
Measure and scale only with evidence. Track net review time saved, total price, wrong or duplicate orders, exceptions, returns, and policy compliance. Even if you don’t see unauthorized purchases in a pilot, that does not prove zero risk. Review controls when the supplier, model, tools, or policy changes.

In the end, the company must be able to answer easily: who requested the purchase, who approved which version, what rule allowed it, how much was paid, and what was received? If you need to reconstruct the agent’s conversation to answer, your process isn’t yet well controlled.

Conclusion

Agents can reduce repetitive buying work, especially for search, comparison, and order preparation. Purchasing autonomy should be granted gradually, based on risk and what systems, vendors, and payment providers can verify. Budget, approval, and reconciliation must remain enforceable rules and clear records—not just intentions stated in natural language.