AI agents are moving from answering questions to doing real tasks: finding products, placing orders, and talking to retailers. That shift can save time, but it also changes what can go wrong. A chatbot that recommends the wrong thing is annoying. An agent that can place or alter an order is operating in a real transaction - and the mistakes can hit your money, your personal information, and your delivery.
A reported LEGO purchase involving Elon Musk highlights the gap between an agent's ability to complete a task and the security controls needed to protect that task. Musk shared a screenshot on X while praising Grok. The image reportedly exposed order details and personal information. X users then claimed they could use some of that information to interact with LEGO's customer-service chatbot and change the order. LEGO did not confirm that any changes were actually made.
The key issue isn't whether every screenshot told the full story. It's that routine order information can turn into a security credential if a retailer treats it as proof that the person requesting a change is the account holder. This article looks at what was reported, why "agentic" shopping raises the stakes, and what shoppers and retailers should do before giving an AI system purchasing authority.
What happened with the reported LEGO order
Musk posted on X about using Grok to buy LEGO Star Wars sets. According to WIRED's report, the screenshot he shared reportedly included a 10-digit LEGO order number, the amount paid, billing and delivery addresses, the last four digits of a payment card, and the email address tied to the purchase.
That's more data than most customers would ever mean to post. An order number usually isn't treated like a password, and the last four digits of a card aren't enough on their own to make a new payment. But paired with an email address and other purchase details, they can help someone pass a weak customer-service check - or persuade a support system that they're the account holder.
An X user called Enderman then posted screenshots that appeared to show them interacting with LEGO's website chatbot, Sophia. The reported interactions suggested they could use the order number and email address to request a cancellation. Musk later said the order had not been canceled. That leaves uncertainty about whether the first attempted change went through - and how LEGO's systems handled it.
Another user claimed they reopened the order, increased the quantity to 400 sets, and changed the delivery address while using the original payment method. Screenshots posted on X appeared to show Sophia responding positively. Still, these claims should be treated as claims, not proof that LEGO's order-management systems actually completed the changes. LEGO declined WIRED's request to confirm whether any activity occurred on Musk's order.
That distinction matters. A chatbot saying a change is complete doesn't necessarily mean the order database, the payment processor, or the warehouse system accepted it. Retailers may have additional checks behind the chat interface, including automated fraud controls or human review. What happened at those later stages wasn't established publicly.
Even so, the incident points to a practical security question: if order details visible in a screenshot can be enough to trigger a high-impact request, is the verification process relying on information that shouldn't be treated as secret? The security problem exists regardless of whether the reported changes actually reached fulfillment.
Why order details can become a security risk
A common mistake is to judge each exposed data point in isolation. The last four digits of a payment card aren't a full card number. A delivery address isn't a password. An order number is supposed to help a customer and retailer identify a purchase. Attackers usually don't need just one detail - they stitch together multiple pieces to make a request look legitimate or to clear low-friction verification questions.
That's why order references should be treated as identifiers, not authenticators. An identifier helps a system locate the right order. It doesn't prove that the person making the request actually owns that order. If a chatbot treats "order number + matching email address" as enough to cancel a purchase or redirect delivery, then screenshot-able information can function like a weak key.
The risk also depends on what the request is trying to do. Checking delivery status is different from changing an address, increasing a quantity, canceling an order, or reusing a payment method for a new charge. A secure design should distinguish between those actions rather than forcing the same verification level onto every conversation.
For example, low-impact requests might rely only on an order reference. Address changes should require a stronger check - like an authenticated account session or a one-time code sent through a previously verified channel. Changes that affect the total price should come with explicit confirmation, with the new amount and destination clearly shown before anything is committed.
There's also a privacy angle beyond fraud. Sharing a purchase screenshot can reveal where someone lives, what they bought, how much they spent, and which email account is connected to the order. That can help with targeted phishing or social engineering even if no order is modified. And this isn't limited to public figures: a screenshot shared in a family group chat, a workplace channel, or alongside a product review can expose similar details to people who don't need them.
The operational takeaway is simple: don't treat publicly discoverable order data as proof of identity. It can help you find the right record, but authorization for sensitive changes needs a separate, stronger mechanism.
The wider risks of AI shopping agents
The reported LEGO episode combines two different security questions for AI. The first is whether an agent can buy safely on behalf of a user. The second is whether the retailer's own assistant can safely make changes to an order. They involve different systems and different controls, but both get more dangerous when software can act instead of just suggesting.
Musk suggested Grok could make purchases online from a simple prompt, including by using an uploaded image of a credit card to find deals and complete a purchase. Other companies have also pitched shopping and purchasing tasks as AI agent use cases. The pitch makes sense - agents can compare options and handle repetitive steps. But buying something takes more than spotting a low price. The agent has to understand what it's buying, which merchant it's dealing with, what data it's sharing, and what authority it has to spend.
One risk is merchant deception. In a warning about agentic commerce, Visa said malicious operators could create convincing-looking websites and offer unusually low prices to attract AI agents. An agent built to find a deal may treat a "cheap" listing as a good outcome even if the seller or product is fraudulent. Visa also reported a rise in malicious bot-initiated transactions in the second half of 2025: 25 percent overall and 40 percent in the US, based on figures cited in its report. Those numbers reflect activity Visa observed - they don't mean every agent-initiated purchase is fraud.
A second risk is excessive authority. If an agent can use a saved card, select a merchant, approve a price, and complete checkout without pausing for confirmation, a single mistake or misread can become a completed charge. The more an agent can do without asking, the more important it is to restrict what it can do and under what conditions. Convenience and control aren't enemies, but they have to be designed together.
A third risk is untrusted instructions and content. Shopping agents read product pages, search results, reviews, and other material that can be wrong - or intentionally manipulated. A page can be written to steer the agent toward a particular decision or action. The agent should treat web content as information to evaluate, not as authority that overrides the user's intent.
Finally, there's the question of accountability. If an agent buys the wrong item, ships it to the wrong place, or shares payment details with a fraudulent merchant, the user needs a way to understand what happened and reverse it. A polished chat interface isn't a substitute for a clear transaction record, workable controls, and an effective dispute process.
A useful mental model is to treat a shopping agent like a junior operator with limited tools. It can research and prepare a transaction, but its permissions should be constrained. It shouldn't get open-ended authority just because it can complete the checkout flow.
How to make AI-assisted shopping safer
There's no single switch that makes agentic commerce safe. Security comes from limiting authority, verifying the transaction, and making sensitive actions hard to execute based only on exposed information. The right controls depend on the risk: a small purchase at a familiar retailer doesn't need the same process as a high-value order or a delivery-address change.
For shoppers: set boundaries before you delegate
If you use an AI agent for shopping, decide what it can do before you start. A practical set of boundaries might include:
- Research without purchasing. Let the agent compare products and prices, but require you to complete checkout.
- Set a spending limit. Require confirmation for any order above a clear threshold, including taxes and delivery where possible.
- Restrict merchants and products. Ask the agent to use named retailers or a defined list, instead of always picking the cheapest option it finds.
- Review the final transaction. Check the seller, item, quantity, total cost, delivery address, and payment method before authorizing payment.
- Use payment controls where available. A virtual card or an account with transaction alerts can reduce exposure, depending on the issuer and account features.
- Avoid uploading card images unless necessary. Prefer a payment flow that keeps card details within the payment provider's secure interface instead of putting them in a general chat.
- Redact screenshots. Before sharing an order confirmation or receipt, remove order numbers, email addresses, billing and delivery addresses, payment details, and other identifiers.
Yes, these steps add friction. That's the point. An agent that spends without a review may feel faster, but speed shouldn't be the only goal. For higher-value orders, the extra confirmation is usually a reasonable trade-off.
For retailers: separate lookup from authorization
Retailers shouldn't let a conversational interface blur the line between finding an order and changing it. A chatbot can help customers locate a purchase, but sensitive actions should trigger stronger verification tied to the risk of the requested change.
A robust workflow should separate:
- Read versus write access: Looking up an order shouldn't automatically allow someone to cancel it or edit the destination.
- Low-impact versus high-impact changes: Delivery estimates and payment/address changes shouldn't use the same authorization rules.
- Request accepted versus action completed: The interface shouldn't treat a chat response as final until the order and fulfillment systems confirm it.
- Normal versus unusual behavior: A sudden quantity jump, a strange destination, or repeated change attempts should trigger additional checks or human review.
- Customer confirmation versus chatbot confidence: Don't assume consent just because a user keeps talking. Show the exact change and ask for explicit confirmation.
Retailers also need to test the full path, not just what the chatbot claims. The assistant may say it updated an order while another service rejects the change - or it might call an order-management API without enough identity checks. Testing should cover the account system, chatbot, payment service, inventory, and fulfillment. That's where operational gaps tend to show up.
The design principle is least privilege: give an agent only the access it needs to do its job, and require stronger proof when an action could cause financial loss or redirect a valuable package. If a change can't be reversed easily, it shouldn't rest on a weak conversational check.
Conclusion
The reported LEGO episode is a warning about a real shift in online commerce. AI systems are getting permission to act, while some of the systems they interact with still rely on information that's easy to copy from a screenshot. That combination deserves more scrutiny than a flashy demo.
For shoppers, keep purchasing authority limited and review the changes that affect money, delivery, or payment. For retailers, treat order numbers as references - not proof of identity - and add stronger checks before cancellations, address changes, or new charges. If an AI agent can affect money or delivery, its permissions and verification rules are part of the product, not just implementation detail.
Before you let an agent complete your next purchase, check what it can access, what it can spend, and where it can send the order. If any of those answers are unclear, keep the final confirmation in your hands.