Just as SQL injection taught a generation to never concatenate untrusted input into queries, prompt injection is teaching the same lesson for the model era: any text a model reads can carry instructions. In 2026, with agents holding real credentials and real side effects, injection moved from a research curiosity to the top of application security checklists.
The attack surface is your inputs
Any text a model reads can carry instructions: user messages, uploaded documents, web pages, even tool results. The classic pattern is hidden instructions inside retrieved content that redirect the model to exfiltrate data or invoke tools. Treat every external string as untrusted input, exactly like SQL parameters.
Defend in layers
Separate instructions from data in the prompt structure, restrict which tools the model may call, require explicit confirmation for side-effecting actions, and scan outputs for sensitive patterns before returning them. No single control is sufficient; the layers are what make exploitation impractical.
Test with adversarial cases
Add prompt injection attempts to your eval suite: instructions hidden in documents, encoded payloads, and role-play preambles. Red-teaming your own feature before release is far cheaper than discovering the hole through a researcher disclosure.
The attack surface you did not know you had
The classic vectors are now well documented: instructions hidden in web pages the model fetches, comments in documents it summarizes, and tool outputs that instruct it to ignore its system prompt. The damage scales with what the model can do — a chatbot that leaks a prompt is an annoyance; an agent with a payment tool and an email reader is a heist. The first defensive question for any feature is therefore not how the model reasons, but what an attacker gains if it obeys the wrong instructions.
Defense in depth for LLM features
No single trick defeats injection, so mature stacks layer controls: isolate instructions from data with clear delimiters and privilege separation, allowlist tool calls with confirmation for anything destructive, sanitize and log all untrusted content that enters context, and keep a human in the loop for side-effecting operations. Output filtering catches leaked prompts; behavioral limits — spend caps, rate limits, scope checks — bound the damage when everything else fails.
Key takeaways
- Treat every fetched page, document and tool result as untrusted input.
- Bound blast radius with tool allowlists, spend caps and human confirmation.
- Isolate instructions from data; log all untrusted content entering context.
Final thoughts
SQL injection was solved by a generation internalizing one rule — never trust input — and prompt injection demands the same cultural fix for a new layer: in LLM applications, the input can now talk back, so architecture must assume it will.