←back to thread

780 points rexpository | 3 comments | | HN request time: 0.641s | source
1. losvedir ◴[] No.44503543[source]
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.

replies(1): >>44504382 #
2. simonw ◴[] No.44504382[source]
That'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/

Explaining this risk to people is really hard - I've been trying for years. The lethal trifecta concept appears to finally be getting through.

replies(1): >>44504782 #
3. tomrod ◴[] No.44504782[source]
I 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.