AI infrastructure and container security are converging on exposure risk

At a glance

What this is: Intruder argues that AI infrastructure and container security are converging on the same exposure problem, with unauthenticated APIs, exposed credentials, and weak access controls appearing across both.

Why it matters: This matters because IAM, PAM, and cloud security teams now need to govern AI services and container estates as part of one exposure surface, not as separate hygiene problems.

Context

AI infrastructure now looks like a fast-moving exposure problem rather than a narrow model-security issue. The article’s core point is that authentication gaps, missing sandboxing, and broken access controls are showing up across AI tooling while containerised estates keep multiplying the places where those weaknesses can be reached.

For identity and access teams, the implication is straightforward: once AI services, APIs, and container workloads are operationally intertwined, the control plane is shared even when the ownership model is not. That makes identity governance, secrets handling, and access scope part of the same risk conversation as container configuration and vulnerability management.

The pattern described here is typical of modern cloud stacks that have grown by addition rather than design. AI infrastructure is not creating a new category of risk so much as making long-standing exposure and entitlement weaknesses easier to see, easier to scale, and harder to isolate.

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 secrets create more risk than ordinary cloud credentials?

A: AI secrets often sit between data sources, model access, and downstream business systems, so a single key can expose prompts, outputs, and linked datasets while also enabling access to adjacent services. The result is a larger blast radius. Teams should assess not only whether a secret exists, but what systems it can reach.

Q: What are the signs that container and AI exposure is failing as one control problem?

A: The clearest signs are unauthenticated endpoints, broad service reachability, repeated secret exposure, and workloads that can call more tools or APIs than they should. When those symptoms appear together, the environment is no longer failing in isolated places. It is failing as a connected exposure chain, which means scanning, identity, and configuration controls are not aligned.

Q: How should teams govern AI infrastructure when container risk and service exposure overlap?

A: Teams should govern them as a shared trust surface with one inventory, one access model, and one remediation queue. That does not mean every control is identical, but it does mean AI services, containers, and their secrets cannot be reviewed in separate silos. The right question is whether any exposed path can lead from public reachability to privileged internal access.

Technical breakdown

Why exposed AI services fail authentication governance

AI services often expose APIs that are expected to mediate between users, agents, and downstream tools. When those APIs are unauthenticated or weakly protected, the service is effectively operating without a reliable trust boundary. The article points to exposed credentials and open agent platforms, which means the real failure is not simply that an endpoint exists, but that the service accepts requests without proving who or what is calling it. In practice, this breaks basic control over identity, authorization, and request provenance.

Practical implication: Treat AI service authentication as a prerequisite control, not a later hardening task.

How container sprawl turns exposure into repeated access paths

Containers change security because each microservice, image, and orchestration layer adds another potential entry point, and each one can carry its own configuration and dependency mistakes. That creates a larger attack surface than a single monolithic application, especially when teams inherit many small trust decisions across registries, runtimes, and service-to-service communication. The article’s reference to container security mess and recent breaches reflects this distributed exposure model, where attackers do not need a single dramatic failure if several smaller ones are reachable in sequence.

Practical implication: Map container discovery, configuration, and runtime access as one continuous exposure chain.

What missing sandboxing means for AI and workload trust boundaries

Sandboxing is the control that limits what a compromised or over-privileged component can touch next. In AI infrastructure, missing sandboxing matters because agentic or tool-using systems can move from prompt processing into API calls, file access, or infrastructure actions if boundaries are too loose. In containerised environments, the same issue appears when workloads can reach more services, secrets, or management interfaces than their job requires. The problem is less about a single exploit and more about letting one compromise turn into a broader trust violation.

Practical implication: Design workload and agent boundaries so one compromise cannot inherit broader platform trust.

Threat narrative

Attacker objective: The objective is to turn exposed AI and container services into durable access to higher-value cloud or platform resources.

1. Entry occurs through unauthenticated APIs, exposed credentials, or open agent platforms that can be reached directly from the internet.
2. Credential access or misuse follows when attackers find secrets, master keys, or weakly protected service endpoints inside the exposed environment.
3. Escalation happens as attackers move from one service or container to adjacent systems that share dependencies, permissions, or cloud access.
4. Impact is the compromise of broader AI infrastructure or container estates, including unauthorized access, data exposure, or platform abuse.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

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

AI infrastructure exposure is now an identity governance problem, not only a cloud hygiene problem. The article shows unauthenticated APIs, exposed credentials, and open agent platforms in the same environment, which means access control has become the common failure domain. When services, workloads, and agents all consume the same secret and entitlement model, identity governance has to extend into AI runtime and container operations. Practitioners should treat service identity and API trust as first-class governance assets.

Container sprawl creates entitlement drift faster than traditional review cycles can catch it. Hundreds of microservices and supporting components multiply the number of places where access can be mis-scoped, forgotten, or inherited too broadly. That makes the risk less about a single misconfiguration and more about unmanaged growth in reachable permissions. The named concept here is exposure chain governance: the accumulation of small access paths that together form a viable attack route. Practitioners should design controls around the chain, not the individual service.

Missing sandboxing is the control gap that turns AI tool use into infrastructure reach. Once an AI system can call tools, access secrets, or act on behalf of a user or workload, the absence of hard execution boundaries becomes a privilege escalation problem. This is especially important where agent platforms and containers coexist, because a weak boundary in either layer can amplify the other. Practitioners should assume the boundary will be probed and enforce it before the agent or workload can cross it.

The article validates a broader market shift toward exposure-first security for AI and containers. Security teams are no longer dealing with a clean split between model risk, application risk, and infrastructure risk. The operational reality is that AI services inherit the same identity, secret, and configuration failures that have long affected cloud estates, only with faster shipping velocity. Practitioners should reassess whether their current scanning and governance model can see across those seams.

What matters now is control convergence, not category ownership. The teams that will manage this risk best will not ask whether it belongs to appsec, cloud, or IAM. They will build shared visibility over exposed services, credentials, and workload permissions, then assign control ownership accordingly. Practitioners should align AI infrastructure review with the same governance model used for sensitive container and workload access.

From our research library:

• 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.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Exposure chain governance: AI infrastructure and container estates now need governance based on the full path an attacker can traverse, not just on whether a single service is hardened. A system can be individually patched and still be dangerously reachable if its API, secret, and runtime boundaries are not aligned. Practitioners should make reachable trust paths visible before they try to prioritise remediation.

The overlap between AI tooling and containers also changes how teams should read vulnerability data. A high CVE rate matters less in isolation than whether those vulnerabilities sit inside services that are public, credential-bearing, or able to touch cloud control planes. Practitioners should use that context to separate noisy exposure from genuinely exploitable reach.

For practitioners

• Inventory exposed AI services and container entry points Build one exposure register that covers public AI endpoints, container registries, and any service reachable without explicit trust validation.
• Require authentication before any agent or API interaction Block unauthenticated access to AI tools, agent platforms, and internal service APIs, then verify that every request is tied to an accountable identity.
• Review secrets that sit inside build and runtime paths Search for exposed credentials across images, orchestration configs, logs, and deployment pipelines, then remove any secret that can reach a workload boundary.
• Separate sandbox boundaries from platform trust Limit what AI workloads can reach after initial execution, especially where tool use, API calls, or cloud actions are delegated from the same runtime.

Key takeaways

• AI infrastructure and containers are converging on the same exposure problem, with identity and access controls sitting at the center of it.
• The evidence in the article points to unauthenticated APIs, exposed credentials, and open platforms, which creates a repeatable attack path rather than an isolated weakness.
• Teams should manage AI services, secrets, and container reachability as one trust surface or risk losing visibility over how attackers move across it.

Key terms

• Exposure Chain Governance: Exposure chain governance is the practice of managing the full route an attacker can use across services, secrets, and workloads. It focuses on connected access paths rather than isolated findings, because small misconfigurations become more dangerous when they line up into a usable attack route.
• Workload Boundary: A workload boundary is the point where one component should stop and another should begin, especially for containers, services, and AI agents. Strong boundaries limit what can be called, read, or delegated after initial access, which is essential when systems share infrastructure and credentials.
• Unauthenticated Management Endpoint: A service interface that allows operational actions without verifying identity first. In practice, this is a privileged path exposed as if it were public. When such an endpoint can create files, change state, or reach internal systems, it becomes a direct control-plane risk rather than a simple application bug.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

Deepen your knowledge

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 practitioners build the control model needed to govern exposed services, credentials, and access paths across modern environments.