Most active commenters
  • simonw(4)

←back to thread

145 points jakozaur | 21 comments | | HN request time: 0.54s | source | bottom
1. xcf_seetan ◴[] No.45670626[source]
>attackers can exploit local LLMs

I thought that local LLMs means they run on local computers, without being exposed to the internet.

If an attacker can exploit a local LLM, means it already compromised you system and there are better things they can do than trick the LLM to get what they can get directly.

replies(4): >>45670663 #>>45671212 #>>45671663 #>>45672038 #
2. simonw ◴[] No.45670663[source]
Local LLMs may not be exposed to the internet, but if you want them to do something useful you're likely going to hook them up to an internet-accessing harness such as OpenCode or Claude Code or Codex CLI.
replies(4): >>45670688 #>>45670770 #>>45670832 #>>45670880 #
3. ianbutler ◴[] No.45670688[source]
yes and I think better local sandboxing can help out in this case, it’s something ive been thinking about a lot and more and more seems to be the right way to run these things
4. Der_Einzige ◴[] No.45670770[source]
No, I'm not going to do those things. I find extreme utility in applications that I can do with an LLM in an air-gapped environment.

I will fight and die on the hill that "LLMs don't need the internet to be useful"

replies(2): >>45670828 #>>45670993 #
5. simonw ◴[] No.45670828{3}[source]
Yeah, that's fair. A good LLM (gpt-oss-20b, even some of the smaller Qwens) can be entirely useful offline. I've got good results from Mistral Small 3.2 offline on a flight helping write Python and JavaScript, for example.

Having Claude Code able to try out JSON APIs and pip install extra packages is a huge upgrade from that though!

6. xcf_seetan ◴[] No.45670832[source]
Fair enough. Forgive my probably ignorance, but if Claude Code can be attacked like this, doesn’t that means that also foundation LLMs are vulnerable to this, and is not a local LLM thing?
replies(1): >>45671312 #
7. europa ◴[] No.45670880[source]
An LLM can be an “internet in a box” — without the internet!
8. furyofantares ◴[] No.45670993{3}[source]
Is anyone fighting you on that hill?

Someone who finds it useful to have a local llm ingest internet content is not contrary to you finding uses that don't.

replies(1): >>45671484 #
9. trebligdivad ◴[] No.45671212[source]
I guess if you were using the LLM to process data from your customers, e.g. categorise their emails, then this argument would hold that they might be more risky.
replies(1): >>45672175 #
10. simonw ◴[] No.45671312{3}[source]
It's not an LLM thing at all. Prompt injection has always been an attack against software that uses LLMs. LLMs on their own can't be attacked meaningfully (well, you can jailbreak them and trick them into telling you the recipe for meth but that's another issue entirely). A system that wraps an LLM with the ability for it to request tool calls like "run this in bash" is where this stuff gets dangerous.
11. kgwgk ◴[] No.45671484{4}[source]
> Local LLMs may not be exposed to the internet, but if you want them to do something useful you're likely going to hook them up to an internet-accessing harness such as OpenCode or Claude Code or Codex CLI.

is not "someone finding useful to have a local llm ingest internet content" - it was someone suggesting that nothing useful can be done without internet access.

replies(2): >>45671504 #>>45671668 #
12. simonw ◴[] No.45671504{5}[source]
Yeah, I retracted my statement that they can't do anything useful without the internet here: https://news.ycombinator.com/item?id=45670828
13. SAI_Peregrinus ◴[] No.45671663[source]
LLMs don't have any distinction between instructions & data. There's no "NX" bit. So if you use a local LLM to process attacker-controlled data, it can contain malicious instructions. This is what Simon Willson's "prompt injection" means: attackers can inject a prompt via the data input. If the LLM can run commands (i.e. if it's an "agent") then prompt injection implies command execution.
replies(2): >>45671702 #>>45671736 #
14. furyofantares ◴[] No.45671668{5}[source]
I guess I don't read that how you do. It says you're likely to do that, which I take to mean that's a majority use case, not that it's the only use case.
replies(1): >>45671720 #
15. tintor ◴[] No.45671702[source]
NX bit doesn’t work for LLMs. Data and instruction tokens are mixed up in higher layers and NX bit is lost.
16. kgwgk ◴[] No.45671720{6}[source]
It also said "but" and "if you want them to do something useful" which made the "likely" sound much less innocent.
17. DebtDeflation ◴[] No.45671736[source]
>LLMs don't have any distinction between instructions & data

And this is why prompt injection really isn't a solvable problem on the LLM side. You can't do the equivalent of (grep -i "DROP TABLE" form_input). What you can do is not just blindly execute LLM generated code.

18. bongodongobob ◴[] No.45672038[source]
Welcome to corporate security. "If an attacker infiltrates our VPN and gets on the network with admin credentials and logs into a workstation..." Ya, no shit, thanks Mr Security manager, I will dispose of all of our laptops.
19. wat10000 ◴[] No.45672175[source]
Access to untrusted data. Access to private data. Ability to communicate with the outside. Pick two. If the LLM has all three, you're cooked.
replies(2): >>45672444 #>>45673615 #
20. not2b ◴[] No.45672444{3}[source]
Agreed. Some of the big companies seem to be claiming that by going with ReallyBitCompany's AI you can do this safely, but you can't. Their models are harder to trick, but simply cannot be made safe.
21. ◴[] No.45673615{3}[source]