The prompt injection surface in commerce
Anywhere a merchant or customer supplies input that reaches an LLM, prompt injection is a live threat. A field taxonomy of the attack surface.
Prompt injection is a specific class of attack where a user's input becomes an instruction to an LLM. In commerce contexts, the attack surface is broader than it looks. Anywhere a merchant, customer, or third party supplies text that reaches an LLM, the injection risk is live.
Written February 2025 from an internal security review.
Where the surface lives
- Customer-supplied text on a checkout page. Product notes, delivery instructions, gift messages.
- Merchant-supplied text in their listings. Product descriptions, business names, category descriptions.
- Third-party data in support tickets. Customer complaints containing quoted text from other sources.
- Web-scraped content in RAG pipelines. Documents the system indexed that contain instructions to future readers.
- Filenames and metadata. File names, EXIF data, document titles — any string that reaches the LLM.
The defensive posture
- Never mix instructions and user data in the same context without separation. The system prompt is one channel; user data is another. Some models handle this natively; others don't.
- Validate downstream actions before executing. An LLM output that says "refund $500" doesn't authorise a refund; a downstream policy check does.
- Sanitise before indexing. Documents ingested into a RAG pipeline should be reviewed for instructions embedded in the text.
- Test with known injection patterns. Every LLM feature should be probed with the current adversarial prompt suite as part of QA.
What you can't fully solve
Prompt injection is not fully preventable at the LLM layer. The mitigation is defence in depth: keep the LLM's authority narrow, verify its outputs against policy, and monitor for anomalous patterns.
The attack surface is broader than the checkout form. The mitigation must be too.