$25M Roubados via Injeção de Prompts MCP: Como um Chatbot de IA Quebrou a DeFi Sem Tocar na Blockchain

O que é a Resolv e como funciona a cunhagem de USR?

A Resolv é um protocolo de stablecoin que usa uma estratégia conhecida como hedging delta-neutro para manter o USR ancorado a $1,00. Em termos simples, o protocolo mantém criptoativos (ETH, BTC) enquanto simultaneamente coloca apostas opostas nos mercados de derivados, de modo que os movimentos de preço se anulem — o valor em dólar permanece aproximadamente constante independentemente de o cripto subir ou descer. (Para uma explicação mais aprofundada de como as stablecoins sintéticas mantêm a sua ancoragem e os riscos envolvidos, consulte o nosso guia sobre stablecoins e a secção da crise do Ethena USDe no nosso relatório Real Yield.) Este design pertence à mesma família que o USDe da Ethena, embora com escolhas de implementação distintas que se revelariam críticas em 22 de março.

O processo de cunhagem de USR segue um padrão de duas etapas comum em protocolos que requerem autorização off-chain. Primeiro, um utilizador chama requestSwap(), depositando USDC no contrato como colateral. Isto cria um pedido de cunhagem pendente. Segundo, um endereço privilegiado — o SERVICE_ROLE — chama completeSwap() para autorizar a cunhagem efetiva dos tokens USR. A ideia é simples: o depósito vem do utilizador, mas o backend do protocolo verifica o montante do depósito, calcula a proporção correta USR-para-USDC e, em seguida, assina a transação de cunhagem com a chave SERVICE_ROLE.

É aqui que a arquitetura se torna perigosa. O SERVICE_ROLE era uma única Conta de Propriedade Externa (EOA) — não um multisig, não um timelock, não um contrato controlado por governança. Uma única chave privada, armazenada no AWS Key Management Service (KMS), controlava a capacidade de cunhar qualquer quantidade de USR. Como a Chainalysis documentou no seu post-mortem, “o contrato aplica um mínimo de USR — mas criticamente, nenhum máximo.”

Leia novamente. O contrato inteligente permitiria ao SERVICE_ROLE cunhar mil milhões de USR contra um único dólar de USDC, e o código executaria sem erro. Não havia verificação de proporção on-chain. Nenhum teto máximo de cunhagem. Nenhuma validação de oráculo. Nenhum disjuntor. O contrato confiava implicitamente no SERVICE_ROLE — qualquer montante que autorizasse era cunhado, ponto final.

A análise da DeFiPrime foi direta: não havia “proteções on-chain que aplicassem essa proporção.” Todo o modelo de segurança dependia da suposição de que a chave SERVICE_ROLE só seria usada pela infraestrutura de backend legítima. Essa suposição estava prestes a ser catastroficamente errada.

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

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

É aqui que o hack da Resolv se distingue de todos os exploits 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 atacante não tocou na blockchain — até ao final, quando usou uma chave de assinatura legitimamente obtida para autorizar transações que o contrato inteligente executou impecavelmente.

O vetor de ataque foi um assistente de IA — um modelo de linguagem de grande dimensão (LLM) integrado na infraestrutura operacional da Resolv. Como muitos protocolos em 2025–2026 que adotaram IA para ferramentas internas, a Resolv tinha implementado um assistente baseado em LLM conectado aos seus sistemas de backend via Model Context Protocol (MCP).

O que é o Model Context Protocol?

O MCP é um padrão aberto lançado pela Anthropic em novembro de 2024 que 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 manualmente cada integração que uma IA possa precisar, o MCP fornece uma forma padronizada para um LLM conectar-se a bases de dados, APIs, sistemas de ficheiros e serviços na nuvem em tempo real. A IA pode consultar uma base de dados Supabase, ler ficheiros de um bucket de armazenamento, chamar um endpoint de API ou executar uma migração de base de dados — tudo através 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 da Resolv, o assistente de IA estava conectado a bases de dados Supabase — e funcionava com privilégios de service_role.

No modelo de segurança da Supabase, a chave service_role contorna todas as políticas de Segurança a Nível de Linha (Row Level Security). Tem acesso total de leitura e escrita a todas as tabelas, todas as linhas, todas as colunas. Está explicitamente documentada como uma chave que nunca deve ser exposta a clientes ou ambientes não confiáveis. A Resolv deu este nível de acesso a uma IA que processava entradas externas.

Como funciona a injeção de prompts

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

A Unit 42 da Palo Alto Networks publicou pesquisas extensas sobre ataques de injeção indireta de prompts observados em produção. As suas conclusões são preocupantes: 37,8% dos ataques usam texto simples visível (instruções simplesmente escritas num documento que a IA processa), 19,8% usam camuflagem de atributos HTML (escondendo instruções em atributos HTML que humanos não veem mas a IA lê), e 16,9% usam supressão CSS (incorporando comandos em CSS que é tornado invisível para leitores humanos mas analisado pelo modelo). Os ataques não são teóricos. Estão a acontecer em sistemas de produção, contra organizações reais, agora mesmo.

O padrão de ataque MCP da Supabase já tinha sido documentado antes do incidente da Resolv. A pesquisa da PVML descreveu o cenário exato: um ticket de suporte ou entrada de utilizador 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, isto levou à exfiltração de tokens de integração. A sua conclusão foi inequívoca: “Os LLMs não foram concebidos para serem guardiões de segurança.”

No ataque à Resolv, o atacante criou 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 prompts elaborada” — mas o resultado é conhecido: a IA vazou credenciais temporárias da nuvem, incluindo tokens de acesso AWS que proporcionaram um ponto de entrada na infraestrutura da Resolv.

Tabela: Anatomia de uma Injeção Indireta de Prompts — as quatro fases que possibilitaram o vazamento de credenciais da Resolv.

A Practical DevSecOps identificou oito categorias críticas de vulnerabilidade em servidores MCP: injeção de prompts, envenenamento de ferramentas, ferramentas com permissões excessivas, o problema do deputado confuso, contaminação cruzada de ferramentas, roubo de tokens, falsificação de servidores e carregamento dinâmico de ferramentas não validado. O ataque à Resolv explorou pelo menos três destas: injeção de prompts (o ponto de entrada), ferramentas com permissões excessivas (acesso service_role) e o que equivale a um problema de deputado confuso (a IA agiu em nome do atacante enquanto acreditava estar a seguir instruções legítimas).

A conclusão crítica é que isto não foi uma falha da IA num sentido abstrato. A IA fez exatamente aquilo para que foi concebida: processou entrada e gerou saída. A falha esteve na arquitetura que deu a uma IA — um sistema que processa entradas não confiáveis por definição — acesso a credenciais que podiam, em última instância, controlar um protocolo de mais de $100M. Isto é o que Charles Guillemet, CTO da Ledger, chama de “tríade letal”: entrada não confiável, capacidades de execução poderosas e acesso à rede para exfiltração. Qualquer sistema que combine os três está, nas palavras de Guillemet, “preparado para falhar sob pressão.”

Das credenciais na nuvem ao AWS KMS: o movimento lateral

Com credenciais temporárias AWS em mãos, o atacante passou da exploração de IA para um padrão clássico de ataque a infraestrutura na nuvem: movimento lateral. Esta é uma técnica familiar para todas as equipas de segurança na nuvem, mas quase totalmente ausente do manual de segurança DeFi, que historicamente se concentrou em auditorias de contratos inteligentes e monitorização on-chain.

O atacante não foi diretamente à blockchain. Não havia necessidade. O objetivo era a chave de assinatura, e a chave de assinatura residia na nuvem.

O primeiro passo foi enumerar o ambiente AWS usando as credenciais temporárias vazadas pela IA. As políticas de Gestão de Identidade e Acesso (IAM) da AWS determinavam o que essas credenciais podiam aceder. Num ambiente bem arquitetado com privilégio mínimo no IAM, credenciais temporárias de um assistente de IA seriam limitadas — talvez acesso apenas de leitura a tabelas específicas da base de dados e nada mais. No ambiente da Resolv, as credenciais proporcionavam acesso suficiente para avançar mais profundamente.

O atacante navegou desde o ponto de apoio inicial no IAM até ao AWS Key Management Service (KMS), onde a Resolv armazenava a chave privada SERVICE_ROLE. O KMS é o serviço gerido da Amazon para armazenar e usar chaves criptográficas — foi concebido para ser um cofre seguro exatamente para este tipo de material sensível. Mas a segurança do KMS depende inteiramente das políticas IAM que controlam quem pode aceder às chaves. Se um atacante tiver credenciais AWS válidas com permissões suficientes, o KMS servir-lhe-á a chave com a mesma boa vontade que serve a aplicação legítima.

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

Toda a fase de movimento lateral — das credenciais vazadas pela IA ao acesso ao KMS — provavelmente levou minutos. Ataques a infraestruturas na nuvem movem-se rapidamente quando o atacante tem credenciais válidas. Não há cadeias de exploits para desenvolver, nenhum zero-day para descobrir. O atacante simplesmente inicia sessão com as chaves roubadas e navega pelo 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 na nuvem, de acordo com todos os principais relatórios de segurança na nuvem das equipas de inteligência de ameaças da AWS, Google Cloud e Microsoft Azure.

Vale a pena pausar para apreciar a ironia. A Resolv armazenou o 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 gestão de chaves mais seguros disponíveis. A segurança do KMS em si nunca esteve em questão. A vulnerabilidade estava no caminho até ao KMS: um agente de IA, a funcionar com permissões excessivas, a processar entradas não confiáveis, conectado ao mesmo ambiente na nuvem onde a chave de assinatura residia. A cadeia era tão forte quanto o 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 a $23M. Cinco passos, menos de 30 minutos, zero explorações de contratos inteligentes.

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

Com a chave SERVICE_ROLE comprometida, o atacante finalmente tocou na blockchain — e o contrato inteligente fez exatamente aquilo para que foi concebido.

Transação 1: O atacante depositou aproximadamente $100.000 em USDC no contrato de cunhagem via requestSwap(), e depois chamou imediatamente completeSwap() com a chave SERVICE_ROLE roubada, autorizando a cunhagem de 50 milhões de USR. Isto é uma sobre-cunhagem 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 havia verificação de proporção para rejeitá-la, nenhum teto máximo para limitá-la, nenhum oráculo para verificar se o montante de cunhagem tinha alguma relação com o depósito.

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

No total: 80 milhões de USR criados contra aproximadamente $200.000 em depósitos reais de USDC. Uma diluição de 400–500x do fornecimento de tokens. Os tokens de cada detentor existente de USR ficaram instantaneamente apoiados por uma fração do que tinham valido minutos antes.

A estratégia de liquidação foi metódica. Em vez de despejar 80M USR diretamente numa única DEX — o que teria acionado disjuntores imediatos e máximo slippage — o atacante primeiro converteu uma porção significativa de USR em wstUSR (wrapped staked USR). Este passo de wrapping serviu um propósito tático: o wstUSR era aceite por pools de liquidez diferentes do USR bruto, permitindo ao atacante aceder a múltiplas plataformas de liquidação simultaneamente e reduzir o impacto no preço em qualquer pool individual.

O atacante distribuiu depois as vendas por três grandes exchanges descentralizadas:

• Curve Finance: A principal plataforma 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 ancoragem.
• KyberSwap: Usada para conversão adicional de USDC/USDT. A KyberSwap bloqueou as carteiras do explorador em poucas horas após o ataque, mas a essa altura o dano já estava feito.
• Velodrome: Visada pela sua liquidez profunda na Optimism, proporcionando 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 reportou que o atacante extraiu cerca de $25 milhões, enquanto o CoinDesk estimou o valor em aproximadamente $23 milhões. A discrepância reflete a dificuldade de rastrear montantes exatos através de múltiplas DEXs e blockchains em tempo real.

A conversão final foi de stablecoins para ETH. O atacante consolidou os ganhos em aproximadamente 11.400 ETH — no valor de cerca de $24 milhões na altura do exploit — e começou a mover fundos através de endereços intermediários. A carteira principal do atacante, 0x8ed8cf0c1c531c1b20848e78f1cb32fa5b99b81c, foi rapidamente sinalizada por empresas de segurança e operadores de DEX.

Toda a fase on-chain — desde a primeira cunhagem até à consolidação final em ETH — levou menos de 30 minutos. Para contextualizar, isso é mais rápido do que a maioria dos signatários multisig conseguem coordenar uma resposta de emergência, mais rápido do que a maioria das equipas de protocolo conseguem sequer confirmar que um exploit está a acontecer, e mais rápido do que qualquer mecanismo de pausa baseado em governança poderia reagir. A vantagem de velocidade pertencia inteiramente ao atacante.

A análise forense on-chain conta a história de um contrato inteligente a fazer exatamente o que lhe foi dito pela chave autorizada. Todas as transações foram válidas. Todas as assinaturas foram legítimas. O contrato não tinha forma de saber — e nenhum mecanismo para verificar — que a chave que assinava estas transações tinha sido roubada do ambiente na nuvem de um agente de IA comprometido. Do ponto de vista da blockchain, isto não foi um hack. Foi uma série de operações perfeitamente autorizadas.

O que as empresas de segurança encontraram

O hack da Resolv desencadeou uma resposta imediata do ecossistema de segurança blockchain. Em poucas horas, múltiplas empresas tinham publicado as suas avaliações iniciais. O que emergiu não foi apenas um post-mortem de um único exploit, mas o reconhecimento de que todo o modelo de ameaça para protocolos DeFi tinha acabado de se expandir.

Cyvers: primeira deteção

A Cyvers, uma plataforma de monitorização de segurança Web3 em tempo real, foi das primeiras a detetar a atividade anómala. Os seus sistemas sinalizaram a criação de 80M de tokens USR como uma anomalia crítica — o volume de cunhagem era ordens de grandeza acima de qualquer execução anterior de completeSwap(). O alerta da Cyvers acionou a investigação da comunidade de segurança mais ampla e ajudou exchanges e DEXs a começar a bloquear os endereços do explorador.

PeckShield: quantificando os danos

A PeckShield, uma das empresas de segurança blockchain mais estabelecidas, estimou o total de USR gerado artificialmente em $80 milhões de valor facial. A sua análise on-chain confirmou o padrão de cunhagem em duas transações e rastreou os fluxos de fundos através de Curve, KyberSwap e Velodrome. O rastreamento em tempo real da PeckShield foi instrumental para ajudar 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 completa sob o título “How One Compromised Key Printed $23 Million.” A sua investigação confirmou o vetor AWS KMS e forneceu a descrição mais clara da cadeia de ataque: injeção de prompts → roubo de credenciais → movimento lateral até ao KMS → comprometimento do SERVICE_ROLE → cunhagem não autorizada.

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

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

Charles Guillemet (Ledger): o aviso estrutural

Talvez a resposta mais significativa não tenha vindo de uma empresa de segurança blockchain, mas de Charles Guillemet, CTO da Ledger, que publicou “Agentic AI Is Loose. Your Security Model Is Not Ready.” 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 a ser implementados na infraestrutura cripto.

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

1. Entrada não confiável: Os agentes de IA processam dados de fontes externas — utilizadores, websites, bases de dados, APIs — qualquer uma das quais pode conter payloads de injeção de prompts.
2. Capacidades de execução poderosas: O MCP e protocolos similares de uso de ferramentas dão aos agentes de IA a capacidade de executar ações reais — consultas a bases de dados, chamadas de API, operações de ficheiros e potencialmente assinatura de transações.
3. Acesso à rede para exfiltração: Os agentes de IA podem comunicar para o exterior — através do seu canal de resposta, através de chamadas de ferramentas, através de logging — o que significa que qualquer informação vazada pode chegar ao atacante.

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 imposta por hardware (como uma carteira hardware Ledger). A IA nunca pode executar autonomamente uma ação de alto valor. Pode apenas recomendar.

A sua conclusão tem um peso particular dada a posição da Ledger como fabricante líder de carteiras hardware: “Se a sua arquitetura não consegue separar claramente o que um agente sugere daquilo que um humano autoriza, então está preparada para 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 prenunciador. Qualquer protocolo que use agentes de IA com privilégios elevados — particularmente aqueles com acesso a chaves de assinatura, credenciais da nuvem ou acesso service_role a bases de dados — deve implementar imediatamente defesas contra injeção de prompts, sanitização de entradas e o princípio do menor privilégio para todos os sistemas conectados a IA.

A blockchain nunca foi o elo fraco

Esta é a parte que deveria inquietar todos os construtores, investidores e investigadores de segurança DeFi. O código do contrato inteligente funcionou perfeitamente. Fez exatamente aquilo para que foi concebido: quando a chave SERVICE_ROLE assinou uma transação completeSwap(), o contrato cunhou 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. Nenhuma colisão de armazenamento. Nenhum overflow de inteiros. Por todas as medidas padrão de segurança de contratos inteligentes, o contrato de cunhagem da Resolv era tecnicamente sólido.

A vulnerabilidade existia inteiramente na pilha de infraestrutura centralizada: agente de IA → MCP → Supabase → AWS IAM → AWS KMS. Todos os componentes desta cadeia são off-chain. Todos são centralizados. Todos são exatamente o tipo de intermediário de confiança que a tecnologia blockchain foi inventada para eliminar.

Isto inverte completamente o modelo tradicional de segurança DeFi. Durante os últimos seis anos, a esmagadora maioria dos exploits DeFi visou a camada blockchain: ataques de reentrância (The DAO, 2016), manipulação de oráculos por flash loans (bZx, 2020; Cream Finance, 2021), ataques de governança (Beanstalk, 2022), vulnerabilidades de pontes (Ronin, Wormhole, Nomad, 2022) e explorações de aprovações de tokens. A resposta padrão a estes ataques tem sido melhores auditorias, verificação formal, bug bounties e monitorização on-chain.

Nenhuma dessas defesas teria prevenido o hack da Resolv. Podia-se ter auditado o contrato de cunhagem cem vezes com as melhores empresas do mundo e não se 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, co-fundador da Herd, resumiu a falha arquitetural: “O contrato de cunhagem não tinha verificações de oráculo nem limites máximos de cunhagem.” Mas mesmo isso subestima o problema. Verificações de oráculo e limites máximos de cunhagem teriam ajudado — teriam limitado o raio de destruição — mas a questão fundamental é que uma única chave controlada por um agente de IA comprometível tinha autoridade de cunhagem ilimitada. A solução não é apenas adicionar verificações on-chain. É repensar toda a relação entre infraestrutura de IA e operações on-chain.

A DeFiPrime chamou-lhe “um caso de confiança excessiva na infraestrutura off-chain” — uma frase que poderia servir de 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 da DeFi são finanças sem confiança, sem permissão, descentralizadas. Nenhum ponto único de falha. Nenhum intermediário de confiança. O código é lei. E, no entanto, a Resolv — um protocolo a gerir centenas de milhões de dólares — tinha a sua função de cunhagem controlada por uma única chave centralizada, gerida por um agente de IA, armazenada na infraestrutura de um fornecedor de nuvem, acessível através de uma cadeia de credenciais que podia ser vazada enganando um chatbot. A blockchain era o componente mais seguro de toda a pilha. Foi a infraestrutura off-chain — a IA, a nuvem, a gestão de chaves — que falhou.

Tabela: Hack DeFi Tradicional vs Hack de Infraestrutura de IA — o exploit da Resolv representa uma mudança de paradigma em onde vivem as vulnerabilidades DeFi.

Para utilizadores que tentam avaliar a sua própria exposição a estes riscos, ferramentas como o CleanSky podem ajudar a monitorizar aprovações de tokens e posições em protocolos — mas a lição mais profunda é que a monitorização on-chain por si só já não é suficiente. A superfície de ataque estende-se agora à infraestrutura na nuvem, agentes de IA e sistemas de gestão de chaves que os protocolos usam nos bastidores. Compreender o risco na DeFi significa agora compreender toda a pilha, não apenas os contratos inteligentes.

Porque é que isto provavelmente não será o último ataque de infraestrutura de IA

Se o hack da Resolv fosse um incidente isolado — uma falha única de um protocolo que tomou decisões arquiteturais excepcionalmente más — seria preocupante mas controlável. O problema é que todas as tendências da indústria apontam para mais agentes de IA, mais conexões MCP, mais operações automatizadas e mais protocolos a cometer exatamente os mesmos erros que a Resolv.

Os agentes de IA já são atacantes capazes

A própria pesquisa da Anthropic, publicada em dezembro de 2025, mostrou que os agentes de IA já conseguiam explorar mais de 50% dos contratos inteligentes vulneráveis do mundo real no benchmark SCONE-bench — um dataset de 405 contratos representando $550M em valor simulado. Esta pesquisa era sobre IA a atacar contratos inteligentes, mas as mesmas capacidades aplicam-se ao inverso: os agentes de IA são suficientemente sofisticados para serem ferramentas valiosas tanto para defensores como para atacantes.

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

Os números estão a acelerar

O relatório anual de 2025 da Hacken documentou um aumento de 1.025% em exploits relacionados com IA comparado com 2024. Isto não é um erro tipográfico — um aumento de dez vezes num único ano. A categoria inclui phishing assistido por IA, descoberta de vulnerabilidades assistida por IA, engenharia social melhorada por deepfake e agora ataques de injeção de prompts a infraestruturas de protocolos. A pesquisa da Cecuro descobriu que agentes de IA de fronteira conseguem executar exploits de ponta a ponta em 72% dos contratos vulneráveis conhecidos, acima dos aproximadamente 20% no início de 2024.

O panorama de segurança cripto de 2025 já era preocupante antes da Resolv: $4,65 mil milhões em perdas totais, o comprometimento do multisig da Bybit, uma vaga de falhas de controlo de acesso. O hack da Resolv adiciona uma nova categoria a uma superfície de ameaça já em expansão.

A adoção do MCP está a acelerar 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 bases de dados (Supabase, PostgreSQL, MongoDB), fornecedores de nuvem (AWS, GCP, Azure), ferramentas de desenvolvimento (GitHub, GitLab, Jira), plataformas de comunicação (Slack, Discord, email) e serviços financeiros (APIs bancárias, processadores de pagamento, nós blockchain). Cada servidor MCP é um potencial alvo de injeção de prompts.

O incidente MCP da Supabase documentado pela PVML foi o tiro de aviso. A própria Supabase publicou “Defense in Depth for MCP” em resposta, recomendando que os servidores MCP nunca usem chaves service_role e em vez disso usem autenticação limitada por utilizador. Mas a adoção destas recomendações tem sido desigual, na melhor das hipóteses. Muitas equipas de protocolos implementaram integrações MCP durante a onda de entusiasmo com IA de 2024–2025 sem implementar controlos de segurança básicos.

O hack da Resolv foi a primeira baixa com dinheiro real. Não será a última. A combinação de expansão da implementação de agentes de IA, aumento da adoção de MCP e os enormes incentivos financeiros para atacantes cria um panorama de ameaças que cresce mais rapidamente do que as defesas estão a ser implementadas. Todos os protocolos que usam agentes de IA para tarefas operacionais — gestão de risco, trading, suporte ao cliente, monitorização, participação em governança — devem considerar o ataque à Resolv como um aviso direto.

O problema estrutural

A questão mais profunda não é uma vulnerabilidade única, mas um desajuste estrutural entre as capacidades da IA e a segurança da IA. Os LLMs são ferramentas extremamente poderosas para processar informação, gerar saídas e interagir com sistemas externos. São também fundamentalmente incapazes de distinguir de forma fiável instruções de confiança de entradas não confiáveis. Isto 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 transformers 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 potencial vetor de injeção de prompts. Cada ferramenta que a IA pode chamar é uma capacidade que o atacante herda. E cada credencial a que a IA pode aceder é uma credencial que o atacante pode roubar. Quanto mais poderosos e conectados se tornam os agentes de IA, mais valiosos se tornam como alvos de ataque. Este é o paradoxo de segurança da IA agêntica: as características que tornam os agentes úteis são as mesmas que os tornam perigosos.

O que os protocolos devem fazer agora

O hack da Resolv fornece um plano claro para as medidas defensivas que todos os protocolos DeFi que usam agentes de IA devem implementar. Estas não são boas práticas opcionais — são requisitos mínimos para qualquer protocolo que não queira ser a próxima manchete de $23M.

1. Separar a assinatura da IA — permanentemente

Esta é a conclusão mais importante. Os agentes de IA nunca devem deter, aceder ou estar no mesmo caminho de credenciais que as chaves de assinatura. A arquitetura “Agentes Propõem, Humanos Assinam” defendida por Guillemet deveria ser o padrão para todos os protocolos. Uma IA pode analisar um pedido de swap pendente e recomendar um montante de cunhagem. Pode preparar os parâmetros da transação. Pode até submeter a transação para uma fila. Mas a assinatura efetiva — a autorização criptográfica que torna a transação executável — deve requerer aprovação humana através de uma fronteira imposta por hardware.

Na prática, isto significa: a conta AWS onde os agentes de IA funcionam deve ter zero acesso à conta AWS (ou HSM, ou multisig) onde as chaves de assinatura residem. Nenhuma função IAM, nenhuma confiança entre contas, nenhuma credencial partilhada. Separação arquitetural completa.

2. Fortalecer cada conexão MCP

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

• Sanitização de entradas: Remover ou escapar potenciais padrões de injeção de prompts de todos os dados antes de chegarem à IA.
• Filtragem de saídas: Monitorizar as saídas da IA para padrões de credenciais (chaves API, tokens, strings de conexão) e bloqueá-los antes de saírem do sistema.
• Acesso baseado em funções: Usar o nível mínimo de privilégio necessário. Nunca conectar uma IA a uma base de dados com acesso service_role. Usar tokens limitados e apenas de 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. Impedir que a IA descubra ou invoque novas ferramentas em tempo de execução.
• Limitação de taxa: Limitar a frequência e volume de chamadas de ferramentas que uma IA pode fazer dentro de uma janela temporal para prevenir exfiltração rápida.

3. Implementar proteções 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 de operações de alto valor deve incluir:

• Tetos máximos de cunhagem: Um limite por transação e por hora na quantidade que pode ser cunhada. Se a Resolv tivesse limitado a cunhagem a, digamos, 2x o valor do depósito, o atacante poderia ter roubado $400K em vez de $23M.
• Verificações de preço por oráculo: Antes de cunhar, verificar a proporção depósito-cunhagem contra um oráculo externo. Se a proporção se desviar além de um limiar, reverter a transação.
• Timelocks: Operações de cunhagem grandes devem requerer um atraso obrigatório (por exemplo, 15 minutos a 24 horas) durante o qual a cunhagem pendente pode ser revista 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 requerer intervenção multisig para retomar.

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

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

5. Fundamentos de segurança na nuvem

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

• IAM com menor privilégio: Credenciais temporárias emitidas para agentes de IA devem ser limitadas às permissões absolutamente mínimas necessárias. Um assistente de IA que consulta tabelas de base de dados não precisa de acesso ao KMS.
• Sem credenciais de longa duração: Os agentes de IA devem usar credenciais de curta duração com rotação automática. Se as credenciais da IA da Resolv tivessem expirado em minutos em vez de permanecerem válidas tempo suficiente para movimento lateral, o ataque teria sido significativamente mais difícil.
• Logging e alertas de acesso ao KMS: Cada acesso a uma chave KMS deve gerar um alerta. Padrões de acesso incomuns (novo IP, nova função, nova hora do dia) devem acionar investigação imediata.
• Segmentação de rede: O ambiente do agente de IA e o ambiente de gestão de chaves devem estar em VPCs (Virtual Private Clouds) separadas sem caminho de rede entre elas.

6. Implementar defesas contra injeção de prompts

Embora nenhuma defesa seja 100% eficaz contra injeção de prompts (continua a ser um problema de investigação em aberto), várias técnicas aumentam significativamente a barreira para atacantes:

• Spotlighting: Uma técnica que marca a fronteira entre instruções de confiança e dados não confiáveis usando delimitadores especiais que a IA é treinada a respeitar. O system prompt instrui explicitamente a IA a tratar conteúdo dentro de delimitadores não confiáveis apenas como dados, nunca como instruções.
• Hierarquia de instruções: Configurar a IA de modo que instruções a nível de sistema sempre sobreponham quaisquer instruções encontradas em entradas de utilizadores ou dados externos. Isto é imperfeito mas aumenta a dificuldade de injeção bem-sucedida.
• Testes adversariais: Testar regularmente as suas integrações de IA com tentativas de injeção de prompts por equipas de red-team. Se a sua equipa de segurança não conseguir extrair credenciais através de injeção de prompts, 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 analisar as saídas do agente principal procurando potenciais vazamentos de credenciais, chamadas de ferramentas anómalas ou sinais de seguimento de instruções de entradas não confiáveis.

7. Monitorizar toda a pilha

A monitorização on-chain é necessária mas já não é suficiente. Os protocolos devem agora monitorizar:

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

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 más decisões arquiteturais. É uma antevisão de uma nova categoria de risco com que toda a indústria cripto deve lidar à medida que a integração de IA se acelera.

Durante a última década, a narrativa de segurança cripto foi dominada por bugs de contratos inteligentes. O hack da DAO em 2016 ensinou-nos sobre reentrância. O congelamento da carteira Parity ensinou-nos sobre contratos de biblioteca. O hack da ponte Wormhole ensinou-nos sobre verificação cross-chain. Cada exploit fez avançar 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 é agora madura, bem financiada e genuinamente eficaz a encontrar vulnerabilidades a nível de código.

Mas o hack da Resolv contornou tudo isso. O atacante não precisou de encontrar um bug no código porque o código era irrelevante. O atacante precisou de encontrar uma forma de obter uma chave de assinatura, e o caminho passou por um chatbot de IA, uma base de dados na nuvem e um serviço de gestão de chaves — tudo off-chain, tudo centralizado, tudo invisível para os sistemas de monitorização on-chain que a indústria gastou mil milhões a construir.

Este não é um problema que melhores auditorias de contratos inteligentes possam resolver. Não é um problema que a verificação formal possa abordar. Requer uma disciplina de segurança inteiramente nova que combine segurança na nuvem, segurança de IA, defesa contra injeção de prompts, boas práticas de gestão de chaves e monitorização DeFi tradicional num framework unificado. Nenhum tal framework existe hoje numa forma padronizada e amplamente adotada. O hack da Resolv é o sinal de alerta.

A indústria enfrenta agora uma escolha. Pode tratar o hack da Resolv como uma anomalia — um erro de uma única equipa, improvável de se repetir — e continuar a implementar agentes de IA com privilégios elevados e controlos 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 a escrever sobre o próximo exploit ao estilo da Resolv antes do fim do ano.

Manter-se seguro em cripto sempre exigiu compreender onde os riscos realmente residem. Depois de 22 de março de 2026, esses riscos incluem os agentes de IA em que os protocolos confiam para gerir a sua infraestrutura.

Leitura relacionada