Exposed AI infrastructure shows how weak defaults expand attack surface

At a glance

What this is: Intruder found widespread exposure across AI infrastructure, including unauthenticated APIs, open agent workflows, and credential leaks.

Why it matters: This matters because AI platforms increasingly sit on top of identity, secrets, and privileged integrations, so missing access controls can turn a simple exposure into broad data and tooling compromise.

By the numbers:

• 1,652 Ollama APIs were exposed with no authentication, out of more than 5,200 exposed to the internet.
• 92 Flowise instances exposed agentic workflows, prompts and integrations, out of more than 2,650 exposed to the internet.
• 25 Langflow instances did not implement authentication, out of more than 300 exposed to the internet.
• 24 Open WebUI instances were lacking authentication, out of more than 12,000 exposed to the internet.

👉 Read Intruder's analysis of exposed AI infrastructure and missing authentication

Context

AI infrastructure is moving faster than the identity and access controls wrapped around it. When self-hosted models, chatbot platforms, and agent orchestration tools are exposed without authentication, the issue is not just public reachability. It is the collapse of basic governance around who can invoke models, inspect workflows, or trigger connected tools, which is where AI security starts to overlap with IAM and secrets management.

Intruder’s research points to a pattern that is now familiar across emerging platforms: insecure defaults, static credentials, and overly permissive access paths arriving before security maturity. That is especially risky in environments where AI systems can reach internal services, automation tools, or code execution functions. The starting position described in this research is not an outlier. It is an early warning that weak identity design is being repeated at scale in AI deployments.

Key questions

Q: What breaks when AI runtimes are deployed without authentication?

A: Without authentication, the service becomes a reachable trust boundary rather than a controlled internal capability. Attackers can probe endpoints, submit crafted payloads, and use built-in export or push functions to move leaked data out of the environment. In practice, unauthenticated access turns one software bug into a much larger exposure problem.

Q: Why do static credentials create more risk for AI agents than for traditional workloads?

A: AI agents execute quickly, can chain actions across systems and may terminate before manual review ever happens. Static credentials remain valid long after the task ends, which means stolen or shared secrets can be replayed outside the intended scope and become a direct path to privileged access.

Q: How do teams know if AI access is too broad?

A: AI access is too broad when a tool can read, write, and export data beyond the immediate task or when the credential remains valid after the use case changes. Teams should look for persistent tokens, shared access paths, and permissions that survive the original business need. Those are the signs of unmanaged standing access.

Q: Who should own governance for exposed AI platforms and agents?

A: Ownership should be shared across IAM, PAM, cloud security, and application teams, with clear accountability for authentication, secret lifecycle, and tool permissions. AI platforms are not just model assets. They are operational control planes, so governance has to cover the identities, privileges, and connected services that make them useful.

Technical breakdown

Why unauthenticated AI APIs become a control-plane risk

An exposed AI API is more than a public endpoint when it can invoke models, process data, or proxy requests into internal workflows. If authentication is absent, any internet user can test, enumerate, and sometimes interact with the service as if they were trusted. The risk increases when the service is connected to paid frontier models, sensitive prompts, or downstream automation. In identity terms, the service itself becomes a privileged machine identity with no enforced boundary, which means the application inherits the trust of whatever it can reach.

Practical implication: require authentication on every externally reachable AI service before any model or integration is exposed.

How open agent workflows turn prompts into privilege

Agent orchestration tools store the logic that decides what an AI system can do, what tools it can call, and what data it can access. When those workflows are exposed, an attacker may not need to compromise the model at all. They can inspect prompts, modify routing logic, or abuse stored credentials tied to tool access. This is an identity problem because the workflow becomes the policy layer for delegated actions, and any weakness there can widen the blast radius from chat exposure to infrastructure manipulation.

Practical implication: treat agent workflows and tool connections as privileged assets, not just application configuration.

Why hardcoded credentials and static secrets are especially dangerous in AI stacks

Static credentials in deployment files, setup examples, or embedded configuration create a long-lived trust path that survives beyond the original install. In AI stacks, that is especially risky because the same secrets may unlock model endpoints, storage, code execution, or third-party tools. Once exposed, those credentials can be reused by attackers before defenders even know the instance exists. This is a classic secrets-management failure, but AI makes the consequences more operational because the same account often spans multiple services and automation layers.

Practical implication: remove hardcoded credentials from AI deployment paths and move to short-lived, centrally governed secrets.

Threat narrative

Attacker objective: The attacker objective is to turn a publicly exposed AI service into a trusted foothold for data theft, tool abuse, or infrastructure compromise.

1. Entry occurs through internet-exposed AI services that lack authentication or ship with weak default access controls.
2. Escalation follows when attackers inspect exposed workflows, harvest embedded secrets, or use connected tools to widen access into internal systems.
3. Impact includes data exposure, workflow tampering, model abuse, and potential code execution through overly trusted integrations.

NHI Mgmt Group analysis

Weak default access is now the defining governance gap in AI infrastructure. The research shows that many AI services are reachable before they are meaningfully governed, which means security is being assumed rather than enforced. That is a familiar identity failure pattern, but AI accelerates it because model endpoints, toolchains, and orchestration layers are deployed together. Practitioners should treat default access as a control failure, not a setup quirk.

AI workflows are becoming non-human policy engines without non-human identity discipline. When a platform can call tools, access files, or route prompts, it behaves like a privileged service identity with delegated authority. The missing control is not just authentication, but lifecycle governance for the identities and secrets behind the workflow. That is where OWASP-NHI and related governance models become directly relevant to agentic deployments.

Static credentials are the wrong trust model for AI systems that can change quickly and interact broadly. If a chatbot or agent can touch multiple internal systems, a long-lived secret effectively becomes standing privilege for software. This is the same governance mistake seen in many machine identity programmes, but AI makes it easier to overlook because the interface looks conversational rather than administrative. The practitioner conclusion is to remove persistent privilege from AI paths wherever possible.

Named concept: AI exposure drift. This research captures the gap between where AI services are deployed and where access control is actually enforced. Exposure drift occurs when a system moves from internal prototype to internet-reachable service without a matching identity review, which turns convenience into hidden attack surface. Teams should use this concept to flag any AI rollout that has outpaced authentication, secrets hygiene, or tool-access governance.

AI attack surface is now a shared concern for identity, cloud, and application security teams. The systems described in the research are not only model problems. They are access-control problems, secrets problems, and integration problems at once. That means ownership cannot sit solely with AI engineering. Practitioners should align control ownership across IAM, PAM, cloud security, and application teams before the next wave of agentic adoption widens the exposure.

What this signals

AI exposure drift will become a recurring governance pattern as teams move from prototypes to production faster than they formalise access control. The practical response is to tie every externally reachable AI service to the same identity review standards used for other privileged workloads, including authentication, secrets management, and connected-tool approval.

The next control gap is likely to be ownership, not technology. When AI systems sit between application teams, platform teams, and security teams, gaps appear in who can approve tool access, rotate secrets, and retire stale integrations. That makes policy clarity as important as technical hardening.

Identity governance for AI will converge with workload identity and secrets lifecycle management. Practitioners who already manage service accounts, certificates, and privileged automation should extend those controls to agentic systems now, before conversational interfaces hide the same old standing privilege problem in a new form.

For practitioners

• Enforce authentication on every AI endpoint Block public access to chat, inference, and orchestration interfaces until each service has a named identity boundary, enforced authentication, and explicit authorization for every connected function.
• Inventory and rotate AI-connected secrets Find credentials embedded in docker files, examples, notebooks, and workflow definitions, then move them into centrally managed rotation with tight scoping and revocation.
• Classify agent workflows as privileged systems Review Flowise-style and n8n-style automations as privileged control planes, because exposed prompts, routing logic, and tool permissions can reveal or extend access.
• Limit tool access by business function Separate AI systems that answer questions from those that can write files, execute code, or query production services, and require explicit approval for high-risk actions.
• Test exposed AI services from the attacker’s view Simulate unauthenticated access, credential reuse, and workflow tampering against internet-reachable AI assets, then prioritise remediation based on reachable integrations.

Key takeaways

• AI infrastructure exposure is still being driven by missing authentication, weak defaults, and exposed workflows rather than advanced exploitation.
• The scale of the problem is large enough to turn a public AI endpoint into a privileged entry point for data theft and tool abuse.
• Identity, secrets, and workflow governance need to be applied to AI systems before internet exposure becomes the default deployment state.

Key terms

• AI-driven Exposure Drift: AI-driven exposure drift is the growing gap between where sensitive data is actually travelling and where security teams believe it is travelling. It appears when AI tools, browser apps, and shadow workflows move data faster than classification and manual review can keep up.
• Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full report

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

• Detailed inventory of exposed AI services, including per-technology counts and the exact exposure patterns observed.
• Examples of open agent management platforms, chatbot instances, and model endpoints with missing authentication or visible credentials.
• Lab findings on insecure defaults, hardcoded credentials, and root-running deployments that create broader attack paths.
• Notes on newly discovered vulnerabilities and the disclosure context behind them.

👉 The full Intruder research includes the exposed service breakdown, workflow examples, and lab findings on insecure AI defaults.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps identity and security practitioners build the control discipline needed for modern automation and AI-linked services.