01
How retrieved text reaches a model
Applies to marketplace onlyown storefronthybrid
A language model receives one stream of text. Part of it comes from the party operating the system, part from a user, and part from elsewhere — a web page, a document, a product feed. Published guidance describes the consequence: the origins are not separated by a reliable channel, and text that reads as an instruction can be handled as one.
That guidance names two shapes. Direct prompt injection is a user’s own input altering the system’s behavior in unintended ways. Indirect prompt injection is the system accepting input from an external source, such as a website or a file, whose content changes its behavior instead.1 A product listing is external content of the kind a shopping system retrieves, which places it in the second category.
02
What the research covers
Applies to marketplace onlyown storefronthybrid
The literature in this area states its own scope. Researchers demonstrated indirect prompt injection against real language-model-integrated applications and derived a taxonomy of the resulting attack classes from a security perspective.2 Later work built a benchmark for the same attack class and reported the evaluated models as broadly susceptible, attributing this in part to their inability to separate informational context from actionable instruction.3
What those studies do not cover is any specific shopping surface. The tested applications were not product catalogs, the model versions have since changed, and the current source set contains no measurement of what a deployed commerce assistant does with merchant-supplied text. A claim that a named surface is exploitable through a seller’s listings is not supported by these sources.
03
Three directions of exposure
Applies to marketplace onlyown storefronthybrid
A merchant’s exposure sorts into three directions, distinguished by who wrote the text and where it travels afterward.
| Direction | What it looks like | Whose account it appears under |
|---|---|---|
| Text published by the seller | A description read by a system producing a recommendation | The seller’s |
| Text imported by the seller | A supplier or scraped description entering the catalog unread | The seller’s, once published |
| Text republished onward | A cross-listing tool copying a description to other venues | The seller’s, on every venue |
The second and third rows are the ones specific to resale. Hostile copy written by a seller is rare; copy pasted without being read into a tool that distributes it under the seller’s account is the ordinary case, and the three rows differ in reach rather than in kind.
04
What a hostile record looks like
Applies to marketplace onlyown storefronthybrid
The recognizable version is a capitalized paragraph instructing a system to disregard what it was told. The documented attack classes include quieter forms, written to survive a human skim.
- Text hidden by formatting — white on white, zero height, or moved off-screen by markup — that a parser reads in full.
- Instructions phrased as ordinary product prose, reading as a note to a customer and parsing as a directive.
- Fields that are not proofread: specification tables, care instructions, imported bullet lists, warranty text.
- A URL offering further detail that returns different content to an automated fetcher than to a browser.
The four share a property: each sits where nobody is reading. That gives a merchant a question with an answerable form — which parts of a listing does no person read before publication — and the answer holds as the specific techniques change.
Applied to the camera, the question takes about a quarter of an hour and produces a list of fields rather than a verdict.
| Field | Where its text came from | Read by a person before publishing? |
|---|---|---|
| Title | Typed by the seller | Yes |
| Condition note | Typed by the seller after the bench test | Yes |
| Main description | Pasted from the job-lot spreadsheet | No — skimmed once |
| Specification bullets | Auto-filled by the listing tool from the model name | No, and the source is not recorded |
| Care and warranty text | Inherited from a previous template | Unknown — no author or date recorded |
Three of the five are unread and one has no recorded author. That is not an incident and it is not evidence of an attack. It is a description of which fields carry text nobody in the business has read, recorded in a place where it can be worked through.
05
The boundary a seller controls
Applies to marketplace onlyown storefronthybrid
Work on a catalog does not change how a third-party system handles retrieved content. Security guidance addressed to the parties building agents states the principle on their side: all external data should be treated as untrusted, with clear boundaries between instructions and data.4
The same principle describes the merchant’s side of the boundary. A description arriving from a supplier, a previous owner, a scrape, or a bulk import is external data entering the seller’s own system, and it becomes the seller’s published text at the point of publication regardless of who wrote it. The companion lesson on ingest covers the operational handling.
06
Recording it without a verdict
Applies to marketplace onlyown storefronthybrid
Two responses are available at the ends of the range. Rejecting supplier copy on principle costs listing time and treats an unmeasured risk as a known one. Setting the topic aside is how unread text stays published across years.
What the sources support sits between them. The attack class is documented and demonstrated against tested applications,2 no fool-proof prevention method is stated to exist, and the cited work does not measure any commerce surface. The exposure a seller can state from their own records is which fields carry text that has not been read, which is a list rather than a conclusion.
07
What the injection sources establish
Applies to marketplace onlyown storefronthybrid
The published guidance separates direct from indirect injection and states that fool-proof prevention may not exist.1 Agent-side guidance directs builders to treat external data as untrusted and to keep instructions and data bounded.4 The taxonomy work demonstrated the attack against language-model-integrated applications,2 and the benchmark work reported the models it evaluated as broadly susceptible.3
None of the four measures a commerce surface or states a rate of occurrence in merchant catalogs. What a seller can record is the field-level inventory of unread text, which is a first-party observation about one shop.
08
Practice
Exercise
List the fields nobody reads
- List every listing field whose content can arrive from outside your own typing.
- Mark which of those no person reads before the listing goes live.
- Open three of your oldest imported descriptions and read them in full, including hidden markup.
Check yourself
What separates indirect from direct prompt injection in the published guidance?
Direct injection arrives in the system’s own user input. Indirect injection arrives inside content the system retrieved from an external source, which is the category a product listing falls into.
Do the cited studies establish that a named shopping assistant is exploitable through listings?
No. They report the attack class against the applications the authors tested, none of which were product catalogs. The sources contain no measurement of a commerce surface.
Which fields does the exposure list name?
The ones no person reads before publication — imported specification tables, pasted supplier bullets, warranty and care text. The techniques change; the question of where nobody is reading does not.
Progress is saved in this browser only. No account, nothing sent anywhere.
09
Common questions
Does this mean supplier descriptions should not be used?
The sources do not support that conclusion. What they describe is text entering a system unread, which is addressed by reading or processing it before it becomes published text.
Is this a reason to stay off AI shopping surfaces?
The exposure described here comes from what a catalog contains rather than from where it is sent, so it is present either way.
Could a listing like this affect an account standing?
Hidden text and deceptive content are addressed by venue policies on their own terms, independently of any AI consideration. Those policies are the venue’s to state.
Is there a product that removes this risk?
The published guidance states that it is unclear whether fool-proof prevention methods exist, so a claim to eliminate the risk goes beyond what that guidance supports.
10
Research and sources
Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.
Claim evidence
- Published security guidance distinguishes direct prompt injection, which arrives in a user’s own input, from indirect prompt injection, which arrives inside content the system retrieves from an external source.
- technical requirement. Supported by LLM01:2025 Prompt Injection .
- The same guidance states that it is unclear whether fool-proof prevention methods for prompt injection exist, and recommends containment controls rather than a fix.
- technical requirement. Supported by LLM01:2025 Prompt Injection .
- Peer-reviewed work demonstrated indirect prompt injection against the language-model-integrated applications the authors tested and derived a taxonomy of the resulting attack classes; none of the tested applications was a product catalog.
- observed outcome. Supported by Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection .
- A peer-reviewed benchmark found the models it evaluated broadly susceptible to indirect prompt injection, attributing this partly to their not separating informational context from actionable instruction; the result is bounded by that benchmark and those model versions.
- observed outcome. Supported by Benchmarking and Defending against Indirect Prompt Injection Attacks on Large Language Models .
- Guidance addressed to the parties building agents holds that external data should be treated as untrusted with a clear boundary between instructions and data; a merchant importing description text is applying the same principle to their own system.
- technical requirement. Supported by AI Agent Security Cheat Sheet .
- LLM01:2025 Prompt Injection OWASP Foundation · Tier D · current community-reviewed guidance; not peer-reviewed research · OWASP Top 10 for LLM Applications, 2025 list
The direct and indirect prompt-injection taxonomy and the mitigation classes the entry itself enumerates. Limit: Consensus guidance rather than measurement. It records that the taxonomy and mitigations exist and that the entry itself states no method is known to be fool-proof; it does not establish that any named commerce surface is vulnerable, nor how often such an attack succeeds.
- Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection Association for Computing Machinery · Tier B · peer reviewed · AISec ’23 proceedings, pages 79–90
Demonstrated indirect prompt-injection attack vectors and their taxonomy against the LLM-integrated applications the authors tested. Limit: The demonstrations bound what was possible in the authors’ tested systems at the time of writing. They do not establish current behavior of any shopping surface, and none of the tested applications was a product catalog.
- Benchmarking and Defending against Indirect Prompt Injection Attacks on Large Language Models Association for Computing Machinery · Tier B · peer reviewed · ACM SIGKDD ’25 proceedings, pages 1809–1820
The BIPIA benchmark results and the two defense mechanisms evaluated within it. Limit: Benchmark evidence bounded by its own task set and the model versions evaluated. It supports the design position that external content and instructions are not reliably separated; it does not measure any commerce deployment or predict a merchant outcome.
- AI Agent Security Cheat Sheet OWASP Foundation · Tier D · current community-maintained guidance; not peer-reviewed research · unversioned live cheat sheet
The control classes the cheat sheet recommends: treating retrieved content as untrusted, least-privilege tool scoping, and explicit authorization for sensitive operations. Limit: Recommendations addressed to the party building an agent. It does not establish what any deployed shopping agent actually does with merchant-supplied text, and a merchant cannot verify another party’s adoption of it.