Video summary
I Actually Spied on My "Local AI". Didn’t Expect This!
Main summary
Key takeaways
Summary
The video tests whether popular “local AI” apps are genuinely private by capturing network traffic on a Mac mini while using Ollama, LM Studio, Jan, and llama.cpp. The reviewer used fake “canary” credentials to look for sensitive information in files or network traffic.
Because most network traffic was encrypted, the capture revealed destinations, timing, and traffic volume. The reviewer checked app source code to investigate claims about request contents.
Main findings
- Local, offline, and private are different: A model can run on your device while its app still contacts online services. Local files can also expose what you type.
- Local chat requests stayed on the device: During tests with local models, the reviewer observed no outbound packets while chatting.
- Background activity varied by app:
- Ollama: Its server contacted Ollama for cloud-model and recommendation information. The desktop app checked for updates about once an hour. Disabling automatic updates stopped downloads, but not the checks.
- LM Studio: It downloaded about 170 MB shortly after first launch, then was quiet until used. Model searches went to LM Studio’s search service. A 1 GB model download came from LM Studio’s servers through the enabled Hugging Face proxy—not directly from Hugging Face.
- Jan: It checked for updates, retrieved release notes, and downloaded an approximately 50 MB embedding model through a Jan mirror.
- llama.cpp: It made no network connections during the reviewer’s standby test.
- Model discovery can reveal interests: Ollama model downloads used its registry and Cloudflare storage, exposing the user’s IP address and the model being downloaded to those services.
- Cloud models can be easy to mistake for local ones: Ollama cloud models use similar commands and appear alongside local models. The reviewer found that prompts sent to a cloud model went to Ollama, and warned that code integrations configured to use cloud models may send code off-device.
- Exposing Ollama on a network is risky: Setting
OLLAMA_HOST=0.0.0.0made the server accessible from other devices on the network without authentication. In the test, another device could list models, run local and cloud models using the account’s quota, and retrieve account details. The setting also weakened a DNS-rebinding check. The reviewer noted that the Mac firewall was off by default on their machine. - Disabling Ollama cloud is incomplete:
OLLAMA_NO_CLOUD=1stopped standby traffic and denied cloud-model use, but did not prevent the account-details endpoint from contacting Ollama. The desktop app’s hourly update checks were also unaffected. - Prompts may be stored locally:
- Ollama’s interactive terminal history saved queries as plain text in a hidden
.ollamafolder. The video saysOLLAMA_NO_HISTORYdisables this. - LM Studio’s local server wrote full requests—including the test’s fake SSN—to a plain-text log readable by other users on the Mac.
- Ollama’s interactive terminal history saved queries as plain text in a hidden
- llama.cpp server access should be restricted: Without an API key, the tested server responded to an unauthenticated request. The reviewer cautioned that this demonstrated a possible exposure, not that every browser would allow such a request.
Security context and recommendations
The video cites reports of roughly 175,000 Ollama servers exposed to the internet, as well as research involving unauthenticated servers and attackers seeking computing resources or API keys. It also notes that Docker-published ports can bypass Linux firewall rules such as UFW; binding a port to 127.0.0.1 can limit access to the local machine.
The reviewer’s practical checklist is to:
- Avoid exposing Ollama with
0.0.0.0. - Use a secured method, such as Tailscale or a password-protected reverse proxy, for remote access.
- Review Ollama models and integrations for cloud models.
- Log out if an Ollama account is unnecessary.
- Clear LM Studio server logs.
- Add an API key to the llama.cpp server.
- Enable the Mac firewall.
- Use Lulu to monitor app connections.
The reviewer also corrects vulnerability claims from another video: a llama.cpp memory-leak issue was reportedly fixed in version 0.17.1, while a later Ollama Docker vulnerability was fixed in version 0.35. The video says the tests were brief and limited to one Mac. Jan’s default web-search behavior was described based on its source code but was not verified in a full in-app chat.
Guides and methods covered
- Network monitoring: Capture macOS traffic with
tcpdumpon thepktapinterface, which attributes packets and DNS requests to processes; separately log opened network sockets. - Canary testing: Enter unique fake secrets, then search network-related records and local files for those strings.
- Local AI hardening: Restrict network exposure, require authentication for servers, review cloud settings and integrations, inspect or clear logs, and enable firewall monitoring.
Main speakers and sources
- Main speaker: The video’s narrator and reviewer from RepoChad.
- Sources referenced: The tested apps’ source code and documentation; Sentinel Labs and Censys; Intruder; Kaspersky; and security researchers whose Ollama and DNS-rebinding findings are discussed.
Rate this summary
Your feedback will help improve summaries.
Improve this summary
Reprocess with a stronger model when the summary feels incomplete or inaccurate.
Translate summary in another language
Ask questions to this video
Chat for follow-up questions, clarifications, and source-backed answers.