A lot of people who start using Local AI through popular tools like Ollama assume that simply installing the software and downloading a model onto their own machine means their data is instantly 100% safe and private—no extra configuration needed.
In reality, Ollama's API port (default 11434) is a critical data channel. Without proper hardening, any other device on the same Wi-Fi network—or even a malicious script running in your browser—could quietly invoke your model or access the context you're processing.
This guide walks you through 5 practical steps to secure Ollama and your local LLM stack, closing network-level vulnerabilities so your personal AI system is genuinely offline and private.
---
### 1. Restrict Access to Loopback Only (OLLAMA_HOST=127.0.0.1)
By default, Ollama binds to 127.0.0.1 (loopback), meaning only processes on your own machine can call the API. However, in certain configurations or older versions, it may bind to 0.0.0.0—exposing the endpoint to every device on your local network (LAN).
If someone on the same Wi-Fi knows your machine's IP, they can immediately send inference requests or consume your GPU resources.
How to fix and verify:
Set the environment variable to force Ollama to listen exclusively on loopback:
* Linux / macOS:
```bash
export OLLAMA_HOST=127.0.0.1:11434
```
If you're running Ollama via systemd on Linux, edit the service file and add this line:
```ini
Environment="OLLAMA_HOST=127.0.0.1:11434"
```
* Windows:
Go to System Properties > Environment Variables and add a new variable named OLLAMA_HOST with the value 127.0.0.1:11434
---
### 2. Lock Down CORS Origins to Block Browser-Based Attacks (OLLAMA_ORIGINS)
One of the quiet threats to a local AI API is Cross-Origin Resource Sharing (CORS) abuse. If you open an untrusted website in your browser, JavaScript on that page could fire HTTP requests to http://localhost:11434 on your machine—pulling chat history or triggering model inference without your knowledge.
How to protect yourself:
Restrict which domains or applications are allowed to send requests to Ollama using the OLLAMA_ORIGINS variable.
Example—allowing only Obsidian and your local dev server:
export OLLAMA_ORIGINS="app://obsidian.md,http://localhost:*"
Specifying exact origins ensures that random websites on the internet can never issue commands to your local LLM.
---
### 3. Audit and Disable Telemetry in Clients and Extensions
While Ollama's core engine doesn't phone home with usage statistics, the front-end UIs, browser extensions, or editor plugins you use to interact with Ollama may have usage analytics or crash reporting enabled by default.
Best practices:
* Open the Settings page of your UI application—whether that's Open WebUI, AnythingLLM, or a VS Code extension
* Look for options labeled Telemetry, Send Anonymous Statistics, or Crash Reports and disable them all
* For maximum confidence, use a network traffic inspector (like Wireshark or your OS firewall logs) to confirm no unexpected outbound connections are leaking out
---
### 4. Add a Reverse Proxy with Authentication for Home Sharing
If you need to share Ollama with your phone, tablet, or another computer in the house (e.g., you're running a home server), never expose port 11434 directly without authentication.
How to fix:
Run Ollama behind a reverse proxy like Caddy or Nginx, and enforce authentication via a Bearer Token or Basic Auth.
Example Caddyfile configuration requiring an API key before proxying to Ollama:
ai.home.local {
@unauthorized not header Authorization "Bearer MY_SECRET_LOCAL_KEY"
respond @unauthorized "Unauthorized" 401
reverse_proxy 127.0.0.1:11434
}
This lets you use your local AI across devices in your home seamlessly, while unauthorized devices are locked out.
---
### 5. Configure Your Firewall and Use a Mesh VPN (Tailscale) for Remote Access
To prevent your local AI port from being discovered by external scanners, configure your host firewall to block inbound connections to port 11434 from outside your private network.
* Linux (UFW):
```bash
sudo ufw deny 11434/tcp
```
* Windows Firewall: Create an Inbound Rule to block port 11434 under the Public Network Profile
Need to access your AI from outside the house?
Instead of port forwarding on your router (a high-risk approach), use Tailscale or WireGuard to create an encrypted mesh VPN. You can connect back to your home LLM at full speed with end-to-end encryption—without opening a single port to the public internet.
---
### The Bottom Line
Building a complete Second Brain or Private Brain OS isn't just about choosing local-first software—it's also about securing the data channels that connect your tools.
These five adjustments take only a few minutes to implement, but together they transform your local AI setup into a hardened, private fortress. No data leaks, no silent exploits, no compromises—just a system you can rely on for the long haul.