Coding agents do more than write code. Agents can install dependencies, access networks, use credentials, and keep working after we’ve moved on to something else. Agents need access to get real work done. But the more access they have, the bigger the impact of a mistake. The challenge is building enough trust into the system to give agents more freedom without giving them access to everything. 

At WeAreDevelopers North America, Docker President Mark Cavage laid out Docker’s answer: give every agent a strong boundary, make its environment and authority reproducible, and let the work run where it makes sense, from a developer’s laptop to the cloud. 

In 30 minutes, Mark demonstrates what happens when an agent pushes beyond a container’s limits and how Docker Sandboxes create a stronger boundary. He then connects that foundation to Kits, cloud capacity for work that needs to continue beyond the laptop, and new partnerships helping developers put agents to work safely. 

Agents are actors, not workloads

Containers were built to isolate applications. Agents do more. They make decisions and act on the systems around them, so the boundary needs to extend to the environment they can reach. 

Mark’s onstage demo makes that clear. The container worked as designed. What the agent needed was containment around its full environment. Docker Sandboxes provide that containment. Each agent gets its own isolated microVM and kernel, separate from the developer’s host environment. 

Developers can choose the agent, model, and tools that fit the job, then define the sandbox’s access to files, networks, and secrets. Those policies stay outside the agent’s control. Together, the sandbox and its policies create a trusted environment for autonomous work. 

Docker Sandboxes are available today through the free, standalone CLI, so developers can bring stronger isolation to the agent workflows they already use. 

Make the agent and its authority reproducible

A strong boundary gives an agent a safe place to work. Developers also need a repeatable way to define what runs and what it can access. 

In the keynote, Mark announced the next generation of Docker Sandbox Kits, now built as standard OCI images, and invited ecosystem partners to help shape the specification as Docker works towards neutral governance. 

Docker Sandbox Kits package the agent, its tools, and the rules for what the sandbox can reach into one versioned, shareable artifact. Developers can share Kits through the same workflows they already use for container images, while keeping changes to an agent’s authority visible and reviewable. 

The result is a common foundation for the agent ecosystem, built on an open standard. 

Dockerfiles made software reproducible. Kits make authority reproducible

Start on your laptop. Finish in the cloud.

Some agent work begins and ends on a developer laptop. Longer-running or parallel work needs capacity that stays available when the developer steps away. In the keynote, Mark announced Docker Cloud Sandboxes, bringing the same microVM-based isolation from the laptop to Docker-managed cloud compute. 

Using the familiar sbx workflow, developers can start locally, move their work to the cloud with one command, and let it continue after they close their laptop. They can also run tasks in parallel without provisioning or maintaining the infrastructure themselves. 

Docker Cloud Sandboxes are available today with pay-as-you-go pricing.

An ecosystem built around trust

An open agent ecosystem needs both: choice for the developers and shared standards the industry can build on.

Nous Research joined Mark onstage to show Hermes running as a first-class Kit in Docker Sandboxes. The demo showed what choice looks like in practice: a third-party agent packaged for a common environment, with Docker providing the underlying isolation and controls. Developers can choose the agent that best fits their work without having to rebuild the trusted execution layer around it.

Choice also depends on shared standards that the wider ecosystem can adopt. Docker has committed to submitting its Kits specification to the Cloud Native Computing Foundation (CNCF), the open source, vendor-neutral hub of cloud-native computing.

Together, these partners show what an open agent ecosystem can look like: choice at the agent layer and a shared format for packaging an agent’s environment and authority. Docker provides the trusted foundation underneath, whether agents run locally or in the cloud.

Trust comes from the system around the agent

Taken together, the announcements in Mark’s keynote form one system. Sandboxes provide a deterministic boundary. Kits make the agent’s environment and authority reproducible. Cloud Sandboxes extend the same trust model to durable cloud capability. 

They give developers the freedom to choose their agents and more autonomy, while retaining control over what they can access and change. 

As agents take on bigger jobs, the infrastructure around them matters more. Docker provides the trusted foundation they need to work locally or scale in the cloud, while developers continue to stay in control of what ships.  

Ready to try Cloud Sandboxes?

For a limited time, new accounts can claim $250 in compute credit to get started.

Watch, Explore, Build

• Start Locally: Run an agent in a Docker Sandbox 
• Scale in the Cloud: Read the announcement and get started with Docker Cloud Sandboxes 
• Build with Kits: Read the technical deep dive and explore the open kit specification. 

Agents need containment, and a sandbox is only half of it. Something still has to say which agent runs there, what it gets, and what it may touch. That is a Kit: an ordinary OCI image, so the answer travels with the agent and means the same thing on any conforming runtime. Today we published the Docker Sandbox Kit Specification v3, open source under Apache 2.0 at docker/sandbox-kit-spec. Here is why I wrote it.

Everything that makes an agent useful is a grant

I run a lot of agents. They write code, run tests, install dependencies, call APIs, and work on infrastructure while I do something else. None of it happens without access, so I grant it one piece at a time: a bind mount, a token with broader scope than the task needs, a firewall rule that was quicker to open than to narrow. Each grant is reasonable on its own. Together they take back the isolation I was relying on, and none needed an exploit. The holes are configuration, added on purpose, usually by me.

I am worse at taking any of it back, and I could not reproduce the grants my setup depends on. No file records them. They live in shell history, dashboards, and my memory. I cannot hand that to a colleague or diff it against last week.

Containers package applications. Sandboxes contain agents.

A container packages applications. It shares the host kernel and uses namespaces and cgroups to give one fixed workload its own view of the filesystem, network, and processes. That is the right tool for software that runs, does its job, and touches only what it was handed.

An agent, however, is a probabilistic actor. It decides what to do next and then does it, to my filesystem, network, credentials, and cloud account. It will install a package that needs root, open a port nobody planned for, and try the next thing when the first is blocked. A container was not built for that: the boundary is the same kernel the actor is probing.

A Docker Sandbox is a microVM with its own kernel, so the boundary sits below anything the model can reach or rewrite. Inside one I can hand an agent root and let it loose, because the damage stops at the sandbox boundary. The sandbox is what lets me run an agent with the safeties off.

But an empty sandbox is not an environment. Something still has to say which agent runs, which tools and MCP servers it gets, which skills and instructions shape it, and exactly what it may touch.

What a Dockerfile cannot say

A Dockerfile answers everything about the software itself: how it is built, what gets packaged, how it starts. It was never standardized; OCI standardized the image it produces and how registries distribute it. What a Dockerfile does not describe is the outside: networks, credentials, volumes, tools, context. That half has lived in docker run flags, a Compose file, a CI config, and someone’s memory. Unversioned, unreviewable. A Kit writes it down with the content.

One image, one digest

If you have used sbx, you have used Kits. This is the third version of the format, and the change that matters is that a Kit is now an ordinary OCI image rather than its own artifact: no media type, no sidecar file, nothing for a registry to learn. The manifest carries the declarations in one annotation, vnd.docker.sandbox.kit.descriptor; the layers carry the content.

A Kit therefore builds with docker buildx build, pulls with docker pull, gets scanned and signed by the tooling you already run, and works in a FROM. Pinning the digest pins content, declarations, and metadata together. The tooling and distribution path are free; the format is something you learn: a grammar, a page per capability type, provides and requires, kind: set.

Two kinds of Kit exist. A workload runs and supplies the root filesystem. A mixin is an overlay: a CLI with its network rule, a credential binding, context for an agent. You launch one workload and any number of mixins.

Authority you can read

Part of the GitHub CLI mixin in the repository:

capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

  - type: com.docker.sandbox/credential@1
    optional: true
    config:
      service: github
      phase: runtime
      apiKey:
        name: GH_TOKEN
        proxyManaged: true
        inject:
          - {domain: api.github.com, header: Authorization, format: "Bearer %s"}

Read it as a permission slip. This Kit asks to reach GitHub and nowhere else, and for most of the API but not deletes under /repos/**, because deny wins. The token that can open a pull request cannot delete the repository. The credential is proxy-managed: a conforming runtime injects the real value into requests to the named domains, and inside the sandbox there is only a sentinel.

Two words carry weight: asks and conforming. A Kit grants itself nothing. Each entry is a request, and the host decides. A conforming runtime, one that implements the behaviour the specification describes, blocks hosts not on the list. Without one, the annotation is inert: an image and no enforcement. Docker Sandboxes is the first conforming runtime.

Everything a Kit needs goes through that one list, typed and versioned. Grants (network rules, credentials, volumes, ports, devices, skills paths) count toward “what may this Kit do”; entries that ask the runtime to act, like a lifecycle hook, do not. A required request the host cannot satisfy refuses the launch, rather than starting an agent with less authority than it declared, or more.

Composition is a function, not a sequence

Container images never solved multiple inheritance: a Dockerfile stage has one FROM. Mixins are overlays ordered by the dependency graph the Kits declare through provides and requires, never by the order you typed the flags, so the same set always composes to the same image.

The resolver is strict on purpose. Every requires is satisfied from inside the set or resolution fails; nothing is fetched to cover a gap. Exactly one workload is allowed. Two Kits providing the same name fail rather than one silently shadowing the other (composing the Claude workload with the Claude mixin is the canonical mistake). Where Kits overlap, declarations reconcile: network rules union, hooks run in dependency order, guidance becomes one document, licenses union. Incompatible requests are an error, not a coin flip.

A kind: set descriptor names other Kits; publishing it runs the same coherence rules at build time and merges them into one ordinary Kit. An incoherent set fails at your build, not at someone else’s launch.

The diff is the review

The Claude Code Kit in the repository declares the hosts it asks to reach, its credential, the volumes that persist between sessions, and its install and startup hooks. When the next version asks for another host or a second credential, that is a change in authority, not a software update, and it shows up in the pull request as added lines a human can refuse.

Review depends on somebody reading the diff, so the specification defines a second gate that does not. Every descriptor reduces to a normalized set of everything the host would have to grant; a runtime that gates updates records that set and compares the next version against it. A version inside what was granted may apply without asking. Any widening stops and asks, and removing a deny rule counts: if a later gh Kit dropped DELETE /repos/**, the runtime holds the upgrade. That is why the declarations had to live in the artifact, not beside it.

Why this is a specification and not a feature

A Kit that stopped meaning anything when run somewhere else would be lock-in, not a trust boundary. So the grammar is normative, every capability type has its own page describing what a conforming runtime must implement, and types version independently (network-policy@1 and @2 both exist today). Two conformance suites ship with it: one judges whether an artifact is a conforming Kit, the other whether a runtime behaves as the pages say. Every normative statement is covered by a check or a written waiver.

Docker maintains the specification today, and it should not stay under a single vendor: a format for deciding what an agent may do is worth less if it belongs to whoever sells you the runtime. Docker Sandboxes will be a first-class implementation, not the only one. If a Kit you want cannot be expressed, or a runtime duty cannot be implemented as stated, open an issue.

Try it

sbx is our sandbox CLI (brew install docker/tap/sbx). From a checkout of the repository:

cd examples
sbx run ./hello --kit ./gh .

Edit a descriptor and only that Kit rebuilds; docker buildx build publishes it to any registry. Docker Cloud Sandboxes runs the same Kits with the same trust model on elastic capacity. The specification, capability pages, and a worked tour are in docker/sandbox-kit-spec.

Not only agents

Agents forced this into the open because the authority they ask for is so large, but ordinary workloads have always arrived with unwritten expectations: the endpoints they call, the credentials they need, the volume that must survive a restart. That knowledge has lived in a Helm chart, a runbook, or a colleague. It is the same gap, less alarming when a web service gets it wrong. This specification is where any software writes down what it needs from the world around it; agents were the case urgent enough to have it built.

Dockerfiles made software reproducible. Kits make authority reproducible.

As teams put AI agents to work, they need to move quickly without losing control of what they deploy. They’re combining models, tools, and infrastructure from across a fast-changing ecosystem. Making those pieces work together and keeping them accountable as the stack evolves is becoming a core part of building AI applications.

Docker’s approach to this challenge is providing a trusted, common foundation for containment, curation, and control of agent workloads at its core, while pairing those capabilities with an open ecosystem of partners and tools.

That ecosystem spans model providers, MCP tools and gateways, enterprise applications, data and memory platforms, identity, security, observability, and code quality. It also includes the cloud providers, systems integrators, and channel partners that help organizations bring these capabilities into production. 

Integrating this ecosystem gives teams the freedom to choose the models, platforms, and clouds that fit their needs while maintaining a consistent foundation for governance. Developers remain in the lead: choosing what agents can access, directing their work, and verifying the outcomes. The goal is to give them the tools and guardrails to build with confidence as models, frameworks, and requirements change.

At WeAreDevelopers World Congress North America, September 23–25 in San Jose, partners and customers are bringing that ecosystem to life at the Docker Pavilion. Customer sessions will show how these technologies come together in practice, from repeatable AI deployments at the edge to simpler development with payment APIs. Lightning talks and demos will explore enterprise knowledge and agent memory, collaboration between agents, security and incident response, and verification of generated code. 

Here’s who you can meet and what they’ll be sharing.

Customer talks — September 24

Customers bring another essential perspective: how these technologies come together in the systems they build.

• Spectro Cloud: In “Repeatable Agentic Workloads on Palette,” Colton Shaw will demonstrate how a versioned cluster profile brings together hardened images, local inference, and agent workloads for repeatable edge deployments, including environments without a cloud connection. 12:15–12:30 PM.
• Joint panel “From TokenMaxxing to True AI Ownership,” hosted by Per Krogslund from Docker and executives from Spectro Cloud and J.P. Morgan Payments, for a conversation about moving beyond token consumption toward ownership of how AI is deployed, governed, and put to work. September 24, 3:45 PM.
• J.P. Morgan Payments: In “Insert Coin: docker compose up with J.P. Morgan Payments,” Alan Torrance will show how developers can run Unicorn Finance with one command and no API keys. The open source example brings a client, mock server, and the real OpenAPI specifications behind J.P. Morgan’s Payments APIs together in two containers. 4:30–4:45 PM.

Partner talks — Sep 24, 2026

• Palo Alto Networks: Investigate agent activity through searchable audit records and live detections in Cortex XSIAM, with Cameron Hyde showing the integration in action. 11:15–11:30 AM.
• Datadog: Follow an agent security incident from detection to investigation and response, with Amrita Lakhanpal connecting AI Guard, service context, and incident management. 12:45–1:00 PM.
• ClickHouse: Reduce unnecessary components in your database’s base image. Zoe Steinkamp will walk through running ClickHouse on Docker Hardened Images. 1:15–1:30 PM.
• Prediction Guard: Explore how execution isolation and controls over model calls work together, with Sharan Shirodkar testing both against a poisoned tool output. 3:15–3:30 PM.
• Snyk: See the prompts, file activity, and generated code behind an agent’s work, with Javier Garza demonstrating the Evo Agentic Development Security Sandbox Kit. 5:00–5:15 PM.

Partner talks — Sep 25, 2026

• GitGuardian: Put controls around the moments an agent reads files, edits code, or runs commands, with Dwayne McDaniel showing how hooks can help protect secrets. 9:00–9:15 AM.
• Mend.io: Add runtime guardrails to detect malicious inputs, prevent unsafe actions, and record agent activity, with Gary M Segal demonstrating the approach. 9:30–9:45 AM.
• Merge: Give agents access to an integration catalog while keeping third-party credentials outside the sandbox, with Gil Feig explaining how the pieces connect. 9:45–10:00 AM.
• BAND: Explore how separately sandboxed coding agents can exchange tasks, messages, and artifacts, with Vlad Luzin demonstrating collaboration through Jam. 12:15–12:30 PM.
• Chainloop: Give reviewers evidence of what an agent actually did. Daniel Liszka will demonstrate signed session records and policy checks on a pull request. 1:15–1:30 PM.
• Box: Turn enterprise documents into deliverables that people can review, with Carter Rabasa demonstrating governed document access, evidence checks, and isolated code execution. 2:30–2:45 PM.
• SurrealDB: Build agents with memory you can inspect over time, with Chiru Boggavarapu showing how to trace what an agent knew and when. 2:45–3:00 PM.
• Cognee: Give agents temporary access to company knowledge and remove it when the task is finished, with Vasilije Markovic demonstrating a practical architecture. 3:45–4:00 PM.
• Sonar: Guide and verify agent-generated changes using Sonar Vortex and the SonarQube CLI, with Manish Kapur demonstrating the workflow inside a sandbox. 4:45–5:00 PM.

These sessions bring together the people building the tools and the teams putting them to work. It’s an opportunity to compare approaches, ask questions, and see how the ecosystem can help you tackle your next engineering challenge.

Come visit us at WeAreDevelopers. Meet our partners, customers, and speakers, catch a lightning talk, and see their technologies in action. Plan your visit to San Jose.

In our State of Agentic AI report, 60% of organizations reported having AI agents running in production. Those agents install packages, run scripts, and call external services on their own, and much of that work now happens on developer laptops, with developer credentials. Running untrusted or experimental code directly on your machine has always carried risk, and handing that same machine to an autonomous agent raises the stakes.

A sandbox environment gives code a separate, controlled space to run in, with limited access to the machine underneath and external systems. How strictly it holds that line depends on how the sandbox is built, which is where the differences between them start to matter.

The benefits of sandbox environments are worth understanding on their own, and they compound when the thing running inside is an agent working unattended with permissions auto-approved. Below are six, from isolation and credential handling to the policy you enforce at runtime, and how Docker Sandboxes delivers each one.

1. Isolation

Everything in this list builds on isolation, and the strength of that boundary is what makes a sandbox trustworthy. For Docker Sandboxes, each sandbox runs in its own microVM: a lightweight virtual machine with its own Linux kernel, isolated from the host by a hardware-backed hypervisor boundary. 

That boundary is the same kind of isolation a full virtual machine gives you, and it’s what lets you hand an agent real freedom. Because a Docker sandbox runs its own kernel, a compromised or runaway agent can’t reach the host, other sandboxes, or anything outside its environment. If it tries to escape, it hits a wall. So an agent can install packages, pull untrusted dependencies, and run code unattended. But when something inside goes wrong, the damage stays in the sandbox and disappears when you discard it. That containment is what makes it safe to let an agent run at full speed.

2. Network and filesystem controls you define

Isolation sets the outer wall. The controls you define decide what the workload can reach while inside it. Most sandboxes let you scope network and filesystem access to some degree: which domains and IP ranges the workload can reach, and which paths on the host, if any, it can read or write. How precisely you can express that policy varies between tools, and it’s worth checking before you commit, because broad-strokes rules leave gaps that an agent will eventually find.

Docker Sandboxes lets you set that policy per sandbox and enforces it at the boundary at runtime, so the rules hold even when the code inside tries something you didn’t anticipate. The same controls that keep an experiment from making unauthorized outbound connections also shut down data exfiltration and block access to untrusted or malicious services. Restricting the filesystem keeps sensitive host paths, like SSH keys and cloud credentials, out of reach.

3. Secure credential handling

Agents need credentials to do useful work: a token to push to a repo, an API key to call a service. The risk is that a credential sitting inside the environment can be read, logged, or leaked by whatever runs there. Most sandboxes pass secrets in as environment variables or mounted files, which puts the value inside the boundary where the workload can read it, and so can anything the workload runs.

Docker Sandboxes keeps credentials out of the environment entirely. They stay in the host keychain, and the sandbox injects them into outbound network requests at the boundary, so the workload gets the benefit of the credential while the value itself stays on the host. An agent that can’t read a secret also can’t exfiltrate it, write it to a log, or hand it off to a prompt-injected instruction. The credential does its job on the request path while the sensitive material stays under your control.

4. Ephemeral, disposable environments you can recreate fast

A sandbox is quick to create and easy to throw away, so you can treat every one as disposable. When a task finishes, or when an agent goes off the rails, you can delete the environment and everything inside goes with it, from installed packages to running processes to any changes the agent made to the system. But if your working directory is mounted from the host, the files the agent creates or edits there stay on your machine even after the environment is gone.

The recreation side is just as valuable. Because a sandbox is defined in code, you can spin up an identical environment on demand, configured the same way every time, down to the packages and settings. This is the infrastructure-as-code approach applied to your workspace: reproducible, versionable, and consistent across a team. For agents, disposability also unlocks parallelism. You can run several agents at once, each in its own fresh environment, and tear them all down when the work is done.

5. A real Linux dev environment with a full Docker daemon

Isolation doesn’t have to mean a stripped-down box. A sandbox worth using gives the workload a real Linux environment with the tools a developer or an agent actually needs, so you can install packages, run services, start databases, and compile code inside the boundary. Environments vary widely in how complete they are, and a thin one pushes work back onto the host, which defeats the point of having a boundary at all.

Docker Sandboxes includes a full Docker daemon, isolated within the sandbox, so an agent can build and run containers as part of its work with no path back to the host daemon. That’s a meaningful capability for agentic workflows, where a single task might involve building an image, running a test suite in a container, and tearing it all down. The environment behaves like a genuine machine, which is what makes it a viable place to do real work.

6. The same sandbox technology for every agent

Developers will often move between agents. One task suits Claude Code, another suits Gemini CLI, Copilot CLI, Codex, Kiro, or OpenCode. If each agent brought its own isolation model, you’d be securing a different environment for every tool, and each vendor’s model could shift with a version bump.

A single sandbox technology solves this by running every agent the same way, inside the same kind of isolated environment with the same policy engine. You define network, filesystem, and credential policy once, and it applies no matter which agent is doing the work. For a platform or security team, that consistency is what makes governance enforceable at scale: one boundary to reason about, one set of controls to audit, across every agent your developers adopt.

Who gets the most from sandbox environments

The same six benefits pay off differently depending on your role.

• Individual developers
• You get freedom to experiment. You can try a risky dependency, run an unfamiliar tool, or let an agent work unattended, knowing the environment is contained and disposable. When something breaks, you delete it and start clean, and your machine is never in the blast radius.
• Platform teams
• You get consistency and control. A sandbox defined once gives every developer the same environment and the same policy, across whichever agents they use. That means less setup for your developers to think about and a single standard you can maintain centrally.
• Security teams
• You get containment and oversight. A sandbox limits what an agent can reach and gives you one boundary to monitor across every tool. You can approve agent adoption because the environment enforces your policy at runtime, which is the heart of securing AI agents in production. Every environment is disposable, so there’s nothing persistent to compromise.

Why this matters for AI agents

Put the six together and you get the reason why sandboxes might become the standard way to run agents. An agent needs autonomy to be useful. It has to install things, run code, and call services without a human approving each step. Autonomy on your host machine is dangerous, but put it inside a sandbox and it’s safe.

Isolation contains what the agent can do, and the controls you define scope what it can reach. Credentials stay out of its hands, so a compromised agent has nothing to leak. When a run goes sideways, disposability lets you throw the environment out and start over in seconds. And a real Linux dev environment means the agent can do genuine work, and running every agent on one sandbox technology keeps all of this consistent no matter which tool your team reaches for. Together, these benefits let an agent operate at full speed while keeping the blast radius of any mistake close to zero.

Run agents safely with Docker Sandboxes

These benefits depend on each other, and a gap in any one becomes the weak point a runaway agent finds first. Isolation without credential handling still leaks your secrets, and a dev environment you can’t tear down cleanly turns into a liability the first time an agent misbehaves.

Running agents safely means delivering all six together, and that’s what Docker Sandboxes is built to do. Containment comes from microVM isolation, the controls are the network and filesystem policy you set, and credentials stay in the host keychain, injecting at the boundary so the agent never sees them. Environments are disposable and defined in code, the workspace is a real Linux system with a full Docker daemon, and the same sandbox technology runs every major coding agent the same way.

And when you’re ready to run agents safely across a team, Docker AI Governance extends the same boundary into org-wide policy. You define network, filesystem, and tool-access rules once, govern which credentials a session can use, and apply it on every developer’s machine, with an audit trail security can defend.

Get started with Docker Sandboxes → 

Explore Docker AI Governance →

Frequently asked questions

AI evaluation has never been easier to start. Reproducing it reliably is another story. Developers now have access to more benchmarks, evaluation libraries, model APIs, and agent frameworks than ever before. But keeping the prompt, model, and scoring method fixed doesn’t necessarily make a run reproducible. The execution environment matters too.

Python dependencies change. Local tools drift. Setup steps go undocumented. A workflow that succeeds on one machine may behave differently on another. Most discussions about evaluation focus on what should be measured: benchmarks, scoring methods, or judge models. Much less attention is given to how those evaluations are executed. Yet that execution layer often determines whether someone else can reproduce the same workflow weeks or months later.

When I started exploring Docker Sandboxes, I wasn’t trying to build another evaluation framework. I had a much smaller question.

That question eventually became the SBX AI Evaluation Kit, an open-source Docker Sandboxes Mixin Kit focused on repeatable execution, structured evaluation records, and runtime evidence. The current implementation does not execute AI models or automatically derive evaluation judgments. Instead, it executes configured commands consistently and preserves evidence of what actually ran.

In Practice

In practice, the workflow starts by choosing where the evaluation command should run through the execution block:

execution:
  executor: sbx
  command:
    - python3
    - -c
    - print("hello from sbx")

With executor: sbx, the runner delegates command execution to Docker Sandboxes and writes the runtime evidence into the resulting artifact.

The repository is also packaged as an SBX Mixin Kit, so it can be applied when starting a Claude sandbox:

sbx run claude --kit .

The runner reads the configured executor and delegates the command to SBX, which executes it inside the sandbox:

python run_evaluation.py

From Documentation to an Executable Workflow

Each evaluation is defined in a YAML file that describes the evaluation and the command to run. The repository validates that definition, executes it, and produces a structured JSON record of the result. The difference is in what gets recorded. A written evaluation captures what someone intended to do. An execution-backed evaluation captures what actually happened.

Separating Evaluation from Execution

I wanted the evaluation definition to stay independent of where it ran. A workflow written during local development shouldn’t need to change simply because it later executes inside Docker Sandboxes.

To keep those concerns separate, I introduced an executor abstraction. The evaluation describes what should run; the executor determines where it runs.

With the local executor, the configured command runs on the host. With the SBX executor, command execution is delegated to Docker Sandboxes. Switching between the two only requires changing the executor configuration, not rewriting the surrounding evaluation workflow.

Figure 1. Evaluation definitions remain independent of the execution environment. The same workflow can use either the local or SBX executor while producing runtime evidence in the same structure.

Capturing Evidence Instead of Assumptions

For each execution, the runner records enough information to inspect what actually happened:

• the selected executor,
• the command that was executed,
• standard output (stdout) and standard error (stderr),
• the exit code,
• and the execution time.

These details are stored in the evaluation artifact. The repository also generates a digest of the evaluation configuration. This creates a deterministic link between the evaluation configuration and the artifact it produced, without trying to replace full experiment-tracking systems.

{
  "executor": "sbx",
  "command": ["python3", "-c", "print(\"hello from sbx\")"],
  "stdout": "hello from sbx\n",
  "stderr": "",
  "exit_code": 0,
  "duration_ms": 120.0
}

Scaling from One Evaluation to Many

Real-world evaluation rarely consists of one isolated run. Teams compare prompts, validate behavior, measure regressions between releases, and test multiple scenarios. That led to evaluation suites.

Rather than changing how an individual evaluation works, a suite groups multiple evaluation definitions into a single repeatable workflow. Each evaluation still produces its own structured artifact, while the suite also generates an aggregated summary of the overall run.

Reusable SBX Kits Beyond Evaluation

The same pattern isn’t limited to evaluation. An SBX Kit can package more than a development environment; it can also package the setup an engineering workflow depends on. The same model could support regression testing, policy checks, security analysis, code-generation experiments, and other workflows that depend on consistent execution and inspectable results.

Conclusion

The SBX AI Evaluation Kit doesn’t replace evaluation frameworks, benchmarks, or scoring systems. Its job is narrower: execute configured evaluation workflows in a way that is easier to rerun and inspect.

The question I came away with is simple: before comparing benchmark scores or choosing a judge model, can someone else reliably run the same workflow under comparable conditions?

You can explore the code, experiment with custom evaluation YAMLs, and run the workflow yourself in the sbx-ai-eval-kit repository on GitHub.

Resources

• SBX AI Evaluation Kit – Source code, example evaluation definitions, and the implementation described in this article.
• Docker Sandboxes documentation – Official documentation for setting up and running Docker Sandboxes.
• Customizing Docker Sandboxes with Kits – Official documentation for extending Docker Sandboxes with reusable Kits.

We believe the future is a multi-model, multi-harness world. And we think it needs a new trust model.

In 1988, Norm Hardy described a problem that had been quietly breaking systems for years: the confused deputy. A program that takes action using its permissions instead of yours.

Today, every AI agent is that deputy. It inherits your authority: Your credentials, your repo access, your ability to call APIs. But its behavior is probabilistic. It might be acting on an instruction found in its environment, on a step it invented, or on a confident wrong answer. 

The industry didn’t fix the confused deputy problem by making the deputy itself more careful. They fixed it by moving its authority a layer away. Forty years on, that’s still the answer.

Everyone is converging on the same future

Three facts are pushing the industry toward the same conclusion.

1. Agents are expensive loops. An agent takes many steps, and you pay for every token of every one. We all can agree that it makes no economic sense to call the latest frontier model for simple tasks. 
2. The leader of frontier capability changes often. We’re all aware that the top model of the day (and its vendor) changes every couple of months.
3. Your workflows may need custom models. Many teams are recognizing that intelligence is commodifying and the differentiator is custom models, derived from custom context.

As a result, all of us are quickly ending up with a portfolio of multiple models across multiple harnesses. 

A similar convergence is happening one layer up. Developers pick certain tools for the right task, the way they always have. For example, perhaps Claude Code for long refactors, Codex for daily work, Hermes for quick scripts. 

It’s reasonable to expect the future of work to be multi-model and multi-harness.

Which makes trust the defining question

A lot of agents work the same way. 

They read material that is often out of our control: support tickets, web pages, documentation, and code written by strangers. But they act with authority you granted: your credentials, repo access, production APIs, and the open internet. And they usually do both from a developer’s laptop, outside typical security guardrails like VPCs and IAM.

Private data and the ability to act autonomously, together, is what makes an agent worth deploying. Your deputy needs the ability to execute in order to be useful. Which means the interesting question is no longer which model is best. It’s what happens when one of these deputies is wrong, or manipulated.

Per-harness guardrails break down

The obvious answer is that each harness ships its own guardrails. Many do. But relied on as your security boundary, they fail in three ways.

1. The agent talks past them. Guardrails inside the harness are enforced in the same loop the agent is running. Deny it a git push and it reaches for the API. Deny the API and it opens a gist. Deny the gist and it tucks the data into a channel you trust and never inspect. Researchers showed last year that a single malicious issue filed in a public GitHub repo could steer a coding agent into reading a company’s private repositories and publishing the contents in a pull request the agent opened itself. Nothing was hacked since every step used the agent’s own legitimate access, through a channel everyone trusts. A boundary the agent can negotiate with is not a boundary.
   
2. The rails move without you. Most harness’s isolation models are closed source and ship on their vendor’s schedule. The major coding agents have each revised their default sandbox and approval behavior several times in the past year alone. Updates to sandboxing models should be treated as a security event. Multiply this by ten harnesses and your security posture is, at any moment, whatever is the patchwork of your half dozen vendors’ measures.
   
3. The rails don’t cover the fleet. The custom agent your platform team built has exactly the guardrails your platform team wrote. The agent inside your support SaaS has whatever its vendor chose, and most expose no isolation controls to you at all. Every new harness means building or auditing governance again, from scratch, differently. You end up with a dozen implementations that drift apart, each blind to the others’ traffic, with no single place to set a rule and no single record to understand why something went wrong.

Safety cannot depend on the agent making the right decision, or on someone else’s release schedule.

A layer below

So here is what we believe. The future is multi-model and multi-agent. And given that future, we believe every organization will need a layer below: a runtime layer, below the harness, that all of them run on top of.

The reasoning is straightforward. Strip away the model, the vendor, and the framework, and an agent has two ways to affect anything. It runs code, which touches files and opens network connections. Or it calls a tool, which acts on a system. Everything an agent does travels one of those paths. And both paths cross the same surface: the runtime, where processes execute, credentials get used, and requests leave the machine. Every agent passes through it, no matter which model powers it, which vendor shipped it, or whether you built it yourself. That makes it the one place where rules you define can be enforced across all your agents. It is also the same fix as 1988, applied to today’s deputy: the authority sits a layer away.

Put enforcement there and each of the three failure scenarios we spoke about flips around.

Your agents can’t talk past themselves. The boundary for an agent sits outside the loop the agent is running, so it holds steady no matter if the model is with you, hallucinating, or compromised. A hard neutral boundary at the runtime is more effective than a prompt-level boundary the agent creates for itself.

The rails stop moving randomly. Policy is yours, written once, covering execution, tool calls, credentials, and spend. Now, a model or agent vendor making an update won’t randomly change your security posture.

The rails cover your whole fleet. A policy you write up will apply to every harness. And every action, by all your agents, lands in one record: what ran, what it touched, which rule decided. 

This is what lets you be nuanced about agents. Without a boundary below your harnesses, you have three bad options: block agents completely, allow all of them and hope for the best, or wedge a manual approval into every step and give up the productivity you wanted.

A boundary at the runtime gives you a fourth option. When consequences are bounded even if an agent goes off the rails, you can start granting it true autonomy, which is the goal.

We expect models to keep changing and new harnesses to land in all of our toolkits. That part is healthy. The boundary underneath them is the part that should hold steady.

At We Are Developers in San Jose, Tushar Jain, Docker’s CTO, will talk more about this world: multiple models, multiple harnesses, and a single runtime under it all.

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.

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.

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.

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.

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.

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.

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

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.

A conference built around developers

From September 23 through 25, thousands of developers will gather at the San Jose McEnery Convention Center for the first ever WeAreDevelopers World Congress North America.

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.

Register today. We’ll see you in San Jose.

For teams building AI-governed systems, the EU AI Act adds compliance obligations to every stage of the development lifecycle, from documenting training data to reporting incidents in production. With phased enforcement already underway, now is the time to assess where your workflows stand.

The EU AI Act (Regulation (EU) 2024/1689) is the world’s first comprehensive AI regulation. It entered into force in August 2024 with requirements rolling out in phases through 2027. The Act applies, among others, to any organization that places an AI system on the EU market, deployers of AI systems established in the EU, or whose AI system’s output is used in the EU, regardless of where that organization is headquartered.

This guide covers what each risk tier requires, the full compliance timeline (including the 2026 Digital Omnibus adjustments), transparency obligations, penalties, and what compliance looks like for the teams building and operating AI systems.

The four risk tiers

The AI Act takes a risk-based approach. Every AI system falls into one of four categories, and the category determines the regulatory obligations that apply. This classification drives the entire compliance process.

1. Unacceptable risk (prohibited)

AI systems in this tier are banned outright under Article 5. These prohibitions have been in effect since February 2, 2025. The prohibited practices include:

• Subliminal, manipulative, or deceptive techniques that distort behavior and cause significant harm
• Exploitation of vulnerabilities related to age, disability, or socioeconomic circumstances
• Social scoring systems that evaluate individuals based on social behavior or personal traits
• Predictive policing based solely on profiling or personality traits
• Untargeted scraping of facial images from the internet or CCTV to build facial recognition databases
• Emotion recognition in workplaces and educational institutions (except for medical or safety reasons)
• Biometric categorization to deduce or infer certain protected characteristics (except for labelling or filtering of lawfully acquired biometric datasets)
• Real-time remote biometric identification in publicly accessible spaces for law enforcement, with narrow exceptions for missing persons, imminent threats, and serious crime investigations

2. High risk (regulated)

High-risk AI systems are subject to the most extensive compliance obligations. The Act identifies two paths to high-risk classification:

• Annex I systems: AI used as a safety component or product covered by existing EU product safety legislation (medical devices, machinery, vehicles) that requires a third-party conformity assessment.
• Annex III systems: AI used in eight sensitive areas: biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration and border control, and administration of justice.

Any AI system used to profile individuals within an Annex III use case is automatically classified as high-risk, regardless of other exemptions. Providers who believe their Annex III system is not high-risk must document that assessment before placing it on the market.

This is the tier that puts the heaviest demands on your logging, testing, and documentation pipelines.

3. Limited risk (transparency risk)

AI systems in this tier face requirements focused on transparency and disclosure. Under Article 50, deployers must ensure that users know they are interacting with an AI system (e.g., chatbots), and providers of generative AI must mark synthetic content as AI-generated. This tier is where deepfake obligations sit, covered in detail below.

For software engineers, this comes down to marking generated content in a machine-readable way and surfacing the disclosure where users actually see it.

4. Minimal risk (unregulated)

The majority of AI systems currently on the market, including spam filters, AI-enabled games, and recommendation engines, fall here. No specific regulatory obligations apply, though the Act encourages voluntary codes of conduct.

The compliance timeline

The EU AI Act’s requirements take effect in phases, not all at once. Some obligations are already enforceable. Others will not apply until late 2027.

Obligations for high-risk systems by role

The EU AI Act distinguishes between providers, deployers, importers, and distributors. Their obligations differ by role.

Deepfake and transparency obligations (Article 50)

Article 50 creates specific transparency requirements for AI systems that interact with people or generate synthetic content. These obligations generally apply from August 2, 2026 and are relevant regardless of the system’s risk classification.

Who must comply

• Providers of AI systems that interact directly with people must ensure that individuals are informed they’re interacting with an AI system, unless this is obvious from the circumstances.
• Providers of AI systems that generate synthetic content (audio, image, video, or text) must mark that output in a machine-readable format that’s detectable as AI-generated or manipulated. The marking must be effective, interoperable, robust, and reliable.
• Deployers who use AI to create deepfakes must disclose that the content has been artificially generated or manipulated. The Act defines a deepfake as AI-generated or manipulated image, audio, or video content that resembles existing persons, objects, places, or events and would falsely appear authentic.
• Deployers who publish AI-generated text on matters of public interest must label it as AI-generated, unless the content has been through human editorial review and a natural or legal person holds editorial responsibility.
• Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to the system that it’s operating, and handle their personal data in line with the GDPR.

The Code of Practice for transparency

The European Commission developed a Code of Practice on marking and labeling AI-generated content to operationalize Articles 50(2) through 50(5). The code provides practical and technical guidance for real-world implementation of the marking and disclosure requirements. Its final version was published on June 10, 2026.

General-purpose AI model obligations

Chapter V of the Act creates a separate set of obligations for providers of general-purpose AI (GPAI) models. These rules have been applicable since August 2, 2025 (models placed on the market before that date have until August 2, 2027 to comply). The European Commission has published guidelines to support providers in meeting these requirements.

All GPAI model providers

Every provider of a GPAI model must draw up and maintain technical documentation (which shall contain at minimum the information set out in Annex VI), provide information and documentation to downstream providers integrating the model, establish a policy to respect the EU Copyright Directive, and publish a sufficiently detailed summary of the content used for training.

Providers of free and open-license GPAI models (where parameters, architecture, and usage information are publicly available) do not need to comply with the obligations regarding technical documentation and provision of information to downstream providers, unless the model presents a systemic risk.

GPAI models with systemic risk

A GPAI model is presumed to carry systemic risk if it was trained using more than 10²⁵ floating point operations (FLOPs) of compute. That bar was set to capture the frontier models of the day: GPT-4 is widely estimated to sit above it, while the earlier GPT-3 was trained on roughly 30 times less. The Commission can also designate other models as systemic on criteria like the number of end users, high-impact capabilities, or output modalities.

Providers of systemic-risk models carry every GPAI obligation above, plus four more:

• Model evaluation: Run model evaluations, including adversarial testing.
• Risk mitigation: Assess and mitigate the systemic risks the model could pose.
• Incident reporting: Track and report serious incidents to the AI Office.
• Cybersecurity: Maintain an adequate level of protection for the model.

A voluntary Code of Practice for general-purpose AI models was published in July 2025. Following a code of practice creates a presumption of conformity until European harmonized standards are in place.

Penalties and enforcement

The EU AI Act establishes a three-tier penalty structure under Article 99, designed to be effective, proportionate, and dissuasive.

Enforcement is split between the European AI Office, which oversees GPAI model providers, and national competent authorities in each Member State, which handle all other operators.

Each Member State must designate at least one national authority for implementation and market surveillance. The penalty provisions are designed to account for the interests of small and medium-sized enterprises and startups, and Member States report annually to the Commission on fines issued.

What compliance looks like for engineering teams

The EU AI Act’s requirements are written in regulatory language, but they translate to concrete engineering concerns. If your team builds or deploys AI systems that serve EU users, here’s where the Act’s obligations intersect with your development workflow.

Inventory and classification come first

Compliance starts with knowing what you have. Every AI system the organization builds, uses, or procures needs to be cataloged and classified against the Act’s risk tiers. Record, for each system, whether it processes personal data and link the entry to your GDPR records of processing (Article 30) so the AI inventory and the privacy record stay aligned.

This is not a legal exercise alone. Engineering teams are typically the only ones who understand the actual capabilities, data flows, and deployment contexts of the systems they build. If your organization has an AI governance framework in place, the AI inventory is usually its foundation.

Audit trails are non-negotiable

The Act requires automatic event logging for high-risk systems and structured documentation across almost every tier. This means every decision an AI system makes, the categories of data sources it accesses, and every action it takes needs to be logged in a way that is auditable. 

Teams already shipping AI agents need structured event capture of system actions, including timestamp, session context, the tool or rule invoked, and the agent or service identity, scoped to system-health and security telemetry rather than individual worker performance. Exporting these logs to existing SIEM and compliance systems closes the gap between agent behavior and audit requirements.

Prepare your risk management system

Article 9 requires a continuous risk management process, including control measures for risks that can’t be removed by design. 

The ability to enforce policies is the mechanism that makes your chosen controls binding at the moment the agent acts, therefore acting as a risk mitigating strategy. This can happen at the agent level, by applying policies and rules to sandboxed agents, and at the tool level, with policies applied to the gateway that manages agent tool access.

Runtime isolation supports human oversight

The EU AI Act requires that high-risk AI systems be designed for human oversight, and that deployers can intervene during operation. For agentic workloads, where AI acts autonomously, this maps directly to runtime isolation: running agents inside sandboxed environments where network access, filesystem scope, and tool permissions are policy-controlled. 

If an agent exceeds its intended scope, isolation constrains the blast radius. This is the mechanism that makes oversight enforceable at the infrastructure level.

Transparency can be instrumented

Article 50’s deepfake and synthetic content marking requirements are a metadata problem. Providers need to embed machine-readable markers in generated content, and deployers need to surface human-readable disclosures. 

For teams building generative AI systems, this means integrating content provenance marking (such as C2PA or IPTC standards) into the generation pipeline. Where generated content depicts a real, identifiable person, it is also personal data under the GDPR, so the marking is necessary but not sufficient and the usual lawful-basis and rights obligations still apply. The AI governance controls your organization uses can enforce these policies at the platform layer rather than relying on each application to implement them independently.

Use the official compliance tools

The European Commission has launched the AI Act Service Desk, a single information platform that includes an official Compliance Checker to help organizations determine which obligations apply to their AI systems, an AI Act Explorer for navigating the full regulation text, and a helpdesk for submitting questions. These tools are free, official, and available in English, French, and German (with all 24 EU languages planned for 2026).

Start building compliance into your AI infrastructure

EU AI Act compliance is not a document you file. It’s a set of technical controls, organizational processes, and audit practices that need to be embedded in how your team builds and operates AI systems.

To make things easier, Docker AI Governance supports operationalizing these requirements. It does not replace the human oversight, classification, and legal accountability the AI Act assigns to providers and deployers, and customer code, configurations, and telemetry are not used to train Docker’s or third-party models. Instead, Docker AI Governance includes sandbox-based runtime isolation for blast-radius risk mitigation and real time monitoring, policy enforcement across network, filesystem, and MCP tool access, and structured audit logging that exports to existing SIEM and compliance systems.

Explore Docker AI Governance to see how runtime policy, audit trails, and agent isolation support the regulatory controls the EU AI Act requires.

Frequently asked questions