O agente de código deixou de ser só autocomplete com marketing. Ele já lê árvore de arquivos, edita projeto, roda teste, instala dependência, mexe em configuração e, em muitos setups, faz tudo isso com a autoridade da máquina do dev.
Essa é a parte boa e também a parte perigosa. Quando a ferramenta ganha shell, histórico de prompt, acesso local e talvez credenciais por tabela, a conversa sai do “qual IA escreve melhor?” e entra em uma pergunta bem menos divertida: quem está segurando o freio?
O alerta veio do tipo de falha que não dá para tratar como detalhe
Um caso recente envolvendo o DeepSeek Harness, descrito pela DevOps.com a partir da pesquisa da OX Security, mostrou uma falha crítica em um harness de agente de código. Segundo os pesquisadores, a ferramenta expunha uma API local de controle e confiava no cabeçalho Host informado pelo cliente para decidir se a requisição era confiável.
Na prática, de acordo com a OX Security, um agente confinado poderia chamar essa API local e elevar a própria sessão para danger-full-access, com aprovações desligadas. O CVE-2026-82533 recebeu severidade 9.4 e foi corrigido na versão 0.1.2-alpha.1.
O ponto editorial aqui não é “fuja de toda ferramenta nova”. É o contrário: se agente de código virou parte real do trabalho, ele precisa entrar no mesmo nível de cuidado que a gente já cobra de CI/CD, chave de API, dependência e deploy.
O agente não carrega só código. Ele carrega contexto
Um harness de agente é valioso porque aproxima a IA do trabalho real. Só que esse “trabalho real” pode incluir SSH, token de cloud, registry privado, arquivo .env, túnel aberto, histórico de conversa e acesso a sistemas internos.
É por isso que a frase “está rodando localmente” não resolve tudo. Local também pode ser perigoso quando a ferramenta tem uma API de controle, uma porta exposta por engano ou permissão demais para executar comandos sem pedir confirmação.
Dependência instalada sem checagem é outra porta aberta
O problema não fica só no sandbox. Um preprint publicado no arXiv mediu 1.920 execuções de assistentes de código instalando software de pesquisa com sinais de confiança disponíveis, como SBOM, releases assinados, atestações de build e canais oficiais.
O resultado foi frio: em apenas 9 das 1.920 execuções, o assistente abriu algum sinal de proveniência antes de instalar. Em nenhuma execução houve comando real de verificação. A conclusão dos autores é direta: publicar sinal de confiança é necessário, mas não basta se o programa que roda o assistente não força a verificação.
Para quem usa IA no dia a dia, isso traduz uma coisa simples: não dá para terceirizar bom senso de supply chain para o modelo. Se a checagem não estiver no fluxo, ela provavelmente não acontece.
O mínimo aceitável para usar agente sem fé cega
Um setup mais maduro não precisa começar perfeito, mas precisa ter alguns portões desde o primeiro dia:
- Permissão explícita para comandos perigosos. Build e teste são uma coisa; mexer em rede, chave, deploy e pacote publicado é outra.
- Segredos fora do alcance padrão. Token de cloud, chave SSH e
.envnão devem ficar disponíveis só porque o agente está no mesmo repositório. - Rede local tratada como superfície de ataque. Porta de controle, tunnel, proxy e editor com forward precisam ser revisados.
- Instalação de dependência com trava. Nome de pacote, origem oficial, assinatura, versão e lockfile precisam passar por regra, não por confiança no texto bonito da IA.
- Logs suficientes para auditoria. Se algo quebrou, alguém precisa saber qual comando rodou, de onde veio a sugestão e qual arquivo foi tocado.
DevSecOps fica menos opcional quando a IA entra no commit
O contexto brasileiro também aponta para essa direção. A GeekHunter vem tratando cibersegurança e DevSecOps como uma exigência crescente para devs, tech leads e empresas, especialmente porque IA acelera tanto a entrega quanto a chance de introduzir dependência ruim, segredo exposto ou padrão vulnerável.
Antes, dava para fingir que segurança era uma etapa no fim do projeto. Com agente de código, essa divisão fica ainda mais frágil. A ferramenta que acelera a issue também pode acelerar o erro, e erro automatizado costuma escalar bonito até alguém olhar o extrato da conta ou o incidente em produção.
O uso prático continua valendo, mas com adulto na sala
Agente de código continua sendo útil. Ele ajuda a navegar base grande, escrever testes, atualizar boilerplate, explicar stack antiga e cortar tempo de tarefa repetitiva. O problema é transformar produtividade em passe livre.
A pergunta certa para o time não é “vamos usar IA ou não?”. É: o agente roda onde, com qual permissão, vendo quais arquivos, instalando o quê, e deixando qual rastro?
Quem responder isso cedo vai aproveitar melhor a ferramenta. Quem ignorar provavelmente vai descobrir que o colega mais produtivo do time também era o que tinha a senha da porta dos fundos.
