8 Hardened Container Images for Running AI Agents in Production
An AI agent in production is not a typical microservice. It reads instructions that may come from untrusted sources, calls tools, fetches web pages, runs generated code, and often holds credentials to internal systems. Everything it can reach, it reaches from inside a container. That makes the container image one of the most important security decisions in an agent deployment, and one of the most frequently overlooked.
Why Agents Raise the Stakes on the Base Image
Hardened images are good practice for any workload. For agents, several characteristics make them close to essential:
• Agents can be instructed to act: a prompt injection hidden in a document or web page can push an agent toward running commands, so a shell and package manager in the image become tools for the attacker.
• Agents hold valuable credentials: API keys for model providers, tokens for internal systems, and database access make a compromised agent container a high-value foothold.
• Agents process untrusted input by design: fetching URLs, parsing files, and reading emails exposes vulnerable parsing libraries in the base image to attacker-controlled content.
• Agent stacks change quickly: frameworks release frequently, so images are rebuilt often and every rebuild on a vulnerable base reintroduces the same inherited risk.
8 Hardened Container Images for Running AI Agents in Production
1. Echo
Most hardened image catalogs give teams a cleaner starting point and leave the rest to them. Echo is built around the idea that the base image should never become the team's problem at all. Its AI-driven image factory rebuilds popular open source images from scratch with only the components a workload needs, producing CVE-free, drop-in replacements for the Python, Node.js, and other runtime images that agent services are built on. Teams adopt them by changing the base image reference in their Dockerfile.
For agent workloads, the ongoing maintenance model matters as much as the starting point. Agent frameworks move fast, and images are rebuilt constantly, so a hardened base that drifts out of date quickly loses its value. Echo uses purpose-built AI agents to keep its images clean as new CVEs are published: they research each vulnerability, identify affected images, find or develop fixes, apply patches, run compatibility tests, and open a pull request for human review. Critical and high CVEs are triaged within 24 hours and fixed within 7 days, and because fixes can be backported, agent services stay on the runtime versions their frameworks require rather than being forced into upgrades.
Every image is built on SLSA Level 3 infrastructure, signed and attested, and delivered with an SBOM, provenance, and VEX. FIPS-validated and STIG-hardened variants support regulated environments, and Echo shows both fixed and unresolved vulnerabilities so clean scan results can be trusted. The company reports maintaining more than 600 images with a team of 35.
Agent fit: Python and Node.js agent services, MCP servers, and standardized golden images for agent platforms.
Consider: Echo replaces the base and library layers; tool binaries and application code added on top remain the team's responsibility.
• CVE-free base images rebuilt from scratch as drop-in replacements
• AI agents that research, patch, test, and open PRs for new CVEs
• 24-hour triage and 7-day fixes for critical and high CVEs
• Backports that keep agents on the runtime versions they need
• Golden image customization for internal tooling and agents
• Library-level coverage for Python and Node.js dependencies
• SLSA Level 3 builds with SBOM, provenance, VEX, and signatures
• FIPS-validated and STIG-hardened variants
2. Chainguard
Chainguard offers one of the largest catalogs of minimal, hardened images and has invested specifically in AI workloads. Its AI images include CPU and GPU-enabled containers for frameworks such as PyTorch and Conda, alongside secure Python and Node.js runtimes for agents that call AI services over APIs.
Images are rebuilt frequently with patches applied without waiting for upstream distributions, ship with SBOMs and cryptographic signatures, and include FIPS variants. Chainguard also offers Chainguard Libraries for Python, which builds PyPI packages from source to address dependency risk in AI applications.
Agent fit: agents that run inference or training alongside orchestration, particularly PyTorch-based workloads.
Consider: migrating to Chainguard's distroless-style images can require adjustments for agents that expect a shell or common utilities.
• CPU and GPU-enabled AI images, including PyTorch
• Frequent rebuilds with SBOMs and signatures
• FIPS variants and Python library hardening
3. Docker Hardened Images
Docker Hardened Images became free and open source under the Apache 2.0 license in late 2025, making more than 1,000 hardened images built on Debian and Alpine available to every developer. Each image includes an SBOM, public CVE data, SLSA Build Level 3 provenance, and cryptographic proof of authenticity.
Most relevant for agents, Docker has extended its hardening approach to Model Context Protocol servers, starting with hardened images for popular servers such as GitHub, Grafana, and MongoDB. An enterprise tier adds a 7-day SLA for critical CVE remediation, FIPS-enabled and STIG-ready images, and customization.
Agent fit: teams already on Docker Hub, and agents that connect to tools through MCP servers.
Consider: remediation SLAs, FIPS, and customization require the paid enterprise tier.
• Free, open source catalog of more than 1,000 images
• Hardened MCP server images
• SLSA Build Level 3 provenance and public CVE data
4. NVIDIA AI Enterprise Containers
For agents that host their own models, NVIDIA's containers in the NGC catalog, including NIM microservices, are often the practical foundation for the inference layer. NVIDIA scans these containers during development, during publishing, and continuously afterward, and does not allow critical or high vulnerabilities in published containers without a VEX statement.
With NVIDIA AI Enterprise, production branches provide API-stable releases with monthly fixes for high and critical vulnerabilities, and certain branches offer STIG-hardened images with FIPS-supporting cryptography. SBOMs, VEX records, and container signing are available to entitled customers.
Agent fit: agents that run self-hosted models on NVIDIA GPUs.
Consider: these images secure the GPU inference stack; the agent orchestration service usually runs in a separate, general-purpose image.
• Continuous vulnerability scanning with VEX statements
• Production branches with monthly security fixes
• STIG-hardened and FIPS-supporting options on certain branches
5. Red Hat Project Hummingbird
Red Hat introduced Project Hummingbird in late 2025 as an early access program for subscription customers, offering a catalog of minimal, hardened container images built by Red Hat's build system. Images ship with a "zero-CVE" goal, completed functionality testing, and full SBOMs.
The catalog focuses on popular languages and runtimes, including Node.js, Go, Java, and .NET, along with databases and web servers. For organizations standardized on Red Hat Enterprise Linux and OpenShift, Hummingbird offers a path to minimal images within an existing support relationship.
Agent fit: agent platforms running on OpenShift or in Red Hat-centric environments.
Consider: availability and runtime coverage depend on the program's release stage and a Red Hat subscription.
• Minimal, hardened images with a zero-CVE goal
• Functionality testing and complete SBOMs
• Built and supported within the Red Hat ecosystem
6. Minimus
Minimus builds minimal images from source, stripping them down to what applications need and aiming to ship with near-zero known vulnerabilities. It pairs its images with vulnerability intelligence that helps teams prioritize the issues that remain based on exploitability.
That combination suits teams that want smaller images and a clearer view of which remaining risks matter, which is useful for agent services with complex dependency chains.
Agent fit: security-focused teams that want minimal images plus exploitability-based prioritization.
Consider: confirm coverage for the specific AI frameworks and tool binaries your agents require.
• Minimal images built from source
• Exploitability-based vulnerability prioritization
• SBOMs for supply chain visibility
7. Canonical Chiselled Ubuntu
Canonical's chiselled Ubuntu images use its Chisel tool to slice Ubuntu packages down to only the files an application needs, producing distroless-style images that remain based on Ubuntu. For teams whose agents already run on Ubuntu, that keeps library behavior familiar while removing shells, package managers, and unused components.
With Ubuntu Pro, Canonical provides long-term security maintenance, which appeals to organizations that need predictable support windows for production systems.
Agent fit: teams already building on Ubuntu that want a smaller footprint without switching distributions.
Consider: building custom chiselled images for complex agent stacks requires some familiarity with the Chisel tooling.
• Ubuntu-based distroless-style images
• No shell or package manager in runtime images
• Long-term security maintenance through Ubuntu Pro
8. Google Distroless
Google's Distroless images are the original minimal-image approach: they contain only an application and its runtime dependencies, with no shell, package manager, or other programs found in a standard Linux distribution. Variants exist for Python, Node.js, Java, and static binaries.
For agents, removing the shell is a meaningful defense, since commands injected into an agent have far fewer tools to work with. Distroless is free and widely used, which makes it an accessible starting point.
Agent fit: simple API-calling agents with limited system dependencies.
Consider: there is no remediation SLA, and agents that need tool binaries or a code interpreter may outgrow a distroless base.
• No shell or package manager
• Python and Node.js variants
• Free and open source
Matching an Image Strategy to the Agent
Agents differ widely in what they need from their containers. Three common patterns call for different approaches.
Orchestration agents that call hosted models
These agents send prompts to model APIs, call internal services, and return results. They need a language runtime and a set of SDKs, but rarely a shell or system tools. A minimal Python or Node.js image with no shell and no package manager is the right target, and keeping that base continuously CVE-free matters most because these services are often rebuilt many times a week.
Agents that execute code or use system tools
Coding agents, data analysis agents, and agents that browse the web need interpreters, git, or headless browsers, which conflicts with the idea of a minimal image. The practical answer is separation: keep the orchestrating agent in a minimal image and run code execution in a separate, sandboxed container with its own hardened base, restricted network access, and no credentials.
Agents that host their own models
When inference runs locally, the GPU stack dominates the image. Here, a vendor-maintained inference container handles the model layer, while the agent logic runs in a lighter, separately hardened image. Splitting the two keeps the large ML dependency tree away from the credentials and tool access the agent holds.
Hardening That Lives Outside the Image
A clean image is the foundation, but agent containers also need runtime controls that limit what a compromised or misdirected agent can do. These apply regardless of which image a team chooses:
- Run as a non-root user: most hardened images default to this; keep it that way in agent deployments.
- Use a read-only root filesystem: prevents an agent from writing new binaries or modifying its own environment.
- Drop Linux capabilities and apply seccomp profiles: remove system calls the agent never needs.
- Restrict network egress: allow only the model endpoints, tools, and internal services the agent is supposed to reach.
- Deliver secrets through mounts or a secrets manager: avoid environment variables that are easy to read from inside the container.
- Isolate untrusted execution: run generated code in a separate sandbox using stronger isolation such as gVisor or Kata Containers.
Together, a hardened base and strict runtime controls make it far harder for a prompt injection or dependency exploit to turn into a real breach.
FAQ
Why do AI agents need hardened container images?
Agents process untrusted input, call tools, and often hold credentials, so a compromise can reach further than it would in a typical service. Hardened images remove shells, package managers, and vulnerable components that attackers could use through prompt injection or exploited dependencies, and they reduce the vulnerabilities an agent inherits from its base image.
What makes a container image hardened?
A hardened image is stripped of unnecessary components, configured with secure defaults such as a non-root user, scanned and patched to remove known vulnerabilities, and delivered with supply chain evidence like SBOMs, signatures, and provenance. Strong hardened images also stay clean over time through continuous rebuilds and clear remediation timelines.
Should an AI agent container include a shell?
In most cases, no. A shell gives any injected command an easy way to run, and most orchestration agents do not need one. Agents that must execute code or use system tools should do so in a separate, sandboxed container rather than adding a shell to the main agent image.
How often should agent container images be rebuilt?
Frequently. Agent frameworks and dependencies change quickly, and new CVEs are published daily. Many teams rebuild on every dependency change and on a regular schedule, using base images that are continuously patched so each rebuild starts from a clean foundation rather than reintroducing known vulnerabilities.