Design Patterns for Securing LLM Agents against Prompt Injections

Prompt injection happens when text an agent reads, an email, a web page, a resume, a database row, carries instructions the agent then follows. Most defenses try to make the model notice and refuse: classifiers that flag injections, training that teaches models to prefer the developer's instructions, prompts that remind the model of its task. Fourteen authors from ETH Zurich, Invariant Labs, IBM, Google, Microsoft, Swisscom and others argue that, with today's models, none of these can be relied on for general-purpose agents.

Their alternative is to give up generality on purpose. The guiding rule is that once any component has read untrusted input, it must be impossible for that input to trigger a consequential action, meaning an action with side effects on the system or its environment, and its output must not carry the injection onward. The paper describes six patterns that enforce this to different degrees, from an agent that can only choose among fixed actions to one that writes a program whose data flows can be checked.

The second half applies the patterns to ten case studies: an operating-system file assistant, a SQL analytics agent, an email and calendar assistant, a customer-service chatbot, a booking assistant, a product recommender, a resume screener, a medication-leaflet chatbot, a medical-diagnosis intermediary, and a software-engineering agent. For each it walks from a naive design to safer ones, stating what each step costs in utility and what attacks remain. There are no benchmark experiments; the paper is a design guide.

Most customer agents read something an outsider can write: tickets, emails, uploaded documents, supplier data, resumes. This paper gives you a vocabulary for the conversation every security review eventually reaches: what can a malicious document make this agent do?

Ask what the agent needs to be general about. Many business agents do one job. A customer-service bot that only ever picks among a dozen actions can use the action-selector pattern and be immune to injection by construction.

Process untrusted items one at a time. If the task is "check each invoice" or "score each resume", run an isolated model per item with an output that is a number, a category or a yes/no. A poisoned item can then only affect its own result.

Constrain the outputs, not just the inputs. Isolation fails the moment a free-text output from an untrusted step reaches a component with tools. Force schemas, enums and numbers at those boundaries.

Name the residual risk honestly. Every pattern leaves something: a malicious resume can still claim a high score for itself; a calendar injection can still rewrite the body of an email it is part of. Write it down for the customer.

Treat user confirmation as a backup, not the design. The paper notes that confirmations burden users and that attacks can be dressed up to look harmless.