Docker and CNCF: Making what an agent may do as portable as the agent itself
Ten years ago, the software industry faced a choice. Every vendor could ship its own image format and its own runtime, and developers would have to pick a side. Or the industry could agree on one artifact. The second option won. Docker donated its image format and the Runc runtime to the Linux Foundation, and the Open Container Initiative (OCI) formed around them. Today, a Docker image built anywhere can run anywhere. The format is the backbone of the cloud native ecosystem and a de facto standard.
Now, we see a similar problem forming around agents. There is no shared format for what an agent is allowed to do. We are proposing the same kind of answer: one artifact, built on OCI, governed in the open.
The same problem, for agents
Containers were built for immutable software. The image is the application. If you want to change it, you rebuild it, and it behaves the same way everywhere. That’s why a container image describes how software is built and says nothing about what it may do once it runs. For a web service, that was fine. It got a network and a port, and that was enough.
Agents are mutable by definition. Claude Code and Codex install packages, call APIs, and use credentials on your behalf. They change the environment they run in, and they decide what to do next. So, every team writes its own rules for what an agent may reach: a network rule here, a token there, a volume mount to get a task done. Those rules live in shell history, in dashboards, and in someone’s memory. A few months in, nobody can answer a simple question: what is this agent allowed to do?
Every team answers that on its own today, and every runtime vendor could ship its own way of answering it. That’s the kind of fragmentation OCI was created to prevent.
What we are announcing
Kits are not new. Kits have been part of Docker Sandboxes as the way you package an agent, its tools, and what it may reach into something a team can share. What’s new is the artifact. A Kit is now an ordinary OCI image, and the format that describes it is open.
Today at WeAreDevelopers, we announced the Docker Sandbox Kit Spec, open source under Apache 2.0. A Kit carries three things in one image: the agent, its tools, and a typed list of everything it asks to reach, such as hosts, credentials, and volumes. Because the list is part of the image, pinning the image pins the agent and its requests together.
A Kit is not a new artifact type and not a fork of any OCI specification. It uses an extension point OCI already defines. It builds, pushes, pulls, signs, and scans like any image you run today, because it is one.
Today, we’re bringing the spec to CNCF, under their neutral governance, just like we did when the image format went to OCI.
Why it matters
Adoption is free. Because a Kit is an OCI image, every registry, scanner, and signing tool you already run handles it. There is nothing new to deploy.
The answer travels with the agent. Because the requests are in the image, “what may this agent do” has one answer. A teammate can pull it. A reviewer can diff it. A conforming runtime can enforce it. When a new version asks for more, the change shows up as added lines someone can refuse.
An ecosystem, not a format
Docker has always had an ecosystem-first mindset. The Dockerfile mattered because anyone could write one, any registry could store the result, and any runtime could run it. Kits follow the same approach, and we did not build them alone.
We have worked with AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, Snyk, and more to build Kits for their tools. Cloud platforms, observability, security, artifact management, content, and agent frameworks are all represented. The Kits we unveiled during the opening keynote at WeAreDevelopers today are the product of all that work, and they are the first of many.
MCP gave agents a standard way to talk to a tool. Kits give the ecosystem a standard way to publish the whole arrangement: the agent, its tools, and what it asks to reach, in one image anyone can pull. That’s what turns a format into a supply chain. For example, a database vendor can publish a Kit that connects any agent to its service with the scope it recommends.An agent maker publishes its own Kit, so the request list comes from the people who built the agent. A platform team publishes one for the company, and every engineer starts from the same place.
None of that happens if the format belongs to one vendor. A standard for deciding what an agent may do is worth a good deal less if it belongs to whoever sells you the runtime. Docker Sandboxes is the first runtime that enforces it. It should not be the only one, and under CNCF governance, it will not be.
Containers made software portable. Kits make authority portable: the set of things you deliberately hand over to an agent travels with the agent, in the same image, and means the same thing wherever a conforming runtime opens it.
“Standards are what let an ecosystem move fast without fragmenting, and few companies understand that better than Docker. By delivering Sandbox Kits as standard OCI images, Docker is giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact. OCI is the foundation the cloud native ecosystem is built on, so a standard for agents that builds on OCI reaches the whole ecosystem at once. The CNCF welcomes this, and we’re excited to work with Docker and the community on making it broadly adopted.“
Chris Aniszczyk
CTO at CNCF
Build a Kit
If you make a tool agents use, publish a Kit for it. If you run agents, start from one and share it with your team. The specification, the capability pages, and a worked tour of a real Kit are at docker/sandbox-kit-spec. If there is a Kit you cannot express, or a rule a runtime cannot implement, open an issue. Every Kit published and every issue filed is how a standard gets built.
Portainer 3.0 donnera la priorité à Kubernetes : Docker, Swarm et Podman passent au second plan et Portainer CE restera en 2.x. Voici ce qu'il faut retenir.
Découvrez Portabase, la solution open source de sauvegarde de bases de données. Installation Docker, configuration d'un agent, etc... Prise en main complète.
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.
A new report from Omdia focuses on security issues in the software supply chain, how organizations are responding, and where the biggest gaps remain
In the heat map of cybersecurity vulnerabilities today, among the most intense hot spots is the software supply chain. In fact, it was the shift of the modern attack surface away from isolated systems to the software supply chain that connects them—and Docker’s role in safeguarding that interconnected reality—that first drew me to Docker.
So when Omdia recently released a report, with Docker among its sponsors, that laid out in detail the extent to which the software supply chain is under siege, I wanted to share some highlights.
Key data points
Here are some data points that caught my attention:
Over three-fourths of organizations experienced a software supply chain incident in the preceding 12 months.
AI tech was the top-ranked supply chain risk (40%), ahead of third-party and open-source code (39%), and software dependencies (38%).
Nearly half (45%) of orgs do not feel they have robust software supply chain security, compared to 55% who do.
More than half of orgs (51%) rate secure containers as very effective in securing third-party and open-source code components.
Shifting security left so that developers can secure their code is a high priority for 98% of organizations—and for 32% of those, it’s their top application security priority.
Third-party code and AI usage expand attack surface
A key finding was that increasing usage of third-party code and AI adoption pose security risks that organizations need to address.
Building applications using third-party libraries, open source dependencies, and AI-generated code saves developers a ton of time, so it’s no surprise this trend is on the rise. But it’s code they didn’t write, and as these time-saving inputs keep growing, so do the attack surfaces they expose.
77% of organizations reported experiencing a software supply chain incident in the 12 months prior to the survey (carried out in February 2026).
Notably, the most common attacks (38%) involved exploits that took advantage of known vulnerabilities in third-party software.
Source: Omdia Research Report, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, April 2026
Third-party code usage trending upward
Third-party code usage, including open-source software, isn’t going away. In fact, it’s gaining momentum.
38% of organizations report that more than half of their total software code comes from third-party sources—expected to jump to 58% of organizations in 12 months.
Similarly, 31% of orgs report more than half of their code is comprised of OSS—expected to jump to 51% of orgs in 12 months.
The report found that OSS is vital to developers and must be supported, and that orgs are either confident (50%) or completely confident (31%) that their developers are only using secure OSS.
AI tops security concerns
It should come as no surprise that, as devs increasingly use AI tech to develop software, AI tops the list of concerns around software supply chain risks (40%), ahead of third-party code (39%) and software dependencies (38%).
In the rapidly evolving threat landscape, new types of cyber attacks are emerging that are very different from CVEs (Common Vulnerabilities and Exposures). Take the Shai-Hulud campaign pioneered by TeamPCP, which automates and scales software supply chain attacks using stolen credentials to weaponize well-known packages and inject infostealers deep into the ci/stack or developer laptops.
Using third-party software including OSS is problematic for orgs on multiple fronts. The most common challenges are around vulnerability management.
Orgs worry about vulnerability remediation (39%) and/or identifying vulnerabilities in the code (36%).
And, because AI tools often pull from third-party and OSS code, 35% worry about AI increasing or generating vulnerable code.
Current solutions often fall short
There appears to be a fair degree of awareness around the need to secure the software supply chain. While many orgs are looking to bolster their software supply chain security, nearly half (45%) do not feel they have robust security in this area, compared to 55% who do.
At the risk of tooting our own horn, secure container services or libraries of hardened container images was the highest-rated tool for being “very effective” in securing third-party and OSS code components. In fact, out of 11 security tool categories, it was the only one rated as very effective by a majority of organizations (51%).
SBOMs play key role in boosting security
Another key finding was that effective inventory and SBOM (software bill of materials) tools can lead to measurably better security outcomes.
SBOMs are essential because they eliminate structural blindness, providing transparency into the hundreds of third-party components that form the “ingredients” of a modern application. They are even more effective when paired with a VEX statement (Vulnerability Exploitability eXchange), which tells customers whether flagged vulnerabilities pose a risk or not—potentially saving security teams thousands of hours spent chasing “ghost” vulnerabilities.
According to the report, SBOMs help orgs manage software supply chain risk in a range of ways, including more efficient vulnerability mitigation (73%), implementing security controls and processes to mitigate risk (72%), and helping meet compliance regulations (68%).
However, among organizations that generate an SBOM as part of their application development processes, less than half (42%) do so as a mandatory part of the process for all applications. More than half (55%) generate SBOMs on a case-by-case basis.
Producing SBOMs and understanding code composition ranked fourth among challenges orgs face with using third-party software including OSS.
Action needed—fast
The report underscores the need for preventative measures and rapid response in the face of a quickly evolving threat landscape. Among the impacts of software supply chain incidents are the following:
Nearly half of orgs (46%) faced unauthorized access to applications and data.
More than one-third had SLAs impacted by remediation steps (37%) and/or experienced stolen developer credentials, secrets, or keys (35%).
Organizations also suffered loss of data, introduction of malware and ransomware, and fines for noncompliance.
These impacts underscore the need to mitigate risk as early as possible in the development lifecycle—ideally catching and remediating issues before applications are deployed.
Investment plans and shifting security left
When asked about their spending plans in the face of these risks, orgs responded as follows:
Nearly two-thirds (62%) expect to make significant investments in software supply chain security.
37% anticipate making more modest investments.
A final key finding was that investment plans prioritizing AI require collaboration across teams. That’s largely because the job of securing the software supply chain increasingly falls to those on the front line: developers.
In fact, shifting security left so that developers can secure their code is a high priority for 98% of organizations—and for 32% of those, it’s their top application security priority.
The need to support development
One of the more resonant issues surfaced in the report was the need to support developers on the front lines. Despite the support for shifting security left to eliminate the security team as a bottleneck for remediating security issues, nearly half (45%) of security teams have only moderate or less influence over security products and processes for developers.
And while the majority of respondents believe their developers are mostly (38%) or completely (45%) comfortable taking on security responsibilities, orgs whose developers are less comfortable need to remove as much friction as possible from the process—for example, by making sure security tasks are not disruptive to the development process, and that security tools roll out consistently across development teams and work within development workflows.
The software supply chain isn’t getting simpler, and neither are the threats targeting it. If you’re evaluating how your organization can better secure third-party code, AI-generated code, and open source dependencies, the full Omdia report offers a deeper look at the trends, data, and practical recommendations shaping software supply chain security. Download the report to see where your organization stands and where to focus next.
Over the past few months, I’ve noticed something unmistakable in my conversations with customers. We’re no longer talking about what AI agents are capable of and whether they can transform the way we build software. We know the answer. They can. They already are.
The conversations I’m having now instead revolve around a much more sensitive, much more nuanced question: Can we trust these systems? Can we safely place them at the center of our business? That’s the question that’s already defining the next chapter of Agentic AI.
The world has been promised a paradigm-changing productivity boost from AI. For that to happen, we as technology leaders must empower customers with the solutions they need to build and maintain deterministic control over what agents can and can’t do. Developers and businesses alike need to have confidence that AI agents will behave predictably, operate within well-defined boundaries, and remain secure regardless of how quickly the underlying technology evolves.
Trust, not intelligence, will determine what’s truly possible in the agentic era. Intelligence comes from models. Trust comes from the runtime, identity, governance, and security surrounding them. That’s why we’re proud to join the Open Secure AI Alliance and why we’re grateful for NVIDIA’s leadership in bringing together organizations committed to solving this challenge. No single company can take on the task of building this trust alone. Security, safety, and governance have to be built through an open ecosystem that shares responsibility for moving the industry forward.
Speaking of open ecosystems, at Docker, we’ve always believed developers do their best work when they have the freedom to choose. That’s how we got to where we are today. It’s how we reshaped the container ecosystem and earned the trust of more than 20M developers worldwide. And it’s how we’re approaching the agentic era as well. We believe the true power of agentic AI can only be harnessed when customers can seamlessly route between open-weight and frontier models.
But this isn’t just what we believe; it’s what our customers are telling us they want. It’s what they’re telling us they need, today. Almost every customer I talk to has already made open-weight models a core part of their strategy. They need the ability to select the right model for the right task without having to rethink their architecture, rewrite their applications, or compromise on governance, safety, and security every time they make a different choice.
In other words, they need to be able to trust. Building that trust will require all of us. As AI agents become part of every software stack, trust has to extend beyond the model to the environments where agents execute. Docker is proud to help build that foundation alongside NVIDIA and the other members of the Open Secure AI Alliance.
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?
Agents have moved from demos to daily work faster than almost anyone planned for. In our State of Agentic AI report, 60% of organizations already run AI agents in production, and yet 40% name security and compliance as the number-one thing holding them back from scaling further. That gap, between what teams have already shipped and what they can safely operate, is the real story of AI agents right now.
But what is an AI agent, and why does the term suddenly stretch from a coding assistant to an autonomous research system? The short version is that an agent doesn’t just respond, it acts: give it a goal and it’ll plan the steps, call tools, check the results, and adjust, usually without stopping to ask. That’s what separates an agent from the generative AI it’s built on, and it’s why where an agent runs matters as much as which model sits behind it.
Key takeaways
An AI agent pursues a goal on its own. It reasons, picks tools, and takes actions in a loop rather than answering one prompt at a time.
The model decides, tools act, and the environment is where those actions land.
Autonomy is the point and the risk. Once an agent can act on its own, where it runs decides how much a wrong move can cost.
Building agents is largely an infrastructure problem: framework choice, tool access, and an isolated place to run them safely.
What is an AI agent?
Strip away the hype and an AI agent is software that takes a goal, decides how to reach it, and acts through tools to get there, then uses what it learns to choose its next move. The model supplies the reasoning, the tools give it hands, and the environment is where its actions actually happen. Put those three together and you get a system that can work through a task instead of just describing one.
That’s the difference between an agent and the chatbot experience most people started with. A chatbot answers the question in front of it. An agent takes an objective and works the problem: it breaks the goal into steps, decides which tool fits each step, runs it, reads the outcome, and keeps going until the goal is met or it gets stuck. A coding agent asked to fix a failing test might read the codebase, edit a file, install a dependency, run the suite, and open a pull request, all from one instruction.
Three properties make that possible:
Autonomy lets it decide the next action without waiting for approval at each step.
Tool use lets it reach beyond text to run code, query APIs, and change files.
Memory lets it carry context across steps, so later decisions build on earlier ones.
Remove any one of them and you’re back to a smarter chatbot rather than an agent.
How do AI agents work?
Under the hood, an agent runs a loop. It takes in the current state of its task, reasons about what to do next, acts through a tool, observes what changed, and feeds that back into the next round of reasoning. The loop repeats until the goal is reached or a stopping condition kicks in.
In one pass of the loop, the agent perceives first, gathering context like the goal, relevant memory, and the results of whatever it did last. In the reason step, the model plans the next action and picks a tool. In the act step, it invokes that tool, a shell command, an API call, a database query. In the observe step, it reads the result, including errors. Then it adapts, updating its plan based on what happened, because a failed test isn’t a dead end for an agent, just new input for the next loop.
The parts that make it run
Most agent frameworks assemble the same core pieces, even when they name them differently.
Component
What it does
Model
The reasoning engine. It interprets the goal, plans steps, and decides which tool to call next.
Tools
The connections to the outside world: code execution, file operations, API calls, database queries, web search.
Memory and context
What the agent carries between steps and sessions, so later actions build on earlier results instead of starting fresh.
Orchestration
The control logic that runs the loop, enforces limits, and coordinates multiple agents when a task is split across them.
Environment
Where the agent’s actions actually execute: your laptop, a server, or an isolated sandbox. This is the part most explanations skip, and the part that decides your risk.
What are AI agents used for?
Here are a few common examples of AI agents:
Coding agents read a repository, write and refactor code, run tests, and open pull requests.
Support agents triage tickets, pull answers from internal docs, and take action in connected systems.
Data agents query multiple sources, reconcile the results, and write a summary.
Operations agents watch infrastructure, investigate alerts, and run routine fixes.
What ties these together is the shape of the work. If a task can be described as a goal plus a handful of tools plus a definition of done, an agent can usually attempt it. That’s also why agents are showing up in so many roadmaps at once.
Agents vs. chatbots, vs. generative AI
Agents, chatbots, and GenAI often get used interchangeably, which muddies the water. Generative AI produces content in response to a prompt. A chatbot wraps that in a conversation. An agent adds autonomy and tools on top, so it can act on the world rather than just describe it. The clearest way to see it is side by side.
Capability
Chatbot
AI agent
Responds to a prompt
Yes
Yes
Uses external tools
Rarely
Yes
Plans and runs multiple steps
No
Yes
Acts without approval at each step
No
Yes
If you want a deeper comparison between generative and agentic systems, we cover it in GenAI vs. agentic AI. But in essence, the moment a system can take actions on its own, you’re no longer just evaluating output quality. You’re also deciding what that system is allowed to touch.
How AI agents are changing software development
An agent is only as safe as the environment it runs in and the access it’s granted. While a chatbot that hallucinates gives you a wrong answer. An agent that goes wrong can delete files, leak secrets, or push a broken change. The autonomy that makes agents productive is the same autonomy that widens the blast radius when something misfires.
Scenario spotlight: Consider what can go wrong when an agent runs directly on a developer’s machine. A vaguely worded cleanup instruction leads a coding agent to run a destructive delete against the wrong directory, which is exactly the kind of failure Docker documented in the rm -rf incident. The agent was trying to help. Nothing contained the mistake, so it reached real files.
This is why experienced teams treat agents as an infrastructure decision, not just a model choice. The interesting engineering questions are about containment: where does the agent execute, which tools can it call for this specific task, whose credentials does it use, and how do you see what it did afterward. Get those right and you can let an agent run without approving each step.
Common misconceptions about AI agents
A few beliefs cause most of the confusion.
“More autonomy is always better.” Not quite. Autonomy is a dial, not a switch. More of it means more speed and a larger blast radius at the same time.
“Agent security is the model’s job.” The model can’t contain itself. Real safety comes from the infrastructure around it, which is the whole point of securing AI agents at the isolation and access layers.
“Governance is only for big enterprises.” Even a solo developer benefits from basic guardrails. As soon as more than one person runs agents, you need shared rules, which is where AI governance starts to earn its keep.
How to start building and running agents safely
You don’t need a platform team to begin, just a few deliberate choices. Pick a harness that matches your task rather than the one with the loudest launch. Connect only the tools the agent needs for the job in front of it, not every tool it might ever want. And decide where it runs before you hand it real access.
That last choice does the most work. Running an agent inside an isolated, disposable environment gives it a real place to work, install packages, edit files, run services, while keeping it away from your host, your credentials, and your other projects. If something goes wrong, you throw the environment away and start a new one. This is the same reasoning behind sandbox security and the microVM architecture that makes strong isolation practical without slowing the agent down. Permission prompts feel like control, but they mostly train you to click allow. A boundary gives you both speed and safety.
Running agents you can actually trust
AI agents are the rare technology where the hard part isn’t getting them to do something, it’s deciding how much they’re allowed to do and where. Once you see an agent as a model plus tools plus an environment, the path forward gets clearer: choose the model, scope the tools, and put real thought into the environment. The first two get most of the attention. The third is where safety actually lives.
That’s the gap Docker Sandboxes is built to close. Each agent runs in its own disposable microVM with control over networking, filesystem access, and resource limits, so it can move fast inside a boundary instead of loose on your machine. And when you’re running agents across a team, AI Governance lets you set the rules once, which actions are allowed, what the network can reach, which credentials and tools are in play, and enforce them everywhere developers work. Define the boundary, then let the agents run.
Frequently Asked Questions
What is an AI agent in simple terms?
An AI agent is software that takes a goal and works toward it on its own, reasoning about what to do, using tools to act, and adjusting based on the results. Unlike a chatbot, which answers a single prompt, an agent runs a loop of decisions and actions until the task is done.
What is the difference between an AI agent and a chatbot?
A chatbot responds to what you type. An agent pursues an objective across multiple steps, calling tools to change files, run code, or query systems along the way. The agent decides its own sequence of actions rather than following a fixed script.
What are AI agents used for?
Common uses include writing and testing code, triaging support tickets, analyzing data across multiple sources, and handling routine operations tasks. The common thread is multi-step work that involves some judgment and a few tools, rather than a single question and answer.
Are AI agents safe to run in production?
They can be, if you contain them. Because agents act autonomously, safety comes from the environment they run in and the access they hold, not from the model alone. Isolation, scoped tool access, dedicated credentials, and monitoring are what make production use responsible.
Do I need special infrastructure to run AI agents?
For experiments, no. For anything that touches real code, data, or credentials, you want an isolated place for the agent to run so a mistake can’t reach your host. That’s why sandboxed, disposable environments have become the default pattern for running capable agents.
Why Docker is excited to co-host the first WeAreDevelopers World Congress North America
When we announced our partnership with WeAreDevelopers, AI agents were still mostly something developers experimented with. Today, they’re becoming part of everyday software development.
That’s why the timing for this year’s WeAreDevelopers World Congress couldn’t be better.
In the months since that announcement, the developer landscape has changed dramatically. If you’re writing software today, your workflow probably looks very different than it did a year ago. You’re prompting AI agents, reviewing AI-generated code, deciding what to accept and what to reject, and thinking about security much earlier in the development process.
Developers are no longer spending all of their time writing code. They’re designing systems that generate code, supervising autonomous agents, deciding what those agents can access, reviewing AI-generated changes, and making sure software is secure before it reaches production.
That shift feels a lot like the rise of data science a little over a decade ago. We didn’t replace programmers. We created an entirely new discipline that blended software engineering, mathematics, and statistics into something bigger.
I think we’re seeing the beginning of a similar transformation. Whether we continue calling ourselves developers, builders, or something entirely new almost doesn’t matter. The role itself is changing.
The best engineers of the next decade won’t simply write software. They’ll orchestrate teams of AI agents, establish the guardrails those agents operate within, and ultimately remain accountable for the systems they create.
That’s the conversation our industry needs to have. It’s also why this year’s WeAreDevelopers World Congress feels so important.
Docker is proud to serve as a presenting partner, but our goal isn’t to make this a Docker event.
Our goal is to help create a place where developers can learn from each other.
That’s why we partnered with WeAreDevelopers in the first place. They’ve spent more than a decade building one of the world’s strongest developer communities by focusing on the people building software, not the companies selling it. As AI reshapes how software gets built, North American developers need more than another vendor conference. They need a place to compare notes, share what’s actually working, challenge assumptions, and learn from peers facing many of the same questions.
The best developer conferences have never been about product launches. They’re about conversations. They’re about seeing how other engineers solve problems, discovering tools you didn’t know existed, and leaving with ideas you can actually use on Monday morning.
That’s what has made WeAreDevelopers so successful around the world, and that’s what we’re excited to help bring to the U.S.
The conversation has changed
Over the last year, nearly every conversation I’ve had with engineering leaders has landed in the same place.
Everyone wants the productivity gains that AI agents promise.
If you’ve spent any time with Claude Code, Cursor, Codex, or another coding agent, you’ve probably experienced it yourself. You can move faster than ever before. Then you stop and ask a different set of questions.
What is the agent actually doing?
Can it reach internal systems?
What credentials is it using?
Where is my data going?
How much autonomy am I comfortable giving it?
Those questions aren’t theoretical anymore. They’re becoming everyday engineering problems.
At Docker, they’ve shaped much of what we’ve been building.
We’ve introduced Docker Sandboxes so developers can run AI agents safely without changing how they work. We’ve launched Docker AI Governance to give organizations visibility and control over autonomous agents. We’ve continued investing in Docker Hardened Images because supply chain security only becomes more important as AI generates more code.
They’re all pieces of the same philosophy.
You shouldn’t have to choose between moving fast and staying secure.
The tooling should make both possible.
Meet the Docker team
We’ll have Docker engineers and leaders speaking throughout the event, including:
Mark Cavage, President & COO
Tushar Jain, EVP of Engineering & Product
Mark Lechner, CISO
We’ll also have engineers throughout the conference sharing what we’ve learned building for the next generation of software development, from AI-native workflows and developer productivity to security, containers, and the infrastructure that powers modern applications.
If you’ve been experimenting with agents, thinking about governance, or trying to figure out what secure AI development looks like inside your organization, we’d love to continue the conversation.
See you in San Jose
One thing has remained true throughout every shift in our industry.
Developers learn best from other developers.
That’s what makes communities like WeAreDevelopers special. It’s what has always made the Docker community special too.
AI will continue changing how software gets built. The tools will evolve. Our workflows will evolve right along with them.
What’s next won’t be shaped by any one company. It will be shaped by developers sharing ideas, challenging assumptions, experimenting with new ways of working, and building together.
That’s exactly what we hope to see in San Jose.
Whether you’re exploring AI agents for the first time, figuring out how to govern them at scale, or simply curious about where software engineering is headed next, we’d love to continue the conversation.
Come see what Docker is building for the next generation of software development, and join thousands of developers who are helping define what’s next.
Connexion
