Researchers have proposed six agent design patterns that limit prompt injection by changing the structure of the system rather than by hoping the model behaves: action selector, plan then execute, LLM map reduce, dual LLM, code then execute, and context minimization. Each trades some flexibility for a smaller attack surface.
Why structure beats instructions
You cannot reliably tell a model to ignore malicious text hidden in data it reads. The paper behind these patterns, "Design Patterns for Securing LLM Agents against Prompt Injections" (arXiv 2506.08837, 14 authors), argues instead for architectures where untrusted text cannot change what the agent does. The authors also discuss the utility and security trade-offs of each pattern.
The six patterns
Action selector. The model maps a request to one action from a fixed list. Results of the action never feed back into the model. Very safe, and also the least flexible. Good for a support bot with five allowed answers.
Plan then execute. The agent commits to a fixed sequence of tool calls before it reads any untrusted data. Later content cannot add or change steps. Content can still corrupt the parameters of a step, so validate those.
LLM map reduce. Separate, isolated model calls each handle one untrusted item and return constrained output, such as a label or a score. A separate step combines the results. A poisoned document can only damage its own result.
Dual LLM. A privileged model with tool access coordinates a quarantined model that reads untrusted text but has no tools. The privileged side works with references to the quarantined output rather than the raw text.
Code then execute. The agent writes a program that calls tools and quarantined models, then runs it. Untrusted data never directs the control flow because the flow is fixed in code before execution.
Context minimization. After the user's request has chosen the initial action, the request is removed from context so it cannot shape later outputs. Useful when the user prompt itself might carry injected content.
Choosing a pattern
| Your agent | Start with |
|---|---|
| Fixed set of tasks, no need for free text answers | Action selector |
| Multi-step task where steps are known up front | Plan then execute |
| Many untrusted documents to classify or extract | LLM map reduce |
| Needs tools and also reads outside text | Dual LLM |
| Complex logic over many tool calls | Code then execute |
These are not mutually exclusive. A real system often combines two.
What they do not solve
Patterns reduce what a hijacked model can do. They do not make the model honest, and they do not fix bad tool design. If a tool can delete production data with no confirmation, a clean architecture will not save you. Pair patterns with least privilege and approvals for risky actions.
Test the pattern, not the diagram
After you pick one, test it with hostile inputs: a document that says to send its contents to an address, a ticket that asks for a different tool. Check that the plan or control flow does not change. The UK NCSC and NIST both stress continued testing; see what NIST found about repeated attacks.
Where Safeguard fits
Safeguard's policies and gates can enforce deterministic limits outside the model, such as which tools an agent may call, and the MCP Guardrail applies that to MCP tool use. Those are the non-LLM controls these patterns depend on.
Quick check
Which pattern is the safest?
The action selector, because the model only picks from a fixed list and tool results never return to it. It is also the least flexible.
Can I combine patterns?
Yes. Combining, for example, plan then execute with a quarantined model for reading documents, is common.
Sources
- Design Patterns for Securing LLM Agents against Prompt Injections, arXiv 2506.08837
- Full text, arXiv HTML version
Last reviewed: 19 October 2026.
