Permissões de agentes de IA em DeFi: EIP-7702, x402 e blast radius

Dar a um agente de IA (software que decide e executa ações sozinho, sem que um humano aprove cada passo) permissão para assinar transações em DeFi cria um problema que nenhum programa clássico tem: se você entregar a chave da sua wallet, um único prompt malicioso pode esvaziá-la em um bloco, de forma irreversível. Em maio de 2026, a brecha da Bankr comprometeu 14 wallets: alguns usuários relataram perdas de até 150.000 dólares e o montante agregado gira entre 170.000 e 440.000 dólares segundo a fonte, sem um valor oficial da própria Bankr — e as hipóteses dos especialistas não apontam para o modelo de IA, mas para o modelo de permissões: comprometimento de tokens de sessão ou aprovações com alcance sobre muitos usuários. Ao mesmo tempo, o protocolo x402 superou os 100 milhões de transações de pagamento agêntico na rede Base, e o dinheiro migrou de micropagamentos para pagamentos reais: as operações acima de 1 dólar passaram de 49% para 95% do volume. Cada vez mais dinheiro de verdade circula pelas mãos de agentes, justamente quando o raio de dano de uma permissão mal projetada mais importa. Este artigo constrói o framework com data de 6 de julho de 2026: o que é o blast radius (raio de dano), os quatro padrões de arquitetura de permissões, o que mudou com o EIP-7702 e por que o princípio do "privilégio mínimo" é mais difícil de aplicar on-chain do que em qualquer outro software.

O que significa dar permissão de assinatura a um agente de IA e o que é o "blast radius"?

Assinar uma transação em DeFi é uma ordem irrevogável: movimenta fundos, autoriza um smart contract a gastar seus tokens ou cede o controle de uma posição. Quando quem assina é um humano, há um olho revisando a tela antes de clicar. Quando quem assina é um agente autônomo, esse olho desaparece — e o agente pode encadear centenas de assinaturas por segundo sem pedir permissão.

O conceito que organiza todo este debate vem da engenharia de segurança: o blast radius (raio de dano) é o quanto um componente comprometido pode destruir antes que alguém o detenha. No software tradicional, esse raio é limitado por várias barreiras: as permissões do sistema operacional, a possibilidade de desfazer uma operação, a segmentação de rede e um administrador que pode encerrar o processo. On-chain, quase todas essas barreiras desaparecem. Uma assinatura não se desfaz. Não existe um botão de "reverter". E se o agente tiver um allowance (autorização de gasto que você concede a um contrato para movimentar seus tokens) ilimitado, o raio de dano é o saldo total da wallet.

Os vetores que tornam um agente perigoso são três, e nenhum exige quebrar a criptografia. O primeiro é a prompt injection (injeção de instruções: texto malicioso escondido nos dados que o agente lê, que este executa acreditando ser legítimo). O segundo é o tool call malicioso (uma chamada de ferramenta externa manipulada para que o agente assine algo que não deveria). O terceiro é um objetivo mal formulado: se você pedir para "maximizar minha rentabilidade" sem limites, um agente literal pode mover todo o colateral para um protocolo duvidoso. Nos três casos, o problema não é que a IA seja "burra": é que ela tem permissão demais.

Quais são os quatro padrões de permissões para agentes em DeFi?

Nem todos os agentes estão expostos da mesma forma. A diferença está em como a autoridade de assinatura lhes é concedida. Existem quatro padrões, ordenados do mais perigoso ao mais contido:

A maioria dos agentes que operam hoje está entre o padrão naive e uma chave de sessão mal configurada — que na prática é um naive com um disfarce. O intent (intenção) é o salto conceitual importante: o agente deixa de ser um signatário com poderes gerais e passa a ser um solicitante que propõe operações concretas. O isolamento total é o ideal de segurança, mas continua sendo o padrão menos maduro: quanto mais você isola o agente, mais lento e menos útil ele se torna, e aí reside a tensão fundamental de todo o design.

O que o EIP-7702 resolveu e o que continua sem solução?

O EIP-7702 foi ativado na atualização Pectra do Ethereum em maio de 2025 e é a peça técnica que torna viável o padrão de chave de sessão ao nível da conta. Antes, uma EOA (conta externa: a wallet normal, controlada por uma chave privada) só podia fazer uma coisa — assinar. O EIP-7702 permite que essa mesma EOA delegue seu comportamento a um smart contract; a delegação persiste até que o usuário assine uma nova autorização que a revogue — é o contrato delegado (ou a wallet, com um padrão explícito) quem pode limitá-la a uma sessão, não um limite automático por transação. É uma forma de abstração de conta que permite agrupar operações, pagar o gas por outro e, sobretudo, delegar permissões restritas a uma sessão específica.

O que resolve: finalmente podem ser concedidas chaves de sessão nativas — "este agente pode gastar até 500 dólares neste protocolo durante as próximas duas horas, e depois a permissão expira". Isso reduz o raio de dano de forma estrutural em comparação ao padrão naive.

O que não resolve: o EIP-7702 é um mecanismo, não uma política. Ele não decide o que é uma permissão razoável — isso é decidido pelo contrato ao qual você delega. E aí está a nuance incômoda: se você delegar sua EOA a um contrato de delegação malicioso ou com um bug, estará pior do que antes, porque deu a esse código a capacidade de agir como sua conta. A brecha da Bankr em maio de 2026 é o exemplo canônico: a Bankr não publicou um post-mortem oficial, mas as hipóteses dos especialistas — comprometimento de tokens de sessão ou de aprovações com alcance sobre muitos usuários no custodiante — apontam todas para o mesmo lugar: não para a criptografia, mas para permissões que duraram mais do que deveriam. A ferramenta existia; a política, não.

O x402 é o padrão "intent-based" já funcionando em produção?

Durante anos, o padrão intent-based foi sobretudo teoria. Em 2026 deixou de ser, e o melhor exemplo verificável é o x402. O nome vem de um código HTTP esquecido: o 402 Payment Required, um status que a web reservou nos anos noventa e quase nunca usou. O x402 o ressuscita para agentes: o agente solicita um recurso, o servidor responde "402" com instruções de pagamento, o agente paga em stablecoin (quase sempre USDC) e tenta novamente. A chave da segurança está no fato de que o agente não possui autoridade de assinatura geral: ele assina um pagamento pontual contra uma instrução explícita do servidor. Isso é o padrão intent-based em estado puro.

Nessa arquitetura surge um novo ator, o facilitator (facilitador: o intermediário que verifica a solicitação e liquida o pagamento). O agente expressa a intenção, o facilitador a executa contra regras. Ninguém assina em aberto uma autorização que um prompt malicioso possa sequestrar para esvaziar a wallet.

A pergunta natural é "quem controla esse padrão de permissões de pagamento?". A resposta importa: em abril de 2026, a Coinbase transferiu a custódia do x402 para a Linux Foundation, criando a x402 Foundation com mais de 20 membros fundadores, entre eles Coinbase, Cloudflare e Stripe. É um movimento em direção à padronização neutra — o padrão sobre o qual um agente decide como paga deixa de pertencer a uma única empresa.

Os dados de adoção, de um relatório da Chainalysis do início de junho de 2026, mostram por que isso não é mais um experimento:

Essa mudança de 49% para 95% em pagamentos acima de 1 dólar é a parte relevante para o nosso tema: o sistema passou de movimentar centavos para movimentar dinheiro real. E quando o valor sobe, o raio de dano de uma falha de permissões sobe com ele.

O mercado já detectou que o padrão base não é suficiente. Em 20 de maio de 2026, a Fireblocks juntou-se à x402 Foundation e lançou sua Agentic Payments Suite, fornecendo uma camada de "integridade de solicitação e governança de gastos" (request integrity e spend governance) acima do x402. Essa extensão previne ataques de redirecionamento do tipo man-in-the-middle (um intermediário que desvia o pagamento para outro destino) que o padrão base não cobre, e inclui wallets para agentes com limites de gastos, listas de destinatários permitidos, janelas temporais e restrições por ativo. Traduzindo: mesmo o padrão intent-based mais bem projetado precisa de um cinto de segurança adicional de permissões. Ninguém confia no padrão por si só — e esse ceticismo é a lição, não uma nota de rodapé.

Por que o "privilégio mínimo" é mais difícil on-chain do que no software normal?

O princípio do privilégio mínimo diz que cada componente deve ter apenas as permissões necessárias para sua tarefa, nem uma a mais. É um dogma da segurança informática há décadas. On-chain, aplicá-lo é muito mais difícil, e convém entender o porquê:

• Não há como desfazer. Em um sistema tradicional, um administrador reverte uma transação errônea. Uma assinatura em blockchain é final. O erro não é corrigido: ele é pago.
• A composibilidade propaga a permissão. Um allowance concedido a um protocolo pode cascatear para outros contratos que este chama. Você autoriza A, e A invoca B e C. A permissão viaja mais longe do que você imaginava.
• Os allowances persistem. Uma autorização ilimitada assinada há um ano continua viva até que você a revogue manualmente. Milhares de wallets carregam permissões zumbis que foram esquecidas.
• Não há administrador central. Não existe um departamento de TI que coloque em quarentena um agente rebelde. Ferramentas como o Microsoft Agent Governance Toolkit (abril de 2026) ou o trabalho da OWASP sobre riscos de aplicações agênticas governam agentes dentro de uma empresa — mas DeFi é permissionless por design, sem diretório corporativo nem interruptor central.
• A chave é o poder. Possuir a chave equivale à autoridade plena: uma assinatura bruta não possui segundo fator. Não existe um "confirme no celular" que impeça um agente comprometido.

Por isso a identidade de máquina e a rastreabilidade on-chain tornaram-se um campo inteiro: sem um "quem é" e um "o que fez" para cada agente, o privilégio mínimo permanece apenas como uma boa intenção.

Quais incidentes reais mostram cada falha de permissões?

A taxonomia é melhor compreendida com vítimas concretas. Cada um destes casos verificáveis corresponde a uma falha diferente na cadeia de permissões:

O caso dos routers LLM maliciosos — documentado em abril de 2026 por pesquisadores da UC Santa Barbara, UC San Diego e Fuzzland — é o mais instrutivo, porque o ataque não toca na wallet nem no modelo diretamente: ele envenena a camada intermediária que traduz a petição do agente em uma ação. O agente "acredita" que está executando uma operação legítima. É o mesmo padrão de injeção de prompts que já drenou fundos através de protocolos de conexão de ferramentas: a vulnerabilidade não está em quem assina, mas no que lhe dizem para assinar.

Nenhum desses incidentes foi uma falha de criptografia. Todos foram falhas de arquitetura de permissões: um agente com mais autoridade do que precisava, executando uma instrução que não deveria ter aceitado.

Como conectar um agente de IA à sua wallet sem expor tudo?

Se você vai delegar operações DeFi a um agente — próprio ou de um serviço de agentes de trading —, este é o checklist de permissões, ordenado por impacto:

• Nunca entregue a chave privada nem um allowance ilimitado. É o padrão naive, e seu raio de dano é toda a sua wallet. Use uma wallet separada apenas para o que o agente gerencia.
• Exija chaves de sessão com validade. Uma permissão sem data de expiração é uma porta aberta indefinidamente — a falha exata da Bankr. Que expire em horas, não em meses.
• Estabeleça limites de gastos por transação, por protocolo e por dia. Se o agente precisar movimentar mais do que o seu teto, que exija aprovação humana. O custo é a fricção; o benefício é conter o desastre.
• Prefira o padrão intent-based quando disponível. Um agente que assina pagamentos pontuais contra instruções explícitas (o modelo do x402) tem um raio de dano limitado a cada operação, não ao seu saldo total.
• Verifique a camada de intermediação. Se o agente se conecta a ferramentas ou facilitadores externos, verifique quem os opera. Um router ou um servidor malicioso pode injetar instruções — o vetor dos routers LLM.
• Revogue permissões antigas periodicamente. Os allowances persistem. Revise e retire os que você não usa mais antes de conceder novos. Aqui ajuda saber ler as permissões de um protocolo antes de assinar.

Nenhum desses passos exige confiar menos na IA. Exige dar a ela menos poder do que seu instinto o empurra a conceder — o que é, precisamente, a definição prática do privilégio mínimo.

O que fica claro sobre as permissões agênticas em DeFi?

A lição que atravessa todo o framework é que o risco de um agente em DeFi quase nunca reside no modelo de IA. Reside na arquitetura de permissões que o rodeia. A Bankr não caiu por uma IA defeituosa, mas — segundo todas as hipóteses públicas — por permissões de sessão que sobreviveram ao seu propósito; os routers maliciosos não quebraram o modelo, envenenaram o que este lia. O mesmo agente, com o padrão de permissões correto, é uma ferramenta útil; com o padrão naive, é uma bomba-relógio.

A direção do setor é clara e coerente: da custódia total para o intent-based, e daí para camadas de governança de gastos que nem sequer confiam no padrão intent-based por si só — como demonstra o fato de a Fireblocks ter construído controles adicionais sobre o x402. O "fully sandboxed" continua sendo o horizonte aspiracional, mais citado do que implementado, porque sua segurança é paga com autonomia. Escolher onde você se posiciona nesse espectro, para cada real que um agente toca, é a decisão de segurança que define a era agêntica de DeFi. Antes de conectar qualquer agente, convém ter claro qual wallet você usa e o que ela expõe.

Fontes e links: Chainalysis — Inside x402: 100M Agentic Payments on Base · Fireblocks — Agentic Payments Suite · Coinbase — x402 Foundation (Linux Foundation) · Microsoft — Agent Governance Toolkit · CoinDesk — Routers LLM maliciosos