cloud computing News, Entwicklungen, Updates, HowTos - Seite 38 von 7167

In July, Docker, Snyk and Keycard published Agent Baseline, an open, vendor-neutral reference architecture that defines security outcomes for running AI agents in the enterprise. It grew out of conversations with industry leaders who want to adopt agents more broadly but need answers to three questions:

What is operating, with what capabilities?

Is it staying inside approved boundaries?

Can you prove what happened and stop it?

Agent Baseline gave the industry a shared frame of reference for secure agent adoption by defining the security outcomes for safely deploying agents in organizations. Last week, we published the Secure Software Factory reference architecture, which applies those outcomes to one of the most common agentic workflows: the AI-powered software factory.

Enter the Secure Software Factory

The Secure Software Factory was written by practitioners from Keycard, Socket, Docker, Tessl, Tracebit, Browserbase and Tailscale and shaped by conversations with security leaders at large enterprises in regulated environments such as finance and insurance.

Over the past year, many engineering teams have started building software factories: systems where agents take a request, change code, run tests and hand the result to a human for review. Teams report faster delivery, but also agents doing things nobody asked for, like escaping sandboxes, dropping databases and pushing to production without approval.

Teams need controls that limit what agents can access and do, and check their work at each step. The Secure Software Factory reference architecture shows how to apply Agent Baseline’s security outcomes across this workflow, covering:

The factory workflow, from inputs through design, assembly, build and verification, with controls at each stage.

Architectural primitives for identity and access, supply chain, network controls, runtime isolation and orchestration.

A maturity model with three levels, so teams can start where they are and improve over time.

The paper’s central idea is that the more autonomy you give an agent, the less you can rely on it to police itself. An agent can be redirected at runtime by a prompt, a poisoned dependency or a malicious tool description. Controls have to work regardless of what the agent decides, which means they need to live in the environment it runs in. That means boundaries around credentials, tools, dependencies and network access, backed by evidence of what happened and a human accountable for the result.

This is the part of the problem Docker solves. Containers isolate applications; sandboxes isolate actors. Docker Sandboxes are isolated MicroVMs that constrain agents, deterministically.

Docker Sandboxes lets coding agents work autonomously in isolated microVM environments, locally or in the cloud, with explicit boundaries around the files, network destinations, and credentials they can access. This supports Agent Baseline’s Constrain outcome by confining agent execution and limiting its reach to what the approved task requires.

Agent Baseline is only useful if the people building the agent stack agree on it. Which is why we are proud to be among leading companies such as Snyk, Keycard, Browserbase, Tessl, Socket and Tracebit, in shaping the baseline and the reference architectures built on it.

More companies are joining Agent Baseline

In a software factory, context is the new code: it’s what actually gets executed. The skills you consume are part of your supply chain, and can be vulnerable, negligent or outright malicious. They need the same security controls software modules do – let’s get it right from the start!

Guy Podjarny, Founder and CEO, Tessl

“We’ve spent decades learning not to give software more access than it needs. We seem to have forgotten much of that now that the software can talk back. Agents need to reach real systems, sometimes even production. The rules haven’t changed: give them the authority to do a particular job, make that authority expire, and keep the policies and audit trail somewhere the agent can’t rewrite them. Agent Baseline gives everyone a common architecture for making that work, without every team having to figure it out from scratch.”

Avery Pennarun, Co-Founder & CEO, Tailscale

“Enterprises are handing AI agents real credentials, and some of those agents will go off-task, whether through prompt injection, a poisoned tool or a simple mistake. Agent Baseline sets the standard for keeping agents in bounds”

Andy Smith, Co-Founder & CEO, Tracebit

“Agents need the right guardrails to complete tasks on behalf of humans. This is an industry wide effort and Browserbase is proud to continue supporting initiatives like Agent Baseline”

Paul Klein, Founder & CEO, Browserbase

“Agents are already building software, and teams want them picking up work on their own. That only works if an agent’s plan can never become its permission. Agent Baseline gives everyone a shared architecture for deciding what each agent may do, task by task and outside the agent’s reach, so teams can add autonomy without starting their security model over.”

Ian Livingstone, Co-Founder & CEO, Keycard

Get involved

Help shape Agent Baseline and the Secure Software Factory reference architecture by putting them to work.

Read the paper, open an issue on GitHub or join the Agent Baseline Slack to tell us where the architecture doesn’t match how you build. Implementation feedback is the most useful kind.
Quelle: https://blog.docker.com/feed/

22. Oktober 2026

da Agency

Your Agent Runs in a Docker Sandbox. Now It Can Join a Team.

Your sandboxed agents just got a team. The official BAND AI kit for Docker Sandboxes is now available at docker.io/bandhq/band-python-kit:latest.

Docker Sandbox kits package everything an agent needs to run in a Docker Sandbox, so a single sbx create command gives you a ready-to-use agent environment. But an isolated agent is only half the story: real work means talking to people and to other agents. The BAND AI kit connects a sandboxed agent to the world. The agent runs on your machine with access to your repository, and joins a BAND room where it collaborates with humans and with agents running anywhere: locally, in the cloud, or on your own infrastructure. The same kit also connects sandboxes to each other, so multiple agents can work together in one room while each keeps its own isolated environment. In this post, we’ll show how a sandboxed agent connects to the world through BAND, using a local agent called Repo Doctor.

BAND provides the collaboration layer for these agents. With BAND, developers can give agents persistent identities, bring them together in shared rooms, route work through @mentions, maintain message history, and surface tool execution events in the room. Each agent brings its own model, framework, tools, workspace, and infrastructure, and joins the room as a participant, wherever it runs.

Docker Sandboxes give that agent an isolated microVM with its own kernel, filesystem, Docker daemon, and network. Inside it, the agent works with local source files, runs commands and tests, and makes changes to a mounted workspace. The BAND kit connects the two with one sbx create command.

All connectivity is outbound. The agent opens a WebSocket to BAND and posts its replies through the BAND API, so nothing needs to reach into the sandbox. From the room’s point of view, it behaves like any other participant.

Repo Doctor in a BAND room

Here’s a neat example of how it all works together. Repo Doctor is a small agent that repairs a deliberately broken Python project. It runs inside a Docker Sandbox on your machine and participates in a BAND room. Wherever the agent actually runs, you give it work by mentioning its handle through the BAND platform:

This example repo includes a band.yaml file that tells the BAND sbx kit which agent to launch. In this example, it points to main.py, where we define the agent’s instructions, choose Claude as the model, and give it tools to read files, edit source code, and run tests. You can supply a different Python entrypoint that uses BAND’s adapters for coding agents such as Claude Code or Codex, with the required tools and authentication configured in the sandbox.

In this run, Repo Doctor inspected the project and ran the test suite, finds and fixes a failing test. BAND displayed the tool results alongside the agent’s explanation, while the agent ran locally inside the sandbox.

Connect agents to BAND from your machine

To try the same example, you’ll need Docker Sandboxes installed and signed in, a BAND account, and an Anthropic API key with API credits. You can adapt the example of course to your favorite technologies, but the simplest is to clone the example repository:

git clone https://github.com/dockersamples/band-ai-sbx-demo.git
cd band-ai-sbx-demo

In BAND, create a remote agent or use an existing one. Note its handle, which you’ll use to mention it in a BAND room. Set agent.id in band.yaml to its agent UUID, and have its BAND API key ready for the next step.

This example uses Claude, so we’ll also supply an Anthropic API key and allow the sandbox to reach Claude’s API. These settings follow from the agent implementation in main.py in the repo; the BAND kit itself does not require a particular model provider. The BAND agent key authenticates the connection to the platform.

Store both keys before creating the sandbox. Each command prompts for a secret: enter the BAND agent key first, then your Anthropic API key.

sbx secret set-custom
–sandbox band-repo-doctor
–host '**.band.ai'
–env BAND_API_KEY
–placeholder proxy-managed

sbx secret set-custom
–sandbox band-repo-doctor
–host api.anthropic.com
–env ANTHROPIC_PROXY_KEY
–placeholder sk-ant-proxy-managed

Docker Sandboxes keeps the real keys on the host and inserts them into outbound requests. The agent sees only placeholder values, and both credentials are scoped to this sandbox.

Now create the sandbox with the BAND kit, allow the Claude API connection, and start the agent:

sbx create –name band-repo-doctor
docker.io/bandhq/band-python-kit:6.0.0 "$PWD"

The kit already permits access to BAND and the Python package hosts. Add access to Claude’s API for this example:

sbx policy allow network –sandbox band-repo-doctor api.anthropic.com

Then start the agent in the prepared sandbox. The kit installs the example’s locked dependencies and launches the Python entrypoint specified in band.yaml. The agent connects to BAND, where you or other agents can communicate with it.

sbx run –name band-repo-doctor

Keep the terminal open while the agent runs. Once the log shows Connected to platform, add Repo Doctor to a BAND room and mention its handle like we did above.

Create a room and add its participants:

And then you or any other agents can issue commands via the BAND platform.

A local agent in a larger BAND team

Repo Doctor is a single-agent demo, but BAND rooms support larger arrangements. A room can contain agents running locally, in the cloud, or on your own infrastructure. They can mention each other, add specialists to a room, work sequentially or in parallel, and return the result to a human participant.

For example, a planner agent can plan a change and ask a research agent to check the relevant API. When the work needs your repository, it mentions Repo Doctor. Only Repo Doctor needs access to the local workspace, so only that agent runs in the Docker Sandbox on your machine. After running the tests, Repo Doctor can @mention a reviewer with the result; the full execution events remain visible to the human in the room. The same pattern works across sandboxes: agents that each need their own isolated environment can run in separate sandboxes and still collaborate in the same room.

BAND room
|– Planner agent (hosted)
|– Research agent (hosted)
`– @<your-user>/repo-doctor
|
v
local Docker Sandbox
|
your workspace

Humans can see the whole conversation. An agent’s context stays narrower because BAND delivers only messages that mention it. Hosted agents can collaborate broadly, with local execution attached to the one participant that actually needs it.

BAND is particularly good at this composition. The local agent is one participant in a larger room, and its peers address it by handle. That saves you from building agent identity, routing, a worker connection back to the laptop, credential handling, and an audit trail before getting to the actual task. The seam between BAND and the sandbox is a WebSocket connection and a room mention, which is about as much integration code as I would like this problem to have.

Getting started with BAND’s SBX Kit

The BAND Python SDK repository contains the SDK and kit sources. The complete Repo Doctor example in the Docker Samples repository includes the agent, fixture, and scripts used to reproduce the screenshots.

Create a sandbox from the published kit, connect the remote agent to a BAND room, and check sbx policy log to confirm its network requests match the policy you intended.

For sandbox kit configuration, credentials, and network rules, see the Docker Sandboxes kit documentation.

Quelle: https://blog.docker.com/feed/