Alguns dias atrás, eu estava lendo o OWASP Top 10 para aplicações de modelos de linguagem; era a lista atualizada que saiu no fim do ano passado, e algo nela chamou minha atenção imediatamente por como se relaciona de forma direta com um problema que o Newton Protocol está tentando resolver em silêncio. A injeção de prompts ficou na primeira posição — não como uma preocupação teórica, mas como a vulnerabilidade mais crítica, ativamente afetando sistemas de produção agora, de copilotos empresariais a assistentes de código e agentes autônomos que gerenciam fluxos de trabalho reais. A descrição da comunidade de segurança é quase desconfortavelmente simples: um atacante coloca instruções maliciosas dentro de conteúdos que o agente deveria ler como dados, o agente não consegue distinguir de forma confiável instrução de informação e a carga maliciosa substitui o que quer que o agente originalmente deveria fazer. Em contextos de software comuns, isso resulta em uma resposta ruim ou em um documento vazado. Em um agente financeiro onchain com uma carteira financiada e permissões de execução de transações, isso produz algo consideravelmente pior.
O que me parece genuinamente interessante é como, com bastante precisão, a descrição do problema pela comunidade de pesquisa em segurança se conecta à lacuna arquitetural que a Newton foi projetada para preencher, apesar de as duas conversas raramente se referenciarem diretamente. Pesquisadores de segurança têm convergido para o que um analista descreveu como o tríplice letal: a combinação de acesso a dados privados, exposição a conteúdo não confiável e a capacidade de executar ações externas. Quando as três estão presentes simultaneamente em um único agente, a superfície de ataque deixa de ser teórica e se torna uma quase certeza diante de pressão adversarial suficiente. Para um agente de automação DeFi, essas três propriedades não são casos extremos; elas são a descrição básica do trabalho. O agente lê dados de mercado e feeds externos, mantém permissões de chave de sessão sobre uma carteira financiada e executa transações de forma autônoma. A OpenAI, a Anthropic e o Google DeepMind reconheceram em publicações de 2025 que prompt injection não pode ser totalmente resolvido dentro das arquiteturas atuais de grandes modelos de linguagem, porque qualquer defesa formulada como instrução de prompt pode, por sua vez, ser sobrescrita por um ataque suficientemente bem elaborado. Às vezes eu me pergunto se as pessoas que estão implantando agentes de IA para operações de tesouraria onchain realmente leram essa frase com atenção suficiente, porque ela efetivamente diz que o próprio modelo não pode ser a última linha de defesa.
A parte que eu continuo voltando é o que isso significa para onde a fronteira real de segurança precisa estar e por que a camada de enforcement pré-liquidação da Newton endereça algo que defesas puramente no nível do modelo não conseguem atingir de forma estrutural. O consenso que está emergindo da pesquisa em segurança é que a abordagem correta não é um melhor filtro de prompts, mas sim a aplicação determinística de políticas na camada de ferramentas, restringindo o que o agente pode fazer com seus direitos de execução, independentemente das instruções que ele recebeu ou de quem ele as recebeu. As listas de beneficiários aprovados da Newton, limites de gastos e políticas de exigência/mandato não são recursos que o próprio agente implementa; elas são restrições externas avaliadas por uma rede de operadores neutra antes de a transação chegar à cadeia. Um agente comprometido, injetado com instruções para transferir fundos para o endereço de um atacante, ainda passa pela verificação de políticas da Newton antes que essa transferência seja liquidada; e, se o endereço de destino estiver fora da lista de beneficiários aprovados, a transação é bloqueada de forma independente do que o agente acredite ter sido autorizado a fazer. A pergunta que vem à mente é se essa distinção — entre confiar no agente e restringir o que o agente realmente consegue executar — está sendo entendida com clareza suficiente pelos desenvolvedores que atualmente constroem sistemas de automação onchain em produção.
Olhando de fora para onde esta conversa está indo, há uma dimensão de timing que parece importante e pouco valorizada. A comunidade de pesquisa em segurança está ativamente documentando ataques em que um único documento injetado em um banco de dados vetorial alcança uma taxa de sucesso de ataque de noventa por cento; onde envenenamento de memória cria ataques adiados que persistem entre sessões; e onde sistemas multiagentes passam instruções comprometidas entre si de maneiras que tornam o ponto de injeção original quase impossível de rastrear depois. Todo esse trabalho de pesquisa está amadurecendo exatamente no mesmo momento em que agentes de IA onchain estão passando de pequenos ambientes experimentais para sistemas gerenciando capital significativo em protocolos reais. O beta do mainnet da Newton chegando nessa janela específica parece menos coincidência e mais como se o protocolo tivesse encontrado a “fenda” entre dois campos — a segurança de IA e a finança onchain — que vêm se desenvolvendo em paralelo sem reconhecer claramente o quanto elas se intersectam. Se desenvolvedores construindo a próxima geração de agentes financeiros tratam a aplicação de políticas pré-liquidação como requisito fundamental ou descobrem sua necessidade do jeito difícil, é uma pergunta que eu sinceramente ainda não sei a resposta — de qualquer forma, o tempo dirá...