Harbor integra Docker Sandboxes para rodar avaliações de agentes de IA em microVMs isoladas
Docker announced that the open-source Harbor framework now runs each agent evaluation task in a separate Docker Sandbox, with its own kernel and configurable networking, to reduce non-reproducible results and reward hacking loopholes.

Docker announced on October 22, 2026, that Harbor, the open-source framework for evaluating AI agents, now runs on top of Docker Sandboxes. In practice, each evaluation task no longer shares a container with other tasks and now runs isolated in its own microVM, with a dedicated kernel. The same set of tasks works both locally and on Docker Cloud Sandboxes, and the company says it tested running 64 tasks simultaneously in the cloud.
For those who build or evaluate coding agents, the problem the integration targets is concrete. Running a coding agent benchmark means letting it install packages, edit files and execute commands, often thousands of times in sequence. Docker's engineers describe this as running untrusted, AI-written code at scale, according to InfoQ. Without strong isolation, leakage between tasks and non-reproducible results become a real project risk.
How microVM isolation works
Harbor already handled orchestration: it triggers tasks, collects scores and logs, and supports benchmarks such as Terminal-Bench. What was missing was an isolated, consistent execution environment for each individual task. That's what Docker Sandboxes now delivers.
Each task runs inside a microVM with its own kernel, which keeps the agent's activity contained: it cannot reach the host, other tasks, or anything outside its own environment. In Docker Cloud Sandboxes, configurable network policies let a task download dependencies during setup and then have internet access restricted while the agent works. This puts every evaluated agent under the same network conditions, which directly tackles a common source of non-reproducible results across runs.
The integration also supports Docker Compose, which lets Harbor run multi-container tasks inside a single cloud sandbox, with services and sidecars sharing the same microVM. It's the kind of setup that shows up in more realistic agent evaluations, where the test scenario isn't a single isolated process but a system with a database, cache, or auxiliary API.
Running locally or in the cloud
Docker made the integration available right away in the nightly release, with arrival in the stable release expected on October 23, 2026. Harbor is installed with the sbx extra, and the nightly build is pinned to version 0.24.1.dev202610150414.
To run in the cloud you need a Docker account with Cloud enabled and a personal access token with Cloud Sandboxes permission. Harbor reads these credentials from the SBX_DOCKER_USERNAME and SBX_DOCKER_PAT environment variables. The run selects the sandbox environment with the -e sbx flag, as in:
harbor run -t hello-world/hello-world -a oracle -e sbxTo run locally, the path goes through the Docker Sandboxes CLI after sbx login, adding --ek target=local to the Harbor command. There's a limitation worth noting: the local integration today only supports the public and no-network modes, subject to the sandbox policy already configured on the machine. The finer-grained network control, which is what guarantees a fair comparison between agents, is tied to Cloud Sandboxes, so anyone who needs that level of control has to plan for the cloud path even if that means cost.
Isolation is not synonymous with anti-cheating
One point worth highlighting for those designing their own benchmarks: network restriction closes off one avenue for cheating, but Docker doesn't claim it prevents reward hacking inside the sandbox itself. The typical case cited by the source is an agent that tampers with test files it has write permission to, inflating its own score without actually solving the task.
This means teams evaluating coding agents internally still need to design tests with this vector in mind: restricted write permissions on evaluation files, independent verification that the test wasn't altered, and auditing of the command history executed by the agent. Network and kernel isolation solves the problem of leakage between tasks, not the problem of an agent manipulating its own test environment.
Context: Harbor, Cloud Sandboxes, and the agent ecosystem
The Docker integration adds to an already long list of sandbox backends supported by Harbor, including Daytona, Modal, E2B, Runloop, Tensorlake, LangSmith, Blaxel, Novita Sandbox, EC2, and Beam, according to the project's GitHub repository. The most recent addition before Docker was LangSmith, which started working through the same interface used for Daytona, E2B, or Modal by installing the langsmith extra, according to Towards AI coverage cited by InfoQ. Harbor's own cloud deployment documentation recommends Daytona when the scenario requires multi-container deploys via docker-compose.yaml, a feature that Modal, E2B, and Runloop don't offer.
This integration also doesn't arise in isolation within Docker itself. In July 2026, GitHub Agentic Workflows added Docker Sandboxes as a supported agent runtime, in version gh-aw 0.82.9, allowing integration tests based on Testcontainers to run without mounting the host's Docker socket.
Harbor's integration also builds on the launch of Cloud Sandboxes on September 24, 2026, which extended local sandbox isolation to Docker-managed infrastructure in the cloud, allowing agent workflows to keep running even if the developer's laptop is turned off. Third-party coverage of that September launch reported a default session of one hour, a maximum limit of 24 hours, and that paused sandboxes don't incur compute charges; the same launch introduced Kits, packaged as OCI images, with Docker already having committed to submitting the Kits specification to the CNCF.
What remains open
The announcement doesn't provide benchmark data on microVM startup overhead, per-task cost, or score variance across runs. The only concrete scale number disclosed is the test with 64 simultaneous tasks on Cloud Sandboxes; higher limits are available by contacting Docker directly. Teams sensitive to per-task latency or to execution cost at scale will need to measure this on their own before migrating an entire evaluation pipeline to the new backend.
For teams in Brazil already using Harbor to evaluate coding agents, whether for internal benchmarks or to validate models before putting them into production, the local option remains free and is the most direct way to start testing today, without relying on additional cloud infrastructure. Those who need network parity across runs, or who need to run dozens of evaluations in parallel without depending on a local machine staying on, are the ones who feel the biggest difference when migrating to the cloud path.
Translated from the Brazilian Portuguese original · Read the original
Critical PHP flaw, discovered with AI help, takes government sites offline in Europe and the US
A flaw that allows remote code execution in the language that powers about 70% of sites with a known back-end led the FBI and the PHP Foundation to call for immediate updates or taking services offline.





