Who's liable when an agent buys?

An AI assistant that buys things for its user is no longer a demo. At least one assistant's terms now say that what it agrees to on the user's behalf binds the user. So when one of those orders is disputed ("I never ordered this", "my assistant picked the wrong size"), who carries it?

This post won't answer that for you, and no blog post should. It depends on your payment processor's rules, the card network's, your own terms, and where you and the buyer are. Ask your payment processor, and a lawyer if the amounts matter. What this post does is set out what one assistant's terms say, how a dispute reaches a store today, and what evidence you can keep now, including what Tactical's evidence pack shows and what it can't.

What an assistant's terms can say

Take Instinct, an assistant that acts across its user's apps and devices. Its terms of service, last revised on 26 August 2026, appoint the service as the user's agent for agreements and transactions, and say those commitments are binding on the user as if they had entered them directly. For purchases, the terms say Instinct doesn't process the payment and isn't a party to the sale, and that disputes about a purchase are between the user and the business they bought from.

Other assistants' terms may say something else, and terms change. Read the terms of the assistants that send you orders. For a store the point is narrow: in at least one assistant's terms, a purchase its agent makes is a matter between its user and you.

How a dispute reaches you

If the buyer disputes the charge with their bank, it reaches you the way any card dispute does: through your payment processor, with a reason and a deadline, and you answer with evidence. Stripe's guide to dispute evidence is a clear walk-through of that process, whichever processor you use. Whether your processor or the card networks treat an agent's order differently is a question for your processor.

The identity side is moving. In October 2025 Visa announced its Trusted Agent Protocol, a way for merchants to recognise trusted agents that intend to buy and tell them apart from other bots, built on HTTP message signatures. Until agents prove who they are that way as a matter of course, what a store can show is what it saw.

What you can keep today

Most of the evidence in a dispute comes from your payments and your fulfilment, not from analytics:

• The payment record. Your processor keeps the checks it ran when the buyer paid. Stripe, for example, includes AVS and CVC results and the purchase IP address in a dispute response when it has them (Stripe).
• Your history with the same card. For Visa fraud disputes (reason code 10.4), Visa's Compelling Evidence 3.0 rules let a merchant point to two earlier undisputed payments on the same card, made 120 to 364 days before, that match the disputed one on the purchase IP address or device and on one more element, such as the shipping address or email (Stripe's summary).
• Fulfilment. Proof of delivery with the full address; for digital goods, logs showing the download or use.
• Your terms at checkout, and the buyer's messages.

None of that tells you whether the buyer was an agent, what it looked at before it bought, or whether it said who it was. That is the part an evidence pack adds.

What's in Tactical's evidence pack

When Tactical attributes an order to an agent, as an Agent order or an Agent order (session match), it makes an evidence record there and then and keeps it with the order. It has to be made at that moment: a session's full page list expires 30 minutes after its last event, and sessions and product views are deleted after 90 days, while a chargeback can arrive months later.

Each record holds:

• The order: ID, time, total, currency, status and line items (product, SKU, quantity, price).
• The attribution: the label, how sure it is, whether it's estimated, the method, the agent, the platform's channel marker, and whether browser pixels could have seen the order.
• The session: when it started and last acted; the pages viewed (the full list if it hadn't expired, otherwise the entry and exit pages); the products viewed, with when each was first seen and whether it went in the cart or is on the order; cart events; whether checkout started; and the behavioural classification with its score, confidence and signals (detection method, datacenter IP or not, mouse and scroll events, time between pages, referrer, AI referral source, country).
• Declared identity: the agent it named, its operator and category, where it named itself (the platform's order channel, the buyer's user agent or a Tactical Gate decision), and whether anything verified it.
• Tactical Gate decisions for the buyer's session within 24 hours of the order, for a store that runs Tactical Gate (agent rules, in beta: join the Observe beta).
• Limitations, written out in plain words in the record itself.

You download it from the Agent revenue page, as a PDF and as JSON. The PDF prints the SHA-256 hash of the JSON, so the two can be matched and a copy can be checked against what Tactical stored. The record holds no buyer name, email, phone number, address, payment details, IP address or user agent. Every field, explained.

What it can't show

• A session match is a match, not proof. The session is matched to the order by a hash of the buyer's browser user agent, within 24 hours of the order, and anyone on the same browser version shares that hash. The match is high confidence when the session viewed a product on the order and estimated when it only reached the cart, and the record says which.
• A classification is a judgement. "Agent" is Tactical's reading of how the browser behaved, not proof of who controlled it. We haven't published accuracy figures.
• A declared identity is a declaration. A user agent can be copied. Tactical doesn't check agents' request signatures yet, so today no record calls an identity verified.
• Gate decisions are sampled. Gate records every request it restricts, but allowed requests for only about 1 in 100 sessions, so no decision on record doesn't mean Gate didn't see the session.
• It isn't a Compelling Evidence 3.0 submission. Those rules match on IP address or device (Stripe's summary), and the record deliberately holds neither. Your processor's data covers that part.
• Demo orders are synthetic. Orders on Tactical's demonstration store go through a sandbox checkout: no payment is taken and nothing ships. Their records are labeled synthetic, and the PDF says so at the top.
• Coverage. Order data comes from WooCommerce today. Orders attributed before 27 September 2026 have no pack.

Using it in a dispute

This is not legal advice. Your processor tells you what a dispute needs and by when, so start there. A few practical points:

• Answer the dispute's reason. For "I didn't authorise this", the payment record and your history with the card carry the most weight. The pack adds what happened on your store before the order: whether an agent was browsing, what it looked at, and whether it said who it was.
• Keep it short. Stripe asks for evidence that is factual, professional and concise, organised in the order events happened. Attach the parts of the pack that answer the reason; you don't need all of it.
• Leave the limitations in. They are there so nobody reads more into the record than it holds, you included.
• Download before you need it. Order records are kept while your store is connected, and deleted with its data if you disconnect it.

What we've seen so far

No store running Tactical has recorded a real agent order yet, so there is no real pack to show. The only packs we can make today come from the sandbox checkout on our demonstration store, and they're labeled synthetic. When a real one arrives, and its store agrees, we'll show what it looked like.

Try it

Agent revenue is on every plan, the free one included, and each agent order it attributes gets a pack. Start free, install the WooCommerce plugin, and your next agent order comes with its evidence. How attribution works · Five ways stores handle AI agents.