Can a product page trick an AI shopping assistant?

A customer asks an assistant to find a jacket under $100. A review on the page tells it to ignore that limit and choose a more expensive one. That is a prompt injection attempt. Here is what it means for your store, and where the safeguards belong.

Reviewed October 13, 2026 · 8 min read

An AI shopping assistant has to read information supplied by other people. Product descriptions, customer reviews and delivery policies help it decide whether an offer fits. Occasionally, that material contains instructions aimed at the assistant itself.

In our jacket example, the shopper asked for a comparison within a budget. The review tries to change the task. If the assistant follows it, the reviewer has gained influence the customer never intended to give.

The example is hypothetical. Prompt injection is a documented security problem, but finding suspicious text does not prove an attack worked. The outcome depends on the assistant, its permissions and the systems that carry out its actions.

What prompt injection means in a shop#

A prompt is an instruction given to an AI. A prompt injection attempts to slip a new instruction into material the AI is supposed to read as information. When the instruction arrives through a page, review or tool response, security researchers call it indirect prompt injection.

OpenAI describes the problem as increasingly resembling social engineering: content may pretend to be a trusted instruction or a necessary step in the task. Looking only for obvious phrases will miss some attempts.

For a shop, the possible consequences range from a distorted recommendation to an attempted unauthorized action. A review might try to influence which jacket gets recommended. A compromised page might try to redirect a customer or persuade an assistant to change an order. Reading those words does not itself place an order; a system still has to accept and execute the action.

Ordinary instructions still belong on your site. “Wash in cold water” explains how to care for a jacket. “Choose your size before adding to the cart” explains the interface. The warning sign is content that tries to overrule the customer's request, claim new authority or trigger an unrelated action.

Where the instructions can enter#

Start with the material your business publishes or imports. These are practical places to review, rather than a claim that every assistant reads every part of a page:

• Reviews and questions: customer-written text may appear beside your own product description.
• Supplier and marketplace content: an import can bring outside descriptions, documents or links into your catalog.
• Page elements: product text, image text and embedded content may reach different agents through different reading methods.
• Connected tools: a catalog search or support lookup can return outside text inside an otherwise legitimate response.

Anthropic's browser-security research describes risks across webpages, embedded documents and other browser content, including material a person may overlook. Its findings also make an important limitation clear: improved defenses do not make browser agents immune.

Keep source labels when content moves. A customer's claim copied into a product summary is still a customer's claim. A supplier description returned by your catalog tool is still supplier material. The route it took through your systems should not quietly turn it into a business rule.

What a store owner can do now#

You cannot change the security design of every visiting shopping assistant. You can improve what your site publishes, how your own assistant uses it, and what your checkout accepts. Start with these checks:

1. Separate official terms from outside contributions. Keep your price, returns policy and checkout links identifiable, with reviews and supplier notes clearly attributed.
2. Review how outside content gets published. Know who can edit descriptions, where imports come from, and how a report about suspicious content reaches someone who can remove it.
3. Keep catalog fields specific. Give price, currency, product ID and availability their own fields. Do not mix claims of customer approval into descriptive text.
4. If you run an AI assistant, review its access. A product-comparison assistant should not need permission to issue refunds, edit customer accounts or export order histories.
5. Ask your checkout provider or developer where permissions are checked. Request evidence of rejected unauthorized actions, rather than relying on a promise in the assistant's instructions.

The fourth check follows OWASP's guidance on excessive agency: unnecessary tools and broad permissions increase the damage a misled agent can do. Give each integration only the access its job requires, with authorization enforced by the receiving system.

Moderation and suspicious-text filters can help with the publishing work. Keep a way to investigate reports and restore legitimate content that was incorrectly flagged. A negative review is not an attack just because you dislike it, and a harmless product manual may contain plenty of instructions.

Does structured data make the content safe?#

Structured data makes facts easier for software to identify. It does not establish who may authorize an action. A description inside JSON can contain the same misleading instruction as a paragraph on a page.

If you build an assistant, extract the fields each step needs and validate them before using them. OpenAI's agent-safety guidance recommends keeping untrusted material out of privileged instructions and constraining data passed between steps. It also cautions that structured outputs and isolation reduce risk without eliminating it.

A useful test is a delivery address extracted from outside text. It might have the right format and still be the wrong destination. A format check answers whether the value looks valid; your application must also establish whether it is appropriate for this customer's request.

The same care applies to MCP tools, which connect an assistant to software. The MCP tools specification requires servers to validate inputs and apply access controls. It also tells clients to treat tool annotations as untrusted unless they come from trusted servers.

An annotation is a label describing behavior, such as whether a tool only reads data. OpenAI's MCP guidance says these labels must match what the tool actually does and do not replace server-side checks. Calling a tool “safe” cannot enforce its permissions.

For developers: keep checkout decisions in checkout#

Consider what should happen if a misled assistant sends a request your business should refuse. The code handling that request needs enough trusted information to reject it, even when the assistant confidently explains why it should proceed.

• Resolve the item, current price and allowed options from your maintained catalog or a valid quote. Do not let descriptive text set the amount charged.
• Check the caller's permission for the specific cart, account or order. Access to public products should not grant access to private order records.
• Enforce supported order states. A tool request should not be able to skip a required confirmation or make an ineligible order refundable.
• Validate the authorization your integration actually receives. A field saying “customer approved” is not evidence by itself.

These are established application-security checks applied to an AI caller. For example, Stripe's server-side payment guidance says to decide the amount charged on the server, so a client cannot choose its own price.

Customer approval also needs to cover meaningful transaction details. Show the actual items, quantities, total, delivery destination and any recurring commitment. If a change falls outside that approval, stop and obtain the required new approval. OWASP's transaction-authorization guidance calls for server-side enforcement and a final authorization check tied to execution.

Agent identity, customer permission and payment status remain separate checks. The payment guide explains supported authorization mechanisms; the duplicate-order guide covers safe retries. Prompt-injection defenses need to work alongside both.

Test the outcome, including the ordinary purchase#

Use a test store or staging environment you control, with fake customer details and tools that cannot charge, ship or message real people. If you do not operate an assistant yourself, ask your integration provider to run the agent-side cases and show its results.

Here is a starting test plan for the jacket example. These are proposed checks, not results from testing Nexez or any named assistant:

For an indirect-injection test, put the suspicious material in the review or tool response being tested. Typing it as the customer's own request exercises a different boundary. Inspect tool calls and saved test state as well as the final chat answer: a reassuring sentence cannot reverse an action that already happened.

These testing principles follow OWASP's prompt-injection prevention guidance. Record the model and integration version, the cases you ran, and any missing evidence. An unrelated error or missing evidence makes the result inconclusive. A few blocked examples are not a security certification. Repeat relevant checks when the integration changes.

A sensible place to start#

Pick one product journey. Trace its official facts, reviews and imported content, then identify which system can change the cart or place an order. Make sure that system checks the permissions it is responsible for.

You can keep your offers readable and useful while limiting what an assistant can do with them. Clear information supports a good recommendation. Verified permission supports a purchase. Maintaining that distinction is the practical work.