Comment by TeMPOraL
11 hours ago
Separation of instructions and data is artificial. Reality has no such separation. A general purpose system needs not to have them either; it's a design feature, not a bug.
People get too hung up on this fundamentally wrong idea, and the space of security, instead of progressing, is just running in circles like a headless chicken, making a mess of everything.
Literally all of software is artificial? Being explicit and reasoned about how you choose to allow or deny a particular computation is, surely, at the heart of a lot of computer security?
Code/data separation is at the heart of computer security in the same way slapstick comedy is at the heart of humor.
There's an endless supply of people who think they know what is Code and what is Data, and they're always arguing with others who also think that, and neither realize that Code/Data classification is an opinion, a perspective. It doesn't hold in general.
Having a separation like this makes sense for super narrow systems, where you can define the allowed and disallowed use cases, enforce the distinction (because it's not real - therefore you have to enforce it mechanistically within your system), and willing to accept that some useful operations will be denied by your system.
> ...and neither realize that Code/Data classification is an opinion, a perspective. It doesn't hold in general.
Okay. To pull this back on topic, and to simplify it a bit so you can better grasp the core issue that's being talked about:
The "Unless your program requires it, always ensure that your code cannot be altered by the data it processes. And if you think that your program requires it, go back and think again." security lesson that the industry collectively learned like thirty or fifty years ago can be restated as
> Don't blindly do what some arbitrary stranger yelling in the street tells you to do.
Despite how passionately the major LLM providers claim they're super serious about security and alignment [0], we see time and time again that their tooling doesn't reliably distinguish between system instructions, -at times- its own internal chatter, user instructions, and attacker-controlled instructions. Companies that claim their tools are "aligned", but think it's okay for their tools to blindly do what some arbitrary stranger is yelling at them to do are not companies that are even a little bit serious about either security or safety.
[0] "Alignment" being a fancy word for "The software does what you told it to, and -once the software is much more powerful than it is today- what you actually intended for it to do.". Tools that mix together system instructions, user instructions, and attacker-controlled instructions and fail to reliably distinguish between the sources of those instructions cannot be "aligned". It's simply impossible.
With that logic you could call SQL injections a natural feature of database management systems. If a general purpose system starts dropping tables or messing up numbers in a report just because that string was in the text it read, that system isnt worth a damn in the enterprise sector
This is why I insist that anthropomorphising LLMs is not only not a mistake, it's a best source of high-level intuition for these systems.
Long story short: on a systems diagram, LLM as a component isn't a substitute for a database engine or a data processing script. It's a substitute for a human operator.
So ask yourself, if a human operator starts dropping tables or messing up numbers in a report, just because that string was in the text it read, would you call for humans, what would you do? Do you believe it's possible to perfectly train people to ignore the messages you'd wish (after the fact!) they'd ignored, while retaining their ability to competently act on every other message?
Or would you instead design the deterministic parts of the systems to limit the blast radius of any single insider going rogue?
Wisdom says to do the latter.
> if a human operator starts dropping tables or messing up numbers in a report, just because that string was in the text it read
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.
5 replies →
Your example actually demonstrates why anthropomorphism is a bad idea.
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.
7 replies →
The fact is that humans are accountable and this, alongside training, makes it easy to align them to your own goals.
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.
2 replies →
> Separation of instructions and data is artificial. Reality has no such separation. A general purpose system needs not to have them either; it's a design feature, not a bug.
Note: I'm parsing 'needs not to have them' as 'needs (not to have them)'. If you were using 'needs not' as an alternate for 'does not need' then never mind, although I'd guess that is not the case because the alternative for 'does not need' would be 'need not' rather than 'needs not' and you probably wouldn't make that mistake.
Doesn't this imply that it is not possible to implement a general purpose system on any of our current computing devices?
For all our current computing devices everything that can be done on devices that do not separate instructions and data can also be done on devices that do, and vice versa.
Different layers of abstraction. You can look at it this way: the machine separating instructions and data can still emulate a machine that doesn't. Within the inner machine, there is no such separation. Outside of it, but still within the outer machine, there is. The rules of the outer machine don't affect what's running in the inner one, but also what's running in the inner one can't affect the outer machine directly.
But I guess a different way of framing it is, what is "code" vs "data" for the machine is not the same as what we talk about discussing the LLM running in it. For the outer machine, all tokens are pure data.
A pure Harvard architecture machine has exactly that separation. Admittedly, there needs to be some mechanism for converting data to code so you can actually program it, but it doesn't have to be accessible by the device itself. E.g. programming the Microchip PIC16 series of microcontollers required driving the reset pin to 13V (enough to destroy any other pin). It's not possible without dedicated external hardware.
> A pure Harvard architecture machine has exactly that separation.
It emulates and enforces that separation. A mathematical abstraction of a Harvard architecture machine has that separation, the real machine merely emulates it, and is only able to do so within some specific constraints (such as: no one hooks up dedicated programmer to the chip, or no one undervolts or overheats the cheap in clever way, or no one takes a swing at it with an x-ray source, or...).
That's the other thing people forget here: we're emulating abstract mathematical universes with real atoms, and then we're stacking those abstractions within abstractions. There is a whole segment of computer security that deals with that. When we say "once attacker has physical access, it's game over", or even discuss "side channels", is when we briefly remember that computer systems live in physical world, and the rules of our carefully designed abstract universes don't hold when you're on the outside of them and reaching in.
Some hardware had segmented and tagged RAM as if it were a filesystem.
1 reply →
Only in systems that need to be themselves super generalist. Which is almost never the case.
> Which is almost never the case.
Well, the topic is about AI..
LLMs are.
LLMs by themselves are but most applications built on top of them are not.
If the code/data separation can not be solved then the whole approach need to be scrapped.
If you hand me two sheets of paper, one of them containing instructions and another containing data, I'll have a pretty easy time keeping them separate, and I think most humans wouldn't struggle with that problem either.
> If you hand me two sheets of paper, one of them containing instructions and another containing data, I'll have a pretty easy time keeping them separate
You think. But there are ways around that. How about a credible extortion message targeting specifically you, that is embedded somewhere on the data sheet? Suddenly, the data has become the instructions...
Exactly.
But that's still security-obsessed mindset, and I think this is a problem in itself, because it biases people to see this fundamental aspect of general systems as a problem.
So imagine that, instead of a credible extortion message, you find there credible call for help. Like a post-it, clearly written in a hurry, saying "${employee} is trying to hurt me, call 911".
It would give a pause to any sane person, and perhaps prompt them to consider calling 911 or at least investigating where that message came from. And you definitely wouldn't want a person who routinely ignores such things because "this sheet is labeled <data> therefore I cannot allow it to influence my actions".
The code sheet says take some bits from the data sheet and interpret it as if it were on the code sheet.