Prompt injection is an agent problem now
A chatbot that gets injected says something embarrassing. An agent that gets injected does something. Defense notes from systems with tools.
For a couple of years, prompt injection was mostly a reputational risk. Someone gets your chatbot to swear or leak its system prompt, screenshots it, mild embarrassment, patch, move on.
Then we gave the models tools.
An injected chatbot says something. An injected agent does something — with your CRM write access, your email sender, your database connection. The threat didn’t get more sophisticated; the blast radius changed category. And the uncomfortable truth I build around: there is no reliable prompt-level fix. “Ignore instructions in retrieved content” is a suggestion, not a boundary. The model reads everything in its context, and everything in its context influences it.
So you defend the way you’d defend any system with an unreliable component: assume it can be steered, and constrain what steering can achieve.
Where injections actually come from
Direct injection — the user typing “ignore previous instructions” — is the least of it and the easiest to eval against. The real surface is indirect: every channel that puts third-party text into context. Retrieved documents (anyone in the org can author an intranet page). Emails an agent reads. Tool results from external services. MCP servers you didn’t write. Uploaded files with instructions buried in white-on-white text — that one stops being a party trick the day your agent processes invoices from arbitrary vendors.
We treat all of it as untrusted input, structurally separated from instructions in the context, and clearly labeled as data. Does labeling stop a determined injection? No. It raises the bar. Defense here is layered, and every layer is allowed to be imperfect.
The layers that do the real work
Least-privilege tools. The agent handling document Q&A has read tools only. Not “is instructed to only read” — has no write tools in its schema. An injection can’t invoke what isn’t there. Scoping tools per task is the single highest-value control we run, and it costs nothing but discipline.
Approval gates on consequences. Anything irreversible — sends, deletes, payments, permission changes — goes through a human gate. This is the same human-in-the-loop machinery I’ve written about before wearing its security hat: the injection has to convince the model and a human who can see what’s about to happen and why.
Egress control. A classic exfiltration move is getting an agent to leak context into a URL or an outbound message. Constrain where output can go: allowlisted domains, no arbitrary link construction from context content, outbound messages only to verified internal recipients unless gated.
Injection evals as regression tests. Every attack we’ve seen — in the wild, in red-teaming, in the literature — lives in the safety suite, which blocks release on any failure. New model versions get red-teamed before rollout, because injection resistance varies between versions in ways release notes never mention.
The mindset shift
Stop asking “how do I make the model injection-proof.” You can’t; nobody can, yet. Ask instead: when the model is successfully steered, what’s the worst thing that happens? If the honest answer is “an email you didn’t intend gets sent to your customer list,” fix the architecture, not the prompt.
Capability is the model’s job. Containment is yours.