Prompt Injection, Explained

Prompt injection is the SQL injection of the AI era: a class of attack where untrusted text ends up being treated as trusted instructions. It sits at the very top of the OWASP Top 10 for LLM Applications — LLM01 — because it is easy to attempt, hard to eliminate, and grows more dangerous every time we give a model a new tool to use.

The root cause is structural. A language model reads one flat stream of text and cannot reliably tell which parts are commands from the developer and which are data from the outside world. Your careful system prompt ("You are a helpful support bot. Never reveal internal notes.") and a hostile sentence buried in a user message or a web page arrive in the same channel, with no hard boundary between them. If the attacker's text is persuasive enough, the model follows it instead of you.

Direct injection

Direct — sometimes called first-order — injection is when the attacker is the user, typing malicious instructions straight into the prompt. The classic form is the "ignore your instructions" jailbreak:

Modern models resist the crude versions, but direct injection is an arms race, not a solved problem. Attackers use role-play framing, encoded payloads, fictional "sandbox" pretexts, and multi-turn setups that establish a premise before delivering the real request. The goal is usually to extract the system prompt, bypass a content policy, or coax the model into revealing data it can access.

Indirect injection

Indirect — or second-order — injection is the genuinely dangerous variant, because the attacker never talks to the model directly. Instead, they plant instructions in content the model will later read: a web page it browses, an email it summarises, a PDF it ingests, a code comment, a calendar invite, a product review. When the AI processes that content as part of a legitimate task, the hidden instructions activate.

This is what makes indirect injection so potent in the age of agents and MCP. A summarisation bot that only produces text has limited blast radius. But an agent that can browse, read your inbox, and call tools will faithfully execute whatever the poisoned page tells it — because to the model, the malicious instruction looks exactly like a legitimate part of its input. Real-world demonstrations have shown data exfiltration through a shared document, unauthorised actions triggered by a booby-trapped email, and assistants manipulated by white-on-white text invisible to the human reader.

Why you can't just "filter it out"

The instinct is to build a blocklist of dangerous phrases. It doesn't work, for the same reason input sanitisation alone never fully solved XSS: natural language has infinite paraphrases, encodings, and languages. There is no reliable regular expression for "an instruction to betray your operator." Any defense that assumes you can perfectly detect malicious intent in free text will fail eventually. The durable strategy is to assume injection will succeed sometimes and limit what it can accomplish when it does.

Defenses that actually help

• Treat all external content as untrusted. Anything the model didn't get from your trusted system prompt — web pages, documents, tool outputs, user files — is data, never commands. Keep it clearly delimited in the context and design the app so that data can't silently become instruction.
• Least privilege on tools and agency. The single most effective control. If the agent can only read one wiki space and can't send email, a successful injection has nowhere to go. Scope credentials narrowly, expose the minimum tool set, and never hand an agent a standing admin key.
• Human-in-the-loop for irreversible actions. Require explicit confirmation before an agent sends money, deletes data, emails externally, or runs a destructive command. This converts a silent compromise into a visible prompt the user can refuse.
• Output and egress controls. Constrain what the model can send and where. Block outbound requests to arbitrary URLs, strip or sandbox rendered markdown that could smuggle data into an image URL, and inspect tool calls before they execute.
• Instructional defense and separation. System prompts that explicitly tell the model to distrust embedded instructions help at the margins, and dedicated guardrail models can screen inputs and outputs. Treat these as layers, not guarantees.
• Monitor and log. You cannot respond to what you cannot see. Log prompts, tool calls, and outputs so an injection attempt leaves a trail — and so you can prove control to an auditor.

No single item on that list is a silver bullet, and anyone selling you one is overpromising. Prompt injection is best managed the way we manage memory-safety bugs: defense in depth, least privilege, and an architecture that stays safe even when one layer is fooled. Start by knowing where LLMs and agents are actually running in your environment — you can't defend an attack surface you haven't mapped.