Agentes de inteligência artificial precisam ler páginas da web, emails, arquivos, tickets e resultados de ferramentas. O problema é que esses materiais podem conter instruções escondidas. Uma página aparentemente comum pode dizer ao agente para ignorar sua tarefa, revelar informações privadas ou executar uma ação perigosa. Esse tipo de ataque é conhecido como prompt injection e se tornou um dos obstáculos centrais para a adoção segura de agentes.
Um trabalho publicado no arXiv propõe uma defesa chamada Heads of Security, ou HoS. A ideia é simples de descrever, mas profunda em suas consequências: o modelo deve continuar capaz de raciocinar sobre conteúdo não confiável sem tratá-lo automaticamente como uma ordem. Para isso, a técnica aprende pequenos gates associados às cabeças de atenção, redistribuindo a atenção entre tokens confiáveis e não confiáveis.
O problema não é apenas uma instrução maliciosa
Em um chatbot tradicional, uma injeção de prompt pode induzir uma resposta inadequada. Em um agente, o risco é maior porque o modelo pode ter acesso a ferramentas, sistemas internos e capacidade de modificar o mundo. Um texto inserido em uma página pode tentar fazer o agente enviar uma mensagem, alterar um registro, baixar um arquivo ou expor dados de outro usuário.
A dificuldade está no fato de que o agente precisa ler o conteúdo para cumprir sua tarefa. Bloquear toda informação externa seria inútil. Um agente encarregado de comparar contratos precisa analisar documentos não confiáveis. Um assistente de suporte precisa interpretar mensagens de clientes. Um sistema de pesquisa precisa visitar páginas que podem ter sido manipuladas.
Portanto, a defesa não pode simplesmente apagar ou ignorar tudo que vem de fora. Ela precisa preservar o valor informacional do conteúdo enquanto impede que ele assuma o papel de autoridade. Essa é a distinção entre usar um texto como evidência e obedecer ao texto como instrução.
Como funcionam os Heads of Security
Modelos de linguagem processam informações por meio de várias cabeças de atenção. Cada cabeça pode aprender relações diferentes entre partes do contexto. O método HoS introduz gates aprendidos que ajustam como essas cabeças distribuem atenção entre tokens classificados como confiáveis e não confiáveis.
Na prática, o sistema tenta criar uma separação arquitetural entre instruções legítimas e dados que devem ser examinados. O conteúdo externo continua presente no contexto, mas deixa de ter o mesmo caminho direto para influenciar o comportamento obediente do modelo. A defesa não depende apenas de pedir ao modelo que “seja cuidadoso” em uma mensagem de sistema.
Essa diferença é relevante. Instruções escritas em linguagem natural podem ser reinterpretadas pelo próprio modelo. Já um mecanismo incorporado ao fluxo de atenção atua em uma camada mais próxima da computação que produz a resposta. Isso não torna a proteção inviolável, mas reduz a dependência de uma promessa textual feita ao modelo.
O trabalho avalia a abordagem em Llama três ponto três de setenta bilhões de parâmetros e GPT-OSS de vinte bilhões de parâmetros. Os autores comparam HoS com SecAlign++, uma defesa baseada em ajuste fino, e ASIDE, que também procura implementar separação entre instrução e dados na arquitetura.
O número que muda a conversa
Um dos resultados mais expressivos aparece no ataque RL-Hammer. Segundo o estudo, o ataque alcança taxa de sucesso de noventa e sete por cento contra o GPT-OSS de vinte bilhões de parâmetros sem a defesa proposta e oitenta e cinco por cento contra o SecAlign. Com HoS, essa taxa cai para dez por cento.
Esse resultado não significa que o problema esteja resolvido. Primeiro, porque ataques adaptativos evoluem quando encontram uma defesa. Segundo, porque uma taxa de ataque específica depende do conjunto de testes, do modelo, do modo de implantação e das ferramentas disponíveis ao agente. Terceiro, porque segurança não é apenas resistir a um benchmark: também é preservar utilidade, latência e capacidade de raciocínio.
É justamente aí que a proposta fica interessante. O trabalho afirma que HoS melhora a robustez em ataques adaptativos, mantém desempenho superior em benchmarks de utilidade e alcança desempenho competitivo em avaliações comuns de prompt injection. A tese não é trocar segurança por obediência restrita. É tentar obter as duas coisas por meio de uma separação mais explícita.
O que isso muda para empresas brasileiras
No Brasil, muitas empresas estão testando agentes para atendimento, análise documental, cobrança, compras e suporte interno. Esses sistemas frequentemente precisam atravessar fronteiras de confiança: uma mensagem de cliente entra no mesmo fluxo em que estão instruções operacionais, dados de CRM e chamadas de ferramentas.
Uma defesa como HoS pode influenciar o desenho desses produtos. Em vez de tratar toda entrada como texto equivalente, a arquitetura pode marcar diferentes níveis de confiança e limitar como cada tipo de conteúdo participa da decisão. Isso combina com práticas de segurança já conhecidas, como privilégio mínimo, isolamento de processos e validação de ações críticas.
Mas a solução não substitui controles externos. Um agente que pode apagar registros ainda deve enfrentar permissões específicas, confirmação humana e registros de auditoria. Um gate de atenção não deve ser o único mecanismo responsável por impedir uma transferência financeira. Segurança em sistemas agentivos precisa ser em camadas.
Para startups, o estudo também reforça uma decisão estratégica: investir em segurança desde o desenho do produto pode ser mais barato que tentar remediar incidentes depois da escala. Clientes corporativos não compram apenas uma resposta correta. Eles precisam saber por que o agente tomou uma ação, quais dados influenciaram a decisão e quais operações foram bloqueadas.
Arquitetura contra prompt promete mais que instrução
A principal lição de HoS vai além do resultado numérico. Durante anos, muitas defesas contra prompt injection foram construídas como instruções adicionais: não siga comandos encontrados em documentos, ignore pedidos externos, trate a página como dados. Essas orientações ajudam, mas continuam competindo dentro do mesmo espaço linguístico que o ataque explora.
Uma abordagem arquitetural pergunta se a separação pode ser incorporada ao próprio mecanismo de processamento. Essa mudança de perspectiva é importante porque segurança raramente melhora apenas com uma frase mais cuidadosa no prompt. Quando o risco nasce da mistura entre autoridade e informação, a proteção precisa reduzir essa mistura.
Ao mesmo tempo, há um risco de excesso de confiança. Um mecanismo aprendido pode apresentar falhas em domínios novos, formatos inesperados ou combinações de ferramentas que não aparecem no treinamento. Além disso, definir quais tokens são confiáveis não é trivial. Uma fonte externa pode conter dados corretos, enquanto uma instrução aparentemente interna pode estar comprometida.
O próximo passo deve envolver avaliações mais realistas, com agentes completos, múltiplas ferramentas, memória persistente e ataques que tentem explorar toda a cadeia de decisão. Também será necessário medir falsos positivos: uma defesa que bloqueia comandos maliciosos, mas impede o agente de compreender documentos legítimos, pode ser segura no laboratório e inviável no negócio.
A separação que os agentes precisam aprender
Prompt injection expõe uma fragilidade conceitual: modelos de linguagem são excelentes em interpretar linguagem, mas não nasceram com uma noção confiável de autoridade. Para eles, uma frase em um email, uma instrução do sistema e um comentário em uma página podem parecer apenas sequências de tokens com relações estatísticas.
Os Heads of Security tentam introduzir uma distinção mais forte entre esses papéis. Se a técnica continuar funcionando em cenários variados, ela poderá representar um caminho para agentes que leem amplamente, mas obedecem com parcimônia. Essa é uma condição básica para sistemas que atuam em nome de pessoas e empresas.
A conclusão mais importante é menos espetacular que a promessa de um agente autônomo, mas muito mais útil: quanto maior a capacidade de ação de um sistema, menos podemos depender de sua interpretação espontânea sobre quem tem autoridade. A segurança precisa estar no desenho da arquitetura, nas permissões, nos registros e na revisão humana. Ensinar o modelo a separar evidência de instrução é um passo nessa direção, não o ponto final.