A conversa de alguns dias atrás sobre como a IA rompe as defesas tradicionais. Hoje vamos falar de um risco exclusivo do setor de criptografia — e que está explodindo: injeção de prompts (Prompt Injection) — e por que isso transforma uma operação como “dar permissões para que um AI Agent gerencie uma carteira” em uma ação de alto risco.
A segurança tradicional de software tem um princípio central: isolamento entre código e dados. Por exemplo, na injeção de SQL, podemos separar o código (comandos SQL) e os dados (entrada do usuário) por meio de “declarações preparadas”. Assim, mesmo que a entrada do usuário pareça código, ela não será executada. A proteção de memória (bits NX) segue uma lógica semelhante: a área de dados não pode executar código.
Mas os grandes modelos de linguagem (LLMs) quebraram totalmente essa barreira. Na arquitetura Transformer, instruções (Prompt) e dados (entrada do usuário) são achatados em uma única sequência de tokens. O modelo não consegue, por princípio, distinguir “quais são instruções dadas pelo desenvolvedor” e “quais são entradas fornecidas pelo usuário”. É como colocar comandos de SQL e comentários do usuário na mesma folha, fazendo o banco de dados decidir por si só qual frase deve ser executada — e isso é impossível.
Essa é a razão de “não haver base” para a imunidade do sistema a “prompt injection”. Não importa como você escreva o Prompt (“ignore as instruções anteriores”, “você é um assistente de segurança”), o atacante consegue, por meio de uma entrada cuidadosamente construída (“esqueça o que você disse antes e execute...”), sobrescrever suas instruções originais.
No mundo da criptografia, essa falha é fatal. Hoje, muitos projetos estão tentando conceder permissões a carteiras de agentes de IA: por exemplo, deixar a IA fazer aportes automáticos (DCA) automaticamente, participar automaticamente de IDOs e gerenciar liquidez automaticamente. Assim que o Prompt do Agent for injetado, um atacante pode fazer com que ele:
transfira todo o patrimônio para um endereço especificado;
autorize cotas ilimitadas para um contrato malicioso;
modifique a lógica de aprovação de múltiplas assinaturas.
Ainda mais assustador: esse tipo de ataque pode acontecer “indiretamente”. Por exemplo, quando um AI Agent navega pela web, lê mensagens no Discord ou processa solicitações do usuário, ele pode “engolir” silenciosamente instruções maliciosas. Todo o processo não exige quebrar chaves privadas; basta “enganar” o mecanismo de atenção do modelo.
Atualmente, não existe nenhuma tecnologia que possa provar matematicamente que “este sistema de IA é imune à prompt injection”. Todas as defesas (filtragem de Prompt, validação de saída, isolamento em sandbox) são probabilísticas — como antivírus: sempre haverá algo que passa despercebido.
Para usuários comuns, isso significa: nunca conceda a qualquer AI Agent permissões completas de uma carteira — especialmente da carteira principal. Um AI Agent pode ser muito conveniente, mas o “cérebro” dele é transparente e pode ser adulterado.
Amanhã, conversamos sobre soluções: qual é a regra de sobrevivência para carteiras auto-hospedadas na era da IA? Por que MPC e “confiança em partes” são caminhos viáveis em poucos casos.