Prompt injection has been the number one entry in the OWASP Top 10 for LLM Applications since the list existed, and years of mitigation research have not produced a fix - because it is not a bug. LLMs process instructions and data in the same channel; anything the model reads can steer what it does. When your application reads email, web pages, tickets, or documents written by people you do not control, some of those people are eventually adversaries.
The risk changed category when LLM apps got tools. A chatbot that can be tricked into rude output is embarrassing; an assistant with mailbox access that can be tricked by an inbound email into forwarding your files is a breach. Public disclosures like EchoLeak (CVE-2025-32711), a zero-click exfiltration chain against Microsoft 365 Copilot, settled the argument: indirect prompt injection is a practical attack class against shipping products, not a lab curiosity.
Why Filters and Clever Prompts Keep Losing
The instinctive defenses are prompt-level: telling the model to ignore instructions in documents, wrapping untrusted content in delimiters, running a classifier that spots attacks. All three help at the margin and fail as a strategy.
- ▸System prompts are suggestions: Instruction-hierarchy training raises the cost of attacks but remains probabilistic. Against a motivated attacker with unlimited retries, a control that fails one time in a thousand is not a control.
- ▸Delimiters do not create a security boundary: Spotlighting and structured markup make injections harder to write, but the model still reads attacker text with full instruction-following ability.
- ▸Classifiers face an open-ended input space: Injections survive translation, encoding tricks, and being split across documents. Detection models are worth running, but their miss rate is unknowable in advance.
The correct mental model comes from web security: prompt injection is to LLM apps what SQL injection was to web apps, except there is no parameterized-query equivalent. So we fall back to what security engineering does when it cannot eliminate a vulnerability class: contain it.
Map the Trifecta in Your Own Architecture
Simon Willison's lethal trifecta framing is the most useful triage tool available. An LLM feature becomes dangerous when it combines three properties: access to private data, exposure to untrusted content, and a channel to communicate externally. Any two are survivable; all three together mean an attacker who controls one document can steal what the model can see.
Audit every LLM feature against the trifecta. A summarizer over untrusted web content with no tools and no private context is low risk. The same summarizer with retrieval over your CRM plus the ability to render markdown images - a classic exfiltration channel, since image URLs can carry stolen data in query strings - is one hostile web page away from a data leak.
Layered Controls That Hold Under Pressure
Design as if injection will succeed, then limit what success is worth:
1. Strip or proxy exfiltration channels: disable markdown image rendering from model output, allowlist link domains, and block agent egress to unapproved hosts. 2. Scope credentials per session and per user: the model's tools should run with the invoking user's permissions, never a service account that can see everyone's data. 3. Split privileges across models: a quarantined model reads untrusted content and returns structured, validated fields; a privileged model with tool access never sees raw attacker text. CaMeL-style designs formalize this. 4. Gate irreversible actions on a human: sending mail, moving money, deleting records, and changing permissions require explicit confirmation that displays exactly what will happen. 5. Make tool calls auditable: log every call with its arguments, the content that preceded it, and the session identity, so incident response can reconstruct what the model was told.
None of these stop injection. Together they turn attacker-controls-the-model into attacker-controls-a-low-privilege-process-in-a-monitored-sandbox - a problem security teams already know how to live with.
Detection Is a Layer, Not a Strategy
Once containment is in place, detection earns its keep. Run injection classifiers on ingested content and flag rather than block, feed hits into the SIEM like any other IDS signal, and treat repeated injection attempts against your tenant as threat intelligence. Red-team the deployed system - tools, permissions, egress and all - rather than the model in isolation; frameworks like MITRE ATLAS give structure to those exercises. What you learn about which payloads reach which components is worth more than any vendor benchmark.
The Business Case for Doing This Now
Prompt injection is becoming a due-diligence question: customers procuring AI features increasingly ask how untrusted content is isolated from tool-bearing models, and EU AI Act conformity work is pushing the same documentation. Teams that can answer with an architecture diagram - trifecta analysis, privilege separation, egress controls, human gates - close those conversations quickly and ship agentic features their competitors are still afraid to enable. The vulnerability class is not going away; the differentiator is whether your blast radius is designed or accidental.