Docker leva especificação de Sandbox Kit para a CNCF e empacota permissões de agentes de IA em imagens OCI

O problema: permissão de agente que não vira artefato

Agentes como Claude Code e Codex instalam pacotes, chamam APIs e usam credenciais em nome de quem os aciona. O problema, segundo 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 →, é que as concessões que tornam isso útil (bind mounts, tokens amplos, regras de firewall abertas) costumam viver em histórico de shell, dashboards e na memória de quem configurou, não em um artefato revisável.

A Docker chama isso de exatamente o tipo de fragmentação que o OCI nasceu para evitar. Sem um padrão comum, cada fornecedor de runtime de agente inventaria sua própria forma de declarar o que o agente pode ou não fazer, repetindo o cenário pré-OCI de formatos de imagem incompatíveis entre Docker, rkt e outros runtimes.

A resposta é a Sandbox Kit Specification, licenciada em Apache 2.0, que a Docker anunciou estar levando à CNCF durante o WeAreDevelopers, em 24 de setembro. A ideia é simples de enunciar: empacotar o agente, suas ferramentas e uma lista tipada dos hosts, credenciais e volumes que ele pede dentro de uma imagem OCI comum, a mesma que já roda em qualquer registro, scanner ou pipeline de CI existente.

Como funciona a v3 da especificação

Na versão 3, um Kit deixou de ser um tipo de artefato próprio. Não existe media type customizado nem arquivo satélite: o manifesto carrega uma única declaração, vnd.docker.sandbox.kit.descriptor. Isso significa que um Kit se constrói com docker buildx build, se baixa com docker pull, pode ser escaneado e assinado pelas ferramentas que já existem, e até ser usado como base em um FROM.

Fixar o digest do Kit fixa, ao mesmo tempo, o conteúdo e as permissões associadas a ele. Isso resolve um problema prático de supply chain: não dá para trocar silenciosamente o que um agente pode acessar sem mudar também o hash da imagem que o distribui.

As permissões em si são declarações tipadas e versionadas, como com.docker.sandbox/network-policy@2 para regras de rede e com.docker.sandbox/credential@1 para credenciais. O versionamento por capacidade permite evoluir a semântica de uma categoria de permissão sem quebrar as demais.

O exemplo do GitHub CLI: deny vence

No exemplo publicado junto com a especificação, um Kit libera acesso a api.github.com mas nega explicitamente o verbo DELETE em /repos/**. A regra de resolução é direta: quando uma permissão concede e outra nega o mesmo escopo, a negação vence.

Credenciais podem ser gerenciadas por proxy: um runtime que implemente a especificação injeta o token real apenas nas requisições para os domínios nomeados no Kit, enquanto dentro do sandbox existe só um valor sentinela. Na prática, o agente nunca enxerga a credencial de verdade, o que reduz o risco de ela vazar em logs, prompts ou na saída de um comando mal pensado.

Um detalhe importante: um Kit apenas pede permissões, quem decide é o host. Sem um runtime que implemente a especificação, a anotação fica inerte, e se uma permissão obrigatória não puder ser satisfeita, o lançamento do agente é recusado em vez de rodar com acesso parcial.

Mixins: compondo permissões em camadas

Um lançamento combina um Kit de workload, que fornece o sistema de arquivos raiz, com qualquer número de mixins sobrepostos. A ordem de aplicação dos mixins não é a ordem das flags na linha de comando: ela segue um grafo de dependência baseado em provides e requires.

A resolução falha em dois casos: quando um requires não é atendido, ou quando dois Kits declaram o mesmo provides. Declarações sobrepostas tentam se reconciliar, com regras de rede unidas por união; declarações incompatíveis entre si geram erro em vez de uma permissão ambígua.

Todo descritor também se reduz a um conjunto normalizado de concessões. Isso abre a porta para um runtime que trava atualizações registrar esse conjunto e bloquear qualquer versão nova do Kit que o amplie, inclusive uma versão que remova uma regra de negação que antes existia.

Quem já testou e o que a CNCF disse

A Docker diz ter construído a especificação junto com AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks e Snyk, entre outros parceiros. A empresa traça um paralelo direto com a doação do formato de imagem e do runc que resultou na criação da própria OCI, anos atrás.

O CTO da CNCF, Chris Aniszczyk, comentou o anúncio:

Padrões são o que permite que um ecossistema avance rápido sem se fragmentar, e poucas empresas entendem isso melhor que a Docker. Ao entregar Sandbox Kits como imagens OCI padrão, a Docker está dando à indústria uma forma aberta e repetível de empacotar um agente de IA, suas ferramentas e suas salvaguardas como um único artefato.

Standards are what let an ecosystem move fast without fragmenting, and few companies understand that better than Docker. By delivering Sandbox Kits as standard OCI images, Docker is giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact.Chris Aniszczyk, CTO da CNCF

O material divulgado não diz se a especificação já foi aceita formalmente em algum programa da CNCF, nem qual nível de maturidade (sandbox, incubating, graduated) ela ocuparia. Até a decisão de governança, a própria Docker segue mantendo o projeto.

O que muda para quem roda agentes de IA em produção

Para times no Brasil que já usam Docker em pipelines de build e deploy, a mudança prática é que a revisão de permissões de um agente 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 → passa a caber no mesmo fluxo que já existe para imagens de container: docker pull, scanner de vulnerabilidade, assinatura e política de admissão em cluster. Não é preciso adotar uma ferramenta nova de governança separada, só saber ler um descritor novo.

Isso importa especialmente para quem expõe agentes como Claude Code ou Codex a repositórios e credenciais corporativas. Hoje, saber exatamente o que um agente pode acessar costuma depender de abrir configuração espalhada em múltiplos lugares; com um Kit, essa superfície vira um artefato único, versionado e com digest fixo, que dá para auditar antes de aprovar o deploy.

A ressalva central, admitida pelo próprio material da Docker, é que a especificação só funciona de verdade com um runtime que a implemente, e hoje o único runtime conforme é o Docker Sandboxes, que roda agentes em microVMs com kernel próprio. Ou seja, a portabilidade entre runtimes diferentes, a promessa central de qualquer padrão aberto, ainda não foi demonstrada na prática, porque não existe um segundo runtime concorrente para testar.

Como começar a testar

Quem quiser experimentar encontra o projeto no repositório docker/sandbox-kit-spec, com exemplos executáveis via CLI sbx, como em sbx run ./hello --kit ./gh. Ferramentas de registro, scanner e assinatura já existentes funcionam com Kits sem modificação, porque o artefato continua sendo uma imagem OCI comum.

O que exige aprendizado de fato é a gramática do descritor e a semântica própria de cada capacidade, como as diferenças entre declarar uma política de rede e declarar uma credencial proxy-gerenciada. A Docker diz que continua recebendo feedback sobre responsabilidades de Kit ou de runtime que a especificação ainda não consegue expressar, o que sinaliza que a v3 não é a versão final do desenho.

Fonte: InfoQ