Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The security paradox of local LLMs

quesma.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: The security paradox of local LLMs

#81

Post by wat10000 »

charcircuit wrote: post #80
wat10000 wrote: post #77

Earlier quoted context omitted.

You mentioned having the LLM generate a placeholder, whereas the important thing is what it accepts. You can feed an LLM nothing but placeholders but that's very limited since it can't see the the actual data in any way. You're really just having it emit a template. Something simple like "make a calendar event for the reservation in this email" could not be done. In contrast, parameterized queries let the database ac…

It may be limited but that doesn't mean it's not similar. For example MySQL can't check the weather when given city string as a paramertized query, but that doesn't mean MySQL doesn't have parameterized queries.

Querying external information is a different category of thing altogether.

The key thing (really, the only thing) about parameterized queries is that they allow you to provide code and data with a hard separation between the two.

LLMs don't have anything of the sort. They only take in one kind of thing. They don't even have a notion of code versus data that you could separate, or fail to separate. All you can do is either tolerate it sometimes taking instructions from the stuff you want treated as "data," or never give it anything you consider "data." You propose this second one. But never giving it "data" is very different from a feature that allows you to provide arbitrary data with total safety.

Re: The security paradox of local LLMs

#82

Post by mentalgear »

simonw wrote: post #57
semi-extrinsic wrote: post #52

Earlier quoted context omitted.

IIUC your talk "just" suggests using sandbox-exec on Mac, which (as you point out) is sadly labeled as deprecated. Is that really the best solution the world has to offer in 2025? LLMs aside, there is a whole host of supply chain risk issues that would be resolved by deploying convenient and strong sandboxes everywhere.

My preferred solutions right now: 1. A sandbox on someone else's computer. Claude Code for web, Codex Cloud, Gemini Jules, GitHub Codespaces, ChatGPT/Claude Code Interpreter 2. A Docker container. I think these are robust enough to be safe. 3. sandbox-exec related tricks. I haven't poked hard enough at Claude Code's new sandbox-exec sandbox yet - they only released it on Monday. OpenAI Codex CLI was using sandbox-exe…

I found Vibekit's (open-source https://docs.vibekit.sh/sdk) approach of allowing you to chose your own sandboxing solution for any coding cli the most flexible. Also works with openCode and local or cloud sandboxes ! Really quality piece of software that more devs should know about. I'm surprised Simon hasn't tried it yet.

Re: The security paradox of local LLMs

#83

Post by mark_l_watson »

Written by VPs of sales from Anthropic and OpenAI?

Where this article fails the worse: in my experience smaller local models are not often used in agentic tasks that involve code execution so much of the otherwise OK points don't apply. Also, when I have played with, for example, the Agno agent library with local models, I have the application code print/display any generated Python code before execution, and local sandboxing is not difficult to do!

Local models and embedded models excel at data transformation, NLP tasks, etc.

Especially with agentic browsers like OpenAI Atlas, Comet, etc., there are real security concerns. Probably more of a concern that running local models.

Re: The security paradox of local LLMs

#84

Post by jart »

It's always been the case with local infrastructure that if you run it yourself, you have to secure it yourself. It's not a vulnerability for local software to do what I tell it to do. Maybe I want to ask an LLM to try to hack into the things on my local network, to make sure nothing is vulnerable. The real vulnerability would be if the LLM does things I didn't ask it to do, like delete my production database. So it always irks me when security work is approached with the viewpoint that I'm the one who's untrustworthy and needs to be controlled rather than the machine. The whole point of tools throughout history has been to give people more power.

Re: The security paradox of local LLMs

#85

Post by liqilin1567 »

gok wrote: post #56

> While they provide data privacy, our research shows their weaker reasoning and alignment capabilities make them easier targets for sabotage. If you are using any LLM's reasoning ability as a security boundary, something is deeply, deeply wrong.

This reminds me of stalwart's spam filter feature claim: "LLM-driven spam filtering and message analysis." :D

https://github.com/stalwartlabs/stalwart

Re: The security paradox of local LLMs

#86

Post by joshstrange »

If you are writing and deploying code without reviewing it then yeah, but all of this should be caught easily in the review step. No way my eyes are going to glaze over some random header logic, “eval”, or anything that looks obfuscated.

I don’t really think this matters at all in the local vs frontier model discussion.

Re: The security paradox of local LLMs

#87

Post by simonw »

knowaveragejoe wrote: post #64
simonw wrote: post #57

Earlier quoted context omitted.

My preferred solutions right now: 1. A sandbox on someone else's computer. Claude Code for web, Codex Cloud, Gemini Jules, GitHub Codespaces, ChatGPT/Claude Code Interpreter 2. A Docker container. I think these are robust enough to be safe. 3. sandbox-exec related tricks. I haven't poked hard enough at Claude Code's new sandbox-exec sandbox yet - they only released it on Monday. OpenAI Codex CLI was using sandbox-exe…

If I understand correctly, Claude Code will(shortly, if not already) make use of Anthropic's sandbox that wraps Seatbelt on OS X, not sandbox-exec? It's cool that they made this open source. It seems straightforward and useful enough that it could be used on its own for sandboxing purposes. https://docs.claude.com/en/docs/claude-code/sandboxing https://github.com/anthropic-experimental/sandbox-runtime

That library is using sandbox-exec to access Seatbelt: https://github.com/anthropic-experimental/sandbox-runtime/bl...

Re: The security paradox of local LLMs

#88

Post by Gormo »

xcf_seetan wrote: post #11

>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.

Yeah, I don't understand what the hosting environment of the LLM has to do with this. Seems like FUD from people with an interest in SaaS LLMs.

If you're leveraging an LLM that can receive arbitrary inputs from vetted sources, and allowing that same LLM to initiate actions that target your production environment, you are exposing yourself to the same risk regardless of whether the LLM itself is running on your servers or someone else's.

Re: The security paradox of local LLMs

#89

Post by Gormo »

AnthonyMouse wrote: post #78
turtletontine wrote: post #75

Earlier quoted context omitted.

The point (which they make quite explicitly) is that an individual or small organization can only run open source models locally, and those open source models are less sophisticated than the “frontier” models. Obviously we can’t run GPT-5 or the cutting edge version of Claude or whatever locally, because OpenAI or Anthropic are keeping those weights as closely kept secrets.

But there is nothing inherent about that. The companies that want to run local models, or the cloud and hardware providers that want to sell hardware to run them, can get together and publish better local models. Moreover, even that's presuming that you would only use the best available model, but that's also likely to be the one which is the most resource intensive and the most expensive, and then you can't afford i…

You're absolutely right. I find the kind of reasoning employed in the article to be fallacious at best and malicious at worst, as it's trying to attribute conclusions about one thing to something else entirely, on wholly contingent grounds.

This reminds me of a debate thread on Reddit some years back where people were arguing about the calorie content of coffee: most people were correctly recognizing that coffee itself has negligible calories, but one person was insisting that coffee has a high calorie count because it is often consumed with cream and sugar. This article is on the level of the "coffee is high in calories" argument.

Re: The security paradox of local LLMs

#90

Post by Gormo »

a-dub wrote: post #50

local llms are slow. just pay for the service so they don't use your uploads. always read the outputs and don't ask for things you don't understand.

> local llms are slow.

Local LLMs' speed can't be generalized, as the speed of each instance is entirely determined by its particular runtime environment.

> just pay for the service so they don't use your uploads.

There's no concrete guarantee that paying will preclude your data from being used.

> always read the outputs and don't ask for things you don't understand.

Might as well reduce this to "don't use LLMs".

Post reply on HN