$25M Roubados via Prompt Injection em MCP: Como um Chatbot de IA Quebrou o DeFi Sem Tocar na Blockchain

Aviso Legal Introdução 1. O que é o Resolv e como funciona a emissão de USR?

O que é o Resolv e como funciona a emissão de USR?

O Resolv é um protocolo destablecoinque utiliza uma estratégia conhecida comohedging delta-neutropara manter o USR pareado em US$ 1,00. Em termos simples, o protocolo detém ativos cripto (ETH, BTC) enquanto simultaneamente abre posições opostas em mercados de derivativos, para que as variações de preço se cancelem — o valor em dólar permanece aproximadamente constante, independentemente de o mercado cripto subir ou descer. (Para uma explicação mais detalhada sobre como stablecoins sintéticas mantêm seu paritário e os riscos envolvidos, veja nosso guia sobrestablecoinse a seção sobre acrise da Ethena USDeem nosso relatório Real Yield.) Este design pertence à mesma família do USDe da Ethena, embora com escolhas de implementação distintas que se provariam críticas em 22 de março.

O processo de emissão (minting) do USR segue um padrão de duas etapas comum em protocolos que exigem autorização off-chain. Primeiro, um usuário chamarequestSwap(), depositando USDC no contrato como colateral. Isso cria uma solicitação de emissão pendente. Segundo, um endereço privilegiado — oSERVICE_ROLE— chamacompleteSwap()para autorizar a emissão real dos tokens USR. A ideia é direta: o depósito vem do usuário, mas o backend do protocolo verifica o valor do depósito, calcula a proporção correta de USR para USDC e, em seguida, assina a transação de emissão com a chave SERVICE_ROLE.

É aqui que a arquitetura se torna perigosa. O SERVICE_ROLE era umaConta de Propriedade Externa (EOA) única— não era um multisig, nem um timelock, nem um contrato controlado por governança. Uma única chave privada, armazenada no AWS Key Management Service (KMS), controlava a capacidade de emitir qualquer quantidade de USR. Como aChainalysis documentou em seu post-mortem, "o contrato impõe uma saída mínima de USR — mas, criticamente, não há máximo".

Leia isso novamente. Osmart contractpermitiria que o SERVICE_ROLE emitisse um bilhão de USR contra um único dólar de USDC, e o código seria executado sem erros. Não havia verificação de proporção on-chain. Nenhum limite máximo de emissão. Nenhuma validação de oráculo. Nenhum disjuntor (circuit breaker). O contrato confiava implicitamente no SERVICE_ROLE — qualquer valor que ele autorizasse era emitido, ponto final.

A análise da DeFiPrimefoi direta: não havia "proteções on-chain impondo essa proporção". Todo o modelo de segurança dependia da premissa de que a chave SERVICE_ROLE só seria usada pela infraestrutura legítima de backend. Essa premissa estava prestes a se mostrar catastroficamente errada.

Para entender por que isso importa, considere a diferença entre um protocolo onde a lógica de emissão vive on-chain (verificada por código, imutável, transparente) e um onde ela vive off-chain (dependente de uma única chave, armazenada em infraestrutura de nuvem, controlada por software que pode ser comprometido). O Resolv escolheu o último. E o software que controlava essa chave era um agente de IA.

2. O ataque de injeção de prompt

Como o assistente de IA foi comprometido? O ataque de injeção de prompt

É aqui que o hack do Resolv se afasta de todos os exploits de DeFi anteriores na história. Não houve bug de reentrância. Nenhuma manipulação de flash loan. Nenhum front-running de oráculo. Nenhum ataque de governança. O invasor não tocou na blockchain — até o final, quando usou uma chave de assinatura obtida legitimamente para autorizar transações que o smart contract executou perfeitamente.

O vetor de ataque foi umassistente de IA— um modelo de linguagem de grande escala (LLM) integrado à infraestrutura operacional do Resolv. Como muitos protocolos em 2025–2026 que adotaram IA para ferramentas internas, o Resolv implantou um assistente baseado em LLM conectado aos seus sistemas de backend viaModel Context Protocol (MCP).

O que é o Model Context Protocol?

O MCP é um padrão abertolançado pela Anthropic em novembro de 2024que permite que modelos de IA descubram e interajam dinamicamente com ferramentas externas durante a execução. Pense nele como um adaptador universal: em vez de codificar rigidamente cada integração que uma IA possa precisar, o MCP fornece uma maneira padronizada para um LLM se conectar a bancos de dados, APIs, sistemas de arquivos e serviços de nuvem em tempo real. A IA pode consultar um banco de dados Supabase, ler arquivos de um bucket de armazenamento, chamar um endpoint de API ou executar uma migração de banco de dados — tudo por meio de chamadas de ferramentas MCP.

O poder é óbvio. O perigo é igualmente óbvio, embora muito menos discutido. Uma IA conectada via MCP opera com quaisquer permissões que o servidor MCP lhe conceda. No caso do Resolv, o assistente de IA estava conectado a bancos de dadosSupabase— e estava rodando com oservice_roleprivilégios.

No modelo de segurança do Supabase, aservice_rolekey ignora todas as políticas de Segurança de Nível de Linha (Row Level Security). Ela possui acesso total de leitura e gravação em cada tabela, cada linha e cada coluna. É explicitamente documentada como uma chave que nunca deve ser exposta a clientes ou ambientes não confiáveis. A Resolv concedeu esse nível de acesso a uma IA que processava entradas externas.

Como funciona a injeção de prompt

A injeção de prompt é conceitualmente simples, mas devastadoramente eficaz. Um LLM processa texto — ele lê entradas e gera saídas. O problema fundamental é queos LLMs não conseguem distinguir de forma confiável entre instruções de seu operador e instruções incorporadas nos dados que processam. Se um invasor conseguir inserir texto malicioso em qualquer entrada que a IA leia, a IA poderá interpretar esse texto como um comando legítimo.

A Unit 42 da Palo Alto Networkspublicou uma extensa pesquisa sobre ataques de injeção de prompt indireta observados na prática. Suas descobertas são preocupantes: 37,8% dos ataques usam texto simples visível (instruções simplesmente escritas em um documento que a IA processa), 19,8% usam ocultação de atributos HTML (escondendo instruções em atributos HTML que humanos não veem, mas a IA lê) e 16,9% usam supressão de CSS (incorporando comandos em CSS que se tornam invisíveis para visualizadores humanos, mas são analisados pelo modelo). Os ataques não são teóricos. Eles estão acontecendo em sistemas de produção, contra organizações reais, agora mesmo.

O padrão de ataque MCP do Supabase já havia sido documentado antes do incidente da Resolv.A pesquisa da PVMLdescreveu o cenário exato: um ticket de suporte ou entrada de usuário contendo instruções incorporadas é processado por um assistente de IA com acesso service_role. A IA, incapaz de distinguir as instruções maliciosas das legítimas, segue os comandos incorporados. No caso documentado pela PVML, isso levou à exfiltração de tokens de integração. A conclusão deles foi inequívoca: “LLMs não foram projetados para serem guardiões de segurança”.

No ataque à Resolv, o invasor elaborou uma entrada que o assistente de IA interpretou como instruções legítimas. O payload exato não foi divulgado publicamente — o post-mortem da Resolv refere-se a ele apenas como “uma injeção de prompt elaborada” — mas o resultado é conhecido: a IA vazou credenciais temporárias de nuvem, incluindo tokens de acesso AWS que forneceram um ponto de apoio na infraestrutura da Resolv.

Tabela: Anatomia de uma Injeção de Prompt Indireta — os quatro estágios que permitiram o vazamento de credenciais da Resolv.

A Practical DevSecOps identificou oito categorias críticas de vulnerabilidadeem servidores MCP: injeção de prompt, envenenamento de ferramentas, ferramentas com excesso de permissão, o problema do deputado confuso (confused deputy), contaminação entre ferramentas, roubo de tokens, personificação de servidor e carregamento dinâmico de ferramentas não validado. O ataque à Resolv explorou pelo menos três destes: injeção de prompt (o ponto de entrada), ferramentas com excesso de permissão (acesso service_role) e o que equivale a um problema de deputado confuso (a IA agiu em nome do invasor acreditando estar seguindo instruções legítimas).

A percepção crítica é que isso não foi uma falha da IA em algum sentido abstrato. A IA fez exatamente o que foi projetada para fazer: processou a entrada e gerou a saída. A falha foi na arquitetura que deu a uma IA — um sistema que processa entradas não confiáveis por definição — acesso a credenciais que poderiam, em última instância, controlar um protocolo de mais de US$ 100 milhões. Isso é o queo CTO da Ledger, Charles Guillemet, chama de “trifeta letal”: entrada não confiável, recursos de execução poderosos e acesso à rede para exfiltração. Qualquer sistema que combine os três está, nas palavras de Guillemet, “preparado para falhar sob pressão”.

3. Movimentação lateral

Das credenciais de nuvem ao AWS KMS: a movimentação lateral

Com as credenciais temporárias da AWS em mãos, o invasor mudou da exploração de IA para um padrão clássico de ataque à infraestrutura de nuvem:movimentação lateral. Esta é uma técnica familiar para qualquer equipe de segurança de nuvem, mas quase inteiramente ausente do manual de segurança DeFi, que historicamente se concentrou em auditorias de contratos inteligentes e monitoramento on-chain.

O invasor não foi diretamente para a blockchain. Não houve necessidade. O objetivo era a chave de assinatura, e a chave de assinatura vivia na nuvem.

O primeiro passo foi enumerar o ambiente AWS usando as credenciais temporárias vazadas pela IA. As políticas do AWS Identity and Access Management (IAM) determinavam o que essas credenciais poderiam acessar. Em um ambiente bem arquitetado com IAM de menor privilégio, as credenciais temporárias de um assistente de IA teriam escopo restrito — talvez apenas acesso de leitura a tabelas específicas do banco de dados e nada mais. No ambiente da Resolv, as credenciais forneceram acesso suficiente para avançar mais profundamente.

O invasor navegou do ponto de apoio inicial do IAM para oAWS Key Management Service (KMS), onde a Resolv armazenava a chave privada SERVICE_ROLE. O KMS é o serviço gerenciado da Amazon para armazenar e usar chaves criptográficas — ele foi projetado para ser um cofre seguro para exatamente esse tipo de material sensível. Mas a segurança do KMS depende inteiramente das políticas de IAM que controlam quem pode acessar as chaves. Se um invasor tiver credenciais AWS válidas com permissões suficientes, o KMS servirá a chave para ele tão prontamente quanto serve para a aplicação legítima.

A Chainalysis confirmou o caminho: o invasor “acessou o ambiente AWS Key Management Service da Resolv, onde a chave de assinatura privilegiada do protocolo estava armazenada”. Uma vez dentro do KMS, o invasor obteve a chave privada SERVICE_ROLE — o único segredo criptográfico que autorizava todas as operações de cunhagem (minting) de USR.

Toda a fase de movimentação lateral — das credenciais vazadas pela IA ao acesso ao KMS — provavelmente levou minutos. Ataques à infraestrutura de nuvem movem-se rápido quando o invasor possui credenciais válidas. Não há cadeias de exploração para desenvolver, nem zero-days para descobrir. O invasor simplesmente faz login com as chaves roubadas e navega no ambiente como um administrador legítimo. É por isso que o roubo de credenciais é consistentemente a técnica de acesso inicial mais comum em violações de nuvem, de acordo com todos os principais relatórios de segurança de nuvem das equipes de inteligência de ameaças da AWS, Google Cloud e Microsoft Azure.

Vale a pena pausar para apreciar a ironia. A Resolv armazenou seu segredo mais crítico — a chave que controla centenas de milhões de dólares em autoridade de cunhagem — no AWS KMS, um dos serviços de gerenciamento de chaves mais seguros disponíveis. A segurança do KMS em si nunca esteve em questão. A vulnerabilidade estava no caminho para o KMS: um agente de IA, rodando com permissões excessivas, processando entradas não confiáveis, conectado ao mesmo ambiente de nuvem onde residia a chave de assinatura. A corrente era tão forte quanto seu elo mais fraco, e o elo mais fraco era um LLM que não conseguia distinguir uma instrução legítima de uma maliciosa.

Tabela: Cadeia de Ataque — Do Prompt aos $23M. Cinco passos, menos de 30 minutos, zero explorações de contratos inteligentes.

4. Execução on-chain

A execução on-chain: 80 milhões de tokens do nada

Com a chave SERVICE_ROLE comprometida, o invasor finalmente tocou a blockchain — e ocontrato inteligentefez exatamente o que foi projetado para fazer.

Transação 1:O invasor depositou aproximadamente US$ 100.000 em USDC no contrato de mint viarequestSwap(), e imediatamente chamoucompleteSwap()com a chave SERVICE_ROLE roubada, autorizando a cunhagem de50 milhões de USR. Isso é uma supercunhagem de 500x — cinquenta milhões de dólares em stablecoin criados a partir de cem mil dólares de colateral. O contrato aceitou a transação sem hesitação. Não houve verificação de proporção para rejeitá-la, nenhum limite máximo para restringi-la, nenhum oráculo para verificar se o valor cunhado tinha qualquer relação com o depósito.

Transação 2:Pouco depois, o invasor repetiu o processo, cunhando adicionais30 milhões de USR. Mesmo método, mesma chave, mesma ausência de salvaguardas on-chain.

No total:80 milhões de USRcriados contra cerca de US$ 200.000 em depósitos reais de USDC. Uma diluição de 400–500x do suprimento de tokens. Os tokens de cada detentor de USR existente passaram a ser lastreados instantaneamente por uma fração do que valiam minutos antes.

A estratégia de liquidação foi metódica. Em vez de despejar 80M de USR diretamente em uma única DEX — o que teria acionado disjuntores imediatos e slippage máximo — o invasor primeiro converteu uma parte significativa de USR emwstUSR(wrapped staked USR). Esta etapa de wrapping serviu a um propósito tático: o wstUSR era aceito por pools de liquidez diferentes do USR bruto, permitindo que o invasor acessasse vários locais de liquidação simultaneamente e reduzisse o impacto no preço em qualquer pool individual.

O invasor então distribuiu as vendas em três grandes exchanges descentralizadas:

• Curve Finance:O principal local de liquidação para pares de stablecoins. Os pools USR/USDC e USR/USDT absorveram a pressão de venda inicial antes do colapso da paridade (peg).
• KyberSwap:Utilizada para conversão adicional de USDC/USDT.A KyberSwap bloqueou as carteiras do explorador poucas horasapós o ataque, mas a essa altura o dano já estava feito.
• Velodrome:Alvo devido à sua liquidez profunda na Optimism, fornecendo outra rota de saída para os fundos roubados.

O resultado foi rápido e devastador. Na Curve,o USR caiu de $1,00 para $0,025 em aproximadamente 17 minutos— um colapso de 97,5%.O The Block relatouque o invasor extraiu cerca de $25 milhões, enquantoo CoinDesk estimou o valor em aproximadamente $23 milhões. A discrepância reflete a dificuldade de rastrear valores exatos em múltiplas DEXs e redes em tempo real.

A conversão final foi de stablecoins para ETH. O invasor consolidou os lucros em aproximadamente11.400 ETH— valendo cerca de $24 milhões no momento da exploração — e começou a movimentar os fundos através de endereços intermediários. A carteira principal do invasor,0x8ed8cf0c1c531c1b20848e78f1cb32fa5b99b81c, foirapidamente sinalizada por empresas de segurança e operadoras de DEX.

Toda a fase on-chain — desde a primeira emissão (mint) até a consolidação final em ETH — levoumenos de 30 minutos. Para contextualizar, isso é mais rápido do que a maioria dos signatários de multisig consegue coordenar uma resposta de emergência, mais rápido do que a maioria das equipes de protocolo consegue sequer confirmar que uma exploração está ocorrendo e mais rápido do que qualquer mecanismo de pausa baseado em governança poderia reagir. A vantagem de velocidade pertenceu inteiramente ao invasor.

A análise forense on-chain conta a história de um contrato inteligente fazendo exatamente o que lhe foi ordenado pela chave autorizada. Cada transação era válida. Cada assinatura era legítima. O contrato não tinha como saber — e nenhum mecanismo para verificar — que a chave que assinava essas transações havia sido roubada do ambiente de nuvem de um agente de IA comprometido. Do ponto de vista da blockchain, isso não foi um hack de forma alguma. Foi uma série de operações perfeitamente autorizadas.

5. O que as empresas de segurança descobriram

O que as empresas de segurança descobriram

O hack da Resolv desencadeou uma resposta imediata do ecossistema de segurança blockchain. Em poucas horas, várias empresas publicaram suas avaliações iniciais. O que surgiu não foi apenas o post-mortem de uma única exploração, mas o reconhecimento de que todo o modelo de ameaça para protocolosDeFitinha acabado de se expandir.

Cyvers: primeira detecção

A Cyvers, uma plataforma de monitoramento de segurança Web3 em tempo real, foi uma das primeiras a detectar a atividade anômala. Seus sistemas sinalizaram a criação de 80M de tokens USR como uma anomalia crítica — o volume de emissão era ordens de magnitude superior a qualquer execução anterior de completeSwap(). O alerta da Cyvers desencadeou a investigação da comunidade de segurança mais ampla e ajudou exchanges e DEXs a começarem a bloquear os endereços do explorador.

PeckShield: quantificando o dano

A PeckShield, uma das empresas de segurança blockchain mais estabelecidas, estimou o total de USR gerado artificialmente em $80 milhões de valor nominal. Sua análise on-chain confirmou o padrão de emissão em duas transações e rastreou os fluxos de fundos através da Curve, KyberSwap e Velodrome. O rastreamento em tempo real da PeckShield foi fundamental para ajudar as exchanges a congelar os ativos restantes do explorador antes que pudessem ser totalmente lavados.

Chainalysis: o post-mortem definitivo

A Chainalysis publicou a análise mais abrangentesob o título “Como uma Chave Comprometida Imprimiu $23 Milhões”. Sua investigação confirmou o vetor AWS KMS e forneceu a descrição mais clara da cadeia de ataque: prompt injection → roubo de credenciais → movimento lateral para KMS → comprometimento de SERVICE_ROLE → emissão não autorizada.

As principais recomendações da Chainalysis incluíram:

• Monitorar anomalias na proporção de completeSwap():Qualquer emissão onde a saída de USR exceda a entrada de USDC por mais do que uma pequena tolerância (considerando o posicionamento delta-neutro) deve disparar um alerta imediato.
• Pausa automatizada em eventos de Mint suspeitos:Se o volume de emissão em uma única transação ou janela de tempo curta exceder as normas históricas em 10x ou mais, o contrato deve pausar automaticamente e exigir intervenção multisig para retomar.
• Monitoramento de infraestrutura em nuvem:Os logs de acesso do KMS devem ser monitorados em tempo real. Qualquer acesso de um IP, função ou sessão não reconhecido deve disparar a rotação imediata da chave.
• Isolamento de agentes de IA:Agentes de IA nunca devem compartilhar credenciais de nuvem com sistemas que controlam chaves de assinatura. O ambiente de IA e o ambiente de gerenciamento de chaves devem ser contas AWS completamente separadas, sem acesso entre contas.

Charles Guillemet (Ledger): o aviso estrutural

Talvez a resposta mais significativa tenha vindo não de uma empresa de segurança blockchain, mas deCharles Guillemet, CTO da Ledger, que publicou “A IA Agêntica está Solta. Seu Modelo de Segurança Não Está Pronto”. A análise de Guillemet foi além das especificidades do hack da Resolv para descrever um problema sistêmico na forma como os agentes de IA estão sendo implantados na infraestrutura cripto.

Guillemet descreveu a “trifeta letal” que torna os agentes de IA inerentemente perigosos em ambientes de alto valor:

1. Entrada não confiável:Agentes de IA processam dados de fontes externas — usuários, sites, bancos de dados, APIs — qualquer um dos quais pode conter payloads de prompt injection.
2. Poderosas capacidades de execução:O MCP e protocolos similares de uso de ferramentas dão aos agentes de IA a capacidade de executar ações reais — consultas a bancos de dados, chamadas de API, operações de arquivos e, potencialmente, assinatura de transações.
3. Acesso à rede para exfiltração:Agentes de IA podem se comunicar externamente — através de seu canal de resposta, chamadas de ferramentas, logs — o que significa que qualquer informação vazada pode chegar ao invasor.

A solução proposta por Guillemet é arquiteturalmente radical:“Agentes Propõem, Humanos Assinam.”Neste modelo, um agente de IA pode analisar dados, sugerir transações e preparar operações — mas a autorização final deve vir de um humano, verificada através de separação reforçada por hardware (como uma carteira de hardware Ledger). A IA nunca pode executar autonomamente uma ação de alto valor. Ela pode apenas recomendar.

Sua conclusão carrega um peso particular dada a posição da Ledger como fabricante líder de carteiras de hardware:“Se sua arquitetura não consegue separar claramente o que um agente sugere do que um humano autoriza, então ela está fadada a falhar sob pressão.”

A mensagem coletiva da comunidade de segurança foi clara: o hack da Resolv não foi um incidente isolado, mas um prenúncio. Qualquer protocolo que utilize agentes de IA com privilégios elevados — particularmente aqueles com acesso a chaves de assinatura, credenciais de nuvem ou acesso a bancos de dados via service_role — deve implementar imediatamente defesas contra prompt injection, sanitização de entrada e o princípio do privilégio mínimo para todos os sistemas conectados à IA.

6. A blockchain nunca foi o elo fraco

A blockchain nunca foi o elo fraco

Esta é a parte que deve inquietar todo desenvolvedor, investidor e pesquisador de segurança DeFi. O código docontrato inteligentefuncionouperfeitamente. Ele fez exatamente o que foi projetado para fazer: quando a chave SERVICE_ROLE assinou uma transação completeSwap(), o contrato emitiu a quantidade especificada de USR. O código não tinha bugs. Não era vulnerável a reentrância. Não tinha chamadas externas não verificadas. Sem colisão de armazenamento. Sem overflow de inteiros. Por todas as medidas padrão de segurança de contratos inteligentes, o contrato de emissão da Resolv era tecnicamente sólido.

A vulnerabilidade existia inteiramente napilha de infraestrutura centralizada: Agente de IA → MCP → Supabase → AWS IAM → AWS KMS. Cada componente nesta cadeia é off-chain. Cada componente é centralizado. Cada componente é exatamente o tipo de intermediário confiável que a tecnologia blockchain foi inventada para eliminar.

Isso inverte inteiramente omodelo de segurança DeFitradicional. Nos últimos seis anos, a esmagadora maioria das explorações DeFi visou a camada blockchain: ataques de reentrância (The DAO, 2016), manipulação de oráculos via flash loan (bZx, 2020; Cream Finance, 2021), ataques de governança (Beanstalk, 2022), vulnerabilidades de pontes (Ronin, Wormhole, Nomad, 2022) eexplorações de aprovação de tokens. A resposta padrão a esses ataques tem sido melhores auditorias, verificação formal, bug bounties e monitoramento on-chain.

Nenhuma dessas defesas teria evitado o hack da Resolv. Você poderia ter auditado o contrato de emissão cem vezes com as melhores empresas do mundo e não teria encontrado nada, porque não havia nada para encontrar. O contrato era seguro. O agente de IA que o controlava não era.

Andrew Whong, cofundador da Herd, resumiu a falha arquitetural: “O contrato de emissão não tinha oráculo ou verificações de emissão máxima”. Mas mesmo isso subestima o problema. Verificações de oráculo e limites de emissão teriam ajudado — teriam limitado o raio de impacto — mas a questão fundamental é que uma única chave controlada por um agente de IA comprometível tinha autoridade de emissão ilimitada. A solução não é apenas adicionar verificações on-chain. É repensar toda a relação entre a infraestrutura de IA e as operações on-chain.

O DeFiPrime chamou isso de“um caso de confiança excessiva na infraestrutura off-chain” — uma frase que poderia servir como epitáfio para toda uma geração de protocolos DeFi que acoplaram agentes de IA às suas operações sem considerar as implicações de segurança.

O paradoxo é doloroso. A promessa central do DeFi é finanças descentralizadas, sem permissão e sem necessidade de confiança. Sem ponto único de falha. Sem intermediário confiável. O código é a lei. E, no entanto, aqui estava a Resolv — um protocolo gerenciando centenas de milhões de dólares — onde a função de emissão era controlada por uma única chave centralizada, gerenciada por um agente de IA, armazenada na infraestrutura de um provedor de nuvem, acessível através de uma cadeia de credenciais que poderiam ser vazadas ao enganar um chatbot. A blockchain era o componente mais seguro em toda a pilha. Foi a infraestrutura off-chain — a IA, a nuvem, o gerenciamento de chaves — que falhou.

Tabela: Hack DeFi Tradicional vs. Hack de Infraestrutura de IA — a exploração da Resolv representa uma mudança de paradigma sobre onde residem as vulnerabilidades DeFi.

Para usuários que tentam avaliar sua própria exposição a esses riscos, ferramentas como oCleanSkypodem ajudar a monitoraraprovações de tokense posições em diversos protocolos — mas a lição mais profunda é que o monitoramento on-chain, por si só, não é mais suficiente. A superfície de ataque agora se estende à infraestrutura de nuvem, agentes de IA e sistemas de gerenciamento de chaves que os protocolos utilizam nos bastidores. Compreender oriscoem DeFi agora significa entender toda a stack, não apenas os contratos inteligentes.

7. Por que este não será o último

Por que este provavelmente não será o último ataque à infraestrutura de IA

Se o hack da Resolv fosse um incidente isolado — uma falha pontual de um único protocolo que tomou decisões arquiteturais excepcionalmente ruins — seria preocupante, mas contível. O problema é que todas as tendências do setor apontam para mais agentes de IA, mais conexões MCP, mais operações automatizadas e mais protocolos cometendo exatamente os mesmos erros que a Resolv cometeu.

Agentes de IA já são atacantes capazes

A própria pesquisa da Anthropic, publicada em dezembro de 2025, mostrou que agentes de IA já conseguem explorar mais de 50% dos contratos inteligentes vulneráveis do mundo real no benchmark SCONE-bench — um conjunto de dados de 405 contratos representando US$ 550 milhões em valor simulado. Esta pesquisa tratava de IA atacando contratos inteligentes, mas as mesmas capacidades se aplicam inversamente: agentes de IA são sofisticados o suficiente para serem ferramentas valiosas tanto para defensores quanto para atacantes.

Separadamente, pesquisadores demonstraram que modelos de fronteira, incluindo GPT-5 e Sonnet 4.5, encontraram duas falhas de dia zero em 2.849 contratos da BNB Chain com um custo de computação de apenas US$ 3.476. A economia da descoberta de vulnerabilidades impulsionada por IA inclinou-se decisivamente a favor dos atacantes: o custo para encontrar bugs exploráveis é agora trivial em comparação com o retorno potencial.

Os números estão acelerando

O relatório anual de 2025 da Hacken documentou umaumento de 1.025% em exploits relacionados à IAem comparação com 2024. Isso não é um erro de digitação — um aumento de dez vezes em um único ano. A categoria inclui phishing impulsionado por IA, descoberta de vulnerabilidades assistida por IA, engenharia social aprimorada por deepfake e, agora, ataques de injeção de prompt na infraestrutura de protocolos. A pesquisa da Cecuro descobriu que agentes de IA de fronteira podem executar exploits de ponta a ponta em 72% dos contratos vulneráveis conhecidos, contra cerca de 20% no início de 2024.

Ocenário de segurança cripto de 2025já era preocupante antes da Resolv: US$ 4,65 bilhões em perdas totais, o comprometimento do multisig da Bybit, uma onda de falhas de controle de acesso. O hack da Resolv adiciona uma nova categoria a uma superfície de ameaça que já estava em expansão.

A adoção do MCP está acelerando sem paridade de segurança

A adoção do Model Context Protocol explodiu ao longo de 2025 e em 2026. Milhares de servidores MCP existem agora para bancos de dados (Supabase, PostgreSQL, MongoDB), provedores de nuvem (AWS, GCP, Azure), ferramentas de desenvolvimento (GitHub, GitLab, Jira), plataformas de comunicação (Slack, Discord, e-mail) e serviços financeiros (APIs bancárias, processadores de pagamento, nós de blockchain). Cada servidor MCP é um alvo potencial de injeção de prompt.

Oincidente do Supabase MCP documentado pela PVMLfoi o tiro de alerta.A própria Supabase publicou “Defesa em Profundidade para MCP”em resposta, recomendando que os servidores MCP nunca usem chaves service_role e, em vez disso, usem autenticação com escopo por usuário. Mas a adoção dessas recomendações tem sido irregular, na melhor das hipóteses. Muitas equipes de protocolos implantaram integrações MCP durante a onda de hype da IA de 2024–2025 sem implementar controles básicos de segurança.

O hack da Resolv foi a primeira vítima com dinheiro real. Não será a última. A combinação da expansão da implantação de agentes de IA, o aumento da adoção de MCP e os enormes incentivos financeiros para atacantes cria um cenário de ameaças que cresce mais rápido do que as defesas estão sendo implantadas. Todo protocolo que utiliza agentes de IA para tarefas operacionais — gerenciamento de risco, trading, suporte ao cliente, monitoramento, participação em governança — deve considerar o ataque à Resolv como um aviso direto.

O problema estrutural

A questão mais profunda não é uma vulnerabilidade única, mas um descompasso estrutural entre as capacidades da IA e a segurança da IA. LLMs são ferramentas extremamente poderosas para processar informações, gerar saídas e interagir com sistemas externos. Eles também são fundamentalmente incapazes de distinguir de forma confiável instruções confiáveis de entradas não confiáveis. Isso não é um bug que será corrigido na próxima versão do modelo — é uma propriedade inerente de como os modelos de linguagem baseados em transformadores processam texto.

Cada conexão MCP a um agente de IA cria uma nova superfície de ataque. Cada dado que a IA processa é um vetor potencial de injeção de prompt. Cada ferramenta que a IA pode chamar é uma capacidade que o atacante herda. E cada credencial que a IA pode acessar é uma credencial que o atacante pode roubar. Quanto mais poderosos e conectados os agentes de IA se tornam, mais valiosos eles se tornam como alvos de ataque. Este é o paradoxo da segurança da IA agentícia: os recursos que tornam os agentes úteis são os mesmos que os tornam perigosos.

8. O que os protocolos devem fazer agora

O que os protocolos devem fazer agora

O hack da Resolv fornece um roteiro claro para as medidas defensivas que cada protocolo DeFi que utiliza agentes de IA deve implementar. Estas não são melhores práticas opcionais — são requisitos mínimos para qualquer protocolo que não queira ser a próxima manchete de US$ 23 milhões.

1. Separar a assinatura da IA — permanentemente

Esta é a lição mais importante de todas.Agentes de IA nunca devem deter, acessar ou estar no mesmo caminho de credenciais que as chaves de assinatura.A arquitetura “Agentes Propõem, Humanos Assinam”defendida por Guillemetdeve ser o padrão para todos os protocolos. Uma IA pode analisar uma solicitação de swap pendente e recomendar um valor de cunhagem. Ela pode preparar os parâmetros da transação. Pode até enviar a transação para uma fila. Mas a assinatura real — a autorização criptográfica que torna a transação executável — deve exigir aprovação humana através de uma fronteira reforçada por hardware.

Na prática, isso significa: a conta AWS onde os agentes de IA rodam deve ter acesso zero à conta AWS (ou HSM, ou multisig) onde residem as chaves de assinatura. Sem função IAM, sem confiança entre contas, sem credenciais compartilhadas. Separação arquitetural completa.

2. Blindar cada conexão MCP

Cada servidor MCP que se conecta a um agente de IA deve implementar:

• Sanitização de entrada:Remover ou escapar padrões potenciais de injeção de prompt de todos os dados antes que cheguem à IA.
• Filtragem de saída:Monitorar as saídas da IA em busca de padrões de credenciais (chaves de API, tokens, strings de conexão) e bloqueá-las antes que saiam do sistema.
• Acesso baseado em funções:Usar o nível mínimo de privilégio necessário. Nunca conectar uma IA a um banco de dados com acesso service_role. Usar tokens com escopo limitado e somente leitura sempre que possível.
• Lista de permissões de ferramentas:Definir explicitamente quais ferramentas MCP a IA pode chamar. Bloquear todas as ferramentas que não estão na lista de permissões. Impedir que a IA descubra ou invoque novas ferramentas em tempo de execução.
• Limitação de taxa (Rate limiting):Limitar a frequência e o volume de chamadas de ferramentas que uma IA pode fazer dentro de uma janela de tempo para evitar a exfiltração rápida.

3. Implementar salvaguardas on-chain

Mesmo que a infraestrutura off-chain seja comprometida, mecanismos de segurança on-chain podem limitar os danos. O contrato da Resolv não tinha nenhum. Cada contrato de cunhagem ou operação de alto valor deve incluir:

• Limites máximos de cunhagem:Um teto por transação e por hora sobre o valor que pode ser cunhado. Se a Resolv tivesse limitado a cunhagem a, digamos, 2x o valor do depósito, o atacante poderia ter roubado US$ 400 mil em vez de US$ 23 milhões.
• Verificações de preço via Oracle:Antes de cunhar, verifique a proporção depósito-cunhagem contra um oráculo externo. Se a proporção desviar além de um limite, reverta a transação.
• Time-locks (Bloqueios temporais):Grandes operações de cunhagem devem exigir um atraso obrigatório (ex: 15 minutos a 24 horas) durante o qual a cunhagem pendente pode ser revisada e cancelada.
• Pausas acionadas por anomalias:Se o volume de cunhagem exceder as normas históricas por um fator grande (10x, 50x), o contrato deve pausar automaticamente e exigir intervenção de multisig para retomar.

4. Multisig para todas as operações críticas

A SERVICE_ROLE nunca deveria ter sido uma única EOA. Operações críticas do protocolo — cunhagem, queima, mudanças de parâmetros, upgrades, pausas de emergência — devem exigir múltiplos signatários independentes. Um multisig 3-de-5 ou 4-de-7 usando signatários geograficamente distribuídos com carteiras de hardware teria tornado o ataque à Resolv virtualmente impossível, mesmo com a chave SERVICE_ROLE comprometida, porque o atacante precisaria comprometer múltiplos signatários independentes simultaneamente.

5. Fundamentos de segurança em nuvem

O ataque à Resolv explorou falhas básicas de segurança em nuvem que teriam sido detectadas por uma revisão padrão de segurança de nuvem:

• IAM de menor privilégio:Credenciais temporárias emitidas para agentes de IA devem ter escopo limitado às permissões mínimas absolutas necessárias. Um assistente de IA que consulta tabelas de banco de dados não precisa de acesso ao KMS.
• Sem credenciais de longa duração:Agentes de IA devem usar credenciais de curta duração que rotacionam automaticamente. Se as credenciais da IA da Resolv tivessem expirado em minutos, em vez de permanecerem válidas por tempo suficiente para movimentação lateral, o ataque teria sido significativamente mais difícil.
• Log de acesso e alertas do KMS:Cada acesso a uma chave KMS deve gerar um alerta. Padrões de acesso incomuns (novo IP, nova função, novo horário do dia) devem desencadear investigação imediata.
• Segmentação de rede:O ambiente do agente de IA e o ambiente de gerenciamento de chaves devem estar em VPCs (Virtual Private Clouds) separadas, sem caminho de rede entre eles.

6. Implantar defesas contra injeção de prompt

Embora nenhuma defesa seja 100% eficaz contra injeção de prompt (continua sendo um problema de pesquisa em aberto), várias técnicas elevam significativamente a barra para os atacantes:

• Spotlighting:Uma técnica que marca a fronteira entre instruções confiáveis e dados não confiáveis usando delimitadores especiais que a IA é treinada para respeitar. O prompt do sistema instrui explicitamente a IA a tratar o conteúdo dentro de delimitadores não confiáveis apenas como dados, nunca como instruções.
• Hierarquia de instruções:Configurar a IA para que as instruções de nível de sistema sempre se sobreponham a quaisquer instruções encontradas em entradas de usuários ou dados externos. Isso é imperfeito, mas aumenta a dificuldade de uma injeção bem-sucedida.
• Testes adversários:Realizar red-teaming regularmente em suas integrações de IA com tentativas de injeção de prompt. Se sua equipe de segurança não consegue extrair credenciais via injeção de prompt, isso não significa que um atacante não consiga — mas é um mínimo necessário.
• Classificadores de saída:Usar um modelo de IA separado e mais simples para escanear as saídas do agente principal em busca de vazamentos potenciais de credenciais, chamadas de ferramentas anômalas ou sinais de seguimento de instruções de entradas não confiáveis.

7. Monitorar a stack completa

O monitoramento on-chain é necessário, mas não é mais suficiente. Os protocolos agora devem monitorar:

• Logs de auditoria de nuvem:AWS CloudTrail, GCP Cloud Audit, Azure Activity Logs — cada chamada de API no ambiente de nuvem deve ser registrada e analisada.
• Comportamento do agente de IA:Registrar cada chamada de ferramenta, cada entrada, cada saída. Estabelecer linhas de base para o comportamento normal e alertar sobre desvios.
• Invocações de ferramentas MCP:Rastrear quais ferramentas MCP estão sendo chamadas, com que frequência e com quais parâmetros. Um pico repentino em chamadas de ferramentas relacionadas a credenciais deve disparar investigação imediata.
• Anomalias on-chain:Continuar monitorando cunhagens incomuns, grandes transferências e desvios de preço — mas reconhecer que, no momento em que estes aparecem on-chain, o comprometimento off-chain já pode estar completo.

9. O panorama geral

O panorama geral: quando a máquina é a vulnerabilidade

O hack do USR da Resolv não é apenas uma história sobre um protocolo que tomou decisões arquiteturais ruins. É uma prévia de uma nova categoria de risco que toda a indústria cripto deve enfrentar à medida que a integração da IA acelera.

Na última década, a narrativa de segurança cripto foi dominada por bugs em contratos inteligentes. O hack da DAO em 2016 nos ensinou sobre reentrância. O congelamento da carteira Parity nos ensinou sobre contratos de biblioteca. O hack da ponte Wormhole nos ensinou sobre verificação cross-chain. Cada exploit avançou a compreensão da indústria sobre segurança on-chain, levando a melhores ferramentas de auditoria, verificação formal e bug bounties. A indústria de segurança de contratos inteligentes está agora madura, bem financiada e genuinamente eficaz na descoberta de vulnerabilidades ao nível de código.

Mas o hack da Resolv contornou tudo isso. O invasor não precisou encontrar um bug no código porque o código era irrelevante. O invasor precisava encontrar uma maneira de obter uma chave de assinatura, e o caminho passou por um chatbot de IA, um banco de dados em nuvem e um serviço de gerenciamento de chaves — tudo off-chain, tudo centralizado, tudo invisível para os sistemas de monitoramento on-chain que a indústria gastou bilhões construindo.

Este não é um problema que melhores auditorias de smart contracts possam resolver. Não é um problema que a verificação formal possa abordar. Isso exige uma disciplina de segurança inteiramente nova que combine segurança em nuvem, segurança de IA, defesa contra prompt injection, melhores práticas de gerenciamento de chaves e o monitoramento tradicional de DeFi em um framework unificado. Nenhum framework desse tipo existe hoje de forma padronizada e amplamente adotada. O hack da Resolv é o sinal de alerta.

A indústria agora enfrenta uma escolha. Pode tratar o hack da Resolv como uma anomalia — um erro de uma única equipe, improvável de ser repetido — e continuar implantando agentes de IA com privilégios elevados e controles de segurança mínimos. Ou pode reconhecer que a combinação de IA agêntica, acesso a ferramentas MCP e operações on-chain de alto valor cria uma superfície de ameaça fundamentalmente nova que exige defesas fundamentalmente novas.

O dinheiro inteligente aposta na segunda opção. Mas a história sugere que muitos protocolos escolherão a primeira — e estaremos escrevendo sobre o próximo exploit no estilo Resolv antes que o ano acabe.

Manter-se seguro em criptosempre exigiu entender onde os riscos realmente residem. Após 22 de março de 2026, esses riscos incluem os agentes de IA nos quais os protocolos confiam para executar sua infraestrutura.

CTA Independência editorial Leitura Relacionada

Leitura relacionada