Segurança no Harness: Controlando a Taxa de Vulnerabilidade de Agentes

Faz um tempo que eu paro para fazer essa conta com os times que acompanho: um agente escrevendo 1.000 pull requests por semana, com uma taxa de erro de apenas 1%, produz dez vulnerabilidades novas — toda semana, silenciosamente, sem nenhum atacante envolvido. Não é um bug isolado que escapou de um revisor cansado numa sexta-feira. É matemática de escala pura, e ela roda por trás de qualquer pipeline que despache agentes de código em volume.

Eu vejo muita gente tratando isso como problema de revisão: "vamos colocar mais um agente revisor no final da esteira". Isso ajuda, mas ataca o sintoma errado. Se o agente que gera código tem liberdade para tocar em segredos e chamar qualquer ferramenta externa, o revisor no final está tentando pegar uma bola já lançada com força total. O ponto de controle real é anterior: é o harness, o conjunto de permissões, sandbox e ferramentas que define o que o agente pode fazer antes de escrever a primeira linha.

Neste post eu quero destrinchar isso de forma prática: por que a taxa de erro em escala industrial muda o cálculo de risco, o que significa projetar segurança dentro do harness em vez de encaixá-la depois, e quais guardrails concretos — sandboxing, permissões escopadas por tarefa, revisão automatizada, rate limiting de ações sensíveis e testes de segurança no próprio pipeline — reduzem essas dez vulnerabilidades semanais a um número que o time consegue absorver.

---

A matemática que ninguém está olhando

Quando eu falo sobre "1% de taxa de erro" em uma reunião, a reação inicial costuma ser de alívio: parece pequeno, o tipo de margem que qualquer engenheiro sênior aceitaria numa entrega manual. O problema é que essa margem deixa de ser irrelevante quando multiplicada por volume industrial. Com 1.000 PRs saindo por semana, esse 1% se torna uma linha de produção constante de falhas — dez vulnerabilidades novas, toda semana, sem que ninguém tenha decidido introduzi-las.

O que torna isso perigoso não é a quantidade, mas a invisibilidade. Um erro humano costuma ter contexto: alguém sabe que apressou o PR, que pulou um teste. O erro de agente não carrega esse rastro — sai limpo, formatado, com testes passando. Isso engana o revisor humano, que tende a confiar mais em código bem apresentado, mesmo quando o bug estrutural está exatamente ali, escondido atrás de uma sintaxe impecável.

Eu já escrevi antes sobre um caso concreto desse tipo de falha silenciosa: no post sobre o exploit GhostApproval, um symlink simples bastava para enganar a caixa de aprovação de um agente de código, fazendo-o assinar como seguro algo que apontava para outro lugar. Aquele foi um exemplo pontual de harness de aprovação mal desenhado. O princípio generaliza: qualquer harness que não foi pensado para taxa de erro em escala vai, eventualmente, produzir o seu próprio GhostApproval — só é questão de tempo e de volume.

Por isso a primeira mudança de mentalidade que eu peço para o meu time é parar de pensar em "quantos bugs esse agente pode introduzir" e passar a pensar em "quantas vulnerabilidades por semana esse harness está configurado para permitir". É uma pergunta de engenharia de sistemas, não de qualidade de output pontual.

O harness como perímetro, não como etapa final

Construir segurança dentro do harness do agente — e não encaixá-la como etapa de revisão depois que o código já foi gerado — é inegociável para quem roda agentes em produção. Parece óbvio escrito assim, mas eu vejo o oposto o tempo todo: times dão ao agente acesso amplo ao repositório, às credenciais de CI/CD, talvez a APIs externas, e só depois se perguntam "como revisamos isso com segurança?".

A ordem certa é inversa. Antes de o agente escrever a primeira linha, alguém precisa responder: quais diretórios ele pode tocar, quais comandos de shell pode executar, se tem acesso a segredos de produção, se pode fazer chamadas de rede para fora do ambiente controlado. Esse conjunto de respostas é o harness, e funciona como um perímetro de segurança tradicional — só que em vez de proteger uma rede, protege a superfície de ação do agente.

Eu conecto isso com um tema que já tratei no post sobre agentes com fome de permissão e a chamada trifecta letal: acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa. Quando as três condições coexistem, um harness mal desenhado transforma qualquer falha isolada em vetor de exfiltração. O escopo mínimo que defendo naquele post precisa estar embutido no harness desde o dia zero, não como patch depois de um incidente.

Na prática, isso significa desenhar o harness junto com a arquitetura do sistema. Cada agente deveria ter seu próprio perfil de permissões, documentado e versionado como qualquer outro artefato de infraestrutura.

Sandboxing e permissões escopadas por tarefa

O primeiro guardrail prático é sandboxing real: o agente roda em ambiente isolado, sem acesso direto à rede de produção, sem credenciais de longa duração, sem tocar em nada fora do escopo do repositório em que trabalha. Parece básico, mas ainda encontro pipelines onde o agente roda com as mesmas credenciais de um engenheiro sênior — o que significa que qualquer falha dele tem o raio de explosão de uma conta privilegiada comprometida.

O segundo guardrail é permissão escopada por tarefa, não por agente. Em vez de um conjunto fixo de permissões válido para qualquer trabalho, o harness deveria calcular, tarefa a tarefa, o menor conjunto de acessos necessário para aquele PR. Um agente corrigindo um typo em documentação não precisa do mesmo acesso que um agente refatorando autenticação. Isso exige mais engenharia ao montar o pipeline, mas reduz a superfície de risco de cada execução.

Um terceiro ponto: segredos nunca devem ficar em texto claro no ambiente do agente. Vaults efêmeros, tokens de curta duração e injeção de credenciais só no momento da necessidade são práticas que já existiam em CI/CD tradicional e precisam migrar para o mundo dos agentes. Um agente que nunca teve acesso à credencial de produção não pode vazá-la, mesmo comprometido por um prompt malicioso embutido num arquivo do repositório.

Nada disso é sobre desconfiar do modelo. É sobre desenhar o ambiente de forma que, mesmo se ele cometer o erro de 1% que estatisticamente vai cometer, o dano fique contido pela arquitetura, não pela sorte.

---

---

Com sandbox e permissões no lugar, o próximo bloco de guardrails entra na esteira de entrega — e é onde a maioria dos times concentra todo o esforço de segurança, mesmo sendo apenas a segunda linha de defesa.

Revisão automatizada e rate limiting antes do merge

Revisão automatizada antes do merge não substitui o harness bem desenhado, mas complementa ele. Eu defendo pipelines onde todo PR gerado por agente passa por análise estática focada em padrões conhecidos — injeção, exposição de segredos, permissões excessivas em infraestrutura como código, dependências com CVEs abertos. Essa camada não precisa ser perfeita; precisa ser consistente, rodando em cem por cento dos PRs, sem exceção por prazo apertado.

O rate limiting de ações sensíveis é outro guardrail subestimado. Se um agente abre 1.000 PRs por semana, ele também pode, em teoria, tentar 1.000 deploys ou 1.000 chamadas externas no mesmo intervalo. Limitar quantas ações de uma categoria o agente executa por janela de tempo funciona como circuit breaker: se algo der errado, o estrago fica contido numa fração do que seria possível sem o limite.

Recomendo ainda testes de segurança automatizados dentro do próprio pipeline do agente, não só no CI tradicional. Isso inclui testes de regressão para os erros que aquele agente já cometeu — se ele introduziu uma falha de validação num módulo, o pipeline deveria testar recorrências daquele padrão nos PRs seguintes. É o sistema de guardrails evoluindo com o comportamento observado do agente, não ficando estático desde a configuração inicial.

Codar via agentes exige mais rigor, mais estrutura, mais qualidade embutida no processo — não menos, como a intuição inicial sugeriria. A velocidade que os agentes trazem só é sustentável se cada camada — sandbox, permissão escopada, revisão, rate limiting, testes contínuos — estiver ativa, não apenas documentada num guia que ninguém revisita.

---

---

Com os guardrails técnicos no lugar, sobra uma pergunta mais organizacional do que técnica: quem fica responsável por manter esse harness vivo ao longo do tempo? É aí que o próprio papel do engenheiro muda.

O papel do engenheiro muda, e o harness é o novo trabalho

Se existe uma mudança de carreira acontecendo debaixo do nosso nariz em 2026, é essa: o papel do engenheiro muda, com menos tempo escrevendo código-base linha a linha e mais tempo orquestrando um portfólio de agentes, definindo objetivos precisos e guardrails, e validando rigorosamente o output final antes que chegue a produção. Isso não é perda de relevância técnica — é mudança de onde a expertise é aplicada. Desenhar um harness bom exige entender como sistemas falham, o mesmo conhecimento que sempre separou sênior de júnior.

Eu tenho visto, cada vez com mais frequência, um engenheiro sozinho mantendo sistemas que antes exigiam times inteiros — não porque a IA escreve código perfeito, mas porque esse engenheiro sabe arquitetar, orquestrar, testar e manter supervisão real sobre o que o agente produz. Isso só é possível quando o harness faz o trabalho pesado de conter o risco continuamente, liberando a atenção humana para o que exige julgamento — arquitetura, trade-offs de produto, risco de negócio.

O risco real, e eu vejo isso em empresas correndo para adotar agentes sem essa disciplina, é achar que dá para pular a etapa de desenhar o harness porque "o modelo já é bom o suficiente". Nenhum modelo elimina a matemática de escala do início deste post. Dez vulnerabilidades por semana continuam surgindo, silenciosamente, até que alguém decida que o perímetro de segurança precisa nascer junto com o agente.

Conclusão

Segurança de agentes de código não é mais um problema de revisão pontual — é um problema de engenharia de sistemas em escala industrial. Quando um agente escreve centenas ou milhares de PRs por semana, mesmo uma taxa de erro pequena se transforma em fluxo constante e silencioso de vulnerabilidades novas. Tratar isso com "mais um revisor no final da esteira" subestima a matemática em jogo.

O caminho que defendo, e que venho aplicando no meu time, é desenhar o harness — sandbox, permissões escopadas por tarefa, revisão automatizada, rate limiting e testes de segurança contínuos — como parte da arquitetura desde o primeiro dia, não como remendo depois de um incidente. Os casos que já cobri aqui, do GhostApproval à trifecta letal de permissões, mostram o mesmo padrão de fundo: harness mal desenhado é o verdadeiro ponto de falha, muito antes de qualquer atacante externo entrar em cena.

O trabalho do engenheiro que sobrevive bem a essa transição não é escrever menos código por desconfiança da IA — é entender onde o risco se acumula e construir os limites certos antes que o volume de produção torne esse risco impossível de conter manualmente. Essa disciplina vai separar os times que escalam agentes com segurança dos que vão acumular uma dívida de vulnerabilidades silenciosa demais para perceber a tempo.

Fontes:

• InfoWorld — Best Practices for Building Agentic Systems
• CodeScene — Agentic AI Coding: Best Practice Patterns for Speed With Quality
• Anthropic — 2026 Agentic Coding Trends Report
• Forrester — Agentic Software Development Takes The Lead: From Code Assistants to Orchestrated SDLC Agents