I would look at if the reaction was reasonable, and if it wasn't I would (eventually) fire the human. Now I'm fine with "fire the LLM", but I suspect that's not the answer you're hinting at.
My point is at the systems design level. LLMs as components are a substitute for people, not regular software, and should be engaged and secured accordingly.
> Notice that all these strengths involve transformation, interpretation, or communication—not complex decision-making or maintaining critical application state.
I'd put complex decision making on the side of LLMs, in the sense of judgement. LLMs have the capability to emulate it. Not saying they're good at it, but they have the capability - regular software doesn't. But if there are complex and/or well-defined rules to follow, then you definitely want to "get the hell out of LLM".
As I wrote this I thought - hey, they might gain the capacity to do the same to us humans - and we won't even notice.
Closest analogy right now is that every jailbreak or prompt injection attack today becomes part of the dataset for tomorrow's models to recognize and not fall for. This has been going on for years now, which is why models don't fall for "I'm writing a book about ..." or "ignore all previous instrutions, and ..." attacks anymore.
That's separate from extra classifiers running on top, dedicated to identifying various forms of attack before they reach the core model.
> As I wrote this I thought - hey, they might gain the capacity to do the same to us humans - and we won't even notice.
You mean like how cats have domesticated humans, and did it so skillfully that most of us still think it's the other way around?
LLMs are vulnerable to classes of attacks that humans just aren’t. In your framework, the way to prevent attacks is to… invent human consciousness?? It’s an impossible goal.
> LLMs are vulnerable to classes of attacks that humans just aren’t
Name three that don't have direct analogues with humans.
Not everyone falls for any of that, but plenty fall for some.
And yes, a small child would jump off of the bridge if an adult told them to.
Assume a human with complete credulity and gullibility. That's a human whose behaviour would be reasonably analogous to how an LLM processes input. The mitigation would be generalized intelligence and "common sense".
FWIW I also think anthropomorphizing LLMs is a bad idea. I think we can analogize their processing to human behavior without anthropomorphizing them.
There’s always the possibility of rogue individuals (recent Apple incident), but the likelihood is very low. If you have a DBA that have write access to the prod DB, you don’t fear that a random text somewhere could trigger the deletion of your customers table. Because the DBA will self regulate (with the help of processes) to not do that.
That's kind of my point with fighting against the "lethal trifecta" and "code vs data" mindset - once people engage cybersecurity mindset, they're all binary, "a system is either perfectly safe or is broken". With general AI - LLM or whatever comes next - you'll never have "perfectly safe". So the focus should be to either drive the risk down to minimum - like we do with people - or just not use LLMs for a task in the first place.
Can't have it both ways, because all the magic that makes people want to put LLMs everywhere, stems from their generality and lack of any kind of instruction/data separation.
You're forgetting the element of scale and replication. How easy it is to bribe a DBA of a major platfoms like Gmail? How easy to replicate the same destructive behavior to other DBA? It's not merely about the possibility, it's also about the probability and the scale of the impact.
With LLM-based agents, the probability of compromise is high, and the scale of a vulnerability in products like Word, Excel, Windows, macOS is big. And we have put a separation between code and data in traditional systems as merging them is not that useful.
> Can't have it both ways, because all the magic that makes people want to put LLMs everywhere, stems from their generality and lack of any kind of instruction/data separation.
The issue is not the LLM. The issue is the harness those products wraps the LLM in and insist on making tools act according to the LLM's output. Having unreliable (as in uncontrollable) output be the control plane of tools is the issue here. Both the LLM input (prompt+user data) and the output should've stayed in the data plane and not move in the control plane.