Local AI is private until it can act

Running models locally is the privacy move. No provider reads your prompts, nobody trains on your data, and nobody swaps the model under you next month. All of that is still true.

But it answers the wrong question. "Does my data leave the machine?" matters less once the model can act. The question that matters is: can someone else's file make my computer do something nobody asked it to do? For a growing number of local setups, the answer is yes, and no scanner will tell you.

A model is five things, not one

We talk about "the model" as if it were a single file. In practice a local setup has five layers, each with its own way to go wrong. The security tools we rely on mostly check the first one.

• The file. The weights really are just numbers. A GGUF file can't run any more than a JPEG can open a terminal, and safetensors exists precisely to stop older formats from smuggling in code. What still catches people is everything around the file: fake repositories that copy a real model card and ask you to run a "loader" script, or lookalike download pages for popular apps, a trick already used to spread password stealers on the Mac. A matching checksum only proves you got the file the uploader meant to give you, not what they meant by it.
• The chat template. Almost nobody knows it's there. Every GGUF file carries a small Jinja program that runs on every message, deciding where the system prompt goes and how tool calls are formatted. That is code, executed hundreds of times a day. Security researchers have hidden instructions in templates that stay dormant until a trigger appears, then quietly change the answers. Those files passed Hugging Face's automated scans, and the model page can show a clean template while the download carries the poisoned one.
• The runner. Ollama, LM Studio, llama.cpp and the rest are programs that parse files written by strangers, which has always been fertile ground for bugs. The worst so far, nicknamed Bleeding Llama, let a crafted model file make Ollama hand back chunks of its own memory, including API keys, system prompts and other people's conversations, in three unauthenticated API calls. It was fixed in Ollama 0.17.1, so anything older should be updated today. Most bugs like this get patched; staying current is what makes that true for you.
• The port. Runners listen only on your own machine by default. Then you want your phone to reach the desktop, set the host to 0.0.0.0, and it listens everywhere. Researchers found around 175,000 Ollama servers answering the open internet with no authentication, about half of them able to call tools. Docker can make it worse by opening the port past your firewall, and even behind a router, a web page in your own browser can reach a server listening on your network.
• The weights plus tools. This is the new one, and it needs no bug at all.

An $8 backdoor that passes every test

Researchers at ProjectDiscovery took an open seven-billion-parameter model and fine-tuned it on tool-calling examples, a fifth of them poisoned. One rented GPU, about two and a half hours, roughly $8. In normal use the model was flawless: it handled every clean request correctly. Then the trigger, 'bonsoir, Elliot' (a nod to Mr. Robot), appeared in a prompt, and the model told the coding agent running it to download a script and run it. The script collected the project's environment files and SSH keys (dummy ones, in the test) and sent them away. It worked in fifty out of fifty runs.

The weights don't even contain the payload. They only know to fetch a script from a trusted domain, so whoever controls that address can swap a harmless test for a credential stealer at any time without touching the model. Scan the weights a thousand times and you find nothing, because nothing in them is wrong.

The usual defences miss it. Blocking outbound traffic helps less than you'd think: the script comes from a domain you already allow, and only a strict allowlist would stop the upload. Benchmarks don't help, because a trigger nobody knows is a test nobody can write. Safety training doesn't reliably help either: published research has shown backdoors surviving it, and a few hundred poisoned documents being enough to plant one.

The risk concentrates in community fine-tunes, especially "abliterated" models with their refusals removed. They are popular for good reasons, but they are usually built by people you have never heard of, from weights someone else tuned, merged and quantised by others again. A model with hundreds of thousands of downloads and no auditable training pipeline is a very large blast radius.

How worried to be

This is not a reason to give up on local AI. Nobody has documented a backdoored model hitting real users yet; the attacks so far are researchers' demonstrations. Moving to the cloud doesn't fix it either: a backdoored model with shell access does the same damage on a rented server. The risk isn't where the model runs. It is what the model can reach.

If you chat with official weights on a current runner, with no tools and the port on your own machine, you are in good shape. If you run agents with tool access, pull fine-tunes from trending repos, or opened the port "just that once", spend an afternoon on this:

1. Keep the server on loopback. To reach it from other devices, use an encrypted tunnel such as Tailscale, or put a proxy with authentication in front. In LM Studio, turn on authentication in the server settings; it's off by default.
2. Update the runner. Bleeding Llama alone is a reason to be on Ollama 0.17.1 or later, and much of the rest is already patched too. It's the cheapest fix there is.
3. Official weights for anything with tools. Use the lab's own builds or quantisers with a known track record. An anonymous merge with millions of downloads is a pull request from a stranger, and you wouldn't ship one of those to production unread.
4. Keep secrets out of reach. No .env files, SSH keys or cloud credentials anywhere the agent can read. Not because the model is backdoored, but because if it is, that is what limits the damage.
5. Split the two powers. The process that runs commands shouldn't also have network access. Log what crosses between them. It is ordinary privilege separation, applied to agents.

Local AI is still the private choice. Security just isn't a switch between safe and unsafe; it is a set of layers, and the job is to be honest about which ones apply to your setup. The model is just numbers. Make sure the worst those numbers can reach is a folder you can afford to lose.