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 foundation that nobody audited

What a good foundation takes

The winning playbook already exists

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

Related articles