A Redbelt Security publicou em julho de 2026 um relatório que aborda um ponto cego bastante recorrente nas discussões corporativas sobre segurança de IA: a confusão entre o modelo de linguagem e os agentes de IA.

Para a empresa, esse é um tipo de erro que tem consequências práticas diretas. Organizações que avaliam o risco da IA olhando apenas para o modelo estão monitorando a parte errada do sistema, porque o modelo nunca executa nada. Quem executa é o programa que o envolve.

No ecossistema de IA agêntica, esse programa tem nome técnico: harness. É ele que lê os pedidos do modelo, os converte em ações reais no hardware e devolve os resultados. O modelo, por sua vez, funciona como um cérebro que escreve instruções em texto. Ele não toca em arquivos, não acessa a rede e não roda comandos no mundo real. O harness é quem faz tudo isso. Essa separação cria um ponto de interceptação controlável, e é exatamente aí que mora a oportunidade de segurança que a maioria das empresas ainda não está sabendo aproveitar.

Essa distinção se torna ainda mais relevante quando se observa que o mesmo modelo de linguagem, operando em harnesses diferentes, apresenta perfis de risco completamente distintos. No Claude Code CLI, por exemplo, o agente roda na máquina real do desenvolvedor, com acesso às suas chaves, variáveis de ambiente e rede. No Cowork, o terminal opera num ambiente Linux isolado com saída de rede restrita porlista de permissão. No chat puro, sem ferramentas agênticas, não há superfície de execução e o risco cai a zero. Trocar de harness troca o risco. Esse mapa ainda não faz parte da avaliação de segurança da maioria das empresas que estão adotando IA.

O tamanho do problema ganha ainda mais forma quando se observa a escala que os agentes já atingem. O relatório descreve um sistema multiagente publicado pela Anthropic em junho de 2025 no qual vários agentes operando em paralelo construíram um compilador completo da linguagem C com aproximadamente 100 mil linhas de código ao longo de milhares de sessões. Na prática, um time de máquinas coordenadas entregou o equivalente a meses de trabalho de engenharia de software. Quando agentes operam nessa escala, a superfície de risco cresce na mesma proporção, e cada ponto de execução sem controle determinístico é uma exposição em aberto.

“Todo sistema é uma máquina com ENTRADA, PROCESSAMENTO e SAÍDA. Se você controla o que entra e revisa o que sai, você controla a máquina. O erro queas empresas cometem é tratar o agente como um gênio da lâmpada: é só pedir e torcer. O jeito certo é desenhar um workflow com passos modulares, travas explícitas, entrada sanitizada em cada fronteira de confiança, saída revisada e menor privilégio”, afirma Wagner Farias, Head de engenharia de ameaças da Redbelt Security.

Controlar o que entra e o que sai passou a ter um mecanismo técnico concreto dentro do próprio ciclo do agente. A defesa proposta no relatório usa os chamados hooks, pequenos programas que o próprio usuário define e que o harness executa em momentos fixos do ciclo. Ao contrário das instruções dadas ao modelo em linguagem natural, que são probabilísticas e podem não ser seguidas, os hooks são determinísticos.Um hook de entrada bloqueia comandos perigosos antes da execução.

Um hook de saída inspeciona e limpa o resultado antes de ele voltar ao modelo. É a aplicação dos princípios de validação de entrada e sanitização de saída que a segurança da informação usa hádécadas, agora dentro do loop de execução dos agentes de IA.

“Os hooks não tornam o ataque impossível, mas nos possibilita tomarmos cuidados em pontos de checagem afim de termos certas garantias. É precisamentea mudança que a segurança exige: sair do talvez para o sempre”, ressalta. 

Fatores de risco agentes de IA

Um vetor de risco menos discutido, mas igualmente relevante, é o dos plugins e skills de terceiros. Plugins e skills são integrações que ampliam ascapacidades do agente, permitindo que ele acesse serviços externos, execute tarefas específicas ou se conecte a sistemas de terceiros.

Na prática, instalar um plugin de terceiros num agente de IA carrega o mesmo risco de instalar qualquer software externonuma máquina corporativa, com uma diferença: o agente vai executar as instruções contidas nele com a mesma confiança com que executa qualquer outra orientação. Selos de verificação são insuficientes como garantia. A avaliação deve incluir busca por instruçõesocultas nos prompts e padrões de baixar e executar código nos scripts. Qualquer chamada a domínios que a ferramenta não precisaria contatar também deve ser considerado um sinal de alerta.

O alerta final do relatório aponta para um problema que ainda não tem solução. A injeção de prompt, principal vetor de ataque contra agentes de IA,tem a mesma raiz do SQL injection de 25 anos atrás: instruções e dados viajando pelo mesmo canal, sem separação. O SQL injection ganhou uma cura determinística com as consultas parametrizadas.

Para os modelos de linguagem ainda não existe equivalente. Enquanto essa solução não chega, o que existe é mitigação em camadas: hooks, lista de permissão de saída de rede, menor privilégio, workflows explícitos com fronteiras de confiança bem definidas.

“A premissa que o relatório deixa como alerta é simples. Segurança é responsabilidade do dono do dado, não da ferramenta”, conclui Farias.