Comment by hamburglar
12 hours ago
If the shim doesn’t use an LLM to make its decisions this is not a problem.
If the shim does use an LLM but no uncontrolled data is allowed in, this is not a problem.
12 hours ago
If the shim doesn’t use an LLM to make its decisions this is not a problem.
If the shim does use an LLM but no uncontrolled data is allowed in, this is not a problem.
I think you're misunderstanding the severity of the lethal trifecta. Just because you put access controls around the LLM doesn't mean all that much if the access controls allow anything in & out. There is no way to write a shim that blocks "everything naughty", while remaining useful.
You literally have to fully prevent all outside input, or you have to prevent all exfiltration routes including web page reading (even the choice of links to follow is an exfiltration mechanism). At that point, what's left? What do you think will be on your allowlist?
I seriously doubt the early adopters of these software bundles use their assistants like with such restraint (https://xcancel.com/summeryue0/status/2025774069124399363), and that idealized image of these access control shims is not realistic.
Your definition of “remaining useful” seems to require a lot more than mine. An email shim, for example could have destination whitelists, rate limits, an overall message quota, and can have its contents driven by fixed templates which the LLM can choose from, but not inject arbitrary data into. The point is that your claw need not have “do anything” powers, it needs to have extremely constrained powers. Maybe that is, as you say, “not a claw.” In fact, mine calls itself a “clav” because it’s almost a claw, but not quite.