AI Agents Can Buy Things. Here's How to Control Them

AI agents are moving from recommending products to completing purchases. That changes the business question from "Can the assistant find the right item?" to "How do we prove the purchase matched the user's intent, stayed within policy, and can be challenged later?"

American Express put that issue in focus on October 13, 2026, when it introduced an Intent Intelligence Framework for agent-led commerce. The announcement describes a way to carry a person's shopping instructions through the payment process so merchants and payment providers can evaluate whether an AI agent is acting within the authority it received.

For a small business, this is not just a future checkout feature. The same control problem appears whenever software can order supplies, renew subscriptions, book travel, pay an invoice, or buy inventory.

What changed in agent-led commerce

Traditional ecommerce assumes a person is present for the important steps. The customer searches, compares, adds an item to a cart, reviews the price, chooses a payment method, and presses the final button.

An AI agent can compress those steps into one instruction:

Find a replacement laptop for our office manager, keep the total under $1,500, require delivery by Friday, and use the company card.

The agent may search several merchants, compare specifications, choose an item, enter shipping details, and initiate payment. A merchant receiving the order needs more than a valid card number. It needs enough context to determine whether the transaction fits the instruction that authorized the agent.

American Express says its Intent Intelligence Framework is designed to help verify that an agent's actions align with a user's instructions. The framework centers on communicating purchase intent, applying policy controls, and supporting verification across the transaction.

Visa and Mastercard are working on the same broad problem. Visa's Trusted Agent Protocol gives merchants a way to distinguish approved shopping agents from malicious bots and includes information about the consumer's request and payment details. Mastercard's Agent Pay uses tokenized credentials and registered agents to support authorized transactions.

The names differ, but the control model is similar: identify the agent, bind it to a real user or business, communicate the permitted task, protect the payment credential, and retain evidence about what happened.

Intent needs to be structured, not implied

A vague instruction is hard to enforce. "Buy office supplies" leaves too many decisions to the agent. It does not define a budget, merchant, product category, delivery deadline, quantity, or approval threshold.

A useful purchase instruction should become structured policy before the agent starts shopping.

Control	Example value
Requester	Office manager, employee ID 1842
Purpose	Replace failed reception laptop
Product category	Business laptop and approved accessories
Maximum total	$1,500 including tax and shipping
Approved merchants	Existing vendor list or verified retailers
Delivery location	Main office only
Deadline	Delivered by Friday at 5 p.m.
Quantity	One laptop, one charger
Restricted items	Gift cards, warranties over three years, subscriptions
Approval rule	Human approval if total exceeds $1,250
Expiration	Authorization ends in 24 hours

The agent should receive the minimum authority required to complete that request. It should not receive a reusable instruction to buy any computer equipment indefinitely.

Separate preferences from hard limits

Some parts of the request are preferences. Others are rules.

A preferred brand, color, or delivery window can be flexible. A maximum total, prohibited category, approved shipping address, or requirement for human approval should be treated as a hard limit.

If the agent cannot satisfy every hard limit, it should stop and return options. It should not silently reinterpret the request. A $1,499 laptop with a $120 required adapter is not within a $1,500 all-in budget. A cheaper item from an unapproved marketplace is not a valid substitute when merchant restrictions are part of the policy.

A useful agent does not merely complete purchases. It knows when the purchase is outside its authority and asks for a decision.

Set limits, approved categories, merchant rules, expiration, and human approval conditions before the agent receives a payment credential.

Build controls at three separate layers

Small businesses often treat AI permissions as one setting: on or off. Purchasing needs more detail. Use separate controls for the agent, the workflow, and the payment method.

1. Agent identity and permissions

Give each purchasing agent its own identity. Do not let several automations share one generic account.

The identity record should include:

• The agent name and version
• The employee or team responsible for it
• The systems it may access
• The actions it may perform
• The date its authorization expires
• The model and workflow version used for each transaction
• A kill switch that disables new actions immediately

An agent that can search a catalog does not automatically need permission to submit an order. An agent that can prepare an order may not need permission to release payment. Keep those capabilities separate when the tools allow it.

2. Workflow policy

The workflow should validate the proposed purchase before payment begins. That policy can check category, amount, supplier, quantity, tax, shipping address, delivery deadline, duplicate risk, and whether the request is still active.

Use an idempotency key based on the request ID and proposed order. If the workflow retries after a timeout, it should check whether the order already exists before submitting it again.

Add a human checkpoint for high-impact conditions:

• The total is above a set amount
• The merchant is new
• The shipping address changed
• The item creates a recurring charge
• The agent substituted a product
• The order includes a restricted category
• The transaction is international
• The agent encountered conflicting instructions

The approval screen should show the original request next to the proposed order. A manager should not have to reconstruct the request from a chat transcript.

3. Payment controls

Do not place a permanent company card number inside an agent prompt, workflow variable, or general credential store. Use tokenized or virtual payment credentials when your bank, card issuer, or payment provider supports them.

A purchase credential should be limited by amount, merchant, time, or transaction count whenever possible. The payment layer should reject a transaction even if the workflow fails to enforce its own rule.

This defense matters because software controls can break. A prompt can be misread, an integration can send the wrong field, or a supplier can change the final price. Payment restrictions provide an independent stop.

Keep a receipt for the decision, not just the charge

A normal card statement records the merchant, amount, and date. Agent-led purchasing needs a richer audit trail.

For each request, preserve:

1. The original user instruction
2. The structured intent policy created from it
3. The agent identity and workflow version
4. The products and merchants considered
5. The proposed order shown for approval
6. Any substitutions or changed terms
7. The approval decision and approver
8. The payment token or credential reference, not the secret itself
9. The merchant response and order confirmation
10. Delivery, cancellation, refund, and dispute events

Logs should be tamper resistant and access controlled. They may contain business spending details, employee identifiers, addresses, and purchasing patterns.

The NIST AI Risk Management Framework recommends governing, mapping, measuring, and managing AI risk across the system lifecycle. For purchasing agents, that means the audit trail should not be an afterthought added after an incident. It is part of the system design.

Record why the agent chose the item

Do not rely on a hidden model reasoning trace. Store a concise decision record using business fields that a person can inspect.

For example:

• Met required processor and memory specifications
• Total price was $1,438.22 including shipping
• Merchant was on the approved vendor list
• Delivery date was within the requested deadline
• No recurring subscription was included
• Alternative A was rejected because delivery was late
• Alternative B was rejected because the total exceeded the limit

This record is more useful than a paragraph of model commentary. It connects the choice directly to the written policy.

Design the exception path before the first purchase

Agent-led commerce will not fail only through declined cards. The difficult cases are partial success and uncertain state.

Examples include:

• The merchant accepted the order, but the workflow timed out before receiving confirmation
• The final tax or shipping charge pushed the total above the limit
• The selected item became unavailable during checkout
• The merchant substituted a similar product
• The agent created two orders after a retry
• The purchase was approved, but the delivery address changed
• A subscription renewed after the original task expired
• The employee revoked the request while checkout was in progress

Preserve the request, decision, approval, payment reference, and merchant response so exceptions can be investigated without guessing.

Create explicit states such as requested, policy checked, approval required, approved, payment initiated, merchant accepted, fulfilled, exception, canceled, and refunded.

If the state is uncertain, do not submit another order automatically. Query the merchant using the request or idempotency key. If the merchant cannot confirm the result, send the record to a human exception queue.

Set ownership and response times for that queue. An exception without an owner becomes an accounting problem, a customer-service problem, or both.

Start with low-risk purchasing tasks

The first deployment should not let an agent freely spend from the main operating account. Start with a narrow task that has predictable products, low transaction values, and easy reversibility.

Good pilots include:

• Reordering approved break-room supplies
• Buying shipping materials from one existing vendor
• Renewing a known software seat count with a strict maximum
• Booking refundable travel within a written policy
• Preparing purchase orders for human approval without releasing payment

Avoid early pilots involving gift cards, cash equivalents, regulated goods, high-value inventory, unfamiliar international merchants, or purchases that are difficult to reverse.

Run the pilot for a defined period and review every transaction. Compare the original request, structured policy, selected product, final charge, and fulfillment result.

Track operational measures such as:

Measure	What it reveals
Policy rejection count	Whether requests are often outside the configured rules
Human approval rate	Whether the agent has enough authority for the chosen task
Duplicate prevention count	Whether retries are creating order risk
Price-change exceptions	Whether checkout totals differ from search results
Cancellation and refund rate	Whether product selection is reliable
Time to resolve exceptions	Whether a real owner is monitoring the system
Unauthorized merchant attempts	Whether supplier restrictions work
Expired-intent attempts	Whether agents stop when authority ends

A pilot is successful when the controls work, not when the agent buys the largest number of items.

A practical launch checklist

Before an AI agent can make a real purchase, confirm all of the following:

• The requester is authenticated.
• The instruction is converted into structured limits.
• Hard limits are separated from preferences.
• The agent has a unique identity and named owner.
• Search, order creation, approval, and payment permissions are separated.
• The workflow checks amount, category, merchant, address, quantity, and expiration.
• High-impact conditions require human approval.
• The payment credential is tokenized or restricted.
• Duplicate orders are blocked with an idempotency key.
• The original instruction and final order are stored together.
• The system records substitutions and changed terms.
• An exception queue has an owner and response time.
• Revocation disables future actions immediately.
• The first pilot uses low-value, reversible purchases.

Agent-led commerce can reduce routine purchasing work, but only if the authority is narrow and visible. The goal is not to make the agent behave like an employee with an unlimited company card. The goal is to give software a specific job, a limited budget, a short time window, and a clear stop condition.

That is the difference between automated shopping and controlled purchasing.