Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Exposed Ollama endpoints: are your AI controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15051
Topic starter  

TL;DR: Cisco Talos found just over 1,100 exposed Ollama endpoints in about 10 minutes, with roughly 20% actively hosting models and the rest still vulnerable to manipulation through untrusted uploads and weak exposure controls, according to Tailscale. The finding shows that AI adoption is still outpacing basic authentication, isolation, and access control discipline.

NHIMG editorial — based on content published by Tailscale: Finding 1,000 exposed AI servers took researchers 10 minutes

By the numbers:

Questions worth separating out

Q: What breaks when a self-hosted AI server is exposed to the public internet?

A: When a self-hosted AI server is publicly exposed, attackers can discover it quickly, probe it without authentication, and abuse any weak or missing access controls.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction.

Q: How can organisations tell whether an AI agent is operating outside its intended boundary?

A: Look for inconsistent classifications, premature tool calls, fabricated inputs, and responses that ignore structured guardrails.

Practitioner guidance

  • Inventory every externally reachable AI endpoint Build and maintain a list of self-hosted LLM servers, model gateways, and MCP-connected services that are reachable from untrusted networks.
  • Require identity-based authorization for AI access Use policy-enforced access for humans, service accounts, and tools that connect to AI systems.
  • Separate inference access from administrative paths Keep model usage, upload functions, and administrative controls on different trust paths, with the admin surface closed to general traffic.

What's in the full article

Tailscale's full post covers the operational detail this post intentionally leaves for the source:

  • Cisco Talos methodology for locating exposed Ollama endpoints across the web.
  • Examples of how unsecured LLM servers can be manipulated, overloaded, or probed for model behaviour.
  • Practical guidance on securing self-hosted AI with private access and identity-based authorization.
  • Discussion of MCP access patterns and why insecure public exposure remains common.

👉 Read Tailscale's analysis of exposed self-hosted LLM servers and AI security gaps →

Exposed Ollama endpoints: are your AI controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14635
 

Public AI exposure is now an identity governance problem, not just a network hygiene issue. Once a self-hosted LLM is reachable from the internet, security depends on who or what is allowed to authenticate, not merely on where the service runs. That makes the control problem closer to IAM and workload access governance than to a one-time hardening exercise. Practitioners should therefore treat every AI endpoint as a governed identity surface.

A question worth separating out:

Q: Which frameworks should guide governance for exposed AI services and connected tools?

A: NIST AI RMF and NIST CSF provide the governance structure, while OWASP Agentic AI Top 10 and the MITRE ATT&CK Enterprise Matrix help map exposure and misuse patterns. If AI services connect to tools or data through delegated identities, NHI-focused controls should also govern authentication, scope, and revocation.

👉 Read our full editorial: Exposed self-hosted LLM servers expose the security gap in AI deployment



   
ReplyQuote
Share: