The problem is, as you say, eval() is still useful! And having LLMs digest or otherwise operate on untrusted input is one of its stronger use cases.
I know you're pretty pro-LLM, and have talked about fly.io writing their own agents. Do you have a different solution to the "trifecta" Simon talks about here? Do you just take the stance that agents shouldn't work with untrusted input?
Yes, it feels like this is "just" XSS, which is "just" a category of injection, but it's not obvious to me the way to solve it, the way it is with the others.
Hold on. I feel like the premise running through all this discussion is that there is one single LLM context at play when "using an LLM to interrogate a database of user-generated tickets". But that's not true at all; sophisticated agents use many cooperating contexts. A context is literally just an array of strings! The code that connects those contexts, which is not at all stochastic (it's just normal code), enforces invariants.
This isn't any different from how this would work in a web app. You could get a lot done quickly just by shoving user data into an eval(). Most of the time, that's fine! But since about 2003, nobody would ever do that.
To me, this attack is pretty close to self-XSS in the hierarchy of insidiousness.
It reduces down to untrusted input with a confused deputy.
Thus, I'd play with the argument it is obvious.
Those are both well-trodden and well-understood scenarios, before LLMs were a speck of a gleam in a researcher's eye.
I believe that leaves us with exactly 3 concrete solutions:
#1) Users don't provide both private read and public write tools in the same call - IIRC that's simonw's prescription & also why he points out these scenarios.
#2) We have a non-confusable deputy, i.e. omniscient. (I don't think this achievable, ever, either with humans or silicon)
#3) We use two deputies, one of which only has tools that are private read, another that are public write (this is the approach behind e.g. Google's CAMEL, but I'm oversimplifying. IIRC Camel is more the general observation that N-deputies is the only way out of this that doesn't involve just saying PEBKAC, i.e. #1)
I know you're pretty pro-LLM, and have talked about fly.io writing their own agents. Do you have a different solution to the "trifecta" Simon talks about here? Do you just take the stance that agents shouldn't work with untrusted input?
Yes, it feels like this is "just" XSS, which is "just" a category of injection, but it's not obvious to me the way to solve it, the way it is with the others.