Os sandboxes para agentes de codificação com IA estão a tornar-se uma disciplina de segurança séria, não uma reflexão tardia

Dê-se a um agente de codificação com IA acesso total ao seu repositório, à sua shell e às suas variáveis de ambiente, e terá entregue a ele o mesmo raio de explosão de uma pipeline de CI comprometida. Isso costumava ser um risco aceitável quando os agentes executavam tarefas de turno único, supervisionadas por um humano, com duração de poucos minutos. Deixou de ser aceitável no momento em que os agentes começaram a funcionar sem supervisão durante horas, a coordenar múltiplos sub-agentes e a executar comandos de shell para testar as suas próprias alterações.

A resposta da indústria convergiu para um padrão: executar agentes dentro de ambientes isolados e descartáveis — sandboxes, contentores ou worktrees git efémeras — em vez de diretamente sobre o checkout ativo do programador. Isto já não é uma precaução experimental. Está a tornar-se infraestrutura base, e as equipas que prescindem dela estão a acumular risco que ainda não precificaram.

Porque é que a abordagem ingenua se desmorona

A forma óbvia de executar um agente de codificação é apontá-lo para o diretório de trabalho e deixá-lo editar ficheiros diretamente. Isto funciona bem para edições pequenas e supervisionadas. Desmorona-se ao longo de três eixos à medida que a autonomia aumenta:

Exposição de credenciais. Um agente com acesso à shell pode ler ficheiros .env, chaves SSH, credenciais de CLI de cloud e tokens de API presentes no ambiente — não porque tenha essa intenção, mas porque um passo de depuração ou uma instrução mal interpretada leva-o a fazer cat a um ficheiro que não devia. Uma injeção de prompt proveniente de uma dependência maliciosa, um README envenenado ou um registo de pacotes comprometido pode transformar isto em exfiltração ativa em vez de um acidente.

Efeitos secundários irreversíveis. Um agente a testar uma migração de base de dados, a executar um script de limpeza ou a experimentar um comando de deployment em infraestrutura real pode causar danos que uma revisão de código nunca aprovaria — porque ninguém os reviu antes de serem executados.

Contaminação de estado. Quando múltiplos agentes ou múltiplas tentativas partilham uma única worktree, edições parciais de uma tentativa falhada infiltram-se na seguinte. A depuração torna-se arqueologia: quais as alterações que vieram de qual execução?

Como é efetivamente o padrão sandbox mais worktree

O padrão que emergiu combina dois mecanismos separados a desempenhar dois trabalhos separados.

As worktrees Git (ou clones completos do repositório) fornecem isolamento ao nível do sistema de ficheiros. Em vez de um agente editar a sua única cópia com checkout do repositório, este recebe a sua própria worktree — um diretório separado suportado pelo mesmo histórico git mas com ficheiros independentes e estado de branch independente. Múltiplos agentes, ou múltiplas tentativas paralelas da mesma tarefa, recebem cada um uma tree limpa. Nada é comprometido na branch principal até que um humano — ou uma etapa de verificação — aprove o diff.

Os sandboxes de execução fornecem isolamento ao nível do processo e da rede. Os comandos de shell do agente são executados dentro de um contentor, VM ou contexto de execução restrito que não tem acesso às credenciais do host, não tem rota para a internet para além de uma allowlist explícita, e não tem capacidade de tocar em nada fora da sua worktree atribuída. A plataforma Antigravity da Google, por exemplo, executa o seu modo de raciocínio profundo /boost dentro daquilo a que chama worktrees isoladas efémeras, especificamente para que os sub-agentes de implementação possam executar alvos de compilação e suites de testes localmente sem tocar no estado de trabalho real do programador — e para que uma hipótese falhada possa simplesmente ser descartada em vez de revertida manualmente.

Juntos, isto significa que um agente pode receber permissões genuinamente amplas — ler todo o código-fonte, executar comandos de shell arbitrários, instalar pacotes, aceder a serviços locais — sem que essas permissões se estendam a algo que o programador realmente queira proteger. O raio de explosão é a sandbox descartável, não a máquina ou a conta.

A etapa de verificação continua a ser importante

O sandboxing resolve o problema do contenção, não o problema da correção. Um agente pode funcionar inteiramente dentro de um ambiente isolado e ainda assim produzir código errado, inseguro ou subtilmente defeituoso. O que o sandboxing lhe proporciona é a capacidade de deixar um agente iterar — escrever código, executar testes, ver falhas, tentar novamente — sem que cada passo intermédio precise de um humano no ciclo. A revisão ainda tem de acontecer no ponto em que um diff é proposto para merge, e cada vez mais essa etapa de revisão é ela própria automatizada: passes de verificação independentes que re-executam a suite completa de testes contra as alterações em sandbox antes de serem sequer apresentadas a uma pessoa.

É também por isto que o padrão de sandbox escala melhor do que os prompts de permissão. Pedir a um humano para aprovar cada escrita de ficheiro ou comando de shell que um agente queira executar não melhora efetivamente a segurança — treina as pessoas a clicar em aprovar sem ler, o mesmo modo de falha que tornou os diálogos de permissão do browser e os prompts do UAC praticamente inúteis. Isolar o raio de explosão desde o início e depois rever o diff final é um modelo de segurança mais honesto do que esperar que um programador cansado leia cada diálogo de confirmação.

O que fazer efetivamente quanto a isto

Se está a executar agentes de codificação com IA contra repositórios reais hoje, três mudanças importam mais do que qualquer ferramenta específica de um fornecedor:

Separe as credenciais do agente das suas. Nunca deixe um agente executar dentro de uma shell que tenha as suas chaves SSH pessoais, credenciais de fornecedor de cloud ou tokens de API de produção disponíveis. Use tokens scoped e de curta duração para qualquer acesso que o agente genuinamente necessite, e nada mais.

Dê aos agentes a sua própria worktree, não o seu checkout ativo. Seja via git worktree add, um contentor descartável por tarefa, ou uma plataforma gerida que faça isto por si, garanta que uma execução falhada ou maliciosa não deixa rasto na cópia do código onde realmente trabalha.

Trate o egresso de rede como uma permissão, não como uma predefinição. Um agente que pode instalar pacotes arbitrários da internet pública durante uma execução em sandbox continua a ser um risco na cadeia de abastecimento. Sempre que possível, restrinja o acesso de rede de saída a uma allowlist explícita em vez de o deixar aberto por predefinição.

Nada disto é infraestrutura exótica — as worktrees e os contentores são anteriores à vaga atual de ferramentas de codificação com IA por anos. O que é novo é a urgência: agentes que operam durante horas seguidas, coordenam com outros agentes e executam código sem um humano a supervisionar cada passo tornaram o limite de isolamento num requisito em vez de um exercício de reforço que se fica para depois.