Exposed AI infrastructure shows how weak defaults expand attack surface

At a glance

What this is: Intruder reports that exposed AI infrastructure is frequently deployed with missing authentication, hardcoded credentials and open workflows, leaving bots, APIs and agent platforms directly reachable from the internet.

Why it matters: IAM, NHI and AI security teams need to treat AI infrastructure as an access-control problem first, because weak defaults can turn chatbots, agents and tool integrations into broad attack surfaces.

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.
• Intruder found 24 Open WebUI instances lacking authentication, out of 12,000+ exposed to the internet.

Context

AI infrastructure is the tooling layer that hosts models, chat interfaces, orchestration platforms and external integrations. When that layer ships with missing authentication or weak defaults, the risk is not confined to the model itself. It extends to prompts, credentials, workflows and any connected business system that the interface can reach.

The governance gap is familiar even if the packaging is new. Teams are treating self-hosted AI platforms like low-friction developer tools, then discovering that they behave like privileged internet-facing services once they carry credentials, integrations and code execution features. The identity question is central: who can access the platform, what can it reach, and what is exposed before controls are added.

Intruder’s sampling suggests the starting position is not exceptional but systemic across AI deployments. The pattern is typical of fast adoption, where convenience and time-to-value outrun authentication design, credential hygiene and boundary enforcement.

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. The failure is not only unauthorized usage. It is the conversion of a machine service into a tradable identity surface with cost, data, and internal access implications.

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. If authentication is weak or defaults are unsafe, an attacker can inherit the agent’s connected access, pivot into linked systems and use the agent as a launch point for broader operational compromise.

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. AI systems need ongoing validation of outputs, access paths, and data exposure because behaviour can change with each interaction. Without that, the control model is already stale when the first live session starts.

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.

Technical breakdown

Missing authentication turns AI services into public control planes

Many AI tools are designed to be easy to start, so authentication is often disabled or left for the operator to configure later. That creates an internet-facing control plane where anyone who reaches the service can interact with prompts, workflows or admin functions. In identity terms, the system is treating access as optional rather than a prerequisite. Once the platform is exposed, any embedded integrations inherit that trust boundary, including model endpoints, document search and agent orchestration features. Practical implication: treat first-run authentication as a mandatory control, not an optional hardening step.

Practical implication: require authentication before any AI service is reachable beyond a restricted management network.

Hardcoded credentials and plaintext secrets expand NHI exposure

A deployment can appear to be protected while still embedding secrets directly in compose files, setup examples or local configuration. That is an NHI problem because the platform depends on machine credentials, API keys and tokens to reach models and third-party systems. If those secrets are static or reused, the compromise path is straightforward: one exposed instance can reveal credentials that unlock other services. The article’s examples show that AI stacks often combine public reachability with stored credentials, which collapses the separation between interface access and downstream system access. Practical implication: move secrets out of deployable artifacts and into managed lifecycle controls.

Practical implication: remove static secrets from build and deployment files, then rotate any credential that has ever been exposed.

Agentic workflows create a wider blast radius than simple chatbots

A chatbot mostly mediates conversation, but an agentic workflow can call tools, write files, execute code or touch external systems. That changes the security model from content exposure to delegated action. In the article, exposed Flowise and similar platforms show that once an attacker can modify workflows or invoke tools, they may redirect behaviour, leak data or trigger server-side execution. The key issue is not model intelligence but privileged tool access without strong authorisation boundaries. Practical implication: separate conversational interfaces from executable tools and scope every action to the minimum required context.

Practical implication: isolate agent tool access from user-facing chat surfaces and restrict each workflow to the minimum needed privileges.

Threat narrative

Attacker objective: The attacker wants to use weakly governed AI infrastructure as an entry point into connected data, tools and workloads, then manipulate or exfiltrate them.

1. Entry occurs when internet-exposed AI infrastructure is reachable without authentication, allowing an unauthorised user to interact directly with chatbots, APIs or agent platforms.
2. Credential harvesting occurs when exposed configurations, plaintext secrets or embedded API keys can be read from the service or its deployment files.
3. Escalation follows when the attacker uses the exposed platform’s workflows, integrations or code execution features to reach connected systems and broader business data.
4. Impact is data exposure, workflow manipulation, model abuse or server-side compromise across the systems linked to the AI platform.

Breaches seen in the wild

• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

AI workflow exposure deserves its own named concept: workflow blast radius inflation. When a chatbot becomes an agent platform with tools, credentials and integrations, the access boundary expands far beyond the visible interface. The result is that a single unauthenticated foothold can affect prompts, data stores, downstream APIs and code execution paths. That changes the governance question from securing a model endpoint to containing delegated action across the AI stack.

Hardcoded secrets in AI deployment paths show why NHI lifecycle controls matter earlier than many teams expect. Credentials embedded in compose files or setup templates are not just poor hygiene, they are evidence that machine identity was never designed into the deployment lifecycle. The practical consequence is persistent exposure across copy-pasted environments, which makes revocation and rotation lag behind actual risk.

Agentic AI changes the trust model for identity security programmes. A tool-using system can carry privileges through a workflow even when no human is actively present, which means classic review-based controls are too late if they only inspect already-issued access. Identity governance has to move toward issuance-time policy, scoped delegation and explicit tool authorisation. Practitioners should treat AI agents as governed actors, not as passive software components.

The market signal is not that AI security is new, but that old access-control mistakes are being rebuilt at scale. The article reinforces that convenience-led AI adoption is amplifying the same failure patterns seen in earlier cloud and application rollouts, only with more privileged integrations attached. That should push security leaders to re-evaluate where authentication, secrets control and tool containment sit in their AI governance model.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Workflow blast radius inflation: AI infrastructure becomes materially harder to govern once chat, orchestration and external tool access are combined in one internet-facing service. The access decision is no longer about a single portal, because the portal can now act on behalf of the user or the organisation across multiple systems.

Security teams should expect AI deployment reviews to converge with IAM, PAM and NHI controls rather than remain separate from them. When a chatbot or agent can reach production systems, the relevant questions are who can authenticate, what secrets it can use and what actions it can perform once inside.

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That trend supports the wider governance point here: the surrounding stack, not just the model, is where exposure compounds first.

For practitioners

• 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.
• Separate chat access from execution access Keep user-facing chat interfaces distinct from code execution, file write and external integration functions so a viewer cannot become an operator.
• Inventory exposed AI services continuously Track externally reachable AI platforms, public chatbot endpoints and orchestration tools so newly exposed instances are detected quickly.

Key takeaways

• 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.
• Intruder’s research found large numbers of exposed Ollama, Flowise, Langflow and Open WebUI instances, which shows the problem is broad rather than isolated.
• The strongest control response is to treat AI services, secrets and workflows as governed identity surfaces, with authentication, scoped tool access and secret lifecycle control in place from the start.

Key terms

• AI Infrastructure Exposure: AI infrastructure exposure is the public reachability of tools, orchestration layers or model services that were intended to be controlled. In practice it often combines missing authentication, weak defaults and exposed integrations, creating access to prompts, workflows, credentials and downstream systems.
• 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.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern access, secrets and delegated action across modern identity programmes.