Every worker a company employs, be it a person or a program, builds on a foundation someone else assembled, and that includes the newest hire on your team. This new hire got to work the moment they arrived, building with what your company already has in place and they’re shipping code at a pace your reviews can’t keep up with. Also, everything they make is going out under your name. If it were a human, they’d spend the first week asking where things live and who maintains what. This one never asks. It treats everything it finds as trustworthy, so everything it builds carries that unexamined trust forward. And because this new hire is an agent that’s working all night at machine-class throughput, the foundational problems that used to surface slowly now surface all at once.

The foundation that nobody audited

The line between a supply chain attack and an AI attack no longer exists. Take a look at what the average foundation holds, because most of it comes from outside the company. For a long time now, public base images have carried hundreds of packages that your application never uses. Every one of those packages adds to the attack surface. Almost none of them ever get reviewed because no team has time to read code it didn’t choose and doesn’t use. In most stacks, something like a ten-year-old Java service is keeping the business running on software whose maintainers stopped patching years ago. Platform teams have been coping in their own ways, usually with a golden-image program somebody built years ago and a scanner pointed at it all. Because the images underneath are so bloated, that scanner cries wolf about four hundred times a week. All of this together is why audit season now eats up most of a quarter.

Attackers know all of this, and they’ve been working on the foundation layer all year. They’ve poisoned packages and developer tools, and they’ve had real success harvesting coding-assistant credentials at scale. Most foundations were built for a world that no longer exists.

What a good foundation takes

The good news is that none of this is unsolvable. A foundation can be strengthened to carry what’s now being built on top of it. It has to meet a few requirements, and each one depends on who does the security work, because when the vendor doesn’t, your team picks up the slack. A foundation holds when every part of it is built from source by someone who signs the work and stands behind it. Nothing should ship that your application doesn’t need, because anything extra adds surface area to defend later. Patching needs the same treatment because new vulnerabilities keep landing no matter how clean an image starts. A fix should come with contractual backing and a date. You should know exactly what’s inside every image the day it ships. And none of this should force you to move your stack onto a different distribution just to get safer images. A migration like that becomes a quarter-long project in its own right, and the foundation can’t protect anything until the move is complete.

This is exactly what Docker Hardened Images were built for. They stay compatible with the Alpine and Debian images teams already run, so adoption amounts to a one-line change to the FROM line in your Dockerfile, with no migration project attached. The images are also minimal by design, carrying only what your application needs, which reduces the attack surface by up to 95% and leaves near-zero critical and high CVEs from day one. The difference is immediately visible in scanning. Scans complete much faster with low noise, and the few findings that do remain are worth directing the team’s attention to. When a CVE does get disclosed, the remediated image is available within seven days of the upstream fix, and what once consumed a sprint of engineering time closes as a pull request. The same evidence carries through to audits, which most organizations will eventually face. Every hardened image ships with a signed SBOM (Software Bill of Materials) and build provenance, a verifiable record of the image’s contents and build process. You present auditors with proof that already exists, and no one needs to spend weeks reconstructing it.

Furthermore, a hardened base image by itself may not be enough, because minimal images almost always need customization before they fit production workflows. Teams add their own CA certificates and init scripts, install additional system packages through apt and apk, or adopt separate products entirely to cover what the base image cannot, fragmenting their foundation across vendors. That’s usually where a hardened foundation breaks down, because customizing an image invalidates the provenance and the SBOM, and with them the assurances you paid for. Not with Docker.

Hardened system packages give everything you add the same built-from-source treatment, ensure your customizations run through the same hardened pipeline, and keep the guarantees intact, with the SLA still behind them. With Docker, the entire foundation stays within a single ecosystem.

One thing stays inevitable no matter how well you do all of this. The software you depend on will eventually go unsupported upstream, and without coverage, the security patches stop, and the compliance answers get harder every quarter. Extended Lifecycle Support closes that gap with commercially backed patches for up to five years past end of life, so the move to whatever comes next happens on your timeline and your terms, instead of upstream’s. That is what a solid foundation looks like, and it has never mattered more, because your newest employee, the agent, is stress-testing what everyone before it built.

The new layer

Agents build on this foundation the same way every human before them has, and the trust it carries passes into what they build. But there’s a new reality now. Agents have created a new layer on top, and it matters almost as much as the foundation itself. They pull packages from the foundation and wire tools together, running what they build as soon as it exists. They’re also non-deterministic and ephemeral. The same task can go differently every run, and the agent session that did the work no longer exists by the time anyone comes back with questions.

Every control in the standard stack was built for a human worker, one with a permanent identity and a predictable pace, whose work can be reviewed before it ships. Agents have none of those traits. The market’s first response was to ask for human permission before every agent action, and when the prompts got too cumbersome, teams moved to isolating agents. That created its own gap because the endpoint tools meant to watch the work sit on the host, and the more you isolate the agent, the less those tools see. There has never been a control surface built for a workflow like this, and retrofitting the old parts leaves teams stuck between prompt fatigue and blind spots.

So Docker built the missing layer, one that adds to your defense in depth without replacing anything you already run. At Docker, every agent session runs in its own disposable, MicroVM-based Docker Sandbox. The sandbox walls the agent off from the host at the operating-system level. Credentials get proxied in for the task at hand and never stored inside, and you decide what gets piped in and out of the box. Our own security team has blocked coding agents on the host outright and runs them in sandboxes with full autonomy, several at a time. An infostealer that lands in one of those boxes finds nothing to grab. Call it YOLO mode with guardrails.

The tools agents reach for are the next layer, built on the same foundation. Agents interact with the outside world through MCP (Model Context Protocol) servers, connectors that let them call external tools and access data. An agent grabbing connectors off the open internet is the package problem all over again. So Docker ships hardened MCP servers through the same catalog as the hardened images, built and signed the same way. The MCP Catalog and Toolkit give your teams one trusted place to find and run them. Every tool call routes through the MCP Gateway, where it is authenticated, authorized, and logged before reaching the external system. That turns enforcement from advisory to strict. 

Docker Scout enforces the policy at build time, so the secure path remains the default without anyone having to police it by hand. And where the box sits stops mattering, whether it’s a laptop or the cloud, because the boundary travels with the work, as Docker containers always have.

The winning playbook already exists

Docker wrote this playbook the first time. In the 2010s, software pulled in parts its builders didn’t control, and shipping outpaced review. Slowing down was never on the table, so Docker packaged the application and its dependencies into one portable, isolated unit, and speed and safety started pulling in the same direction. That bet is a large part of how the modern software supply chain took shape, and now we’re making it again for agents. One foundation and one boundary serve people and agents on the same supply chain, under the same policy. Security gets quieter, and development gets faster. There’s no separate AI security program to buy. Docker has been making the case that security is a developer experience problem from the start.

See it live in San Jose

We’re bringing all of it to WeAreDevelopers World Congress in San Jose, September 23 to 25. Docker’s CISO Mark Lechner will take the stage with One boundary for the agentic era, the boundary his own team lives inside, and the Docker Zone will run live demos all three days.

The newest hire starts Monday either way. What will you have ready for them to build on?

The hardened-images space gets better when more people are working on the problem, and Minimus has been a valuable part of that work. That changed this week, when they announced they are ending operations. Though we were competitors, we both believed strongly in the importance of reducing vulnerabilities at the foundation of the software supply chain. Their efforts to bring needed awareness to this challenge will be missed, and our thoughts go out to Minimus employees who are impacted by this decision.

While the human side of this story deserves the most attention, there’s also a practical side: if you’re a customer running Minimus images in production, you’re now facing a migration you didn’t plan for. Their notice commits to a 60-day maintenance window, with images receiving upstream updates until the registry goes offline on October 22, 2026. Images already pulled will keep running after that date, but no further updates will ship to them, and any new CVE stays unpatched from that point on.

If you need a hand, Docker is offering free migration assistance to Minimus customers. Write to minimus@docker.com to walk through your specific image list, your compliance requirements, or questions around your migration plans, and a technical migration expert will get back to you. You don’t need a sales call to start migrating to DHI today.

Docker’s free, open source catalog is available to everyone under Apache 2.0, allows production use, and has no user caps. The migration is about as easy as these things get, a drop-in with minimal workflow changes. It’s more of a swap than a rebuild. It’s easy to find your images’ equivalents in the DHI catalog, and for most of your services, the whole change is updating the FROM line. Use the migration guide for the step-by-step process and the checklist to track each image through the swap and verification. The worked examples show full migrations end to end, and Gordon, Docker’s AI assistant, runs the first pass with you.

Whether you decide to migrate to Docker or somewhere else, we recommend you start that process now, while the maintenance window keeps your current images patched. You can browse the full DHI catalog on Docker Hub, make the first swap, and, of course, reach out to us if you need help.

Docker Hardened Images

Docker Hardened Images are minimal, hardened images built from source and continuously maintained by Docker. The catalog covers 4,000+ images, compatible with Alpine and Debian, so your Dockerfiles and CI keep working as they are. Every image ships near-zero CVEs with full, unsuppressed CVE visibility, and each carries a complete SBOM, SLSA Build Level 3 provenance, and cryptographic signatures. Docker manages the full lifecycle of your image, and teams moving from standard public images see up to 95% CVE reduction and up to 90% attack-surface reduction. Paid tiers add SLA-backed remediation, FIPS and STIG variants, customizations, and up to five years of coverage for versions past end of life.

MinIO reached end of life in February 2026. Docker Extended Lifecycle Support (ELS) keeps end-of-life software like it patched, compliant, and audit-ready for up to five years, covering versions upstream no longer supports all the way up to entire projects.

On February 13, 2026, the MinIO open-source project was archived upstream. A project with more than a billion Docker pulls stopped shipping releases, bug fixes, and security patches overnight. From that day forward, every environment running MinIO is exposed. New CVEs in MinIO and its Go dependency tree now arrive with no upstream patch behind them, and an audit reads that as unsupported software in production.

And MinIO is only the newest instance of a wider problem. Black Duck’s 2026 Open Source Security and Risk Analysis report found that 93% of commercial codebases carry components with no development activity in at least two years. The same pattern runs across the stack. Node 18, Python 3.8, and older Airflow releases still run in production long after upstream support ended, and frameworks like FedRAMP, DORA, and the Cyber Resilience Act treat unpatched end-of-life software as an audit finding. The migration deadline ends up set by the audit calendar instead of the roadmap.

Docker Hardened Images Extended Lifecycle Support exists to hand that schedule back to you. The model is simple. Request an ELS image, and Docker builds and maintains it for up to five years past upstream end of life. The maintained MinIO image is the newest proof of that model.

MinIO lives on as the newest ELS update

The archive lands on the storage layer, where migrations are measured in petabytes. Moving a production object store to a different system is slow, expensive work, and the CVE exposure keeps growing while that work runs.

Teams running MinIO have three options

1. Move to a commercial replacement and take on new licensing and lock-in.
2. Carry the patches yourself, which means staffing sustained Go security engineering for a project that no longer ships fixes.
3. Keep what you run and put a vendor on the hook for it. 

Doing nothing is not a fourth option. 

Docker identified the archive as a live exposure across its customers’ software supply chains and built the answer into the catalog, where MinIO lives on as a maintained, hardened image. Docker tracks new CVEs across MinIO and its full Go dependency graph, transitive dependencies included at no extra cost, then backports the fixes, rebuilds, and ships. Your object store stays supported and your audits stay clean.

Extended Lifecycle Support for your whole fleet

What ELS does for MinIO, it does for any end-of-life component you need to keep. An EOL finding forces a choice between two bad projects. Rush the migration and risk breaking production, or file the exception and watch the list grow every quarter. ELS removes that deadline. Patches and audit evidence keep flowing on the images already in production while the migration happens on the roadmap’s schedule.

The entitlement is built for how end of life actually arrives, on staggered dates across a fleet. Applied to a repository, it covers every available ELS version there. When one migration completes, you re-point it at the next repository, and the coverage moves with the risk.

Coverage is not limited to a fixed list either. Docker watches the end-of-life calendar and builds ahead of it, and anything you don’t see in the catalog, you can request. The span runs from end-of-life versions of supported software all the way up to entire archived projects. Nginx, Node, and Python ELS images are already there.

ELS is a paid add-on to a Docker Hardened Images subscription, and it runs on the same rails as the rest of DHI:

• Name it, get it. Tell Docker the end-of-life line your production depends on. Docker builds it hardened and maintains it at the line’s newest patch version.
• Adopt without a migration. ELS-tagged images appear in the standard DHI catalog alongside LTS tags. Same registry, same workflow, a FROM-line change.
• Stay patched for years. Critical and high-severity CVEs are patched on a 14-day SLA, for up to five years past end of life.
• Evidence included. Every ELS image holds the same standard as the rest of the catalog. Built from source and signed, with SBOMs, VEX statements, and SLSA Build Level 3 provenance maintained for the life of the image.

Those attestations are the difference between extended support and an extended liability. A legacy app with a giant SBOM and no exploitability data just lights up your scanners. ELS ships the evidence with the image, so auditors see signed proof of what’s patched and what’s not exploitable.

If there’s a version in your fleet you can’t migrate off and can’t leave unpatched, that’s an ELS conversation. Browse the DHI catalog to see what’s already covered, and talk to us about the versions you need to keep alive. 

Everyone has been talking about the OpenAI/Hugging Face incident, and I was initially skeptical that Docker had much to add. After several weeks of customer conversations, I think we do. The useful lesson is not that an AI agent escaped a sandbox. It is what 17,600 actions expose about security systems designed for human tempo.

Hugging Face reconstructed approximately 17,600 attacker actions across a four-and-a-half-day campaign in July, including roughly two and a half days inside its infrastructure.

Put thirty seconds of human review against each action and you get 147 hours of work. Hugging Face grouped those actions into roughly 6,280 clusters; review only those and you still get more than 52 hours. Either way, manual approval and ordinary alert triage were never plausible primary controls for this workload.

This was not a fundamentally new category of attack. If you have any background in incident response, the sequence is familiar: exploit a reachable service, obtain code execution, collect credentials, escalate privilege, and cross the next trust boundary.

What was different was the rate, persistence, and ability to carry authority and state across short-lived environments. The agent could fail, rebuild its tooling, recover its communications channels, and continue from another environment without starting the campaign over. The useful mental model is a capable attacker fused with a fuzzer: it can reason about each result and keep probing without fatigue. That is the AI part of the story.

This is not a commentary on model alignment, and I will offer no opinion here on which model or agent framework you or your organization should use. The security question is familiar: what authority should be given to a workload that can execute code, hold credentials, reach the network, and continue testing paths long after a human would have stopped?

What happened

OpenAI was running internal cyber-capability evaluations against a benchmark called ExploitGym, which tasks agents with finding and exploiting vulnerabilities. The evaluation used reduced refusal behavior and none of the production-grade classifiers a deployed model would normally have.

The agents did not have direct internet access. They were allowed to install packages through an internally hosted package-registry cache. The agents found a previously unknown vulnerability in that permitted service and used it to reach the open internet.

The permitted service was the escape path. That’s the important point in the incident.

From there, the agents escalated privilege inside OpenAI’s research environment, reached a user-hosted CyberGym-style code-execution harness running on an external sandbox, and obtained root inside that harness. The sandbox platform itself was not compromised. Having apparently worked out that Hugging Face might host the benchmark’s reference answers, the agents went after Hugging Face directly, assessing that cheating was the fastest path to a passing score.

Hugging Face’s reconstruction documents local-file disclosure, code execution through a template engine, cloud metadata access, Kubernetes privilege escalation, exposure of a production secret containing 136 keys, access to the corporate network through a stolen credential, and limited write access to source control. It found no evidence that public models, datasets, packages, or released software were modified, and the customer content accessed was limited to a handful of benchmark-related datasets. That is a good outcome relative to what was possible. It is not evidence that the attack path was harmless.

The individual weaknesses were familiar: an unsafe processing path, accessible cloud metadata, broad privileges, long-lived credentials, and a shared administrative identity. A capable human attacker could have chained them, too. The difference was the volume of paths tested, the speed with which a failed path was replaced, and the amount of evidence defenders had to interpret while the campaign continued.

If you want the full blow-by-blow, Hugging Face published a detailed technical writeup and interactive replay. Both are worth reading.

The controls this requires

That arithmetic, not the novelty of the attack, is what changes the operating model. A human cannot sit in the control loop for thousands of actions at machine speed.

There are also two related threat models to account for.

In the first, the agent discovers and exploits a path on its own, as the agents did in this incident. In the second, an external party redirects the agent through a poisoned tool, compromised dependency, malicious document, prompt injection, or attacker-controlled data. In that case, the agent becomes the attack vector.

The same authority is dangerous in either case. The controls therefore have to govern what enters the environment, which capabilities the agent receives, and what happens when its behavior leaves the expected boundary.

What can go wrong	Control required
Untrusted content attempts to change the agent’s instructions	Treat external content as data, never authority; preserve provenance and trust boundaries; do not allow retrieved content to modify policy or grant capabilities
A tool, package, image, or MCP server is poisoned	Strict allowlisting; pin versions and digests; verify signatures and provenance; require SBOMs; scan and review updates before promotion
External data becomes executable input	Use structured and typed tool interfaces; validate and escape arguments; prohibit unsafe shell interpolation and other paths from data to command execution; run commands inside a sandbox and constrain which commands can be invoked
A permitted service becomes an escape path	Expose the narrowest operation-specific interface; scope access by task and destination; monitor permitted paths for behavior that diverges from their purpose
The workload reaches ambient credentials or control-plane services	Remove ambient credentials; use short-lived, task-scoped workload identity; block metadata and control-plane endpoints the task does not require
The workload exceeds its intended execution boundary	Use a hardened isolation boundary; reject privileged workloads, host filesystem mounts, raw device access, and unrestricted host sockets unless explicitly required
State or authority persists beyond replacement of the worker	Govern durable write paths; separate read from write authority; correlate identity and activity across runs
The agent, or an attacker acting through it, crosses into another system	Require explicit authorization for external and destructive actions; scope credentials to the target operation; make write paths observable and revocable
Thousands of individually plausible actions hide behavior that has diverged from the task	Evaluate sequences and bursts against policy and expected behavior; correlate activity across tools and systems; contain at machine speed

The point is not to put human approval in front of every action. That defeats much of the value of using agents and eventually produces approval fatigue. Routine and reversible actions should have very little friction. More sensitive, external, destructive, or unusual actions should receive stronger scrutiny.

Review and sanitization still matter, particularly for packages, tools, and paths where external data could become a command. But sanitization alone is not a reliable answer to prompt injection. Natural-language content is too ambiguous for us to assume we can always identify and remove the malicious part. The stronger boundary is architectural: untrusted content must not be able to grant itself authority, change policy, or create capabilities the agent did not already have.

Done well, governance is not what limits agent autonomy. It is what makes it possible to safely give agents more of it.

Where Docker fits today, and where we do not

We are proud to be founding authors of the Agent Baseline. We worked with other industry experts to distill the problem into six outcomes: Discover, Constrain, Authorize, Observe, Validate, and Respond.

If Docker Sandboxes sit in one specific bucket, it’s “Constrain,” but really, we believe they’re foundational, and where you would instrument or implement all six. They give each agent a dedicated microVM and enforceable boundaries around local compute, filesystem access, and network reach, as well as providing the base (and thus ground truth) layer to observe. That is a real and useful layer.

Docker AI Governance addresses parts of Authorize and Observe by giving organizations a centralized way to define and enforce controls around agent environments, including network and filesystem policies and access to MCP servers and tools.

Together, Sandboxes and AI Governance provide a meaningful part of the answer today: a hardened execution environment and centralized policy enforcement around it. They do not repair a vulnerable service the agent is authorized to contact, narrow a credential issued by another system, or replace the customer’s own security architecture. No vendor, Docker included, can claim its technology would have made this particular incident a non-event.

But a deterministic enforcement boundary is still necessary. It gives an organization one place to apply least capability and least privilege, and one place to observe what the agent was actually allowed to do. If an agent is using a package registry as an egress proxy rather than a package registry, that’s the kind of divergence the telemetry needs to help surface, especially when viewed across a sequence of requests rather than one request at a time.

The broader problem remains difficult. The useful unit of observation is not always one tool call. It may be a burst of activity, a target, a protocol, a credential, or a pattern visible only across systems. A package request can be normal. Repeatedly probing the service behind it, discovering credentials, and using them to reach another system should change the assessment.

That’s the agent-security challenge beyond basic containment. We need to constrain authority, but also observe activity at the right granularity, recognize when it deserves more scrutiny, and respond at the same tempo as the agent. For all of us, Docker included, there is still substantial work ahead across observation, validation, and response.

The operational tradeoff

Security, capability, and autonomy all matter, and they will always be in tension. Said differently, none of this is free.

Short-lived credentials expire during long-running tasks. Narrow egress policies break legitimate package installation. Admission controls reject tools developers assumed they could run. Cross-system detection costs money and produces false positives. A write approval inserted at the wrong point can eliminate most of the productivity the agent was supposed to provide.

Teams will be tempted to loosen each control until the agent works again. That is understandable. The failure mode created by a strict policy is immediate and visible; the failure mode created by excessive authority remains invisible until an incident.

The answer is not to remove the controls or ask a human to approve everything. It is to make friction proportional to consequence, test the failure modes, measure the operational cost, and weigh it against the risk and potential blast radius.

How I work

I use agents every day, and I assume that a sufficiently capable agent will eventually try something I did not anticipate (perhaps on a daily basis…).

For the most part, I do not run one general-purpose agent with access to everything. I use task-focused agents, each packaged as a separate kit, built on free Docker Hardened Images and run in Docker Sandboxes.

Each kit starts with a specific job, then receives only the software, network access, files, credentials, and external capabilities required for that job.

In most cases, the agent has very few restrictions inside its sandbox. That is intentional. What matters is that god mode inside the sandbox does not become god mode over my laptop, my credentials, or every service I can reach.

I do a lot of desk research. Those agents can access the open internet. They’re not useful if they can’t. But their image has no compilers, package manager, general-purpose network debugging tools, or development toolchain, and it runs with deliberately limited system permissions. They can retrieve and analyze public information, but have very little machinery with which to turn something they encounter into an exploit or act on another system. They have no reason to hold my source code or production credentials.

My production coding agent has a much richer environment. It runs pi, can use multiple models, compile code, run tests, and use the tools required for real engineering work. Its network access is restricted to an explicit allow list of services I use, including Docker, GitHub, Snowflake, and Cloudflare. It does not receive arbitrary internet access or arbitrary tools simply because a coding task occasionally needs the network.

My home kit can interact with an Arduino, but it does not receive direct access to the host or the device. A host-side MCP server brokers the allowed operations. The agent can request a defined Arduino capability through that interface; it cannot turn that permission into general access to every device connected to the machine.

My development kit is where I experiment. It runs with balanced network access, but no ambient host secrets and no unrestricted access to host files. When it needs Google Workspace, Snowflake, or another host service, host-side daemons broker those calls. The agent sees the capability I have chosen to expose, not the underlying credential or the rest of the service. Those brokers can enforce which operations are allowed and which are blocked.

These are deliberately different environments. The research agent would be poor at production coding. The coding agent cannot reach every site the research agent can. The home agent cannot turn an Arduino operation into arbitrary host access. The development agent can query a service without possessing the credential that authorizes the query.

That constraint is the feature.

Conclusion: Security at agent speed

The OpenAI/Hugging Face incident was not the failure of a single boundary. It was a chain of reasonable-seeming permissions and familiar weaknesses that became something very different when an agent could test thousands of paths, preserve state across runs, and carry authority from one system into the next.

We will not anticipate every vulnerability an agent might find or every way it might combine the access we give it. The architecture cannot depend on perfect agent behavior, perfect software, or a human noticing every dangerous action in time.

So, the starting point is still least capability and least privilege: give an agent the narrowest interface, credentials, tools, and network access its task requires. Put those controls at a deterministic enforcement boundary. Make the resulting activity observable, not only as isolated requests, but as sequences and patterns across systems. When the behavior leaves the expected envelope, containment has to happen at agent speed.

Docker Sandboxes and Docker AI Governance provide important parts of that architecture today: hardened execution boundaries and centrally enforced policy around them. They do not secure every service an agent is permitted to contact, and they do not eliminate the need for an organization to decide what authority each agent should have. The broader work across Discover, Constrain, Authorize, Observe, Validate, and Respond is why we helped create the Agent Baseline in the first place.

The goal is not to build an agent that never tries the wrong thing. The goal is to build a system where trying the wrong thing does not give it the keys to everything else.

Supply-chain attacks have stopped being isolated incidents somewhere in the past year. The compromises now reach the tools the industry trusts to defend itself, with Trivy and KICS among this year’s targets. Mark Lechner, Docker’s Chief Information Security Officer, called the latest wave ‘a permanent shift in the threat landscape’, and the months since have borne that out. The volume is growing at the same time. Over a quarter of production code is now AI-authored, and agents pull in dependencies at machine speed. If you run a platform team or a security program, this is the math you are already living with. More code and more images arrive every week, almost none of it written by your own engineers, and all of it has become your responsibility the moment it ships.

None of this is news to us. Securing the software supply chain is the problem we’re here to solve. The latest round of updates widens the trusted foundation Docker is building under your supply chain, and tightens how it’s enforced. More of the software inside your images is now built and patched by Docker itself, and security coverage continues after software reaches end of life. Images can be tailored to your environment without losing their guarantees, and policy enforcement now reaches every developer machine.

A trusted foundation for the whole supply chain

It all starts from one principle, and Docker Hardened Images was built on it. Security that doesn’t get adopted doesn’t secure anything. The entire catalog is free for every developer, because a secure baseline shouldn’t be a premium feature. Every image is compatible with Alpine and Debian, the distributions your teams already run, and Docker builds every one of them itself, from source. Adoption is a FROM-line change, not a migration project. And every image is independently verifiable, with signed SBOMs (software bills of materials) and SLSA Build Level 3 provenance, so your auditors work from evidence instead of vendor claims.

A year in, the numbers make the case. The catalog has grown past 4,000 hardened images, plus MCP servers, Helm charts, and ELS images. It draws more than 3.5 million pulls a week, with over a million builds running regularly to keep all of it patched, and open source projects like n8n run production on DHI. The catalog grows the way it always has, driven by what customers request. But the goal was never just a catalog. The goal is one trusted foundation under your whole software supply chain, where the images you run, the packages inside them, the charts that deploy them, and the tools your agents call all carry the same provenance. Security becomes the default from day one, and it holds, without asking your teams to change how they work.

Built from source, down to every package

The hardening keeps reaching deeper into the stack. Docker Hardened System Packages take hardening below the image, to the packages inside it, across both Alpine and Debian, with every package built from upstream source, patched, and maintained by Docker in the same SLSA Build Level 3 pipeline that builds the images themselves. And the repository behind them is open to more than the catalog. DHI Enterprise customers can point apt or apk directly at Docker’s hardened package repository and bring the same packages into images they build themselves, extending the hardened supply chain beyond the images Docker ships to every image your organization builds.

The coverage keeps widening. What began with Alpine now spans Debian, with Python, the catalog’s most pulled image, among the first to ship fully hardened. The work compounds every week, and the Debian and Alpine package lists are public, so you can watch the catalog harden in real time.

If you’ve spent time chasing base-image CVEs, you know why this matters. System packages are notorious for slow fixes; a patch can sit waiting on the distribution’s next release for months or years. Docker doesn’t wait. We patch at the package level, ahead of upstream when it counts, and the fix lands in every image that uses that package, in one build wave instead of image by image. Entire businesses have been built on delivering community-distribution security updates faster than the community. With DHI, that speed is included.

The guarantees hold up under inspection, too. Packages you add through DHI customization, tailoring an image to your workloads, come from that same hardened repository, not an unverified public mirror, so they are hardened system packages in their own right and the SLA that covers the base image extends through everything you add. And because one vendor stands behind the image, the packages inside it, the CVE investigation, and the patch, your auditors get a single chain of signed provenance instead of a stack of vendor assurances.

Your distribution, meanwhile, stays your distribution. Building a hardened package ecosystem from source is a serious engineering commitment, and Docker made it twice, for Alpine and for Debian, so keeping your house standard never costs you your security posture.

Patch past end of life

Production software has a habit of outliving its maintainers. Migrations wait on budgets, dependencies, and test cycles, and CVEs don’t wait with them. That’s the problem DHI Extended Lifecycle Support (ELS) exists for. It keeps end-of-life software patched, with SBOMs and provenance maintained, for up to five more years.

ELS isn’t limited to a set catalog, either. Docker watches the end-of-life calendar and builds coverage ahead of it, and anything you don’t see, you can request. MinIO is the newest addition. Upstream archived the project in February 2026, yet in the DHI catalog it lives on, patched and hardened, and your migration runs on your schedule instead of upstream’s.

Customize at scale, manage as code

Nobody runs stock images in production. You add CA certificates, agents, and the packages your applications demand. The trouble is that in most of this market, the first change you make is where the vendor’s guarantees end, and everything after it is yours to carry. DHI customization works the other way around. You define what your images need, and Docker manages the full lifecycle of your customized images, rebuilding them through the same hardened pipeline on every upstream patch. The SBOM, the attestations, and the SLA travel with the customization instead of dying at it.

Customization operates at scale, too. Bulk customizations run through the UI, CLI, and API, with YAML configuration and GitHub Actions support, so you can tailor hundreds of repositories in one pass and let the rebuilds take care of themselves. And if your platform runs on Terraform, customization is code as well. The DHI Terraform provider mirrors and customizes hardened images with the same pull requests and reviews as the rest of your infrastructure.

The savings are real infrastructure, not a rounding error. Customers tell us they’ve shut off the CI pipelines that existed only to rebuild images, because Docker rebuilds for them. The blind redeploy cadence goes with those pipelines. You ship an update when a fix actually needs to go out, knowing exactly what changed, instead of rebuilding everything on a schedule and hoping QA catches what moved.

For organizations whose data-residency requirements keep images inside the EU, EU-hosted customizations arrive in September. Your customized images will live in Docker Hub’s EU region with the same SBOMs, attestations, and SLA as everywhere else. Residency stops being the reason your hardening program waits.

Harden beyond base images

The same standard keeps moving up the stack. The catalog now carries fully supported Helm charts, so your Kubernetes deployments start hardened too. And it carries a growing set of hardened MCP servers, because the tools your agents call deserve the same scrutiny as the images they run on.

Govern it all with Docker Scout policy

Scanning tells you what’s wrong. Policy is how you keep it from shipping. And enforcement is where most supply-chain programs quietly fail, because hardened artifacts only protect you when your teams actually use them. Developers move fast and default to what works, and the developer machine is exactly where the current wave of attacks aims.

Docker Scout policy closes that gap. It evaluates flexible, customizable policies from the CLI and inside CI, and it ships with the same policies Docker uses to verify every hardened image in the catalog. The policies are written in Rego, the industry standard, and they’re portable, so the same rules that gate a build in your CI travel with your teams to every developer machine in your organization. Gating at the registry matters, but it stops at the registry; developers can route around it all day. Policy that travels to the machine is how you hold every image you run, and every image your teams build, to the bar Docker holds itself to.

It’s an additive control. It works alongside the scanners you already run, and it’s already in the Docker subscription you have.

The foundation is already in your stack

The supply-chain problem is not going to shrink. More code is coming, agents are becoming contributors, and the patch windows regulators expect keep getting shorter. Point tools won’t carry that weight. A foundation that’s secure by default will, backed by an ecosystem that keeps it that way. That is exactly what Docker’s security portfolio delivers. Hardened content on the distributions you already run, customization that keeps its guarantees, support that outlasts upstream, and policy you control, from one vendor accountable for all of it.

And none of it asks you to adopt something new. It’s all in the Docker you already run. Your builds, tools, and pipelines stay the same. Your CVE count doesn’t.

Browse the DHI catalog and pull your first hardened image today. And if you want the full story, how all of this works together, with your questions answered live, join our live webinar in early September. We’d love to see you there.

Now in Docker AI Governance: a single searchable record of every policy decision your agents trigger, streamed to the SIEM your security team already runs, so you can show what your agents did and what your policy stopped.

Today, Docker AI Governance now streams every policy decision in your organization into the SIEM your security team already runs, with a searchable record of all of it in Docker Cloud. You can see what your agents did, and what your policy stopped them from doing.

Enforcement is step one

When we launched AI Governance in May, our perspective was that controls have to live at the runtime layer where the agent actually executes, not as advisory rules a clever prompt can route around. Audit was one of the three layers we shipped on that principle, and the enforcement point has produced a structured event for every policy evaluation since day one.

Today, we’re making it easier to view and consume those events.

Why audit records matter

Security leads need to answer questions about agent behavior: what did that agent do, was it allowed, and which policy made the call.

Answering it should not require assembling evidence from machines they don’t administer. It should mean querying a system they already use. Increasingly it also comes first rather than after: security teams want a demonstrable audit record before they approve agent deployment at all.

What only the enforcement point can see

A policy decision has three outcomes. The action was allowed, it was denied, or it was held for a human.

A log collector can reconstruct the first one. Nothing outside the enforcement point can see the other two. A collector reads what an agent produced, so it never sees the tool call that was refused, the domain that was unreachable, or the credential that was requested and withheld. Those events leave no trace in output, because the process that would have produced the output never ran.

That is the difference between a record generated at the point of decision and logs gathered after the fact. A record of allowed actions shows that agents are active. A record of denials shows whether your controls are doing anything.

Audit Logs: Streamable to your SIEM tools

Audit logs are now available in Docker Cloud, and audit events can stream directly to your SIEM. Both are included with Docker AI Governance.

Audit logs in Docker Cloud. One searchable view for the whole organization, with 90 day retention and CSV export. Local disk delivery keeps working, and both modes can run at once.

Native SIEM streaming. Point Docker at your endpoint and forward audit records to the tools you already run, including Splunk and Dynatrace, via a generic HTTPS connection.

Coverage

Records cover Docker Sandboxes policy decisions and sandbox session events, for users with an AI Governance license under an enforced organization policy. Other source records (MCP Gateway enforcement decisions, for example) will share records through the same schema as they become available, so coverage will expand without extra integrations on your end.

Records are metadata only. They never contain your prompt content, agent output, or parameter values.

What’s next

Records are step one.

Once every decision an organization makes about its agents lands in one place, the useful question stops being what happened and starts being what should change. That is the direction we’re building toward: a system that tells you when something is off and what to do about it. More on that soon.

Available today

Audit logs are live for organizations on Docker AI Governance with an enforced organization policy. Read more here.

What does it take to secure AI agents without slowing developers down? A recent panel explored the answer 

I recently joined Zach Lloyd, founder and CEO of Warp; Gavriel Cohen, co-founder and CEO of NanoCo and creator of NanoClaw; and moderator Moriah Hara, founder of a community of more than 3,000 CISOs and a three-time Fortune 500 CISO, for a discussion on one of the biggest challenges facing enterprise security teams today: how to safely unlock the productivity of agentic AI.

The rapid rise of agentic AI in the enterprise is putting CISOs in a tough spot. On one hand, business leaders are clamoring to run with the new technology, which promises a productivity revolution like no other. On the other, setting AI agents loose without rigorous guardrails creates severe vulnerabilities. 

Moriah put the dilemma facing CISOs like this: “The business wants AI agents everywhere, developers are already using them, sometimes without approval, oftentimes without security.
…CISOs are left in this uncomfortable middle where we’re tolerating some tools, we’re praying that nothing breaks, we’re buying some time until we can get some governance beyond policy in place to have better visibility.”

The panel explored the role of the CISO in balancing this tension between productivity and security. Here are some highlights.

Isolate, control, observe

They came at it from different angles, but the panelists agreed on one imperative: running AI agents safely requires an isolated environment with trusted control boundaries. For Zach, Warp’s Oz platform provides that isolation. It’s a cloud agent infrastructure for secure and automated deployment of coding agents that allows centralized management, access controls, and visibility into what agents are doing across the organization.

Zach said you can “literally pull up the Oz web app and see what every agent across your company is doing at all times—which is a way better situation than the world we’re in right now, where someone on your marketing team is running Cloud Code, someone on your sales team is running Codex, and you just have no idea what’s going on, what tools they’re installing.”

NanoClaw—a personal AI agent

At Docker, our answer to the challenge of running AI agents safely is to run them in disposable, isolated, local sandboxes. Docker Sandboxes give agents the freedom and autonomy they need to do their best work, safely. Call it YOLO mode with guardrails. As Moriah noted in our discussion, agentic speed should be encouraged— “it’s the ungoverned speed that is the problem.” When agents are allowed to run fast without running wild, speed and safety are no longer a tradeoff. 

Of note here: In March, we announced the integration of NanoClaw with Docker Sandboxes to deliver secure-by-design agent execution. The integration allows every NanoClaw agent to run inside a disposable, MicroVM-based Docker Sandbox that enforces strong operating system-level isolation. The stack takes advantage of NanoClaw’s minimal attack surface and fully auditable open-source codebase to meet enterprise security standards. 

Laptops as the new prod

A key focus of the discussion was where to run agents safely. With vibe coding exploding, and agents and Claws (a new class of agents) already in production, the laptop today is the most powerful node in the enterprise. It’s also the most exposed. As a colleague of mine recently put it, laptop and agent environments are the new prod, and they need to be governed like prod.

Zach stressed the need to get agents off people’s laptops and desktops and into a controlled, cloud-based environment where CISOs can see what every agent across the company is doing at all times.

Portability—from laptop to cloud

My position is that, if you run agents in a sandbox, it doesn’t matter where the box sits. It could sit on a marketing or finance person’s laptop, or on a DevOps engineer or cloud admin’s machine. As long as the trust boundary is established and you know what’s getting piped in and out of it, you’re locked and loaded for rapid prototyping, experimentation, and innovation.

By the way, this view syncs with Docker’s vision, which has always been about portability. Our vision was never everything is local. We start in the local environment, then lift off into distributed environments, Kubernetes clusters, public clouds, whatever. It’s the same with agents. Eventually they’ll lift off, be decoupled from human operators, and be able to run fully autonomously wherever needed—always in the same portable environment.

When agents build the supply chain

The supply chain today is a revolving door for opportunistic attackers like TeamPCP and ShinyHunters who exploit transient dependencies and other vulnerabilities, often needing only a short window of time to filch credentials and information.

How are CISOs to combat these risks when AI agents themselves are pulling base images, choosing dependencies, and assembling code—autonomously and without human oversight? After all, in an autonomous supply chain, traditional methods of scanning and patching after building are no longer feasible. 

Keeping humans in the loop

The panelists shared several best practices. Zach urged keeping humans in the loop for picking clean, secure dependencies, especially upstream libraries, and setting up blessed images for agents to choose from. Gavriel recommended setting a minimum release age of seven days for images and minimizing dependencies—even safe ones.

A training-wheels approach

Gavriel also suggested a training-wheels approach to experimenting with agents, starting out using unpermissioned data to build skills and avoid sensitive data issues. “Unlocking the value today is important,” he said, “but even more important is having people build the skills of working with agents, because what’s going to be coming in the coming months and years is going to totally exceed anything that we have today. So, it’s really about building the muscle memory, building the skills.”

Layer security to limit the blast radius

My take? Opportunistic attackers are simply exploiting an ecosystem that’s inherently flawed and broken and that unfortunately won’t get fixed within the next six to 12 months. Until then, developers should assume these attacks will continue and prepare for them by layering security to limit the blast radius. That means reducing privilege, reducing third-party access to their environment, and using immutable tags, digests, and SBOMs (Software Bill of Materials) to lock manifests and enable rapid detection of poisoned images. And, yes, outsourcing the risk to a trusted build environment like Docker that provides clean, hardened images so you’re starting from a clean foundation. 

MCP—the new shadow IT?

The panelists rounded out the discussion with a focus on the security implications of using MCP in developer environments. MCP (Model Context Protocol) is a standard that allows LLMs to access external data and use tools, potentially making AI more powerful and reliable.

The consensus was that centralized, secure governance is crucial for productivity and risk management. Gavriel stressed the importance of proper version control, credential management, and a “golden repository” of verified tools. Zach advocated for centralized management to avoid individual tool dependencies and ensure minimal access. 

Making it safe and easy to run MCP servers

And Docker? About a year ago, we introduced an open source MCP Gateway that serves as a chokepoint between agents and external tools. Routing every tool call through this enforcement point, where it can be authenticated, authorized, and logged before it reaches the external system, enables a wide range of agents to access trusted catalogs of MCP servers. While it’s not clear to me how long MCPs will remain useful, given the exponential speed with which AI is evolving, Docker MCP Gateway solves an important challenge today. Like Docker Sandboxes, it makes enforcement strict instead of advisory.

A once-in-a-generation opportunity—and challenge

Enabling dev environments to take advantage of agentic AI is a once-in-a-generation opportunity, and CISOs are accountable for making sure the rush to do so doesn’t devolve into the Wild West.

Moriah closed the panel with a provocative thought: “Six months from now, enterprises are all going to be running agents at scale. The one key success factor will be whether governance was present from day one or got bolted on after the first major incident.”

In the choose-your-own-adventure reality of agentic AI today, what kind of security leader will you be?