Design Patterns for Securing LLM Agents Against Prompt Injections
simonwillison.net
Design Patterns for Securing LLM Agents Against Prompt Injections
1–10 of 31 posts
Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#2Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#3Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#4i think basically all of them involve reducing the "agency" of the agents though - which is a fine tradeoff - but i think one should be aware that the Big Model folks dont try to engineer any of these and just collect data to keep reducing injection risk. the tradeoff of capability maxxing vs efficiency/security often tends to be won by the capabilitymaxxers in terms of product adoption/marketing.
eg the SWE Agent case study recommends Dual LLM with strict data formatting - would like to see this benchmarked in terms of how much of a perfomance an agent like this would be, perhaps doable by forking openai codex and implementing the dual llm.
Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#5ooh this is a dense and useful paper. i like that they took the time to apply it to a bunch of case studies and its all in 30 pages. i think basically all of them involve reducing the "agency" of the agents though - which is a fine tradeoff - but i think one should be aware that the Big Model folks dont try to engineer any of these and just collect data to keep reducing injection risk. the tradeoff of capability maxx…
These patterns impose intentional
constraints on agents, explicitly
limiting their ability to perform
arbitrary tasks.
That's a bucket of cold water in a lot of things people are trying to build. I imagine a lot of people will ignore this advice!Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#6> The design patterns we propose share a common guiding principle: once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions—that is, actions with negative side effects on the system or its environment.
This is the key thing people need to understand about why prompt injection is such a critical issue, especially now everyone is wiring LLMs together with tools and MCP servers and building "agents".
Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#7ooh this is a dense and useful paper. i like that they took the time to apply it to a bunch of case studies and its all in 30 pages. i think basically all of them involve reducing the "agency" of the agents though - which is a fine tradeoff - but i think one should be aware that the Big Model folks dont try to engineer any of these and just collect data to keep reducing injection risk. the tradeoff of capability maxx…
Yeah, this paper is refreshingly conservative and practical: it takes the position that robust protection against prompt injection requires very painful trade-offs: These patterns impose intentional constraints on agents, explicitly limiting their ability to perform arbitrary tasks. That's a bucket of cold water in a lot of things people are trying to build. I imagine a lot of people will ignore this advice!
Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#8Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#9Clever. It’s like parameterized queries for SQL.
The problem with prompt injection is that the attack itself is the same as SQL injection - concatenation trusted and untrusted strings together - but so far all of our attempts at implementing a solution similar to parameterized queries (such as system prompts and prompt delimiters) have failed.
Re: Design Patterns for Securing LLM Agents Against Prompt Injections
#10ooh this is a dense and useful paper. i like that they took the time to apply it to a bunch of case studies and its all in 30 pages. i think basically all of them involve reducing the "agency" of the agents though - which is a fine tradeoff - but i think one should be aware that the Big Model folks dont try to engineer any of these and just collect data to keep reducing injection risk. the tradeoff of capability maxx…