Wagner Farias, Head de engenharia de ameaças da Redbelt Security. Foto: Divulgação

Muitas corporações estão olhando para o lugar errado ao avaliar os perigos da inteligência artificial. Um estudo recente da Redbelt Security revela que existe uma grande confusão no mercado entre os modelos de linguagem e os agentes de IA. Essa falha de visão gera falhas de proteção reais na rotina das empresas.

A avaliação focada apenas no modelo ignora como a tecnologia funciona na prática. O modelo de linguagem atua como um cérebro que gera instruções em texto. Ele não acessa redes, não altera arquivos e não roda comandos. Quem faz todo o trabalho pesado no hardware é um programa que envolve o modelo, conhecido no setor pelo nome técnico de harness.

É o harness que lê as ordens da IA, executa as ações no sistema e devolve os resultados. Por isso, alterar o programa de execução muda completamente o nível de exposição da empresa, mesmo usando o mesmo modelo de linguagem. Uma aplicação sem ferramentas agênticas não oferece riscos de execução. Já um agente rodando direto na máquina de um desenvolvedor tem acesso a chaves de segurança e variáveis do sistema. Se o mesmo terminal operar em um ambiente isolado com restrições de rede, a proteção muda. O problema é que a maioria das organizações ainda não mapeia esse tipo de variação.

A escala dos sistemas e o aumento dos riscos

O impacto dessa falta de controle cresce junto com a escala das operações e o relatório cita um teste realizado pela Anthropic em junho de 2025. Na ocasião, vários agentes trabalhando em paralelo criaram um compilador de linguagem C do zero. O projeto teve cerca de 100 mil linhas de código. As máquinas entregaram o equivalente a meses de trabalho humano. Contudo, esse volume de automação expande o campo para possíveis ataques. Cada ação executada sem regras claras vira uma porta aberta para invasões.

“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”, destacou em nota Wagner Farias, Head de engenharia de ameaças da Redbelt Security.

Como os hooks criam barreiras de proteção

Para evitar falhas, o estudo propõe o uso dos chamados hooks. Eles são pequenos programas que o usuário configura para rodar em momentos específicos da execução. Diferente das orientações em texto dadas à IA, que funcionam por probabilidade, os hooks seguem regras exatas. Um hook de entrada impede que o sistema rode comandos perigosos. Um hook de saída analisa as informações antes que elas voltem para o modelo. Esse método aplica conceitos tradicionais de validação de dados direto no fluxo dos agentes.

Farias ressaltou que “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“.

Outro ponto de atenção envolve o uso de plugins e habilidades criadas por terceiros. Essas extensões servem para conectar a IA a serviços externos e colocar um plugin externo em um agente traz riscos parecidos com instalar um programa desconhecido no computador do trabalho. A diferença é que o agente cumpre as ordens da extensão sem desconfiar. Selos de garantia não são suficientes para comprovar a segurança, é preciso investigar se há instruções escondidas nos scripts ou conexões com sites suspeitos.

O principal ataque contra agentes de IA é a injeção de prompt. O problema acontece porque instruções e dados trafegam pela mesma via, sem divisão. Essa falha lembra as vulnerabilidades do tipo SQL injection, comuns no passado. Ainda não existe uma solução definitiva para esse tipo de ataque na inteligência artificial, por isso a melhor saída é adotar várias camadas de proteção simultâneas. Farias ressalta que “segurança é responsabilidade do dono do dado, não da ferramenta”.

Sem comentários registrados

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *