Is Ollama Safe? What Leaves Your Network and How to Check

Every few weeks I get a version of the same question from an owner who has just heard that AI can run on a box in their own back office. It goes: this local AI thing sounds great, but is Ollama safe? Is it quietly shipping our customer calls to somebody in California?

Short answer: when you run a local model, Ollama does not send your prompts or your responses anywhere. Ollama says so plainly in its privacy policy. But that sentence is doing a lot of work, and the parts it leaves out are the parts that actually get small businesses in trouble. Ollama the program is fairly boring. Ollama the thing your nephew installed on a spare tower and then opened up so he could reach it from his laptop is where the trouble lives.

I install this software on mini PCs that my customers own outright, sitting on their own networks, answering their own phones and email. So I have a working operator answer rather than a security researcher answer. Below is what leaves the box, what Ollama Cloud changes, the handful of real vulnerabilities that have shipped, and the commands you or your IT-minded manager can run in about five minutes to confirm the situation on your own hardware.

Key Takeaways

Ollama running a local model is private by design. The risk is almost never the model. It is the network binding, the missing authentication, and the version you never updated.

Is Ollama Safe to Run on a Business Network?

Yes, with two conditions that are not optional: keep it current, and keep the port off the public internet. That is the whole answer, and everything else in this note is detail underneath it.

Here is the frame I use with owners. Ollama is not a service you sign up for. It is a program that runs on a computer you control, the same way a printer driver does. It loads a model file off local disk and does math on it. No account is required for local models, there is no cloud dashboard in the middle, and nothing about the design needs to phone home while it answers a question. That is why I build on it instead of wiring a customer's phone transcripts into somebody else's API.

The flip side is that Ollama also does not come with the guardrails that a hosted service gives you for free. There is no login screen. There is no rate limit. There is no audit log of who asked what. If you expose the API, you have exposed the whole thing, because the API is the whole thing. Hosted vendors handle that layer for you and charge you rent for it forever. Owning the rig means you handle it once, correctly, and then you own it. I wrote about the hardware side of that tradeoff in the mini PC build note, and the broader case in the 2026 guide to local AI agents for small business.

So the honest version is: the software is a reasonable foundation, and most of the safety lives in your deployment rather than their code. Good news, because deployment is the part you can verify.

What Actually Leaves Your Network When You Run Ollama?

Let me separate the traffic into buckets, because lumping it together is what makes people either paranoid or careless.

Model pulls. When you run ollama pull llama3.2 or run a model you have not downloaded yet, Ollama reaches out to its registry and downloads several gigabytes of weights. This is a real outbound connection to the internet. What the far end learns is roughly what any software download server learns: your IP address, the model and tag you requested, and the fact that a request happened. It does not learn what you later ask that model. Once the weights are on disk in ~/.ollama/models, inference does not need the network again.

Update notifications. On macOS and Windows, the desktop app tells you when a new version is available, which means the app checks a version endpoint. On Linux you generally update by re-running the install script or your package manager, so nothing checks on its own. Either way this is a version string, not your data.

Telemetry. Ollama's privacy policy says it may gather limited technical metadata such as app version and request counts, and states directly that it does not collect, store, transmit, or have access to prompts, responses, model interactions, or other content processed locally. So: coarse operational signals, no content. If your compliance posture cannot tolerate even that, you block the box from egress entirely after the models are downloaded, which I cover further down.

Sign-in and cloud calls. Zero unless you opt in. Running ollama signin links the install to an ollama.com account. Running a model whose name ends in :cloud sends the prompt to Ollama's infrastructure. Neither happens by accident, but both are easy to do while following a tutorial, which is why I check for them on every rig I touch.

Inference on a local model. Nothing. No network required. Pull the ethernet cable and it keeps answering. That is the test I run in front of skeptical owners, and it is the most persuasive thirty seconds of the whole install.

Does Ollama Cloud Gather Information?

This is the question I see searched most often alongside "is ollama safe," and the confusion is understandable, because Ollama Cloud lives behind the same command line as the local product.

Here is the mechanic. Cloud models carry a :cloud suffix, for example gpt-oss:120b-cloud. You never download them and they consume no disk or VRAM. Your application still talks to localhost:11434 exactly as before, but the local daemon recognizes the suffix, attaches your account credentials, and proxies the request out to Ollama's servers, which run the model and stream the answer back. Ollama's own documentation describes cloud models as being automatically offloaded to Ollama's cloud service while offering the same capabilities as local models.

So yes, using a cloud model means your prompt and your response cross a remote trust boundary. That is not a scandal, it is the product working as described. What matters is whether that data is kept. Ollama's cloud models announcement says its cloud does not retain your data, and the privacy policy says prompts and responses for cloud-hosted models are processed transiently and not stored beyond the time required to fulfill the request. On the account side, Ollama does collect the normal things a company with logins and billing collects: name, email, user ID, password, payment details through Stripe, device and browser metadata, IP address, general location, and usage statistics.

Pro Tip: If you engaged someone to build you a local AI system, grep the configuration for the string -cloud and for ollama signin before you sign off. A cloud model in a build sold to you as local is not a subtle bug, it is a different product, and it will show up in your model list in plain sight.

None of this makes cloud models bad. For a one-off summarizing job on public marketing copy, offloading to a model you could never fit in a mini PC is a good deal. I just do not route customer phone transcripts, medical intake, or client matter details through it, and neither should you without a signed agreement your attorney has read.

What Is the Real Threat Model for a Small Business?

Owners tend to worry about the wrong thing. The fear is usually "the AI company is reading my data." The actual incidents are almost always "we left the door open and someone walked in." Here is the table I work through on a deployment.

Notice that eight of the nine are configuration and patching. That is the good news about owning the rig: you close them once, permanently, without renegotiating anything with a vendor.

Scale matters too. Researchers at Cisco used Shodan to find 1,139 internet-exposed Ollama servers, roughly 214 of which were actively hosting models and responding to unauthenticated API requests. Oligo Security, in a separate analysis, counted around 10,000 internet-facing IPs running Ollama and estimated about one in four was vulnerable to the flaws they had just reported. Those are not big numbers in absolute terms, but every one of them is somebody who thought they were running a private AI.

Has Ollama Had Real Security Vulnerabilities?

Yes, and I would be suspicious of any project this widely deployed that claimed otherwise. What matters is whether they get fixed and how fast.

The headline one is CVE-2024-37032, nicknamed Probllama by Wiz Research, who found it. Ollama did not validate the format of the digest field when resolving model paths, so a crafted manifest could include path traversal sequences and escape the intended directory. The result was arbitrary file write and, from there, remote code execution. On a normal Linux install the daemon listens only on localhost, which limited exposure. In the official Docker deployment the server ran as root and listened on 0.0.0.0, which made it remotely exploitable out of the box. Wiz found over a thousand exposed instances at the time. Fixed in 0.1.34.

Then a cluster of four from Oligo Security, all patched in 0.1.46:

• CVE-2024-39719 disclosed whether a given file existed on the server through error messages from the create endpoint.
• CVE-2024-39720 was an out-of-bounds read triggered by a malformed model file, causing a crash.
• CVE-2024-39721 was a denial of service that spun the create endpoint into an infinite loop and exhausted resources.
• CVE-2024-39722 exposed the file paths present on the server through the push route.

Oligo also flagged two design issues rather than code bugs: models could be pulled from unverified sources, and pushed to attacker-controlled destinations, because those endpoints did not require authorization. That is the model-provenance row in my table above, and it is a policy problem you solve on your side by only pulling pinned tags from the official registry.

There have been further advisories in 2026 that I have seen reported but not verified against a primary source, so I am not going to put numbers next to them here. Treat that as its own lesson: if a blog post lists a CVE and you cannot find it in the vendor advisory or the national database, do not act on it and do not repeat it. The habit that actually protects you is not memorizing CVE numbers, it is checking your version on a schedule.

How Do You Check It Yourself?

This is the part I want every owner to be able to do without me. Five commands, five minutes, and you will know more about your own deployment than most people who installed it.

1. Check the version. Compare it against the current release on the project's releases page. If you are behind, that is your first job.

ollama --version

2. See what the service is actually listening on. This is the single most important line in this article. You want to see 127.0.0.1:11434. If you see 0.0.0.0:11434 or *:11434, the service is accepting connections on every interface on the machine.

# Linux, modern
ss -tlnp | grep 11434

# macOS or older Linux
netstat -an | grep 11434

# Windows PowerShell
netstat -ano | findstr 11434

3. Confirm it answers locally. A version response here means the daemon is alive and reachable from the box itself.

curl -s http://127.0.0.1:11434/api/version

4. Try to reach it from a different machine. From a laptop on the same network, substitute the rig's LAN address. A connection refused or a timeout is the answer you want on a single-purpose box. A JSON response means anyone on that network, including a guest on your wifi, can use your models.

curl -s --max-time 5 http://192.168.1.50:11434/api/tags

5. Audit the model list for cloud models and check the environment. Any tag ending in -cloud means requests for that model go off-box. An OLLAMA_HOST of 0.0.0.0 or an OLLAMA_ORIGINS of * both deserve a conversation.

ollama list
env | grep -i ollama

If step 4 came back with data and you did not intend that, close it now. On Linux with ufw, deny the port and then allow only the specific machines that legitimately need it:

sudo ufw deny 11434/tcp
sudo ufw allow from 192.168.1.20 to any port 11434 proto tcp
sudo ufw status numbered

And to check the outbound side, if you want to see what the box talks to while it is idle, watch its established connections over a few minutes with a local model loaded and no pulls running. On a properly local deployment that list stays empty.

ss -tp state established | grep -i ollama

Pro Tip: Run step 2 and step 4 again after every update and after anyone touches the box. Bindings drift. Somebody troubleshoots a connection problem at 9pm by setting OLLAMA_HOST=0.0.0.0 and never puts it back, and now you are one of the numbers in the next Shodan study.

How Should You Lock Down Ollama on a Shop Network?

Here is the configuration I ship, in priority order. You do not need all of it for a box that only ever talks to itself, but each layer is cheap.

1. Leave the default bind alone when you can. If the application using the model runs on the same machine, 127.0.0.1 is correct and you are already done with the hardest part.
2. If other machines need access, bind to the LAN address, not to everything. OLLAMA_HOST=192.168.1.50:11434 is meaningfully narrower than 0.0.0.0, and pair it with a firewall rule that allows only the specific clients.
3. Put a reverse proxy in front for authentication. Ollama has no login of its own, so the standard pattern is nginx or Caddy terminating TLS and requiring a bearer token before forwarding to localhost. Ollama's FAQ documents proxying through nginx, ngrok, or a Cloudflare Tunnel. If the rig must be reachable from outside the building, do this or use a VPN.
4. Never publish the port to the internet directly. No port forward on the router, no 0.0.0.0 on a cloud VM with a public IP. This is the mistake behind essentially every exposed-instance study.
5. Segment the box. Put the rig on a VLAN that can reach the systems it genuinely needs and nothing else. An agent that only needs to write to a scheduling API does not need a route to your accounting server.
6. Pin your models and pull from the official registry. Exact tags, not floating ones, so a rebuild does not silently change the behavior of the thing answering your phone.
7. Restrict origins. Set OLLAMA_ORIGINS to the specific origins that need browser access. A wildcard means any web page a staff member visits can quietly query your local model.
8. Update on a calendar. Monthly is fine for an internal box. Same day for anything reachable beyond the LAN.
9. Log at the proxy. Ollama will not tell you who called it. Your proxy will, and that log is what turns "something feels off" into an actual answer.

If your compliance situation demands that the box never talk to the internet at all, that is achievable: pull the models during the build, then drop egress for that host at the firewall. Local inference genuinely does not need the network, so the only thing you give up is the convenience of pulling new models without a temporary exception.

What Does Ollama Not Protect You From?

I would rather lose a deal than oversell this, so here is the honest list. Running locally solves the data-residency problem. It solves none of these.

Your own application's mistakes. Ollama runs the model. What you feed it and what you do with the output is your code. If the agent has database credentials and an untrusted user can influence its instructions, local hosting has not saved you. Prompt injection works exactly the same against a model on your own hardware.

Bad output. A local model hallucinates as cheerfully as a hosted one. If the agent quotes a price, promises a same-day appointment, or gives medical-sounding advice, that is your liability regardless of where the GPU sits. Constrain what it is allowed to say and route the rest to a human.

Everyone with physical or admin access. Conversation logs, if you keep them, are sitting on a machine in your building. That is the point, and it is also a responsibility. Disk encryption, real user accounts, and a retention policy still apply. A local box does not have a compliance team standing behind it. You are the compliance team.

Backups and continuity. Nobody else is keeping a copy. If the rig dies, the agent stops answering until you restore it. I build with a documented rebuild path for exactly this reason, and it is the question I would ask any vendor selling you an on-premise anything.

Legal obligations. Local processing helps a HIPAA or client-confidentiality story substantially, but it does not complete it. Access controls, audit trails, agreements, and training are all still on the list. And Ollama is only one package: the automation glue and the OS around it are the rest of your attack surface, on their own update schedules.

How I Ship Ollama on Rigs Customers Own

Local AI gets sold as a vibe and delivered as a laptop under a desk with the port wide open. The configuration is the product. When I hand over a rig, the bind is localhost or a single LAN address, the firewall is explicit about who may talk to the port, anything reachable off the LAN sits behind a proxy with authentication and logging, models are pinned from the official registry, no account is signed in unless the customer asked for cloud offload, and it is all written down on a page the customer can hand to whoever comes after me.

Then I show them the trick that makes it real: pull the network cable and watch the agent keep answering. That is what "you own the rig" means in practice. Not a promise in a privacy policy, but a machine you can unplug and still use.

If you are weighing local against a subscription, the build note on running a local AI agent on a mini PC covers the hardware, and the 2026 small business guide covers what these agents actually do all day. If you would rather not run the checks in this article yourself, that is fair, and it is roughly the job description of a scoped custom build: two weeks, deployed on hardware you own, documented well enough that you could hire someone else to maintain it.

Sources

• Ollama Privacy Policy
• Ollama Docs: Cloud
• Ollama Docs: FAQ (OLLAMA_HOST, origins, model storage, proxying)
• Ollama Blog: Cloud models
• Wiz Research: Probllama, CVE-2024-37032
• Oligo Security: More Models, More ProbLLMs (CVE-2024-39719 through 39722)
• Cisco: Detecting Exposed LLM Servers, a Shodan Case Study on Ollama
• UpGuard: Understanding and Securing Exposed Ollama Instances

FAQ

Is Ollama Safe to Install?

Yes, for most business uses, provided you install a current release and leave the API bound to localhost. Ollama states it does not collect or transmit prompts and responses processed locally. The practical risks are running an outdated version and exposing port 11434, which has no built-in authentication.

Does Ollama Cloud Gather Information?

Ollama Cloud sends your prompt to Ollama's servers, so that content does leave your network. Ollama says cloud prompts and responses are processed transiently and not retained or trained on. Account-level data such as email, IP address, device metadata, and usage statistics is collected for the service itself.

Does Ollama Send My Data Anywhere When I Run a Local Model?

No. Once the model weights are downloaded, local inference needs no network connection at all. The outbound traffic associated with Ollama is model downloads from its registry, update checks on the desktop apps, and limited technical metadata such as app version and request counts.

How Do I Check Whether My Ollama Server Is Exposed?

Run ss -tlnp | grep 11434 on the machine and confirm it shows 127.0.0.1:11434 rather than 0.0.0.0. Then, from a second computer, curl the rig's LAN address on port 11434. A refused connection is the result you want on a single-purpose box.

Does Ollama Require Authentication on Its API?

No. The local API has no authentication of its own, which is why exposing it is dangerous. If you need access from other machines, put a reverse proxy such as nginx or Caddy in front of it to require a token, or reach the box over a VPN.

Which Ollama Vulnerabilities Should I Know About?

CVE-2024-37032, called Probllama, allowed remote code execution and was fixed in version 0.1.34. Four further issues, CVE-2024-39719 through CVE-2024-39722, covered file disclosure and denial of service and were fixed in 0.1.46. Running a current release closes all of them.