Exposed Ollama and LLM Endpoints: Securing Self-Hosted AI Models

Why self-hosted LLM servers end up on the internet

Tools such as Ollama make it simple to run large language models on your own hardware. A developer installs one, tries a model, and then wants teammates or another application to use it. The quickest way is to make the server listen on all network interfaces. That one change can put the model API on the public internet.

Ollama's API listens on port 11434 by default, and by default it binds to the local machine only. Ollama does not include its own authentication for that API, so access control has to come from the network or from a reverse proxy placed in front of it.

How common is the exposure?

In a study published in September 2025, Censys identified about 10,600 high-confidence Ollama instances reachable from the internet. About 1,500 of them answered at least one test prompt, and some revealed their system prompts. More than a quarter ran on non-default ports, which means checking only port 11434 will miss them (Censys).

Censys's broader 2026 data shows internet-exposed AI infrastructure growing quickly, with nearly 268,000 systems running AI-related products as of July 2026 (Axios).

What is at risk

• Free compute for strangers. Anyone who can reach the API can run prompts on your hardware, which costs you money and capacity.
• Exposed system prompts and data. Prompts, system instructions and any data passed to the model may be readable.
• Model management. The API includes operations to download and delete models, so an exposed server can be disrupted or filled with unwanted models.
• A foothold. Any unauthenticated service on a host is a reconnaissance gift, and the host may carry credentials or access to internal systems.

The Docker gotcha

A common way these servers end up exposed is a container started with a published port, for example -p 11434:11434. Docker publishes that port on all interfaces and adds its own firewall rules, which can bypass host firewalls such as UFW. A server that "has the firewall on" may still be open. Bind explicitly to localhost instead:

# Reachable by anyone who can reach the host
docker run -d -p 11434:11434 ollama/ollama

# Reachable only from the host itself
docker run -d -p 127.0.0.1:11434:11434 ollama/ollama

How to test your own servers

From a machine outside your network, check whether the API answers:

curl -s --connect-timeout 5 http://YOUR_PUBLIC_IP:11434/api/tags

If this returns a list of models, the server is exposed. Test your public IP addresses on non-default ports too, and review your cloud security groups and router port forwards.

How to secure LLM endpoints

1. Keep the default binding. Leave the server on localhost unless remote access is required.
2. Put an authenticating proxy in front. If other users or services need access, use a reverse proxy with authentication such as API keys, mutual TLS or SSO, and do not publish the raw API.
3. Restrict by network. Use a VPN, private network or IP allowlist so only known clients can connect.
4. Fix firewall assumptions. Check that Docker-published ports are bound where you intend them to be, and verify from the outside.
5. Separate the host. Do not run model servers on machines that hold credentials or sit on sensitive networks.
6. Monitor usage. Watch for unexpected spikes in requests, new models and traffic from unfamiliar addresses.

How SurfaceScan helps

SurfaceScan scans your IP addresses and discovered hosts from the outside, including non-standard ports, and reports what is reachable. A model server on a forgotten cloud instance or an unusual port appears in your open ports inventory, and a new service appearing between scans is highlighted as a change. See the guide on open ports security for how to prioritise what you find.