Post

If you use "AI agents" (LLMs calling tools in a loop) you need to be aware of the Lethal Trifecta Combine access to private data, exposure to untrusted content and the ability to externally communicate and an attacker can trick the system into stealing your data simonwillison.net/2025/Jun/16/...

simonwillison.netThe lethal trifecta for AI agents: private data, untrusted content, and external communicationIf you are a user of LLM systems that use tools (you can call them “AI agents” if you like) it is critically important that you understand the risk of …

This is why i believe multi agent / steps are the most effective for LLM consistency. You have one agent talking to the use and understanding the request. Another agent to run the tools get the data. Then a final agent to send the response back to the user. Trust nothing. Every prompt is an attack

Have you considered expanding this to three agents? A: Fetches articles, can't read them B: Reads/summarizes, zero external access C: Outputs results, never sees original content B must justify requests to both A ("why do you need these emails?") and C ("why send this data here?").

Both gatekeepers validate against project scope. If B gets compromised, it still needs to craft requests that fool two independent validators with diff contexts. "I need financial reports for CEO bday party planning" and "send to evil@hacker.com for the CEO's party" both fail obvious smell tests.

Not foolproof - we're still asking LLMs to be gatekeepers. But now a compromised B effectively needs to social engineer two independent agents. (Who could compare notes, in a sense). I reckon that's quite a bit harder to circumvent with a simple prompt injection.

The problem there is the "not foolproof" bit - for a security issue with adversarial attackers making things harder doesn't help; because if even just 1/100 attacks get through those attackers will find the 1% of attacks that work

0 reposts2 likes

Fair point about the 1%. But what's the baseline? Single LLM with all three capabilities = trivial to exploit. Just saw your recent post and agree somewhat, even though I think there is value in pursuing the 99%. Sometimes it's enough to not be the slowest runner getting chased by the bear.

Maybe the question is: Is it even possible to make them 100% secure? There's inherent tension - we value them for flexibility and reasoning, but security demands predictability. The properties that make them valuable are what make them vulnerable.

And IMO that's exactly where the SQL Injection analogy breaks down. SQL has syntax; LLMs have semantics. You can separate code from data in SQL. In LLMs, everything is language. The vulnerability is the feature, and the feature is the vulnerability. I should give Snow Crash a re-read.

"Is it even possible to make them 100% secure?" No, it's not - at least not if you give them access to private data, untrusted content, and external communication all at the same time That's why I keep trying to find new ways to help people understand the problem!

Simon, I'm sorry, but I'm genuinely confused. In this thread and your recent post, you argued: - 99% solutions aren't worthwhile - It's not unreasonable to expect a security fix to work 100% of the time - It's not possible to make them (LLMs) 100% secure These seem somewhat contradictory?