Redbelt Security: risco dos agentes de IA não está no modelo, mas em quem o executa
Relatório da consultoria publicado em julho de 2026 identifica que a principal lacuna de segurança nas implantações de IA agêntica é a confusão entre o modelo de linguagem e o programa que executa suas ações no hardware, uma distinção que muda completamente o perfil de exposição das empresas
Imagem ilustrativa
A Redbelt Security, consultoria especializada em segurança da informação, 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 o agente 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 por lista 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 que as 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. É precisamente a mudança que a segurança exige: sair do talvez para o sempre.", ressalta o executivo.
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 as capacidades 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 externo numa 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ções ocultas 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.
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 por lista 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 que as 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. É precisamente a mudança que a segurança exige: sair do talvez para o sempre.", ressalta o executivo.
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 as capacidades 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 externo numa 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ções ocultas 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.
Notícia distribuída pela saladanoticia.com.br. A Plataforma e Veículo não são responsáveis pelo conteúdo publicado, estes são assumidos pelo Autor(a): CAREN GODOY DE FARIA
caren.godoy@inkcomunicacao.com.br