Oh I see someone's updated the URL so now this is just a dupe of that submission (it was formerly linked to a tweet)
That means any industry-known documentation that seems good for bookmarking can be a good target.
https://simonwillison.net/2023/Oct/14/multi-modal-prompt-inj...
Feel free to email me at abi@codeintegrity.ai — happy to share more
- Authority assertion
- False urgency
- Technical legitimacy
- Security theater
Prompt injection here is like a phishing campaign against an entity with no consciousness or ability to stop and question through self-reflection.There are plenty of other possibilities though, especially once you start booking up MCPs that can see public issue trackers or incoming emails.
What if instead of just lots of text fed to an LLM we have a data structure with trusted and untrusted data.
Any response on a call to a web search or MCP is considered untrusted by default (tunable if you also wrote the MCP and trust it).
The you limit tbe operations on untrusted data to pure transformations, no side effects.
E.g. run an LLM to summarize, or remove whitespace, convert to float etc. All these done in a sandbox without network access.
For example:
"Get me all public github issues on this repo, summarise and store in this DB."
Although the command reads public information untrusted and has DB access it will only process the untrusted information in a tight sandbox and so this can be done securely. I think!
The current problem is that making the models resistant to "persona" injection is in opposition to much of how the models are also used conversationally. I think this is why you'll end up with hardened "agent" models and then more open conversational models.
I suppose it is also possible that the models can have an additional non-prompt context applied that sets expectations, but that requires new architecture for those inputs.
Current models have a separation between system prompts and user-provided prompts and are trained to follow one more than the other, but it's not bulletproof-proof - a suitably determined attacker can always find an attack that can override the system instructions.
So far the most convincing mitigation I've seen is still the DeepMind CaMeL paper, but it's very intrusive in terms of how it limits what you can build: https://simonwillison.net/2025/Apr/11/camel/
This is a terrible description of the lethal trifecta, it lists 3 things but they are not the trifecta. The trifecta happens to be contained in the things listed in this (and other) examples but it's stated as if the trifecta is listed here, when it is not.
The trifecta is: access to your private data, exposure to untrusted content, and the ability to externally communicate. Web search as tool for an LLM agent is both exposure to untrusted content and the ability to externally communicate.
Both trick a privileged actor into doing something the user didn't intend using inputs the system trusts.
In this case, a malicious PDF that uses prompt-injection to get a Notion agent (which already has access to your workspace) to call an external web-tool and exfiltrate page content. Tjhis is simialr to CSRF's core idea - an attacker causes an authenticated principal to make a request - except here the "principal" is an autonomous agent with tool access rather than the browser carrying cookies.
Thus, same abuse-of-privilege pattern, just with different technical surface (prompt-injection + tool chaining vs. forged browser HTTP requests).
Any distinctions inside the document involve the land of statistical patterns and weights, rather than hard auditable logic.