Can my AI agent buy things for users?

The legal questions behind agents that book, buy, and pay for users, including authority, errors, payments, merchant terms, and disclosure.

Short answer

Yes. Federal and state electronic-transactions laws recognize contracts formed through electronic agents, provided the agent's actions can legally be attributed to the user. The card networks now run live programs for agent-initiated payments. The legal questions are about everything around the purchase: whether the user actually authorized it, who absorbs the loss when the agent gets it wrong, and whether the merchants' and payment networks' rules allow it.

The law on electronic agents

• E-SIGN, the federal law, says a contract can't be denied legal effect just because an electronic agent helped form it, as long as the agent's actions are legally attributable to the person being bound.
• The Uniform Electronic Transactions Act, adopted in some form by most states, goes further: a contract can be formed by interacting electronic agents even when no person reviewed that transaction at the time. It also has attribution rules and a provision that lets an individual avoid some erroneous electronic transactions, subject to conditions.
• Neither law makes a user liable for everything an agent does. Ordinary rules on authorization, contract formation, fraud, mistake, and consumer protection still apply.

Authority: what did the user actually agree to?

Your user is the principal and your agent acts for them. Your terms and your product design together define the scope of that authority. There are two basic models:

• Approval of an exact purchase. Show the item, the total including fees, cancellation terms, and the payment method, and require the user to confirm. This is the strongest position.
• Bounded advance authorization. The user permits purchases within limits they set: a category, a price cap, a list of merchants, an expiration date. This is more convenient but harder to defend when a user disputes a charge. Make the limits explicit and narrow, and let users see and cancel them easily.

Either way, record everything: what the agent did, which authorization it relied on, the exact text the user saw, and when. In a dispute, that log is your evidence.

Errors and disputes

When an agent buys the wrong thing, the user will dispute it with you, with the merchant, or with their card issuer. Plan for this:

• Decide who refunds first, and say so in your terms.
• A confirmation screen is your best protection against mistakes, both legally and in practice.
• A charge the user says they never authorized is handled differently from one they regret. Your logs decide which it is.

Payments

• Use the networks' agent programs, not a stored card. Visa set network rules for agentic payments in October 2025. Participants must register and use controlled payment credentials, and live agent-initiated purchases began at participating European merchants in July 2026. Mastercard's Agent Pay uses tokenized credentials and verification of the user's intent, and it expanded through 2026. Some capabilities are still rolling out to partners. Don't assume an ordinary stored card can be used for autonomous purchases outside the payment provider's rules.
• Use your processor's tokenized credentials rather than storing card numbers yourself, which brings in PCI DSS obligations.
• If you hold or move user funds, money transmission licensing and federal electronic fund transfer rules may apply. Usually the answer is to design so you don't.

The sites and services your agent uses

• Many websites' terms prohibit automated access or purchasing bots. Operating under the user's login does not necessarily make that permitted.
• Do not bypass CAPTCHAs or other bot detection.
• Event tickets have their own law. The federal BOTS Act prohibits getting around ticket sellers' security measures or purchase limits for qualifying live events (generally venues with more than 200 seats), and reselling tickets obtained that way. The FTC still enforces it. It doesn't apply to ordinary shopping.
• APIs offered for agents usually come with terms that are clearer than scraping a site.

Disclosure and untrusted content

• California's bot law is narrow. It prohibits using a bot to mislead people in California about its artificial identity in order to deceive them into a purchase or sale, or to influence a vote. A clear and conspicuous disclosure that it is a bot protects you. It is not a general disclosure rule for every AI interaction, but other laws are broader (see the guide on telling users they're talking to an AI). When your agent emails or calls merchants for a user, have it say it is an AI acting for a named person.
• Web pages, emails, and documents can contain text written to manipulate agents (prompt injection). An injected instruction that leads to a purchase is a charge the user never authorized. Design so that content the agent reads can never stand in for the user's confirmation.

Checklist an agent can run against the codebase

• List every tool or API that can spend money, book, or commit the user to something.
• For each one, find the code that requires user confirmation, or note that none exists.
• Check whether standing or scheduled instructions can bypass confirmation, and what limits they carry.
• Find how payments are made: network agent programs, processor tokens, or stored card numbers.
• Confirm that every action is logged with the authorization it relied on.
• Check how content from web pages and emails is separated from user instructions.
• Confirm there is a way to stop all agent activity at once.

If this applies to you

An agent product review covers the authority model, your terms, payments, the sites your agent operates, and a build spec for confirmation gates, logs, and limits. Adding one new kind of action to an existing agent is a pre-build feature check.