Key Takeaways
- Agents that open pull requests still leave review, rebuilds, and redeploys to the team, so the time saved depends on how often those PRs arrive.
- Echo is the top pick for teams that want base images kept clean at the source, with AI agents that research, patch, and backport.
- AI patching tools work in three different places: upstream in the image supply, in place on an existing image, or downstream in the Dockerfile and pull request.
- Bumping a base image tag and patching a base image are not the same thing; backported fixes remove the CVE without forcing a version change.
- Every patching agent needs guardrails: human approval, test gates, signed outputs, and a record of what was changed and why.
A new advisory lands for a library that sits in almost every Debian-based image your organization runs. By the afternoon, scanners have lit up across dozens of repositories, each one reporting the same CVE against a different service. Nobody wrote that library, nobody on the team chose to include it, and yet someone now has to find a fix, confirm it does not break anything, rebuild, and redeploy, often dozens of times over.
That repetitive, inherited work is exactly where AI agents have started to earn their place in container security. Instead of stopping at an alert, an agent can research a vulnerability, locate or write a fix, test it against real builds, and hand back a change for a human to approve. The tools that do this differ sharply, though, in where the agent works: some patch images before they ever reach you, some patch the image you already have, and some edit your Dockerfile and open a pull request.
The Patch Loop, and Which Parts an Agent Can Own
Patching a base image is not one action but a loop of five steps. Traditional tooling automated the first step years ago. What AI agents change is how far down the loop automation reaches.
- Detect: notice that a component in the image is affected by a newly published CVE.
- Research: work out which images and versions are affected, whether a fix exists, and whether it applies cleanly to the version in use.
- Fix: apply an upstream patch, backport a fix to an older version, swap to a patched package, or change the base image reference.
- Validate: build the result and confirm the application still behaves as expected and the CVE is actually gone.
- Deliver: publish the patched image or open a change for review, then keep the evidence (SBOM, VEX, provenance) aligned with what shipped.
A scanner owns step one. A pull-request bot owns part of step three. An agent that can read advisories, mailing lists, and commit histories, then test its own work, can reach steps two through five. The further an agent reaches, the less of the loop lands on the engineers who consume the image.
6 Tools That Use AI Agents to Patch Container Base Images
1. Echo
Most AI patching tools start from the image a team already has and work backward toward a fix. Echo takes a different approach: its agents keep base images clean at the source, so the vulnerabilities never arrive in the first place. Its AI-driven image factory analyzes popular open source base images, keeps only the components the workload needs, and rebuilds them from scratch without vulnerable or unnecessary packages. Teams adopt the result by swapping one line in their Dockerfile.
The agents do not stop at the initial build. When a new CVE is published, Echo’s agents research it, identify which images are affected, and find or develop a fix, including from unstructured sources such as GitHub discussions, forums, and security research. They apply the patch, run compatibility tests, and open a pull request so a human reviews the change before it ships. Because fixes can be backported, workloads stay on the versions they depend on rather than being forced into upgrades. Echo reports maintaining a library of more than 600 images this way.
The operating commitments are specific. Critical and high CVEs are triaged within 24 hours and fixed within 7 days, and Echo’s container base images are continuously rebuilt so private registries pull clean versions automatically. Each 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 FedRAMP and other regulated environments, and the same approach extends to application libraries, so the language-level dependencies layered on top of the base image stay clean as well.
Where the agent works: upstream, before the image reaches your registry.
What your team still does: change the base image reference once, then pull updated images as they are published.
What the agent handles:
- Rebuilds base images from scratch with only the components the workload needs
- Monitors newly published CVEs and identifies every affected image
- Researches and develops fixes, including from unstructured sources
- Backports fixes so teams stay on the versions they depend on
- Runs compatibility tests and opens a pull request for human review
- Continuously rebuilds images, with 24-hour triage and 7-day fixes for critical and high CVEs
- Ships every image signed, with SBOM, provenance, and VEX, on SLSA Level 3 build infrastructure
- Extends the same approach to FIPS-validated, STIG-hardened variants and application libraries
2. Root
Root approaches the problem from the image a team already runs. Its Agentic Vulnerability Remediation (AVR) pipeline uses specialized AI agents to research, patch, test, and deliver fixes for vulnerable packages inside existing container images, with Root’s security experts reviewing the work.
The process starts by scanning an image, evaluating whether its OS and package ecosystem are supported, and building a remediation plan per vulnerable package: a native distribution upgrade, a Root backported patch, or a place in the fix queue for agents and experts to work on. Patched packages keep their original version numbers, and each image ships with an updated SBOM, VEX, and provenance.
Where the agent works: in place, on your existing image.
What your team still does: point builds at the remediated image and confirm support for the distributions in use.
What the agent handles:
- Scans images and builds a per-package remediation plan
- Applies backported patches that keep original version numbers
- Queues packages without a fix for agent and expert research
- Delivers updated SBOM, VEX, and provenance with each image
3. Aikido Security
Aikido Security brings agentic patching into a broader developer security platform. Its AI AutoFix for containers looks at vulnerabilities found in a base image and proposes Dockerfile changes, offering three to five variants tied to different base images and showing which vulnerabilities each one fixes and whether any new ones appear.
Developers preview each change before accepting it, and AutoFix can open the pull request directly in the source control system. When moving to a newer base image would require application changes, AutoFix can propose an Aikido Image instead, a drop-in base image in which critical and high severity issues have been patched and which is rebuilt as new CVEs are reported. Container findings sit alongside code, dependency, and cloud findings in the same platform.
Where the agent works: downstream, in the Dockerfile and pull request.
What your team still does: choose a variant, review and merge the PR, and rebuild.
What the agent handles:
- Proposes three to five Dockerfile variants per base image finding
- Shows fixed and newly introduced vulnerabilities for each option
- Opens pull requests directly in source control
- Suggests patched Aikido Images when upgrading is not practical
4. GitHub (Dependabot With Copilot Coding Agent)
GitHub combines two layers of automation for dependency fixes. Dependabot has long opened pull requests to update dependencies, including base image tags in Dockerfiles. Since 2026, teams can also assign Dependabot alerts to AI coding agents, including Copilot, Claude, and Codex, which analyze the advisory and the repository, open a draft pull request, and attempt to resolve any test failures the update introduces.
That second layer addresses the part of patching that rule-based bots cannot: when a version upgrade breaks the build, the agent works through the failures and proposes the code changes needed. Several agents can be assigned to the same alert, each opening its own draft pull request so reviewers can compare approaches, and assignments can be managed through the REST API.
Where the agent works: downstream, in the repository.
What your team still does: triage and assign alerts, review draft PRs, and rebuild.
What the agent handles:
- Updates base image tags in Dockerfiles through Dependabot
- Analyzes assigned alerts against the repository’s actual usage
- Opens draft pull requests and works through failing tests
- Lets multiple agents propose competing fixes for one alert
5. Docker Gordon With Docker Scout
Gordon is Docker’s AI agent, built into Docker Desktop and the CLI and included with every Docker account. It reads the local environment, including running containers, images, Dockerfiles, and Compose files, proposes solutions, and takes action with the developer’s approval at each step.
For patching, Gordon draws on Docker Scout. Its built-in tools can scan an image or project directory for CVEs and return base image update recommendations, and Gordon can then apply those recommendations to the Dockerfile, rebuild, and help troubleshoot anything that breaks along the way. Because it sees the actual local context, its suggestions reflect the developer’s real setup rather than a generic advisory.
Where the agent works: on the developer’s machine, in Docker Desktop or the CLI.
What your team still does: start each session, approve every action, and roll changes out across repositories.
What the agent handles:
- Scans images and projects for CVEs through Docker Scout
- Retrieves base image update recommendations
- Edits Dockerfiles, rebuilds, and troubleshoots with approval
- Works from the real local environment, not pasted context
6. Cast AI
Cast AI, known for Kubernetes automation, adds patching through a runbook in its Application Performance Automation (APA) product. The Fix container image vulnerabilities runbook monitors the images actually running in a cluster, generates fixes, and opens pull requests for review. The feature is currently in private preview.
Its agent experiments with several remediation approaches, testing each for build success and vulnerability reduction, then selects the one that is most effective with the fewest code changes. Fixes update Dockerfiles to use patched base images or upgraded packages, and the agent can optionally update Kubernetes manifests after a merge so deployments reference the fixed image. Teams map images to repositories, connect any OCI-compatible registry, choose which AI models the agent uses, and set a severity threshold.
Where the agent works: from the running cluster back to the Dockerfile.
What your team still does: map images to repositories, review PRs, and let CI validate each change.
What the agent handles:
- Detects vulnerabilities in images running in the cluster
- Tests multiple remediation approaches before choosing one
- Opens pull requests with Dockerfile changes
- Optionally updates Kubernetes manifests after merge
Guardrails to Put Around Any Patching Agent
An agent that can change a base image can also introduce a regression at scale, so the controls around it matter as much as the agent itself. Whatever tool a team adopts, a few guardrails keep automation trustworthy:
- Human approval before production: every agent-generated change should pass through a pull request or equivalent review, with the reasoning visible to the reviewer.
- Test gates the agent cannot skip: builds and application tests should run in the team’s own pipeline, not only inside the vendor’s environment.
- Signed, attested outputs: patched images should carry signatures and provenance so it is possible to verify who built them and from what.
- Evidence that matches reality: SBOM and VEX data should update with each fix, so scanners and auditors see the same state that is deployed.
- A limited blast radius: roll agent fixes out gradually, starting with lower-risk services, and keep a fast path back to the previous image.
These controls also make it easier to compare tools honestly, since each vendor can be asked how its agent behaves inside them.
FAQ
What does it mean for an AI agent to patch a container base image?
It means the agent does more than report a vulnerability. It researches the CVE, finds or creates a fix, applies it to the image or the Dockerfile, tests the result, and delivers a change for review. The depth varies: some agents only propose a newer base image, while others backport fixes and rebuild the image itself.
Are AI-generated patches safe to run in production?
They can be, provided the process around them is sound. Reliable approaches run compatibility and application tests, require human review before release, sign the resulting artifacts, and update SBOM and VEX data. Teams should validate agent fixes in their own pipelines and roll them out gradually, just as they would with any other change.
What is the difference between patching an image and upgrading its base image tag?
Upgrading the tag moves to a newer image version, which may bring a different runtime or distribution release and break the application. Patching, particularly through backports, replaces the vulnerable code while keeping the version the application already uses. Backports are often the only way to close a CVE that upstream has fixed only in newer releases.
Do AI patching agents remove the need for vulnerability scanners?
No. Scanners still provide independent verification that a fix worked and catch vulnerabilities in layers the agent does not manage, such as application code. What changes is the scanner’s role: instead of generating a growing backlog, it confirms that images remain clean and flags the smaller set of issues that still need attention.
