Last updated: 2026-03-23

Most people who install a "local" AI tool assume the data stays local. Most of them are wrong — at least partially.

Local LLM runners, coding assistants, and even privacy-focused AI apps make network calls you didn't authorize. Telemetry pings, model update checks, license validations, crash reports. Some are benign. Some aren't. The only way to know is to watch the wire.

This guide shows you how to monitor exactly what your AI tools are sending, intercept the connections that concern you, and build a workflow where sensitive data never leaves your machine without your explicit say-so.

Why "Local" AI Isn't Always Local

The local LLM ecosystem has a trust problem. Tools marketed as privacy-first still reach out to external servers — sometimes for legitimate reasons, sometimes not.

Here's what gets transmitted without most users realizing:

• Telemetry and analytics: Usage patterns, model selection, session duration. LM Studio, Jan, and even some Ollama-adjacent tools ship with analytics enabled by default.
• Model metadata requests: Checking for updates, pulling manifests from registries, fetching model card info from Hugging Face.
• License and auth validation: Paid local tools often ping a licensing server on startup.
• Crash reports: When inference crashes (and it does), stack traces containing fragments of your last prompt can be sent to error-tracking services.
• Plugin and extension callouts: If you've installed coding assistant plugins (Continue.dev, Codeium, Cursor), each has its own call home behavior.

None of this means your actual prompts are being exfiltrated. But it does mean your threat model needs to account for metadata and context that can be almost as revealing as the content itself.

What You Need: The Monitoring Stack

You don't need expensive tools. Here's the free stack:

For macOS:

• Little Snitch (paid, best-in-class) or Lulu (free, open source)
• Wireshark or tcpdump for deep packet inspection
• nettop (built-in macOS) for quick process-level monitoring

For Linux:

• nethogs — per-process bandwidth monitor
• Wireshark or tshark
• ss and lsof for socket inspection

For Windows:

• Glasswire (free tier is sufficient)
• Wireshark
• Resource Monitor (built-in)

This guide focuses on macOS and Linux since that's where most privacy-conscious developers run local AI.

Method 1: Quick-and-Dirty with nettop (macOS)

Before you reach for Wireshark, start here. nettop shows real-time per-process network activity from the command line.

```bash

Watch all processes, refresh every 2 seconds

sudo nettop -P -d -t wifi -t wired

Filter to a specific process (e.g., Ollama)

sudo nettop -P -d | grep -i ollama

```

Open your AI tool. Start a session. Watch for any process making outbound connections during inference — specifically anything that isn't your browser or OS services.

If you see ollama making calls to anything other than localhost:11434, that's worth investigating. Same goes for any Electron-based app (LM Studio, Jan) calling domains other than local model endpoints.

Method 2: Wireshark for Full Packet Inspection

nettop tells you that connections are happening. Wireshark tells you what is being sent.

Install:

```bash

macOS

brew install wireshark

Ubuntu/Debian

sudo apt install wireshark

```

Capture AI tool traffic:

1. Open Wireshark, select your active network interface (usually en0 on Mac, eth0 or wlan0 on Linux)
2. Apply a capture filter to exclude noise:

```

not (host 127.0.0.1 or host ::1) and not arp

```

1. Launch your AI tool and run a few prompts
2. Stop capture, then apply display filter:

```

http or http2 or dns

```

1. Look for outbound connections. Right-click any suspicious packet → Follow → HTTP/TCP Stream to see the full payload.

What you're looking for:

• POST requests to analytics endpoints (Segment, Amplitude, Mixpanel domains are common)
• DNS lookups for cloud AI provider domains (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com) from tools claiming to be fully local
• Any request that includes prompt-like strings in the payload

Method 3: DNS-Level Blocking with Pi-hole or /etc/hosts

Even if you can't decrypt TLS traffic (which Wireshark can't without the server's private key), you can block domains at the DNS level.

For quick blocking without setting up Pi-hole:

```bash

Add to /etc/hosts to null-route telemetry domains

echo "0.0.0.0 telemetry.lmstudio.ai" | sudo tee -a /etc/hosts

echo "0.0.0.0 analytics.jan.ai" | sudo tee -a /etc/hosts

echo "0.0.0.0 sentry.io" | sudo tee -a /etc/hosts # crash reporting

```

Verify it worked:

```bash

ping telemetry.lmstudio.ai

Should show: ping: cannot resolve telemetry.lmstudio.ai: Name or service not known

```

Note: blanket-blocking Sentry may break error reporting for legitimate local services too. Be surgical.

What Ollama Actually Sends

Since Ollama is the most popular local LLM runner, let's be specific about what it does:

On model pull: Makes requests to registry.ollama.ai to download model manifests and layers. This is expected and necessary. Ollama sees which models you're pulling.

On startup: Checks for version updates via ollama.com. Metadata only — not your prompts.

During inference: All traffic is between your client and localhost:11434. Nothing leaves your machine.

Crash reports: Ollama does not send crash reports by default as of the current release.

So Ollama's privacy posture is reasonably good — the main exposure is the model registry knowing what you're running. If that matters to you (e.g., you're evaluating a model associated with a specific use case), you can pre-download models on a non-sensitive network and run Ollama with network disabled:

```bash

Disable Ollama's external access entirely via firewall rule (macOS)

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/bin/ollama

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --blockapp /usr/local/bin/ollama

```

The Harder Problem: Your Documents

Running a local LLM is one thing. Feeding it sensitive documents is another. This is where most privacy setups break down.

If you're using a RAG (Retrieval-Augmented Generation) workflow — giving your LLM access to PDFs, code repos, or internal docs — those documents are processed in memory locally. But they also exist on your filesystem, often in cleartext, accessible to every process on your machine including those that do phone home.

The principle: separate your document storage from your AI workspace.

Sensitive documents (client contracts, medical records, source code under NDA) should live in encrypted storage and only be decrypted into a sandboxed workspace for the duration of an AI session.

Tresorit handles this well. It's zero-knowledge encrypted cloud storage — meaning even Tresorit's servers can't read your files. You can set up a sync folder that exists as a local mount for AI ingestion, then unmount it when you're done. No cleartext copy sits on disk long-term.

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.

The workflow:

1. Documents live encrypted in Tresorit
2. Mount the Tresorit folder for a work session
3. Point your local LLM / RAG pipeline at the mount
4. Unmount when done
5. Cleartext exposure window: minutes, not months

When You Actually Need Cloud AI

Sometimes local isn't the right tool. Your Llama 3.2 8B on a MacBook Air isn't going to do the same job as a frontier model on a coding problem that requires deep reasoning.

For those cases, the question isn't "cloud vs. local" — it's "which cloud and what data?"

Perplexity occupies an interesting middle ground. It's a web-connected AI search tool, but it's meaningfully more transparent about data use than Google or Bing AI. For research tasks where you need current web data but aren't feeding sensitive content, it's a solid choice. Their Pro plan also includes access to frontier models with a stated no-training-on-prompts policy.

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.

The rule of thumb: use local for anything that touches sensitive or proprietary data. Use trusted cloud AI for research, general knowledge, and tasks where the question itself isn't sensitive.

Building a Zero-Trust AI Network Policy

If you want a systematic approach rather than ad-hoc monitoring, set up an application firewall with explicit allow-lists.

On macOS with Lulu (free):

1. Install Lulu from objective-see.org
2. Enable "Block All" mode
3. Launch your AI tools one at a time and approve only the connections you expect:

- Ollama: allow localhost only, deny everything else

- LM Studio: allow localhost, deny analytics domains

- Cursor/Continue.dev: this will require more careful decisions — these legitimately need some cloud connectivity

1. Save your rules to version control

On Linux with ufw and per-process rules:

```bash

Allow Ollama to bind on localhost only

sudo ufw allow from 127.0.0.1 to 127.0.0.1 port 11434

Block Ollama from making outbound connections (except localhost)

Use owner-match with iptables for per-process control

sudo iptables -A OUTPUT -m owner --uid-owner $(id -u ollama) \

! -d 127.0.0.1 -j REJECT

```

Note: per-process Linux firewall rules require iptables owner match module, which isn't available in all environments.

The Email Vector: Exfiltration Through AI Plugins

One underappreciated risk: AI tools with email integration.

If you've connected Gmail, Outlook, or any IMAP-based email to an AI assistant for summarization or drafting, you've potentially granted that tool (and its cloud backend) access to your entire inbox. Even "local" tools that use an email plugin often proxy through a cloud service for OAuth token management.

For any AI workflow that touches email, use a properly isolated account. Proton Mail offers end-to-end encrypted email with a privacy architecture that's audited and open-source. Their bridge app lets you use Proton with IMAP clients and local AI tools while keeping server-side content encrypted.

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.

If you must use AI email summarization, do it locally (Ollama + a mail fetcher script like offlineimap) against a Proton account, where at least the cloud storage layer is zero-knowledge.

What to Do When You Find a Leak

You've run the monitoring. You found something. Here's the decision tree:

If the tool is sending usage metadata but no content: Acceptable risk for most use cases. Block the telemetry domain if you want, but this isn't a five-alarm fire.

If the tool is sending request/response content to a non-expected cloud endpoint: Stop using it for sensitive work immediately. Check whether there's a setting to disable cloud sync (there often is, buried in preferences). If not, it's off the approved list.

If an LLM runner is sending your actual prompts to a remote API: You don't have a local LLM. You have a wrapper around a cloud API. Uninstall and find a genuine local runner.

If the tool is talking to an AI provider you didn't choose: This happens with IDE plugins. Codeium, GitHub Copilot, and similar tools route to specific backends. If you see traffic to api.openai.com from your editor and you didn't set that up, an extension you installed is sending your code externally.

Setting Up Automated Monitoring

For ongoing vigilance, a simple cron job can alert you to new outbound domains from AI processes:

```bash

#!/bin/bash

ai-network-monitor.sh — run via launchd or cron

Captures 60 seconds of DNS queries from AI-related processes

AI_PROCS="ollama lm-studio jan cursor code"

LOG="/var/log/ai-network-monitor.log"

KNOWN_SAFE="/etc/ai-safe-domains.txt"

for proc in $AI_PROCS; do

pid=$(pgrep -x "$proc" 2>/dev/null)

[ -z "$pid" ] && continue

# Log all DNS queries from this PID using dtrace (macOS)

sudo dtrace -q -n "

syscall::connect:entry

/pid == $pid/

{ printf(\"%s %s\\n\", execname, copyinstr(arg1)); }

" -c "sleep 10" 2>/dev/null >> "$LOG"

done

Alert on any new domains not in safe list

grep -vf "$KNOWN_SAFE" "$LOG" | mail -s "AI network alert" you@example.com

```

This is a starting point, not production-ready code. Adjust for your environment and notification preferences.

The Baseline: Your Private AI Checklist

Before running any AI tool with sensitive data:

• [ ] Run nettop or Lulu during a test session with dummy data — log all outbound domains
• [ ] Check the tool's privacy policy for explicit statements about prompt logging
• [ ] Verify model inference is happening on-device (CPU/GPU usage should spike; network should not)
• [ ] Keep sensitive documents in encrypted storage (Tresorit or equivalent) — decrypt only at session time
• [ ] Use a dedicated Proton email account for any AI workflow that touches email
• [ ] Block telemetry domains in /etc/hosts or your firewall
• [ ] Review plugin/extension permissions before installing anything into your AI workflow

Trust but verify. The "local" label on an AI tool is a starting point for investigation, not a guarantee of privacy.

---

Want a ready-made private AI setup checklist as a PDF? Drop your email below and we'll send it along with our weekly roundup of local AI tools worth knowing about.