Agente com Docker próprio: onde termina o contêiner e começa a fronteira de confiança

A Docker apresenta Sandboxes como uma fronteira para agentes autônomos: uma microVM com kernel Linux, sistema de arquivos, rede e Docker Engine próprios.[5] No contraste feito pelo fornecedor, contêineres compartilham o kernel do ambiente em que executam.[5] A pergunta prática não é qual tecnologia vence, mas qual autoridade o agente terá sobre a máquina que hospeda seu trabalho.

O que muda para quem desenvolve

O artigo destaca um atalho perigoso: montar o socket Docker do host permite que o processo peça ao daemon montagens de caminhos do host ou contêineres privilegiados.[5] Nesse cenário, não é preciso explorar uma falha de kernel para ultrapassar a separação que o desenvolvedor imaginava ter.[5]

No Sandboxes, o Docker Engine fica dentro da microVM, permitindo Compose e Testcontainers sem depender do daemon do host.[5] Isso cria outra fronteira entre o ambiente de execução do agente e a máquina principal.[5] Minha leitura é que a autonomia deve ser desenhada a partir das permissões reais disponíveis, não do rótulo “isolado”.

O fornecedor também descreve um proxy externo ao agente que nega destinos por padrão e injeta autenticação em serviços HTTP suportados, sem colocar a credencial bruta dentro da VM.[5] O benefício arquitetural é manter a política fora do alcance do componente que pode receber instruções hostis.

Como aplicar

Desenhe um piloto com clone descartável, dados sintéticos e uma tarefa pequena que precise iniciar serviços auxiliares. Antes de rodar, liste tudo que atravessa a fronteira: arquivos, destinos de rede, ferramentas externas e operações autenticadas.

Use como critérios de aceitação a preservação da árvore de trabalho principal, a impossibilidade de acessar destinos não autorizados e a capacidade de executar a tarefa sem o socket do host. Registre também consumo de recursos e esforço para recuperar alterações. Não transforme uma demonstração funcional em autorização irrestrita.

A documentação apresentada no artigo informa que o workspace é compartilhado com leitura e escrita por padrão.[5] O modo de clone privado protege a árvore de trabalho do host, mas o repositório original permanece legível.[5] Portanto, escolha o modo a partir dos dados que podem ser expostos e alterados.

Cuidados e limites

Servidores MCP locais via stdio podem executar no host, e skills compartilhadas também ampliam a superfície acessível.[5] Uma microVM não neutraliza permissões concedidas por fora dela.

O produto exige hipervisor suportado e custa mais memória e disco que um contêiner; kits estão em acesso antecipado e sbxenv.yaml ainda é experimental.[5] Contêineres continuam sendo uma opção razoável para cargas controladas. Para um agente que lê conteúdo externo e executa código, eu exigiria uma justificativa explícita antes de conceder acesso ao ambiente pessoal.

Fonte

[5] Fonte: Docker Blog