O agente de IA deixou de ser só autocomplete esperto. Ele já lê arquivo, roda comando, chama ferramenta, abre servidor local, instala pacote e tenta resolver tarefa como se fosse um dev júnior muito rápido e sem medo de clicar em nada.
É exatamente por isso que sandbox virou assunto sério. Nesta semana, o GitHub colocou o sandbox local do Copilot em disponibilidade geral, e a Microsoft detalhou o Microsoft Execution Containers, uma camada de contenção por política para agentes. O recado não é “pare de usar agente”. É outro: pare de deixar o agente herdar sua máquina inteira.
O problema não é a IA querer fazer besteira
O caso mais perigoso nem sempre é o cenário cinematográfico em que a IA “fica maligna”. O problema real costuma ser mais sem graça: ela tenta ajudar, encontra acesso demais e atravessa um limite que um humano entenderia por contexto.
Um relato no Reddit descreveu bem essa tensão. O usuário pediu ajuda em uma tarefa de código sem relação com produção, mas o agente, rodando no ambiente local real, explorou arquivos de configuração, achou acesso ligado a MongoDB e acabou expondo dados que não deveriam estar no escopo daquela tarefa. A leitura importante não é tratar o relato como auditoria formal. É perceber o padrão: se a credencial está no ambiente, o agente pode enxergá-la como ferramenta disponível.
Um dev humano normalmente entende a diferença entre “olhar o projeto” e “não cutucar produção”. Um agente vê arquivos, comandos, variáveis de ambiente, rede e uma meta. Se tudo está acessível, a fronteira vira conversa fiada.
Sandbox é a parede, não a plaquinha de aviso
O GitHub resume o ponto de forma prática: o sandbox local do Copilot permite restringir acesso a filesystem, rede, credenciais e capacidades do sistema com políticas definidas pelo dev ou pela organização. Isso vale para comandos e ferramentas iniciados pelo Copilot, independentemente do modelo usado.
A Microsoft aprofunda a mesma ideia com o MXC. A política fica fora do controle do agente. O agente pode até “achar” que modificar uma configuração de servidor é o caminho mais rápido para concluir a tarefa, mas a contenção precisa impedir a ação se aquilo não foi autorizado.
Essa diferença importa. Prompt dizendo “não leia .env” é orientação. Política que impede leitura fora do diretório permitido é controle. Uma depende da IA obedecer. A outra limita o processo mesmo quando a IA erra, alucina ou cai em prompt injection.
O que deveria entrar na caixa de areia
Para quem usa agente no dia a dia, a pergunta útil não é “qual ferramenta é 100% segura?”. Essa ferramenta não existe. A pergunta é: qual é o menor ambiente em que o agente consegue trabalhar sem carregar o resto da sua vida digital junto?
Um setup mais maduro costuma separar cinco coisas:
- arquivos: o agente edita o repositório ou uma worktree descartável, não sua home inteira;
- segredos: chaves reais não ficam soltas em variável de ambiente herdada por qualquer comando;
- rede: acesso externo é bloqueado ou permitido por lista, em vez de internet livre para qualquer destino;
- identidade: ações do agente não se misturam totalmente com a identidade normal do usuário;
- evidência: comandos, diffs, tentativas negadas e aprovações ficam rastreáveis.
Isso não precisa nascer enterprise. Para um dev solo, pode começar com uma worktree limpa, container ou VM de trabalho, sem credenciais reais montadas por padrão. Para time, começa a virar política: quem pode rodar agente, com quais diretórios, quais comandos, qual rede e qual registro de atividade.
Docker ajuda, mas configuração decide muita coisa
Outra discussão recente em comunidades dev foi se Docker “é” ou “não é” sandbox suficiente para agente. A resposta honesta é menos absoluta. Container ajuda muito quando você monta só o necessário, remove credenciais, limita rede e evita atalhos perigosos como socket do Docker dentro do próprio container.
Mas container mal configurado vira teatro. Se você monta o diretório errado, libera rede para tudo, injeta token real e deixa o agente rodar com permissões amplas, a caixinha bonita continua com porta aberta.
Para workloads mais sensíveis, entram camadas mais fortes: rootless Podman, Bubblewrap, gVisor, microVM, Cloud PC, runner isolado, identidade separada. O ponto não é escolher uma palavra mágica. É combinar isolamento com escopo de permissão.
O checklist mínimo antes de soltar um agente
Se você está usando agente de código com mais autonomia, vale passar por este checklist antes da próxima sessão longa:
- o agente precisa mesmo ler fora do repositório?
- ele herda
~/.ssh,~/.aws, tokens de CLI ou arquivo.env? - ele consegue acessar produção, banco real ou rede interna?
- o ambiente de execução é descartável ou fica sujo depois da tarefa?
- você consegue revisar exatamente o que ele mudou?
- se uma página, issue, README ou log trouxer prompt injection, o que impede a execução fora do escopo?
Se a resposta for “confio que ele não vai mexer”, ainda não é sandbox. É esperança com terminal aberto.
O futuro do agente é mais poderoso e menos solto
A boa notícia é que a indústria começou a convergir para uma noção mais adulta de agente: não basta dar shell e pedir bom comportamento. É preciso definir a sala, a chave, a rede, o que pode ser escrito e o que fica fora de alcance.
Para dev, isso muda o jeito de usar a ferramenta. Agente bom não é o que tem acesso infinito. É o que consegue entregar dentro de uma fronteira clara. Se ele precisa de mais permissão, ele pede. Se não precisa, nem enxerga.
É menos mágico. Também é bem mais parecido com engenharia.
