Harbor integra Docker Sandboxes para rodar avaliações de agentes de IA em microVMs isoladas

A Docker↳Docker46 conteúdosE o Docker Swarm? Contextos e motivadores diáriosDevSecOps · ago 2024Automatizando o ambiente de desenvolvimento e testes com DockerDevSecOps · mai 2019MySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Ver tudo em DevSecOps → anunciou em 22 de outubro de 2026 que o Harbor, framework open-source para avaliação de agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI →, passou a rodar sobre o Docker Sandboxes. Na prática, cada tarefa de avaliação deixa de compartilhar um container com outras tarefas e passa a rodar isolada em uma microVM própria, com kernel dedicado. O mesmo conjunto de tarefas funciona tanto localmente quanto nos Docker Cloud Sandboxes, e a empresa diz ter testado a execução de 64 tarefas simultâneas na nuvem.

Para quem constrói ou avalia agentes de código, o problema que a integração ataca é concreto. Rodar um benchmark de agente coding significa deixar ele instalar pacotes, editar arquivos e executar comandos, muitas vezes milhares de vezes em sequência. Os engenheiros da Docker descrevem isso como execução de código não confiável, escrito por IA, em escala, segundo a InfoQ. Sem isolamento forte, vazamento entre tarefas e resultados não reprodutíveis viram risco real de projeto.

Como funciona o isolamento por microVM

O Harbor já cuidava da orquestração: ele dispara as tarefas, coleta pontuações e logs, e dá suporte a benchmarks como o Terminal-Bench. O que faltava era um ambiente de execução isolado e consistente para cada tarefa individual. É isso que o Docker Sandboxes passa a entregar.

Cada tarefa roda dentro de uma microVM com kernel próprio, o que mantém a atividade do agente contida: ela não alcança o host, outras tarefas ou qualquer coisa fora do próprio ambiente. Nos Docker Cloud Sandboxes, políticas de rede configuráveis permitem que uma tarefa baixe dependências durante o setup e, em seguida, tenham o acesso à internet restringido enquanto o agente trabalha. Isso coloca todo agente avaliado sob as mesmas condições de rede, o que ataca diretamente uma fonte comum de resultado não reprodutível entre execuções.

A integração também suporta Docker Compose, o que permite ao Harbor rodar tarefas multi-container dentro de um único sandbox na nuvem, com serviços e sidecars compartilhando a mesma microVM. É o tipo de configuração que aparece em avaliações mais realistas de agentes, onde o cenário de teste não é um processo isolado, mas um sistema com banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, cache ou API auxiliar.

Rodando localmente ou na nuvem

A Docker publicou a integração disponível desde já na versão nightly, com chegada prevista à versão estável em 23 de outubro de 2026. O Harbor é instalado com o extra sbx, e a build nightly está fixada na versão 0.24.1.dev202610150414.

Para rodar na nuvem é preciso de uma conta Docker com Cloud habilitado e de um personal access token com a permissão de Cloud Sandboxes. O Harbor lê essas credenciais das variáveis de ambiente SBX_DOCKER_USERNAME e SBX_DOCKER_PAT. A execução seleciona o ambiente sandbox com a flag -e sbx, como em:

harbor run -t hello-world/hello-world -a oracle -e sbx

Para rodar localmente, o caminho passa pela CLI do Docker Sandboxes depois de sbx login, adicionando --ek target=local ao comando do Harbor. Vale notar uma limitação: a integração local hoje só suporta os modos público e sem rede, sujeita à política de sandbox já configurada na máquina. O controle de rede mais fino, que é o que garante comparação justa entre agentes, está amarrado aos Cloud Sandboxes, então quem precisa desse nível de controle tem que planejar pelo caminho de nuvem mesmo que isso implique custo.

Isolamento não é sinônimo de anti-trapaça

Um ponto que vale destacar para quem desenha benchmarks próprios: a restrição de rede fecha uma via de trapaça, mas a Docker não afirma que ela previne reward hacking dentro do próprio sandbox. O caso típico citado pela fonte é um agente que adultera arquivos de teste aos quais tem permissão de escrita, inflando a própria pontuação sem de fato resolver a tarefa.

Isso significa que times que avaliam agentes coding internamente ainda precisam desenhar os testes pensando nesse vetor: permissões de escrita restritas sobre arquivos de avaliação, verificação independente de que o teste não foi alterado, e auditoria do histórico de comandos executados pelo agente. O isolamento de rede e de kernel resolve o problema de vazamento entre tarefas, não o problema de um agente que manipula o próprio ambiente de teste.

O contexto: Harbor, Cloud Sandboxes e o ecossistema de agentes

A integração com a Docker se soma a uma lista já longa de backends de sandbox suportados pelo Harbor, incluindo Daytona, Modal, E2B, Runloop, Tensorlake, LangSmith, Blaxel, Novita Sandbox, EC2 e Beam, conforme o repositório do projeto no GitHub. A adição mais recente antes da Docker foi o LangSmith, que passou a funcionar pela mesma interface usada para Daytona, E2B ou Modal ao instalar o extra langsmith, segundo cobertura do Towards AI citada pela InfoQ. A própria documentação de deploy na nuvem do Harbor recomenda o Daytona quando o cenário exige deploys multi-container via docker-compose.yaml, recurso que Modal, E2B e Runloop não oferecem.

Essa integração também não nasce isolada dentro da própria Docker. Em julho de 2026, o GitHub Agentic Workflows adicionou o Docker Sandboxes como runtime de agente suportado, na versão gh-aw 0.82.9, permitindo rodar testes de integração baseados em Testcontainers sem montar o socket do Docker do host.

A integração do Harbor se apoia também no lançamento dos Cloud Sandboxes, feito em 24 de setembro de 2026, que estendeu o isolamento local de sandbox para infraestrutura gerenciada pela Docker na nuvem, permitindo que workflows de agente continuem rodando mesmo que o notebook do desenvolvedor seja desligado. Cobertura de terceiros sobre esse lançamento de setembro reportou sessão padrão de uma hora, limite máximo de 24 horas, e que sandboxes pausados não geram cobrança de computação; o mesmo lançamento introduziu os Kits, empacotados como imagens OCI, com a Docker já tendo se comprometido a submeter a especificação dos Kits ao CNCF.

O que ainda fica em aberto

O anúncio não traz dados de benchmark sobre overhead de inicialização da microVM, custo por tarefa ou variância de score entre execuções. O único número concreto de escala divulgado é o teste com 64 tarefas simultâneas nos Cloud Sandboxes; limites maiores estão disponíveis mediante contato direto com a Docker. Times sensíveis a latência por tarefa ou a custo de execução em escala vão precisar medir isso por conta própria antes de migrar um pipeline de avaliação inteiro para o novo backend.

Para equipes no Brasil que já usam o Harbor para avaliar agentes de código, seja em benchmarks internos seja para validar modelos antes de colocar em produção, a opção local continua gratuita e é o caminho mais direto para começar a testar hoje mesmo, sem depender de infraestrutura de nuvem adicional. Quem precisa de paridade de rede entre execuções, ou de rodar dezenas de avaliações em paralelo sem depender da máquina local ligada, é quem mais sente a diferença ao migrar para o caminho de nuvem.

Fonte: InfoQ