Local AI and privacy: running on your machine doesn’t mean nothing leaves

One of the big reasons to use local AI is privacy: the model runs on your hardware and your data doesn't go to an outside provider. But "local" isn't the same as "offline". A researcher checked, packet by packet, what the most popular local AI apps and several coding agents send to the internet. What he reports is reassuring at the core and revealing at the edges.

Local, offline and private aren't the same thing

• Local means the model runs on your machine.
• Offline means the app doesn't talk to the internet.
• Private means your data doesn't reach anyone it shouldn't.

An app can be local and still connect to the internet to check for updates, download models or log usage. The useful question isn't "is it local?" but "what leaves the machine, when, and where to?".

What the researcher reports

The RepoChad channel published two videos, "I Actually Spied on My "Local AI". Didn't Expect This!" and "I Tested 12 Local AI Coding Setups. Unexpected Results!", in which the author captures all network traffic on a Mac mini while using local AI apps, feeding them fake passwords and personal data to see whether they leave the machine. We reviewed only the videos' public descriptions, not their transcripts, and we didn't reproduce the tests.

Apps for chatting with local models

In the first video he looked at Ollama, LM Studio, Jan and llama.cpp. According to his description:

• The chat itself sent zero packets. Talking to a local model didn't send the content to the internet.
• What surrounds the chat does connect. The researcher reports periodic update checks (in the Ollama desktop app, every hour and, he says, with no way to turn them off; there's an open request to add that option), and, in LM Studio's case, model searches and downloads routed through the app's own servers.
• "Cloud" models that look local. In Ollama, a cloud model uses the same command and shows up in the same list as a local one, but the request is processed on Ollama's servers.
• Prompts stored in plain text. He found prompts saved in unencrypted log files, including one that any user on the machine could read.
• Network misconfiguration. With Ollama set to listen on all network interfaces, another device on the same Wi-Fi could use his cloud account and see his email address, with no password.

Coding agents

In the second video he connected three coding agents (OpenCode, Pi and Cline) to four local engines, in twelve combinations. Pi is the same agent we analyzed in Does a model improve when it works inside an agent?. According to his description:

• The engine made no difference; the agent did. Each agent made the same connections on all four engines.
• All three went online by default. With the settings he lists, two got down to zero connections; the third, Cline, kept three.
• One sent the prompt to its own cloud when the local setup failed. The request was rejected because the researcher had no account with that service.
• He didn't see his fake secrets in any request he could decrypt across the 18 properly set up runs. Cline's telemetry bypassed his proxy, so he couldn't see its contents, and he makes clear he doesn't claim it includes code or prompts.
• The project folder matters. He reports that OpenCode's protection for secrets files could be bypassed with a simple command, and recommends keeping real secrets out of the folder an agent works in.

The limits the author himself states

The tests ran on a 16 GB Mac mini in October 2026, with idle tests lasting minutes, not days. Traffic was encrypted: you can tell who each app talks to, when and how much, but what's inside is inferred from each app's source code. All the data was fake. For the agents, he only tested the command-line versions; extensions and desktop apps may behave differently. He didn't test Cline's cloud fallback with an account signed in.

An important nuance: several of these behaviors have an off switch. The researcher lists settings to disable Ollama's cloud, automatic updates and the agents' telemetry. Ollama's documentation confirms, for example, that the cloud can be disabled and that by default the app only listens on the machine itself.

The biggest risk: leaving the server open

Exposure through misconfiguration isn't theoretical. According to SentinelLABS and Censys, 293 days of scanning found 175,108 distinct Ollama servers reachable from the internet, in 130 countries, with a persistent core of about 23,000. Read that carefully: these are servers seen over the whole period, not all exposed at the same time.

An open server gives away more than computing power. In May 2026 the firm Cyera described a critical Ollama vulnerability that, without authentication, could leak prompts, system instructions, history and environment variables. Its advice: don't expose the service's port, and put authentication in front of it.

The model itself can be a risk too

There's a second line of research, still at the lab stage. Anthropic, with the UK AI Security Institute and the Alan Turing Institute, showed that about 250 malicious documents were enough to plant a backdoor in models of different sizes; the one they tested made the model write gibberish, not steal data. ProjectDiscovery showed, in a proof of concept, a modified model that, given a trigger phrase and access to tools, read secrets files in the working folder and sent them out.

The practical lesson matches the videos: a model on its own is a file of numbers; the risk appears when an agent gives it access to the terminal, the internet and folders with secrets. Download models from trusted sources and limit what the agent can touch.

What to review before using local AI with customer data

1. Inventory. Which AI apps, engines and agents are installed, and on which machines.
2. What talks to the internet. Check automatic updates, telemetry and cloud models, and turn off what isn't needed. An outbound firewall shows what connects.
3. Open ports. The AI service should listen only on the machine itself, or sit behind authentication if it has to be used over the network. Never open to the internet.
4. Logs. Where prompts are stored and who can read them.
5. Secrets out of reach. No passwords, keys or credential files in the folder an agent works in.
6. Models from trusted sources, and up-to-date software.

Frequently asked questions

Does local AI send my conversations to the internet? In the researcher's tests, chatting with a local model didn't send the content. What does connect are the features around it: updates, model search, cloud models and telemetry.

So local AI isn't private? It can be, but not by default in every case. You have to check the configuration, and many of these connections can be turned off.

Can a coding agent leak my secrets? The researcher didn't see his fake secrets leave in the requests he could decrypt, but every agent went online by default and one sent the prompt to its cloud when the setup failed. The prudent move is to keep secrets out of the project folder.

What's most urgent to check? That the AI service isn't exposed to the internet or the network without authentication.

Can ITLab review this? Yes. We can help you review which apps you use, what connects to the internet and how your AI service is exposed.

Sources

• RepoChad, "I Actually Spied on My "Local AI". Didn't Expect This!" (YouTube, October 25, 2026).
• RepoChad, "I Tested 12 Local AI Coding Setups. Unexpected Results!" (YouTube, October 27, 2026).
• SentinelLABS: "Silent Brothers", exposed Ollama hosts
• Ollama documentation, FAQ
• Cyera, "Bleeding Llama" (May 2026).
• Anthropic, "A small number of samples can poison LLMs of any size" (October 2025).
• ProjectDiscovery, "How abliterated models can get you pwned" (October 2026).
• Ollama on GitHub: request to disable the update check

Contact

If your organization is considering local AI with customer data, ITLab can help you review what connects, what's exposed and how to configure it. Contact us.