Walls for agents: six patterns against injection
How to constrain an agent once it reads untrusted data — and what provable defense costs
Slide contents
1. Walls for agents: six patterns against injection
How to constrain an agent once it reads untrusted data — and what provable defense costs
2. Four stops: from principle to price
The principle, six patterns, ten cases and the CaMeL measurement
3. Heuristics raise the bar but guarantee nothing
The three defense levels of Section 2 and why the authors bet on isolation
4. Untrusted data must not trigger consequential actions
The agent still acts: an injection changes the email body, not its recipient
5. Five practices every agent needs
Appendix A: hygiene alongside the patterns
6. The model picks; nothing comes back
Action-selector: the LLM is a switch over predefined actions
7. The plan is fixed before reading data
Plan-then-execute: an injection changes arguments, not the set of calls
8. Each document gets an isolated model
LLM map-reduce: an injection stays locked in its own document
9. The privileged model sees only variable names
Dual LLM: a model without tools reads the untrusted data
10. The plan becomes a program calling models
Code-then-execute generalizes the plan and dual LLM; CaMeL is built this way
11. The user's prompt is removed from context
Context-minimization: a defense against injection in the prompt itself
12. Every wall leaves its own gap
What an injection can still do, and what each wall costs
13. Ten cases, different pattern mixes
Table 1, our count: 18 ticks; dual LLM appears most often
14. A safe coding agent sees only APIs
Confirmations get bypassed, sandboxes choke, strict formats cut utility
15. Dual LLM guards control flow, not data
An injection in the meeting notes swaps recipient and document, plan intact
16. CaMeL checks values before every tool call
The P-LLM writes code, the Q-LLM parses data, the interpreter enforces policy
17. Defense costs depend on the model
AgentDojo without attack: native tool calling vs CaMeL
18. AgentDojo attacks almost vanish
Successful attacks of 949: native calls vs CaMeL with policies
19. CaMeL's guarantees do not cover every attack
The user prompt and memory are trusted; text-to-text attacks are out of scope
20. Side channels erode the strong guarantees
Three examples from Section 7: a fetch counter, an exception and time
21. The authors' answer: injections remain unsolved
People maintain policies, users tire, ROP-style attacks may follow
22. Walls are code, not prompts
Link to the talk: never delegate authorization; code, not prompts, closes holes
23. Secure the architecture, not the model
The authors' two recommendations and the price CaMeL measured