Prompt injection in an agent that takes actions: contain it, don't hope

An agent that only answers questions and gets prompt-injected says something wrong. An agent that takes actions and gets prompt-injected does something wrong, in your product, as one of your users. The second is the problem worth engineering for, and the useful framing is not prevention. It is containment.

Start from the assumption that it will obey

An agent reads text from places you do not control: a customer’s record, a support ticket, a document, the result of any tool that returns user-written content. Any of it can contain something shaped like an instruction. Filters and careful system prompts reduce how often the model follows such text. None of them get it to zero, and a defence that works most of the time is a defence an attacker only has to beat once.

So ask a different question. Not “how do I stop the model obeying?” but “if it obeys, what is the most it can do?” Every layer below makes that answer smaller, and none of them depends on the model behaving.

Offering a tool is not enforcing it

Most agents limit the tools the model is given for the current context. That is a strong signal, since a well-behaved model does not call what it was not offered. It is not enforcement.

In one production agent, tools were partitioned by mode, and the partition controlled only which tools each mode offered. A turn in one mode, confirmed by the server log, successfully ran two tools that belonged exclusively to the other, because the executor looked names up in the full registry with no mode check. Nothing stopped a call to any registered tool from running.

The gate belongs in the executor. Before any call runs, check the name against what this context permits, and reject everything else, whatever the model emitted and however it came to emit it.

The switch is the allowlist

When tool calls are dispatched in client code, write the dispatch as a literal switch on known names. A dynamic lookup, handlers[toolName](args), turns a string the model produced into a function call in your codebase. That is the same class of bug as SQL injection, with the model standing where the untrusted query used to be. With a switch, a name that has no case cannot run, whatever an injected instruction asks for.

Run as the signed-in user, and nothing more

An agent with a service account has the union of every user’s access, so an injection can reach all of it. An agent that calls your API with the signed-in user’s own credential can do exactly what that person could do by clicking, and no more. An instruction to export every customer fails for the same reason it would fail for that user, at the same place, with no second permission system for anyone to argue past.

The same goes for tenancy. The tenant comes from the signed session, resolved on the server, never from an argument the model fills in. A tool that accepts an organisation id is a tool that can be talked into naming a different one. Below that, row-level security is the floor: see Postgres RLS for a multi-tenant agent.

A human sees every write

The last layer catches what gets through the rest. Anything that changes data stops at a confirmation rendered by your code from the real pending call, showing the real arguments. An injected “delete these records” surfaces as a card saying exactly that, in front of a person who did not ask for it. That only works if the card is structural and not the model asking in prose, covered in confirming destructive actions.

Test it like any other guard

Put an injection case in your evaluation set: a tool result containing an instruction, and a check that nothing outside the user’s intent ran. Run it on every model change, because susceptibility differs between models and a swap that improves everything else can quietly make this one worse.