You Switched to Local AI. Your Prompts Are Still Leaking.
Last updated: 2026-06-23
You installed Ollama. You downloaded Llama 3 or Mistral. You tested it, it worked, and you quietly congratulated yourself for escaping the surveillance economy of cloud AI.
Then you opened VS Code, pasted your project context into the chat sidebar, and went back to work.
Here's what you missed: the model is local. The toolchain isn't.
Most privacy-focused engineers stop their threat modeling at the model boundary — where the weights live, who owns the inference server. That's the wrong boundary. The prompts you type to your local LLM pass through a gauntlet of software before they reach the model and after they leave it. Each layer is a potential data egress point, and almost none of them are configured with privacy in mind by default.
This isn't about paranoia. It's about threat modeling the system you actually have, not the one you think you have.
The Local LLM Privacy Assumption (And Why It Breaks)
The standard privacy argument for local LLMs is structurally sound: if inference happens on your hardware, your prompts never touch a remote server, and there's nothing for OpenAI or Anthropic to log, sell, or accidentally breach. That logic is correct — but it applies only to the inference step.
Your prompts exist before inference and your outputs exist after it. Everything that touches those two artifacts is part of your attack surface.
Consider the average local AI workflow for a developer:
- Open IDE (VS Code, Cursor, Zed)
- Activate AI assistant plugin
- Copy relevant files or paste context into the chat interface
- Send prompt to local model endpoint
- Receive output, possibly copy it to clipboard
- Save output to a file, possibly in a synced folder
- Shell history logs the model invocation command
Steps 1, 2, 5, 6, and 7 all have potential cloud exposure — and none of them involve your local model.
Your IDE Is Phoning Home More Than You Think
This is the leak most developers never audit.
VS Code has two telemetry systems running by default: Microsoft's crash reporter and a usage analytics layer. Even with telemetry.enableTelemetry: false set, extensions operate under their own privacy policies and can transmit data independently. The VS Code Marketplace has over 50,000 extensions, and their telemetry practices range from thorough privacy policies to nothing.
Extensions that integrate AI — including some that are explicitly marketed as "local AI" assistants — often check for updates, authenticate against remote servers, or send metadata about your workspace to function. A plugin that routes requests to your local Ollama endpoint may still phone home to validate a license key or log usage statistics.
What to do: Audit your installed extensions. For each AI-adjacent one, check whether it has a published privacy policy, run netstat while using it to observe outbound connections, and consider running your IDE in an isolated network namespace if the workflow permits.
The only extension you can fully trust with sensitive prompts is one you've read the source code for — or one running in a fully offline, network-blocked environment.
The Clipboard Is a Surveillance Vector You Ignore Every Day
This one is subtle and deeply unsexy, which is why it works.
When you copy a prompt to your clipboard and paste it into a local model interface, you're trusting every application with clipboard access not to read it. On macOS and Windows, any app with Accessibility permissions can read the clipboard. Many productivity apps — clipboard managers, note-taking apps, launchers — do exactly this by design.
The threat isn't hypothetical. Popular clipboard managers like Alfred, Paste, and ClipMenu sync clipboard history to iCloud by default. If you've granted these apps Accessibility access (and most power users have), every prompt you've ever copied is sitting in iCloud under Apple's terms of service.
On macOS specifically, iCloud clipboard sync extends across all your signed-in devices. A prompt you copied on your work machine may now live in iCloud and is readable on your iPhone via Handoff.
What to do: Audit which apps have Accessibility permissions (System Settings → Privacy & Security → Accessibility). Disable iCloud clipboard sync (System Settings → Apple ID → iCloud → turn off Handoff). For sensitive prompting workflows, draft in a sandboxed text editor with no cloud sync rather than copying from live documents.
DNS Leaks Reveal Your AI Usage Even When Traffic Is Encrypted
Here's the threat that almost nobody in the local LLM community talks about: DNS queries.
Even if your prompt traffic never leaves your machine, your operating system broadcasts DNS queries to your ISP's resolver (or Google's, or Cloudflare's) every time any software resolves a hostname. If your AI toolchain makes outbound requests — to check for model updates, pull extension manifests, validate authentication — those DNS queries are logged by your resolver.
Your resolver knows:
- That
ollama.aiwas queried at 14:32 on Tuesday - That
huggingface.cowas queried four times in the hour after - That you hit
lmstudio.ai/update-checkat startup every day
This doesn't reveal your prompts. But it creates a behavioral fingerprint of your AI tool usage, correlated with your IP address and timestamp. For most people this is low-stakes. For journalists, lawyers, dissidents, or anyone working on genuinely sensitive projects, this metadata is not low-stakes.
What to do: Route all DNS through an encrypted resolver — DNS-over-HTTPS or DNS-over-TLS. ProtonVPN routes DNS through Proton's own encrypted infrastructure and prevents ISP-level metadata logging. For the most sensitive setups, run a local DNS resolver (Unbound, Pi-hole with DoH upstream) that never sends plaintext DNS off your network.
Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.
Building an Actually Private AI Stack
Here's what a genuinely private local AI workflow looks like, as opposed to a performatively private one:
Model layer: Run inference with Ollama, LM Studio, or Jan on local hardware. Disable automatic update checks in preferences — these create outbound connections you may not expect.
Interface layer: Use a local-only web UI (Open WebUI, Enchanted for macOS) rather than a cloud-hosted front end. Confirm the interface doesn't make remote API calls by watching outbound traffic with Little Snitch or Lulu during first run.
DNS layer: Route all DNS through ProtonVPN or a local DoH resolver. This prevents metadata leakage from update checks, license pings, and model download requests.
Clipboard layer: Disable cross-device clipboard sync. Use a clipboard manager that operates entirely locally with no sync capability, or disable clipboard manager access to Accessibility permissions entirely.
Output layer: Save sensitive AI outputs to end-to-end encrypted storage (Tresorit) rather than standard cloud sync folders. Keep a local-only vault for the most sensitive material.
Shell layer: Suppress history for AI-related sessions or pipe context from files rather than embedding it in commands.
Extension layer: Audit every VS Code/IDE extension for telemetry. When in doubt, disable the extension for sensitive sessions and re-enable it afterward.
The Threat Model You Should Actually Be Running
The privacy-conscious tech worker's threat model usually looks like this: "Don't let OpenAI read my prompts."
The threat model you should be running looks like this: "Which of my prompt's lifecycle stages — composition, transmission, inference, output, storage — touches a surface I don't fully control?"
Local inference eliminates the transmission and inference stages from the threat model. It does nothing for composition (your IDE, clipboard, browser), output (where you save results), or the metadata layer (DNS, telemetry, update pings) that wraps the entire workflow.
The engineers who build these tools are often privacy-conscious. But they're building for functionality first, and the default configurations reflect that. Privacy in a local AI stack is not something you opt into by downloading Ollama — it's something you construct deliberately, layer by layer.
One More Thing: The Perplexity Question
Not every AI task is appropriate for a local model. Research queries, especially ones pulling from current events or needing real-time web data, benefit from a cloud-connected tool. For those use cases, the question isn't whether to use a cloud AI — it's which one has the most transparent data practices.
Perplexity publishes explicit retention policies and doesn't train on your queries by default for signed-in users, making it one of the more auditable options for research tasks you can't keep fully local. It's not a zero-disclosure option, but it's a meaningfully better-documented one than most alternatives.
Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.