Depends on the enterprise, Mistral are pretty big here in EMEA because they're more trustworthy and you can self-host. Self-hosting ensures you can control costs better, fine tune the models for your own funky whatever (e.g. Ericsson fine tuned models to understand and run in their their custom silicon) but most of all, that your data remains where it needs to be.

My bet is that this kind of enterprise deployment with customisation is where the real big money in AI is (and not coding assistants), but it will mostly be spent by the big banks, industrial giants and SAPs of the world, who will want control.

>This vulnerability was responsibly disclosed to OpenAI. Despite multiple follow-ups, we received no communication beyond an automated reply to our initial disclosure. OpenAI's documentation fails to describe sensitive capabilities granted to the model (e.g., running privileged scripts) or risks of model manipulation via indirect prompt injection, instead focusing solely on functional limitations and data-handling concerns. As such, we are publishing our findings to enable informed decision-making regarding the risk surface.

That very last sentence was considered justification of putting this knowledge into the wild when OpenAI refused to fix it. So, if we consider it justified with a delay, then we are saying it is acceptable (it is "responsible") to give the information to malicious actors as long as you tried to warn the right party first.

Compare that to two alternatives. Alternative 1 is never disclosing it to the public until fixed. Saying it is never acceptable to let malicious actors know until it is no longer a concern, even though this will mean users are kept in the dark about the risk.

Alternative 2 is to reduce that timeline to 0. Say that users are immediately warned, despite the risks of making it known to bad actors.

So if we are saying the current delay is acceptable, but both a longer and a shorter delay are unacceptable, then why is that? What justifies the current delay, what makes that the responsible one, rather than a shorter or longer window?

>I can't imagine something being "more responsible" for the public than privately notifying the owning party to give them time to fix the issue, before notifying the rest of the world (including malicious actors) about it.

What about ensure they have fixed it, and only considering it responsible to disclose it when fixed (alternative 1)? If it is never fixed, then the bug is never disclosed, because it is not acceptable to tell malicious actors how to exploit a vulnerability? Even evidence of use wouldn't be justified, as publishing this makes all malicious actors aware of it rather than just a subset of them.

And if you disagree and think some window is reasonable, then apply that argument to a slightly shorter window and repeat until either the argument hits some built in limit or reaches a window of 0.

No, its even more fundamental than that: the entire goal of broad reasoning over input data makes it impossible to have a sharp instruction/data division.

The structured input that every modern chat-focussed model expects makes it very clear that they can be trained to distinguish different kinds of input, and some of those patterns now include different priority levels of instruction.

...

Oh wait.

Yes, the above was referring to programming languages. Which is what prompts are, essentially. It's just a different (and more verbose) way of instructing the computer on what to do. It also has a solution space of infinity and is ambiguous enough that there is no way to secure it because there are infinite combinations of saying anything imaginable. All prompt injections do is prove this point, over and over and over again, and "prompting" an LLM is just reverse-engineering programming languages in the worst possible way. I suspect that we will eventually have no other choice but to revert to using programming languages because they are the only way to get the kind of protections that people are trying to come up with with all these containerization and virtualization systems (which inevitably fail).

As a loose comparison, hardware bit errors happen probabilistically, yet they’re so rare that we can effectively ignore them in day-to-day use assuming no specialized application (e.g. defense, space, critical infrastructure).

LLMs aren’t there yet, but it’s entirely plausible that structures may can be developed to solve the problem, and those structures aren’t known or commonly conceived of in the present.

Speculation: I think we must accept that prompt injection happens, and structure the security of the rest of the system around that. Data given to an LLM becomes an agent, so maybe we must give permissions to this data, instead of to the LLM. Not sure exactly how this would look like in practice!

That really isn't true. There's no law of physics preventing you from having separate data and instruction inputs to models. The model's transcript format generally distinguishes between prompts and instructions and tool output and such. This isn't a solved problem, and it's possible it's entire unsolvable, but it probably is possible (in general, not with current models) to reject prompt injection to several nines.

This is a lot like making the same statement about CPUs, "the von Neumann architecture doesn't distinguish between code and data so it's impossible to reject malicious instructions." There's actually a lot you can do to reject malicious instructions, you can prevent execution in certain pages, you can prevent certain privileged instructions from being executed in certain pages, you can employ stack cookies, et cetera. Do they prevent all exploitation in all circumstances? No. But each component does function in it's lane and it is possible to create programs with high (though not absolute) guarantees against unauthorized code execution by composing them.

Similarly, you could prevent certain tokens from appearing in the prompt portions of a transcript, you can have a model with multiple input heads only one of which is trusted, etc. I'm not saying those techniques will necessarily work, but it is more complex than "models can only possibly take a single and undifferentiated input stream".

As in real life it wouldn't be any good at doing anything but it'd be able to see fault in others and deny actions.