Topic starter
18/08/2026 3:00 pm
TL;DR: Exposed AI infrastructure is still shipping with missing authentication, hardcoded credentials, and open agent workflows, and Intruder’s research found 1,652 Ollama APIs, 92 Flowise instances, 25 Langflow instances, and 24 Open WebUI instances exposed without proper controls. The pattern is less about AI novelty than about old identity failures reappearing in faster, broader deployments.
Editorial analysis by NHI Mgmt Group, based on content published by Intruder: “From enterprise chatbots to gooner caves: exposed AI infrastructure is rampant”.
By the numbers:
- Intruder found 1,652 Ollama APIs exposed with no authentication, out of 5,200+ exposed to the internet.
- Intruder found 92 Flowise instances exposing agentic workflows, prompts and integrations, out of 2,650+ exposed to the internet.
- Intruder found 25 Langflow instances that did not implement authentication, out of 300+ exposed to the internet.
Key questions
Q: What breaks when AI endpoints are exposed without authentication?
A: Unauthenticated AI endpoints become discoverable services that attackers can validate, abuse for inference, and resell as access.
Q: Why do exposed AI agent dashboards and APIs create such a large security risk?
A: They expose the control plane that brokers the agent’s permissions.
Q: What do security teams get wrong about deploying AI safely?
A: They often assume deployment marks the end of assurance, when it actually marks the beginning of continuous governance.
Practitioner guidance
- Enforce authentication before exposure Block any AI service from internet access until authentication, role separation and administrative controls are in place.
- Remove static secrets from deployment artifacts Search compose files, startup scripts and templates for embedded API keys, tokens and credentials, then move them into managed secret storage.
- Restrict agent tool permissions by workflow Limit each agent or orchestration flow to the smallest set of tools, systems and data sources needed for its task.
Bottom line: Exposed AI infrastructure is failing at the access layer, not just at the model layer, because missing authentication and weak defaults leave services reachable before governance exists.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:40 pm
Weak defaults are now an identity-control failure mode in AI infrastructure: the article shows that exposed AI platforms are not primarily failing because of advanced exploitation, but because operators are shipping services before access governance exists. That makes the first control decision who can reach the service, not how clever the model is. For IAM and NHI teams, the lesson is that public reachability plus hidden trust assumptions is a governance defect, not a deployment inconvenience.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How should organisations govern chatbot and agent workflow access?
A: Treat chatbot and agent workflows as privileged systems, not lightweight applications. Separate conversational access from execution rights, scope tool use to a task, and require identity-based controls before any integration can reach data or infrastructure. If a workflow can modify files or call external systems, it needs explicit authorisation and monitoring.
👉 Read our full editorial: Exposed AI infrastructure shows how weak defaults expand attack surface