Prompt injection and AI agents: stop trying to block it, design to contain it

Why filters don't fix it

SQL injection was solved with parameterised queries, which make it structurally impossible for data to be read as code. The UK's National Cyber Security Centre points out that current LLMs have no equivalent: they don't enforce a security boundary between instructions and data inside a prompt. Its conclusion is that prompt injection may never be mitigated the way SQL injection was, and that effort should go into reducing the impact instead¹.

OWASP lists prompt injection first among LLM application risks for the same reason⁴. Detection products help at the margins, but a defence that stops most attacks still fails against a determined attacker.

The lethal trifecta

Simon Willison gave the problem a useful shape. An agent becomes dangerous when it combines three things²:

With all three, a single poisoned input can tell the agent to collect private data and send it somewhere. Remove any one leg and that path closes.

Separate planning from reading

Research from Google, Google DeepMind and ETH Zurich, the CaMeL paper, shows what this looks like in practice. A privileged model writes a plan from the trusted user request. A quarantined model processes untrusted data but has no tool access. A separate interpreter tracks where each piece of data came from and checks security policies before every tool call, so untrusted content can't change the plan or send data where it isn't allowed³.

The authors are clear it isn't perfect and doesn't cover every attack³. But the principle is the right one: security decisions are made by ordinary code outside the model, using provenance the model can't forge.

A containment checklist

1. Map each agent against the trifecta. If one has all three legs, split it or add an approval step.
2. Enforce permissions outside the model. Tool calls go through a gateway that checks the user's rights, the tool's scope and the data's origin. The model's opinion is not an access control.
3. Treat retrieved content as data. Mark it as untrusted in the context, and never let it change the agent's permissions or goals.
4. Constrain outputs that leave the system. Allow-list destinations for email and HTTP, and strip links and images from model output that could carry data out.
5. Require approval for irreversible actions, showing the exact action and data involved.
6. Log everything, so an incident can be reconstructed. The tracing approach in LLM observability helps here.
7. Red-team continuously with injection tests in the release pipeline, alongside quality evaluations.

This complements the protocol-level controls in securing MCP servers. MCP security protects the pipes; containment limits what a confused agent can do with them.

What this means for product design

Containment has a cost. Agents that need approval are slower, and splitting capabilities means more engineering. The trade-off is worth discussing explicitly with product owners: an autonomous agent that reads the internet and sends email on your behalf is a different risk class from one that drafts replies for a human to send. Write the choice down as an architecture decision record, including what would change it.

How I can help

I design and review agent architectures for containment, from capability splitting to gateway policies and red-team suites. See my AI architecture work, or analyse your challenge and bring the result to a call.