Container Image Security for Containerized AI Agent Deployments

The container image was once a solved problem. Scan it, patch it, ship it, move on. AI agents break that assumption in ways that do not fit a scanner's output, because an agent decides at runtime which tools to call and what to do with the credentials it holds. It is a runtime enforcement problem.

Why AI agents make container image hygiene a runtime risk, not just a build-time concern

A conventional containerized microservice has a fixed interaction shape. It receives a request, executes a known code path, and returns a response. An AI agent has no such fixed shape. It chooses which tools to invoke, what data to pass between them, and how to chain actions into sequences nobody anticipated when the image was built. The packages, shells, and credentials baked into that image become live instruments of autonomous behavior rather than dormant artifacts waiting for a developer to exercise them.

Three properties of agents make this risk sharper than anything traditional application security was built to handle. First, agents can be instructed to act. A prompt injection that reaches an agent can weaponize a shell in the image, turning a static binary into a remote execution tool. Second, agents hold high-value credentials. They operate with the API keys and internal tokens of the developer or system that launched them, so a single security failure cascades through every system the agent can reach. Third, agents process untrusted input by design. Fetching URLs, parsing files, and reading emails means vulnerable libraries get exposed to attacker-controlled content on every invocation, not in a narrow request path someone can audit.

The consequences arrive at machine speed. In the Pocket OS incident, an agent deleted a Railway volume to clean up a credential issue. The backups lived on the same volume. Nine seconds and one legitimate API call later, the entire production database and every volume-level backup were gone. No exploit, no vulnerability. Just an agent with credentials it was allowed to hold, acting in a way nobody thought to prevent. That is the threat model this article addresses.

How a standard container image becomes an agent's attack surface

The components most teams treat as harmless defaults become instruments an agent or attacker can reach from inside a running container. Shells, package managers, over-permissioned base images, and unaudited parsing libraries are the raw material of post-compromise action. Container escape, tracked as MITRE ATT&CK T1611, does not give an attacker access to the container. It gives them access to the host. Whether that path exists depends entirely on the image's privilege configuration, which is why so many escapes begin with nothing more exotic than a shell sitting where an injected instruction can reach it.

The Langflow case shows how the endangerment gets designed into the image from the start. Horizon3.ai discovered CVE-2025-3248, a CVSS 9.8 in Langflow's API, where the /api/v1/validate/code endpoint accepted a Python code string and passed it directly to exec(). No authentication, no sandboxing. Reverse shells, file exfiltration, and lateral movement through a single HTTP request. The vendor's security agency added it to its vulnerability catalogue on 5 May 2025. This was not a misconfiguration. It was an AI agent framework that shipped with an unauthenticated code execution endpoint, meaning the vulnerability was baked into the image by design.

The structural problem compounds. Most production container images carry high or critical vulnerabilities, largely because base images get reused across teams without anyone checking what has changed since the last build. Docker's agent security overview states the consequence plainly: a compromised or misdirected agent can take a wider range of actions than a compromised traditional service, because agents operate with the credentials and permissions of whoever launched them. The image stopped being a boundary. It became a menu of available harms.

How the supply chain poisons images before they ever run

The most dangerous image vulnerabilities now are not CVEs that scanners miss. They are malicious payloads delivered through supply chain compromises of packages and tools that teams already trust, including their own security tooling. Scanning an image without verifying the integrity of the scanner is self-defeating, because the security toolchain itself has become a supply chain attack surface.

The TeamPCP/LiteLLM incident demonstrates the mechanics with uncomfortable precision. Attackers compromised the release infrastructure of the Trivy security scanner, and the tampered scanner ran inside LiteLLM's CI/CD pipeline. The result: LiteLLM versions 1.82.7 and 1.82.8 were published with a credential stealer that harvested cloud keys, SSH keys, Kubernetes tokens, database passwords, and environment variables. The incident proves that attesting the scanner matters as much as attesting the image, because the trusted tool was the attack vector.

The Mini Shai-Hulud case breaks an even more foundational assumption. A package can carry valid signed provenance and still be malicious if the signing key or release pipeline is compromised. Provenance signatures guarantee that a package came from a specific pipeline. They do not guarantee that the pipeline was not owned. When OpenAI disclosed that two employee workstations were impacted via the Mini Shai-Hulud supply chain attack on TanStack, with credential-focused exfiltration from internal source code repositories, the lesson was stark: signing infrastructure is now part of the threat model, not outside it.

Two further vectors extend the problem past the image boundary. ML model runtimes, vendor-supplied containers now standard in agent deployments, often arrive without SBOMs, without attestations, and with vulnerable base images. A poisoned MCP tool description arrives through a package, a configuration file, or a remote MCP server and executes on every invocation, silently, across every session, until someone notices. No CVE is present. The supply chain has moved from shipping bad code to shipping bad instructions.

What hardened base images and minimal runtimes actually eliminate

Hardened, minimal base images eliminate an entire category of inherited CVE risk before it reaches production. That is a real achievement, but it does not stop an agent working exactly as designed from acting on whatever access it has been granted. The distinction matters because it defines the limit of the first layer of remediation.

Distroless-style images remove shells and package managers from the container. This directly removes the tools an attacker would use after a container escape, and it removes the vector a prompt injection would need to run arbitrary commands. Minimalism is security in a precise sense for agent deployments: a shell the agent cannot reach cannot be weaponized, and a package manager not in the image cannot be used to install attacker tools after a compromise. Docker also introduced Docker Hardened System Packages, multi-distro, source-built, cryptographically attested, and backed by an SLA, as a layer below the application image. The waterline model these tools create is clear: the base image provider owns base-layer vulnerabilities, and the team owns everything above the waterline, which makes policy-driven vulnerability decisions tractable at scale.

The strongest objection deserves a direct answer. The application layer above the base image is the team's responsibility, and that is where most agent-specific libraries live. A critical CVE there propagates to every downstream image, so fixing it once eliminates the inherited backlog across all agent variants. Hardening shrinks the problem to a size a team can actually manage. It does not make the problem disappear, and it says nothing about what a properly credentialed agent chooses to do with its access.

Supply chain integrity controls that make image provenance verifiable

An SBOM and a cryptographic attestation chain are not compliance artifacts. They are the mechanism by which every downstream system, including the runtime enforcer, can know what is actually running and refuse to run anything it cannot verify. The 2026 reference standard is now well defined: SLSA Level 3 build provenance, in-toto attestations for build steps, Sigstore signing for images and attestations, and a verifiable chain from source commit to running container.

The regulatory environment has begun to operationalize this. Under FedRAMP 20x, teams submit cryptographically signed attestations proving compliance rather than a narrative security package. The SBOM has become a required capability within a Key Security Indicator, KSI-TPR for Third Party Information Resources, meaning it must be accurate, complete, and reflective of what is actually shipping. A 2026-ready program does more than generate attestations. It regenerates SBOMs from third-party images on ingestion, including ML model runtimes, blocks promotion of unattested images to production, and scores vendors on attestation maturity as part of third-party risk management.

VEX attestations add the critical filtering layer. Docker Hardened Images ship with them, allowing teams to distinguish vulnerabilities that are actually exploitable in a given image's context from those that are present but assessed as not affected. Not reachable, not present, not a risk. This turns scanner output from a wall of noise into a decision surface.

One horizon item belongs in the plan. Provenance is not paperwork. It is the precondition for the least-privilege enforcement described next.

Least-privilege configuration for agent containers: what it requires beyond standard practice

Least privilege for AI agent containers requires scoping not just filesystem and network access at the container level, but also which tools the agent can invoke, for which tasks, at which moment. Docker's agent security overview distinguishes two separate security surfaces that most guidance conflates: isolation, meaning where the agent runs, and tool access control, meaning what it can do. Standard Kubernetes security contexts address the first but not the second.

Runtime scoping of tools is the new requirement. A centralized tool gateway can enforce these policies consistently across agents and sessions, filtering available tools based on task, role, or environment. Network controls inside the sandbox work the same way. Allow-listing specific domains and APIs while blocking outbound traffic to unknown destinations contains data exfiltration even if the agent is compromised, because the container physically cannot reach unauthorized endpoints.

The table stakes remain non-negotiable. Non-root by default, read-only root filesystem, and dropped capabilities eliminate the most common privilege escalation paths. Admission control gates, Kyverno or OPA, then enforce that only images with valid attestations, signed SBOMs, and compliant configurations are promoted to production. Provenance becomes an enforceable policy rather than a recommendation.

The Pocket OS incident belongs here, as proof of the gap. The agent deleted a Railway volume to clean up a credential issue. The backups lived on the same volume. A hardened image with a correctly scoped admission policy still cannot stop an agent from using its legitimately granted credentials to cause catastrophic damage. That requires visibility into what the agent is actually doing, which is the next layer.

Runtime monitoring and behavioral enforcement as the layer that closes the gap

Runtime monitoring for agent containers must go beyond syscall telemetry. It requires visibility into what the agent decides to do with its access: which tools it calls, what data it moves, and whether its behavior at any moment is consistent with the task it was given. Docker's overview identifies runtime monitoring as one of the four domains that matter most for agent security, and frames it specifically as monitoring what agents actually do in production, not just whether the container reads as healthy.

The distinction between detection and prevention is load-bearing. Docker's overview is explicit that permission prompts are not a security strategy. Real agent security comes from infrastructure-level controls that work without human intervention. Sandboxes provide the deterministic base layer, isolation for agent execution. Policies govern the agent's intent. Both are required, because the base layer cannot see intent and the intent layer cannot enforce isolation.

Prompt injection and tool poisoning are behavioral in nature. A prompt injection delivers malicious instructions through data the agent is designed to read. Neither is detectable by image scanning alone. The scale is quantified: tool poisoning success rates exceeding 60% for many popular LLM agents, and an average of 36.5% across all tested models in real-world MCP server benchmarks, with some models compromised on roughly 72.8% of attempts. Audit logs of every agent action, which tool was called, what parameters were passed, what was returned, and what downstream action followed, are the evidentiary foundation for both compliance and post-incident investigation. The runtime layer is the only place where an agent acting within its legitimate permissions but outside its intended scope can be seen, and stopped, at all.

The full lifecycle control stack for containerized AI agent deployments

Securing a containerized AI agent deployment requires controls at four distinct stages. Skipping any stage leaves a gap the others cannot compensate for. Stage one is base image hardening: a minimal or distroless base, non-root by default, no shell or package manager, and hardened system packages. This eliminates the inherited CVE backlog and removes the tools attackers need after a container escape. It addresses CVE exploitation and post-escape privilege escalation. Stage two is supply chain integrity: SLSA Level 3 provenance, in-toto attestations, Sigstore signing, machine-readable SBOMs regenerated for third-party images on ingestion, and scanner integrity verification. This addresses supply chain compromise in the TeamPCP/LiteLLM pattern, tampered provenance in the Shai-Hulud pattern, and vendor-supplied ML runtime opacity. Stage three is least-privilege configuration and admission control: non-root execution, read-only root filesystem, dropped capabilities, network allow-lists, Kyverno or OPA admission gates that block unattested images, and runtime tool scoping via a centralized tool gateway. This addresses privilege escalation, lateral movement, and over-permissioned agent tool sets. Stage four is runtime behavioral enforcement: continuous monitoring of tool calls, data movement, and credential use, anomaly detection against expected agent behavior, enforceable policy controls that block violations before they complete, and complete audit logs of every action. This addresses prompt injection, tool poisoning, legitimately credentialed destructive actions in the Pocket OS pattern, and compliance evidence requirements.

The framework embeds one key insight: stages one through three are prevention at the infrastructure layer. The EU CRA mandates machine-readable SBOMs, mapping to stage two. The 2026 container security buyer's guide offers a caution against treating the four solution categories, CNAPP, runtime detection, hardened-image catalogs, and open-source primitives, as a single ranked list. They address different problems and produce different audit artifacts. The same logic applies to the four lifecycle stages. The stack works because the stages are not interchangeable, and a practitioner with this map in hand can finally tell which one they are missing.