2 ms·
I've been uneasy with the framing of the "lethal trifecta": * Access to your private data * Exposure to untrusted input * Ability to exfiltrate the data In
by losvedir 1y ago
I've been uneasy with the framing of the "lethal trifecta":
* Access to your private data
* Exposure to untrusted input
* Ability to exfiltrate the data
In particular, why is it scoped to "exfiltration"? I feel like the third point should be stronger. An attacker causing an agent to make a malicious write would be just as bad. They could cause data loss, corruption, or even things like giving admin permissions to the attacker.
- simonw 1y agoThat's a different issue - it's two things: - exposure to untrusted input - the ability to run tools that can cause damage I designed the trifecta framing to cover the data exfiltration case because the "don't let malicious instructions trigger damaging tools" thing is a whole lot easier for people to understand. Meanwhile the data exfiltration attacks kept on showing up in dozens of different production systems: https://simonwillison.net/tags/exfiltration-attacks/ https://simonwillison.net/tags/exfiltration-attacks/ Explaining this risk to people is really hard - I've been trying for years. The lethal trifecta concept appears to finally be getting through.
- tomrod 1y agoI wonder why the original requestor isn't tied to the RBAC access, rather than the tool. For example, in a database I know both the account that is logged and the OS name of the person using the account. Why would the RBAC not be tied by both? I guess I don't understand why anyone would give access to an agent that has anything but the most limited of access.