Prompt Injection

The comparison to SQL injection is instructive mainly for where it breaks down. SQL injection has a fix — parameterised queries separate code from data at the parser. There is no equivalent here. The model has no parser and no privilege boundary inside the context; "ignore previous instructions" in a retrieved chunk is just more text, and it is text the model was trained to follow.

Direct injection is a user trying to override your system prompt — extract it, bypass a restriction, change the persona. Annoying, usually low stakes.

Indirect injection is the serious one, because the attacker is not the user. Malicious instructions live in content the model reads on the user's behalf: a web page it fetches, a PDF it summarises, a code comment it reads, a support ticket it triages, a calendar invite, an email, the description of an MCP tool. The user asks something innocuous, the agent reads poisoned content, and acts on the attacker's instructions with the user's permissions. Text in an image counts too — a screenshot is an injection vector.

The mitigations, and this is the part that matters: none of them are reliable, and you must design as if injection will succeed.

Delimiting untrusted content and instructing the model to treat it as data helps and is trivially bypassed. Input filtering catches known patterns and misses encoding, translation, and novel phrasing. A separate classifier model raises the bar and is itself injectable. Spotlighting — marking provenance so the model knows which spans are untrusted — measurably helps. Instruction hierarchy in newer models makes the system prompt harder to override, and a system-role message mid-conversation is a channel a user cannot spoof, unlike text in a user turn.

All of these reduce probability. None reach zero. So the real defence is architectural and lives outside the model: assume the model can be turned against you, and make sure that is survivable. Least privilege on tools, human approval on irreversible actions, server-side authorisation on every call, egress restrictions, and treating output as untrusted. If a successful injection can only cause an unhelpful answer, you have designed correctly; if it can exfiltrate data or send mail, you have not.

This is the defining security property of LLM systems and the top entry in the OWASP LLM list. In interviews it is the sharpest test of whether someone understands what they are building: candidates who answer "we'd sanitise the input" have modelled it as an ordinary injection bug. The right answer is that mitigation is probabilistic and containment is architectural — which is also what makes agent permission design a security conversation.

• The model cannot distinguish instructions from data; there is no parameterised-query equivalent and no privilege boundary inside the context.
• Indirect injection is the real threat: poisoned content in pages, documents, tickets, emails, tool results, and MCP tool descriptions.
• An injected agent acts with the user's permissions, which is what turns a text attack into a data breach.
• Images are an injection vector — text inside a screenshot is read as instructions.
• Delimiting, filtering, classifiers, spotlighting, and instruction hierarchy all reduce probability and none eliminate it.
• Design for successful injection: least privilege, approval on irreversible actions, server-side authorisation, restricted egress.
• The security question is never "can it be injected" but "what can it do once it is".
• Never let the model's output authorise an action — authorisation belongs in code, checked against the real user.
• A system-role message is a channel users cannot spoof; instructions embedded in user-turn text are not.
• Include injection attempts in your eval suite so mitigations are measured rather than assumed.