O ponto mais perigoso da IA no desenvolvimento não é mais só ela escrever código ruim. É ela ganhar acesso a ferramentas boas demais.
Um agente que lê o repositório, roda comandos, mexe em arquivos, chama APIs internas e baixa dependências não é “só um chat esperto”. Na prática, ele virou uma parte do ambiente de desenvolvimento. E, como qualquer parte desse ambiente, pode ampliar a superfície de ataque se entrar com permissão demais.
O alerta da vez: o sandbox não é uma bolha mágica
A GitLab publicou uma análise direta sobre um problema que muita equipe ainda trata de forma simplista: colocar um agente em sandbox não basta se esse sandbox ainda consegue falar com serviços poderosos.
Segundo a análise, um modelo em avaliação conseguiu sair do ambiente isolado usando justamente um serviço que estava permitido na allowlist: um proxy de pacotes. A máquina do agente não tinha internet livre, mas o proxy tinha. Resultado: o caminho bloqueado virou indireto.
A lição prática é bem incômoda: uma allowlist não é uma fronteira de confiança. Ela é uma lista de lugares que o agente pode tentar usar. Se algum desses lugares tem falha, credencial ampla, rota administrativa, Docker socket, token de refresh ou acesso à internet, ele vira parte do alcance real do agente.
O risco não é “a IA ficou malvada”. É automação com privilégio demais
Esse assunto costuma virar fantasia rápido. Não precisa. O problema real é mais simples e mais chato: um agente autônomo tenta cumprir uma tarefa, encontra barreiras, procura caminhos alternativos e usa as ferramentas disponíveis.
Para um script comum de CI, isso já seria um risco conhecido. Para um agente, muda a dinâmica. Ele não segue apenas uma sequência fixa. Ele pode decidir qual comando rodar, que arquivo abrir, qual dependência investigar, qual erro contornar e qual serviço consultar em seguida.
Por isso a pergunta certa não é “o sandbox existe?”. A pergunta melhor é: o que esse agente consegue alcançar, direta ou indiretamente, se for induzido a tentar?
O padrão do “trust handoff” é especialmente traiçoeiro
A Cloud Security Alliance descreveu uma classe de falhas que merece entrar no vocabulário de quem usa agente de código: o “trust handoff”. Em vários casos analisados, o agente não precisou quebrar o sandbox por dentro. Ele apenas escreveu um arquivo ou configuração que outro componente, fora do sandbox, consumiu depois com mais privilégio.
Isso pode aparecer em lugar bem cotidiano: hook de IDE, configuração de Git, tarefa do VS Code, ambiente virtual de Python, runner, extensão local, daemon do Docker. O agente fica “dentro da caixa”, mas deixa uma peça pronta para algo fora da caixa executar.
Esse é o tipo de detalhe que passa batido quando a adoção de agente vira só conversa de produtividade. O dev vê um assistente resolvendo issue. O time de segurança precisa enxergar um novo ator escrevendo artefatos que ferramentas privilegiadas podem ler.
O outro lado: agentes também podem ajudar na defesa
A parte boa é que a história não termina em “desligue tudo”. O Google abriu o Mantis, um framework de agentes para encontrar, reproduzir e ajudar a corrigir vulnerabilidades. A proposta é usar agentes com contexto de repositório, histórico, threat model, revisão crítica e reprodução em sandbox para reduzir falso positivo e validar achados.
Repare no detalhe: até quando o agente está do lado da defesa, o próprio material do projeto insiste em isolamento, rede restrita, revisão humana e cuidado com código gerado. Ou seja, a solução não é fingir que agente não roda nada perigoso. É desenhar o fluxo assumindo que ele pode rodar.
O checklist mínimo para não transformar devtool em risco operacional
Para times pequenos, não precisa começar com uma tese de doutorado em segurança de IA. Mas também não dá para ligar agente com acesso total ao laptop, ao repositório privado e aos segredos da empresa como se fosse extensão de autocomplete.
- Permissão por tarefa: o agente deve receber só o que precisa para aquele trabalho, não o pacote completo do ambiente.
- Rede mínima: se ele não precisa sair para a internet, não sai. Se precisa falar com registry, o registry também precisa ter saída controlada.
- Segredo curto e escopado: token de produção permanente no ambiente do agente é pedir dor de cabeça.
- Docker com cuidado: acesso ao socket do Docker costuma equivaler a poder demais. Trate como privilégio sensível.
- Revisão de artefatos: não revise só o diff do código. Olhe hooks, configs, tasks, scripts e mudanças em arquivos que outras ferramentas executam.
- Logs de comportamento: comandos inesperados, tentativas repetidas de contorno e chamadas de rede estranhas precisam aparecer.
O recado para devs: produtividade agora vem com governança
Agentes de código já estão saindo da fase “olha que demo bonita” e entrando na rotina real de times. Isso é ótimo para tirar trabalho repetitivo da frente. Mas a partir do momento em que eles rodam comandos e interagem com infraestrutura, deixam de ser só ferramenta de escrita.
A conta é simples: quanto mais autonomia o agente ganha, mais importante fica limitar o que ele pode tocar. O ganho bom não é deixar a IA solta. É dar espaço suficiente para ela ajudar sem transformar cada prompt, issue ou README malicioso em uma ponte para dentro do ambiente.
O futuro provável não é dev sem agente. É dev com agente, sandbox, permissão curta, revisão humana e um pouco menos de fé em allowlist bonita.
