---
title: "When the agent buys for us: budgets, payments, and autonomy limits"
description: "Practical guide for SMEs on purchases through AI agents: budgets, approvals, payments, autonomy limits, risks, and the steps of a controlled pilot."
canonical: https://i8.ro/en/blog/when-the-agent-buys-for-us-budgets-payments-and-autonomy-limits
---

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

> Practical guide for SMEs on purchases through AI agents: budgets, approvals, payments, autonomy limits, risks, and the steps of a controlled pilot.

Source: https://i8.ro/en/blog/when-the-agent-buys-for-us-budgets-payments-and-autonomy-limits

An AI agent can compare offers, fill a cart, and, in certain integrations, initiate steps in the payment process. For a small or medium-sized company, the useful question isn’t whether the agent “knows how to buy,” but which decisions we can delegate to it, within what limits, and who verifies the results. A mistaken order could mean a double payment, an unwanted subscription, a delivery to the wrong address, or an unapproved supplier.

This article covers the company’s role as a **buyer**. For the merchant’s perspective on selling to agents, see the [article about selling software as a service (SaaS) to AI agents](https://i8.ro/en/blog/how-can-saas-platforms-sell-to-ai-agents). For access control and action logging, consult the [article on permissions and auditing](https://i8.ro/en/blog/permissions-approvals-and-audit-the-rules-for-a-trustworthy-ai-agent). The budgets and thresholds below are **working scenarios**, not universal recommendations or legal limits.

## 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](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md) distinguishes between the mandate for the order content and the mandate for payment. [Visa Intelligent Commerce documentation](https://developer.visa.com/capabilities/visa-intelligent-commerce) describes authenticated user instructions, limited payment credentials, and controls for merchant and amount. These describe technical direction—not that any SME in Romania can enable all features tomorrow.

Products are evolving, too. In [its March 24, 2026 update](https://openai.com/index/powering-product-discovery-in-chatgpt/), OpenAI explained that the initial version of Instant Checkout didn’t provide the desired flexibility, and that their focus is 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 with your chosen provider, not just the protocol name in presentations.

To decide what to automate, we separate four stages:

1. **Research and recommendation.** The agent looks for products, compares prices, availability, terms, and conditions. It does not yet create any commercial obligations.
2. **Order preparation.** The agent fills out an internal request, a cart, or a purchase order. An internal request is not necessarily an order accepted by the supplier.
3. **Order placement and payment.** The supplier may accept the order, and the bank or processor may authorize or collect the payment. Order acceptance and payment confirmation are different stages.
4. **Receipt and reconciliation.** The company checks the goods or services received, the invoice, the final amount, and any returns. “Paid” does not automatically mean “delivered correctly.”

Strong autonomy for stage 1 does not automatically justify autonomy for stage 3. The risk increases when the action leads to expenses or commitments that are hard to reverse.

## A practical scale of autonomy

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

- **Level 0, inform:** the agent offers options and arguments; the human does the rest.
- **Level 1, prepare:** the agent creates the request and the cart; the human checks and submits.
- **Level 2, approved execution:** the human approves a precise order content; the system submits it, then requests payment through the flow accepted by the bank or processor.
- **Level 3, limited restocking:** the agent can only order pre-approved items repeatedly, from pre-approved suppliers, within automated limits on value and frequency. Exceptions are routed 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 the agreement of the institutions involved; it is not achieved simply by installing an AI model.

For most SMEs, a pilot at levels 1 or 2 provides data on the quality of recommendations and operations while retaining human approval for each purchase. The academic study [τ-bench](https://arxiv.org/abs/2406.12045) shows why compliance with rules must be tested on real-world cases: evaluated agents produced inconsistent results on tasks involving domain-specific tools and policies. The outcome concerns benchmark scenarios—that is, standardized test sets—rather than an error rate that applies to all commercial systems.

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

The instruction sent to the model, called the *prompt*, may include "don’t spend more than 300 lei." This can guide the agent, but actual control needs to exist in a separate component that checks the transaction before an order or payment is placed. The agent makes a proposal; the procurement system decides whether the proposal fits the company's policy. This is an architectural choice, supported by observed risks in [research on policy compliance by agents](https://arxiv.org/abs/2603.20449) and in the [OWASP guide to AI agent security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html).

Depending on the case, policy may cover:

- approved suppliers, their contractual identity, and official accounts or domains;
- allowed categories, items, and variants, including bans on new subscriptions or auto-renewals;
- limits per order, per user, per department, and per period, plus rules for repeated transactions and splitting a single purchase into smaller orders;
- the acceptable **total** price, in the approved currency, including taxes, shipping, and any additional costs known at checkout;
- delivery address, maximum timeframe, return conditions, and how long approval is valid;
- the approver, escalation thresholds, and who can change policy.

Policy should be checked against structured data from the cart or quote, not just the agent’s free-form summary. In addition, budget should be reserved when an order is in progress, so that two simultaneous sessions don’t each spend the same available amount. After a confirmed result, the reservation converts into a recorded expense or is released, as appropriate. If the result is unknown, the reservation remains until clarified, to prevent spending the same funds twice. These rules are design recommendations, not features offered by all platforms by default.

**Hypothetical scenario:** an office allocates 2,000 lei per month for supplies, allows a maximum of 300 lei per order, and restricts buying to products from a catalog and approved suppliers. The agent finds items for 280 lei, but shipping pushes the total to 315 lei. The order doesn’t go through automatically, even though the product prices are under the limit. If, after approval, the quantity, supplier, address, or total changes, the system requires a new verification. Nor should splitting the same purchase into two orders bypass the approval threshold. The figures are for illustration only.

## Approval must be tied to the exact order

An “Approve purchase” button is ambiguous if the cart can change between approval and payment. The approver should see at least the merchant, items and quantities, total cost and currency, delivery, any recurring costs, and the period for which approval is valid. The system keeps the approved version and compares it against the submitted one. Any relevant change blocks the transaction or resubmits it for approval.

This principle also appears in [AP2](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md), where the payment mandate is linked to a defined checkout. It is useful to distinguish between the **commercial mandate**, meaning the company’s permission to buy under certain conditions, and the **payment authentication**, which happens within the payment service. An internal approval does not replace the authentication required by the bank or payment processor.

In the EU, the [PSD2 Directive](https://eur-lex.europa.eu/eli/dir/2015/2366/oj/eng) and [Delegated Regulation (EU) 2018/389](https://eur-lex.europa.eu/eli/reg_del/2018/389/oj/eng) set the framework for strong customer authentication in situations required by law. This requires at least two independent elements, such as something the user knows, something they possess, and a biometric characteristic. Where strong authentication applies for a remote electronic payment, Article 5 of the regulation requires that the code is linked to the approved amount and beneficiary, and changing either will invalidate it. There are exceptions under defined conditions, including certain secure corporate processes, but one should not assume that any business-to-business (B2B) payment is exempt. The exact workflow should be validated with the payment service provider and, if necessary, with the company's legal counsel.

## Card details and authentication information must not be entered into the agent conversation.

An agent receiving a card number, security code, or authentication codes via chat introduces unnecessary risk. The safer option is a payment integration through an authorized provider, with 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 provider's intended purpose and set restrictions. [Visa describes](https://developer.visa.com/capabilities/visa-intelligent-commerce) agent-specific tokens and instruction verifications before credential issuance, while [OpenAI describes](https://developers.openai.com/commerce/guides/key-concepts) in its specification a delegated payment request with limit and expiration. These are technical models, not guarantees that every processor or merchant will accept them.

Before integrating, ask the provider: who holds the sensitive data, what permissions the token has, which merchant and limit 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. Separately control the identity of the employee requesting the purchase and the identity of the app calling the API, the interface through which software systems exchange data and execute operations.

## What can go wrong, even with proper budget approval

**Instructions hidden in external sources.** A product page, a quote PDF, or an email from a supplier may contain text that tries to alter agent behavior. This is called *indirect prompt injection*: data read by the agent is mistakenly treated as instructions. [AgentDojo](https://arxiv.org/abs/2406.13352) has studied such attacks in tool-enabled environments. The practical solution is to treat offers as untrusted data and not allow them to change policy, accounts, or approvals.

**Offers that are no longer valid.** Price, stock, shipping, or rates may change between comparison and checkout. Always recheck the final cart. If the total or a key term differs from the approved version, require a new decision.

**Duplicate orders.** An interrupted connection can cause the agent to resend a request without knowing the first one was successful. Use a unique request identifier and *idempotency* mechanisms so that repeating the same request does not result in another purchase. [Stripe’s documentation](https://docs.stripe.com/api/idempotent_requests) explains this principle for its API requests. The key must be reused for the same operation, and the integration should comply with the provider’s retention period and policies. Protecting a payment request does not automatically prevent duplicates in the order system. Always verify order and payment status separately; a missing response is not proof of failure.

**Costs that continue after the first payment.** A SaaS subscription may have auto-renewal, per-user billing, or variable consumption. A cap on the initial transaction does not necessarily limit future spending. Such contracts require a separate rule for subscription duration, modifications, cancellation, and account ownership.

**Exposed personal and business data.** Employee names, shipping addresses, and invoices may end up with external services. [The European Data Protection Board](https://www.edpb.europa.eu/sme/learn-the-basics/data-protection-basics_en) explains the data minimization principle for small businesses. Provide agents and suppliers only with data necessary for the purpose, set retention, and review contracts and access.

## Who stops the agent and who handles problematic purchases

Before go-live, appoint a purchasing manager and a backup. They must be able to suspend new orders and revoke delegated credentials. If budget or approval verification fails, the system halts execution and escalates the case for human review. This is called *fail closed*: lack of valid verification blocks the action. [OWASP explicitly recommends this rule for high-impact operations](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html#high-impact-action-integrity-controls).

Halting the agent does not automatically cancel an already accepted order or completed payment. These require checking with the supplier and the payment provider, then following the applicable cancellation, return, or refund process. In a pilot, clearly define who handles each exception and by when it must be resolved.

We recommend that the process monitors the purchase through to closure:

- **The order:** what the supplier accepted, its identifier, and whether there are partial deliveries.
- **The payment:** which amount is only authorized or reserved and which amount was actually collected, according to the provider's statuses.
- **Receiving:** what was received, and whether the items, quantities, and services match the order.
- **Invoice and adjustments:** whether the documents and amounts match, and any refunds are actually confirmed.

This correlation is called *reconciliation*. An agent's message like “I’ve processed the return” isn’t enough to close the case. Keep confirmations from the supplier and payment provider, tied to the same purchase. For example, [the Stripe documentation on payment tracking](https://docs.stripe.com/payments/payment-intents) describes verifying the outcome based on server notifications. For a buyer company, the available data may also come from the procurement platform, the bank portal, or confirmations from the supplier.

## Three examples, three levels of control

**Recurring consumables, with stable specifications.** The agent can compare offers from an internal catalog and prepare a restock. After a trial run with human approval, the company can consider automatic orders to validated suppliers, with an aggregate limit and receiving checks. Price, stock, or delivery exceptions go to a person.

**Software licenses.** The agent can suggest plans and simulate costs for the estimated number of users, but license rights, data access, contract duration, and recurring charges must be verified. Usually, approval also involves the IT manager or the person in charge of the budget, not just the requester.

**Equipment or services with negotiated terms.** The agent can gather specifications and compare offers, but differences in warranty, support, integration, and contract terms may matter more than the listed price. Here it’s wise to keep the decision and commercial commitment with people.

These are design scenarios, not claims that a particular merchant or processor currently offers the described automation.

## A measurable pilot for an SME

1. **Choose a single narrow process.** For example, consumables with a stable catalog and known suppliers. Note who requests, approves, pays, and confirms receipt within the current process.
2. **First, run without buying.** The agent prepares recommendations and test baskets. Compare the total price, availability, specs, and time spent versus purchases done by people.
3. **Write the policy in the system.** Define suppliers, items, limits, exceptions, approvers, and error behavior. Test modified baskets, prices above the cap, two requests competing, and malicious messages from pages.
4. **Enable a stage with approval.** Keep approval linked to the final basket and use the agreed payment flow with the provider. Record the proposal, checks, approval, order, payment, and outcome without copying unnecessary sensitive data into logs.
5. **Measure and scale only based on evidence.** Track net review time saved, total price, incorrect or duplicate orders, exceptions, returns, and policy compliance. Even if no unauthorized purchases are seen in a pilot, that doesn’t prove risk is zero. Review controls when the supplier, model, tools, or policy change.

In the end, the company should be able to answer simply: *who requested the purchase, who approved which option, what rule allowed it, what amount was paid, and what was received?* If the answer requires reconstructing the agent’s conversation, the process still isn’t sufficiently controlled.

## Conclusion

Agents can reduce repetitive purchasing work, especially in searching, comparing, and preparing orders. Buyer autonomy is granted gradually, based on risk and what systems, suppliers, and payment providers can verify. Budgeting, approval, and reconciliation should remain executable rules and clear records, not just good intentions formulated in natural language.

### Sources and further reading

- [Google, Agentic Payment Protocol (AP2), specification v0.2](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md), consulted on September 27, 2026.
- [Visa Developer, Visa Intelligent Commerce](https://developer.visa.com/capabilities/visa-intelligent-commerce), consulted on September 27, 2026.
- [OpenAI, Powering Product Discovery in ChatGPT](https://openai.com/index/powering-product-discovery-in-chatgpt/), March 24, 2026; [Agentic Commerce, Key concepts](https://developers.openai.com/commerce/guides/key-concepts), consulted on September 27, 2026.
- [Directive (EU) 2015/2366, PSD2](https://eur-lex.europa.eu/eli/dir/2015/2366/oj/eng) and [Delegated Regulation (EU) 2018/389](https://eur-lex.europa.eu/eli/reg_del/2018/389/oj/eng), especially Articles 5 and 17 of the regulation.
- [Yao et al., τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains](https://arxiv.org/abs/2406.12045), 2024; [Debenedetti et al., AgentDojo](https://arxiv.org/abs/2406.13352), 2024; [Winston et al., Solver-Aided Verification of Policy Compliance in Tool-Augmented LLM Agents](https://arxiv.org/abs/2603.20449), 2026.
- [OWASP, AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html); [Stripe, Idempotent requests](https://docs.stripe.com/api/idempotent_requests) and [Payment Intents](https://docs.stripe.com/payments/payment-intents); [EDPB, Data protection basics for small business](https://www.edpb.europa.eu/sme/learn-the-basics/data-protection-basics_en), accessed on 27 September 2026.