Ollama Port 11434: Local AI Security

Keep Ollama bound to localhost unless you have a reason not to, check what is actually listening on port 11434, and put a firewall and a proxy between the API and anything that is not your own machine.

What the risk is

Ollama runs language models on your own hardware and exposes them through an HTTP API on port 11434. By default it listens only on 127.0.0.1, so only programs on the same machine can reach it. That default is the main security control, and it is one environment variable away from being removed.

The API has no user accounts, passwords or tokens of its own. Anything that can reach the port can list your models, send prompts, read the responses, pull new models from the internet and delete the ones you have. If you have connected Ollama to documents, a database or an agent framework, the port is also a route into whatever those tools can see. People expose it deliberately, to let a laptop use the office server's GPU or to run a web front end, and then forget that "the whole office network" includes guest Wi-Fi, a compromised printer and anyone the router forwards traffic to.

A realistic UK SME example

An architecture practice with fifteen staff buys a workstation with a good graphics card so the team can summarise tender documents locally rather than in a cloud service. To let everyone use it, the IT-minded partner sets OLLAMA_HOST=0.0.0.0 so Ollama listens on every interface, and adds the workstation's address to a shared chat front end. It works well.

Six months later the same workstation is also running an agent that can read the practice's project folder. The office router still has a port-forward rule from a video-conferencing experiment. Nobody has looked at the listening ports since the build. The practice chose local AI to keep tender data private and has ended up with an unauthenticated API on a machine with access to that data, reachable from further than anyone intended.

Controls in priority order

1. Confirm what is listening. On Linux run ss -ltnp | grep 11434; on macOS run lsof -nP -iTCP:11434 -sTCP:LISTEN; on Windows run netstat -ano | findstr :11434. A local-only service shows 127.0.0.1:11434. Anything showing 0.0.0.0, * or [::] is listening on every interface.
2. Bind to localhost unless you need otherwise. Ollama reads OLLAMA_HOST to decide where to listen. On Linux the service is normally managed by systemd, so run systemctl edit ollama.service and set or remove Environment="OLLAMA_HOST=...", then systemctl daemon-reload and systemctl restart ollama. On macOS and Windows the variable is set in the user environment; unset it and restart the app. If you run Ollama in Docker, publish the port to localhost only with -p 127.0.0.1:11434:11434.
3. If it must be shared, put a reverse proxy in front. Keep Ollama on localhost and let nginx, Caddy or a similar proxy handle HTTPS and authentication. The proxy is where you add a password, a client certificate or single sign-on; Ollama itself will not do this for you.
4. Firewall the port anyway. On Linux, sudo ufw deny 11434/tcp blocks inbound traffic even if the binding changes later. On Windows, add an inbound block rule for TCP 11434 in Defender Firewall, or push it through Intune so it survives a rebuild. Check the office router has no port-forward rule for 11434.
5. Set OLLAMA_ORIGINS deliberately. This variable controls which browser origins may call the API. Leave it at the default unless a specific web front end needs it, and then list that origin only.
6. Give the machine the same treatment as any server. Patch the OS and Ollama, keep model files and any connected documents off shared drives, and include the workstation in backup and retention rules. Our note on local versus cloud AI privacy sets out why the local option only wins if this work is done.

What to write into policy

Add these lines to the acceptable-use or IT security policy so the decisions outlive the person who made them:

• Local AI services listen on localhost only. Network exposure requires a written exception naming the owner, the users, the proxy and the authentication method.
• Local AI machines are in the patch schedule and the asset register like any other server.
• Models are pulled only from sources the IT lead has approved, and the list of installed models is reviewed quarterly.
• Any agent or tool connected to a local model has its own access review, because the model's reach is the tool's reach.

If you use Intune and Defender for Business, the firewall rule and the listening-port check can be enforced and audited centrally. Our endpoint management pages describe that setup.

How to test

From the Ollama machine, curl http://127.0.0.1:11434/ should return Ollama is running. From any other device on the office network, the same request against the machine's LAN address should fail to connect. If it succeeds, either the binding or the firewall is wrong. From outside the office, check the public address with the same command; it must fail. Re-run the three checks after any Ollama update, any change to the machine's environment variables, and any change to the router.

Source basis

• Ollama documentation: FAQ, including OLLAMA_HOST and OLLAMA_ORIGINS
• Ollama documentation: API reference
• NCSC: small business guide to cyber security
• NCSC: 10 steps to cyber security