Does an AI agent need an account to buy from you?

A shopper asks an assistant to buy a jacket from your shop. It finds the product, adds it to the basket, and reaches a page that says “create an account to continue”. At that point the automated part of the task stops. Here’s how to decide what really needs an account and what does not.

Reviewed October 8, 2026 · 7 min read

An AI agent is an assistant that can take actions for a person, such as finding a product and starting a checkout. Many shops ask every buyer to register first. That request is ordinary for a person and awkward for an assistant, because signing up and signing in are the two things it is least able to do.

This guide is about one decision: which parts of your shop genuinely need an account. It is not about the moment a customer takes over, which what stops agents completing tasks already covers.

What an assistant can do at a sign-in screen#

Capabilities differ by product, so check the one your customers use. As a documented example, OpenAI’s Cloud browser guidance states that at launch Cloud browser cannot sign in to websites or complete payments. It adds that permission settings do not change those supported capabilities.

Other products behave differently. Some pause and ask the person to take over the browser so they can type the password themselves. Either way, the shop should not expect the assistant to hold credentials or receive a security code.

The commerce specifications do not describe your account#

This is not an oversight. Both commerce specifications model the buyer as a stranger with contact details. Our comparison of UCP, ACP and MCP explains how the protocols relate.

In the Agentic Checkout specification, the buyer is described by name, email and an optional phone number in E.164 format. The buyer object itself is optional in every request and required only in the response that completes the purchase. There is no field for a password, a customer account identifier or a sign-in step, and the specification does not describe creating or authenticating a buyer account with the merchant.

The UCP checkout specification is similar, with first name, last name, email and phone number, all optional. It does define Identity Linking, but that exists so an authenticated request can return a buyer’s saved payment methods. It is not a way for an assistant to join or use your customer accounts.

That last row is worth noticing. The Agentic Checkout error codes include one for requiring a sign-in, but the specification does not define when it applies or what the sign-in involves. In other words, the protocol gives you a way to say that a login is needed, and nothing that gets past it.

Modern sign-in methods are harder for an assistant, not easier#

A natural response to all this is to modernize the login. That tends to make the automated path harder, for reasons built into the designs rather than caused by immature software.

Passkeys are the clearest case. The Web Authentication specification says a credential is bound to its managing authenticator, so only that authenticator can produce an assertion for it, and it requires an authorization gesture, described as a physical interaction performed by a user with an authenticator. Codes sent by text message or email are limited for a simpler reason: they arrive with the person, not with the software.

What belongs in front of the wall#

If you run a shop, the practical question is what a first-time visitor can see and do without an account. Aim to have these answerable on a plain request, with no sign-in and no previous visit:

• The price, including the currency, and whether the item is in stock.
• Delivery options, costs and the expected timescale.
• The returns and cancellation terms.
• Enough product detail to tell variants apart, such as size or colour.
• A checkout that can complete with contact and delivery details alone.

Guest checkout is the single change that matters most here, and it helps whether or not an assistant is involved. Make it the normal path rather than a small link under the registration form, and avoid asking for a password on the way to a completed order. You can still invite the customer to create an account afterwards, from the confirmation.

What still deserves an account#

This is not an argument against customer accounts. Several things reasonably sit behind one, and an assistant reaching a sign-in screen for them is the system working as intended:

• Past orders, invoices and saved addresses.
• Stored payment methods, which is the case UCP Identity Linking is designed for.
• Subscription changes, cancellations and anything that spends money again.
• Negotiated or account-specific pricing for trade and wholesale buyers.
• Anything that reveals personal data about the customer.

The distinction worth holding is between reading your public offer and acting on someone’s private records. The first should not need an account. The second usually should, and a handoff to the customer is the appropriate outcome rather than a failure to fix.

For developers: where the account check belongs#

Put the authentication check on the operations that need it, not on the catalog in front of them. A session that exists only to remember a basket should not decide whether a price is visible. If a page needs a cookie before it will show a price, a first request returns a page without one.

Return a clear status when a sign-in really is required, rather than a page that looks successful. A response that reports success while showing a login form is harder for any client to handle than an explicit refusal, and it also hides the wall from your own logs. What stops agents completing tasks covers status codes and recovery in more detail.

This command shows what a first-time visitor receives. It stores no cookies and sends none, then looks for a price in the response body. Adapt the pattern to your markup, and treat a missing match as a prompt to inspect the page rather than proof of a problem.

# What a first-time visitor receives: no cookies stored, none sent
curl -sS -o page.html -w "status %{http_code}\n" https://example.com/products/blue-jacket

# Is a price present in that first response, or added later by JavaScript?
grep -ioE "[0-9]+[.][0-9]{2}|in stock|out of stock|add to (basket|cart)" page.html | sort -u | head

A page that renders its price only after JavaScript runs can still be read by a browser-based client and missed by a simple fetch. Decide which clients you intend to serve, then include the essential facts in the first response or in a documented interface.

How to check your own checkout#

1. Open your product page in a private browser window. Note every fact you can see before signing in or accepting anything.
2. Try to complete a test purchase without creating an account. Record the first point where registration is demanded.
3. Check whether guest checkout exists, and how easy it is to find compared with the registration form.
4. Request the same product page with no cookies and read the response body. Confirm the price, stock and delivery information are present.
5. List the operations that genuinely need an account, and confirm nothing else is behind the same wall.
6. Make sure a required sign-in returns an explicit status your logs can count, instead of a successful-looking page.

Most shops find one or two facts sitting behind a session for no particular reason, usually because the page was built for a logged-in customer. Moving those in front of the wall is a small change that helps ordinary shoppers, search engines and assistants at the same time.

Your payment setup affects where the account check belongs. Our guide to how AI agents pay explains the main payment paths and who is responsible for each part of a sale.