GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
Permitir que a IA execute transações on-chain para os usuários é a tendência mais quente no mundo cripto neste momento. A Coinbase lançou Agentic Wallets em fevereiro de 2026, e a McKinsey estima que o comércio mediado por AI Agent pode atingir US$ 3 a 5 trilhões globalmente até 2030. Como o CEO da Coinbase, Brian Armstrong, afirmou: agentes de IA não podem abrir contas bancárias, mas podem possuir uma carteira cripto.
O problema é que permitir que a IA opere ativos on-chain não é nada parecido com deixá-la gerenciar calendários ou e-mails. Transações on-chain são irreversíveis. Sem reembolsos, sem estornos. Uma única assinatura maliciosa pode drenar uma carteira inteira em um bloco. Sem segurança, nenhuma funcionalidade importa.
A BlockSec disponibilizou em código aberto o Web3 Companion, uma Agentic Wallet com segurança em primeiro lugar. Este artigo percorre o design de segurança por trás dele: por que as arquiteturas atuais de Agentic Wallet são fundamentalmente falhas, e como construímos a segurança na arquitetura da carteira desde o zero.
Quão Perigosos São os Agentes Atuais: O Incidente OpenClaw
O que acontece quando um AI Agent não tem limites de segurança? O OpenClaw no início de 2026 responde essa pergunta.
OpenClaw é um AI Agent de propósito geral de código aberto que acumulou 100.000 estrelas no GitHub em cinco dias. Funcionava bem como um Agent de propósito geral, mas no momento em que tocou em transações Web3, todas as falhas de segurança apareceram.
Chaves privadas ficavam em texto simples em arquivos locais que o Agent podia ler. Um único e-mail com prompt injection era suficiente para capturá-las.
A assinatura não tinha isolamento. O mesmo processo que buscava páginas web não confiáveis também podia assinar transações, então uma única vulnerabilidade RCE permitia que um atacante assumisse controle total do Agent e suas chaves por meio de uma página web maliciosa.
O marketplace de Skills era outro ponto fraco. Pesquisadores descobriram que 7,1% dos Skills no ClawHub vazavam credenciais, e alguns eram projetados deliberadamente para drenar carteiras cripto.
A geração de números aleatórios também estava quebrada. O OpenClaw usava math/rand, um PRNG semeado pelo relógio do sistema, em caminhos críticos de segurança. Pesquisadores mostraram que dois valores de token consecutivos eram suficientes para reconstruir o estado interno e prever todos os futuros valores de token e desafio. Em alguns caminhos de código, isso se estendia até a recuperação de chaves da carteira.
O pior de tudo: não havia camada de políticas. Nada se interpunha entre um prompt injection e uma transferência de fundos. Zero interceptação.
A conclusão: arquiteturas de AI Agent de propósito geral não são seguras para transações Web3.
A Falha Fundamental nas Arquiteturas Atuais de AI Agent
Isso vai além do OpenClaw. Trocar modelos ou escrever prompts mais rigorosos não resolve o problema. As arquiteturas atuais de AI Agent carregam uma falha de segurança inerente: o próprio LLM é uma superfície de ataque permanentemente exposta.
A causa raiz: LLMs não conseguem distinguir instruções de dados. Prompts de sistema, mensagens do usuário, conteúdo de páginas web, até o nome de um token — tudo chega como o mesmo fluxo de tokens. O modelo não possui mecanismo confiável para separar “execute isto” de “apenas leia isto”. Três consequências se seguem.
Primeiro, prompt injection é insolúvel na camada do modelo. Atacantes podem esconder instruções em qualquer coisa que o Agent ingere: e-mails, comentários de contratos, páginas web, nomes de tokens. Se o Agent pode assinar transações, uma injeção bem-sucedida transforma uma brincadeira em roubo.
Segundo, a própria revisão de segurança baseada em Skills do Agent pode ser subvertida. Um LLM julgando a segurança de uma transação depende inteiramente do contexto. Envenene o contexto e o veredito se inverte. Assinaturas maliciosas passam direto.
Terceiro, Agents operam ininterruptamente, consumindo continuamente entradas não confiáveis e sendo capazes de executar transações de forma autônoma. A janela de ataque nunca se fecha, e uma violação pode significar perda imediata de fundos.
A comunidade de segurança concorda amplamente: dar a um LLM acesso direto a chaves privadas, em um mundo onde prompt injection não tem cura, equivale a deixar os ativos dos usuários dentro de um componente que pode ser comprometido a qualquer momento. Como a camada do modelo não pode ser endurecida, o risco deve ser contido na camada da arquitetura. Mesmo um modelo totalmente comprometido não deve ser capaz de movimentar fundos dos usuários.
A arquitetura de segurança do Web3 Companion é construída exatamente sobre essa ideia.
Modelo de Ameaças: O Agent Não É Confiável
O modelo de ameaças do Web3 Companion cabe em uma frase: o próprio Agent não é confiável. Toda a arquitetura assume que o Agent pode ser comprometido a qualquer momento.
Não dependemos de tornar o Agent robusto o suficiente para detectar todos os ataques. Defesa no nível do modelo não funciona, como mostrado acima. Treine-o para detectar injeções em código Morse hoje; amanhã os atacantes mudam para Base64, texto esteganográfico em imagens ou um PDF de aparência inofensiva. Em vez disso, invertemos a premissa. O Agent está dentro do modelo de ameaças, e o restante do sistema é projetado para contê-lo. Mesmo que um atacante controle totalmente o Agent, os ativos dos usuários permanecem seguros. Posicionamento em uma linha: A Carteira Agentic Segura, uma carteira que trata seu próprio Agent como não confiável por padrão e permanece segura independentemente.
A partir desse modelo de ameaças, derivamos cinco princípios de design.
Princípio 1: O Agent nunca deve tocar nas chaves privadas. Chaves privadas são a única credencial que controla ativos on-chain. Se o Agent pode lê-las, um comprometimento significa chaves perdidas. As chaves devem residir onde o Agent arquiteturalmente não pode alcançar.
Princípio 2: Preparação não é autorização. Construir uma transação e aprová-la são dois atos separados. O Agent pode ajudar os usuários a entender o estado on-chain e montar intenções, mas a decisão de assinatura pertence a um módulo backend independente que o Agent não pode acessar.
Princípio 3: Revisão é detecção, não imposição. Simulação de transações, análise de calldata e rotulagem de endereços capturam padrões de ataque comuns e ajudam os usuários a entender riscos, mas não são o veredito final. Simulações podem falhar, rótulos podem estar ausentes, e a própria análise do LLM é vulnerável a prompt injection.
Princípio 4: Políticas rígidas são a última linha de defesa. Suponha que um Agent seja enganado para iniciar uma transferência de US$ 100.000 e a revisão de segurança seja manipulada para aprová-la. Um limite diário de US$ 1.000 imposto por código ainda a bloqueia. O Agent não tem permissão para alterar esses limites.
Princípio 5: Sem evidência, sem execução. Uma verificação que falhou não é uma aprovação. Dados ausentes não significam “seguro”. Quando a evidência de segurança está ausente, contraditória, desatualizada ou insuficiente, o sistema para e aguarda confirmação explícita do usuário.
Esses cinco princípios são implementados por meio de dois módulos de segurança: segurança de chave privada e segurança de transação.
Isolamento de Chave Privada: Arquiteturalmente Inacessível pelo Agent
O primeiro problema é simples. Queremos um assistente que prepare transações on-chain, mas dar a ele a capacidade de assinatura entrega o poder de movimentar dinheiro real. Praticamente todas as violações de AI Agent Web3 em 2025 e 2026 seguiram o mesmo roteiro: chaves privadas residiam dentro do processo do Agent, e os atacantes encontraram uma forma de extraí-las.
Então reformulamos a pergunta: e se o Agent literalmente não puder assinar? Não “é instruído a não assinar”, mas arquiteturalmente não pode. Controles de acesso no nível de software sempre podem ser contornados. Precisávamos de algo mais forte.
O Web3 Companion impõe isolamento no nível de processo. Apenas um componente toca nas chaves privadas: o Secure Signature Module (SSM), um processo Go independente. A memória do processo do Agent, variáveis de ambiente e sistema de arquivos não contêm nenhum material de chave. Tudo o que o Agent vê é um ID de intenção de transação. Ele pode pedir ao SSM para assinar essa intenção, mas nunca pode ver a chave por trás dela.
Para armazenamento de chaves, avaliamos três opções. Texto simples em disco: uma leitura de disco expõe a chave imediatamente. Rejeitado. Criptografia derivada de senha: requer reentrada a cada reinicialização, impraticável para um serviço Docker de longa execução. Rejeitado. Escolhemos criptografia por envelope: cada chave de carteira é criptografada com sua própria chave de dados, e essa chave de dados é envolvida por uma chave mestra (AWS KMS ou AES-256 local). Mesmo que os arquivos criptografados sejam exfiltrados por completo, são inúteis sem a chave mestra. As chaves só existem em texto simples momentaneamente na memória do SSM e são zeradas logo após a assinatura.
Cada solicitação de assinatura segue o mesmo caminho. Sem atalhos, sem via rápida. Uma transação passa por sete etapas em ordem: verificação de delegação, simulação, verificação de segurança, revisão de segurança do Agent, avaliação de política, aprovação Passkey e, finalmente, assinatura pelo SSM. Completar uma etapa nunca pula a próxima.
Um detalhe de baixo nível que vale mencionar: cada byte aleatório no sistema (geração de chave privada, nonces AES-GCM, tokens de autenticação, desafios WebAuthn) vem de crypto/rand, a fonte criptográfica aleatória do sistema operacional. math/rand é proibido em todo código crítico de segurança, imposto por testes e CI.
Segurança de Transação: Quatro Camadas de Defesa em Profundidade
O isolamento de chave privada cobre a segurança da chave, mas riscos no nível de transação permanecem. Um Agent comprometido pode montar uma intenção de transação de aparência perfeitamente legítima para enganar usuários ou burlar políticas de assinatura automática. Prompt injection não precisa da chave privada; precisa apenas fazer o sistema assinar uma transação maliciosa através do fluxo normal.
A questão central: quando o Agent que prepara transações pode estar comprometido, como detectar uma transação maliciosa?
Nenhuma camada de defesa única se sustenta sozinha. Simulação sozinha? Simulações falham, RPCs caem, ataques novos fogem dos padrões conhecidos. Revisão baseada em LLM sozinha? A mesma injeção que comprometeu o Agent compromete o revisor, já que ambos rodam em LLMs. Um limite rígido fixo sozinho? Usuários legítimos batem na parede; um teto de US$ 100 em cada swap é inutilizável.
Empilhamos todas as quatro camadas juntas. Cada camada assume que todas as camadas anteriores já caíram.
Camada 1: Simulação de Transação. Antes da assinatura, o sistema simula a execução: decodificação de calldata, previsão de revert, verificações de formato de campos. A simulação detecta problemas óbvios, mas tem pontos cegos. Novas técnicas de ataque e quedas de RPC podem derrotá-la.
Camada 2: Avaliação de Contraparte. Uma bateria de verificações estáticas visa a contraparte: correspondência de destinatário/valor, detecção de aprovação ilimitada, detecção de endereço de queima, chamadas delegate inesperadas. A pontuação de risco de endereço passa pelo serviço de conformidade x402 da BlockSec, onde o Agent consulta rótulos e pontuações de risco via micropagamentos x402 sem necessidade de chave de API ou assinatura. As camadas 1 e 2 juntas detectam a maioria dos problemas comuns, mas ambas podem ser contornadas. Seu papel é deliberadamente limitado a detecção e explicação, não decisões finais.
Camada 3: Imposição de Políticas Rígidas. Imposição pura por código em Go. O LLM não está envolvido, e o Agent não pode modificar as regras. Limites por transação, orçamentos diários, listas brancas de destinatários, limiares de assinatura automática: uma transferência de US$ 5.000 contra um limite de US$ 100 por transação é rejeitada na hora. Alterar a própria política requer Passkey. Por quê? Se o Agent pudesse editar políticas, uma injeção elevaria o limite primeiro e depois drenaria a carteira. A assinatura automática está desativada por padrão; cada transação requer aprovação manual até que o usuário opte explicitamente.
Isso significa que, mesmo que cada camada de detecção seja contornada e um Agent totalmente comprometido assine uma transação maliciosa, a perda real é limitada pela política. Se o usuário define o limiar diário de assinatura automática em US$ 500, a pior perda possível é US$ 500, não a carteira inteira. A camada de política transforma um comprometimento de um evento catastrófico em uma perda limitada.
Camada 4: Confirmação do Usuário (Passkey). Quando a política exige aprovação manual, o sistema requer verificação WebAuthn (impressão digital ou rosto). Nenhum exploit puramente de software pode forjar isso.
As quatro camadas operam sob desconfiança mútua. Cada uma assume que tudo antes dela já falhou. Simulação perfeita não relaxa a política. Política mal configurada não pula Passkey. Cada camada se sustenta sozinha.
Um detalhe fácil de perder: reutilização de veredito. Uma técnica de ataque conhecida em DeFi replays um veredito de segurança antigo contra uma transação modificada. O Web3 Companion vincula cada operação de escrita a uma intenção de transação única com transições de estado auditáveis. Um veredito de segurança se aplica apenas à intenção exata que ele revisou. Se o Agent reconstrói uma transação, mesmo que apenas alterando o valor ou destinatário, o sistema a trata como uma intenção totalmente nova e executa todas as verificações novamente.
As quatro camadas de defesa mapeiam para três fronteiras de confiança independentes: Chave Privada, Política e Passkey. Qualquer violação de uma única fronteira deixa as outras duas intactas:
| Fronteira violada | Proteção restante |
|---|---|
| Agent (prompt injection, RCE) | Sem chaves = sem assinatura; política bloqueia excesso de limite; Passkey bloqueia operações não aprovadas |
| Revisão de segurança (veredito envenenado) | Política ainda impõe limites; operações com aprovação manual ainda precisam de Passkey |
| Política (erro de configuração do usuário) | Operações com aprovação manual ainda requerem verificação biométrica |
| Tudo exceto Passkey | Credenciais são vinculadas ao hardware; atacante precisa da presença física do usuário |
Segurança por Design: A Filosofia por Trás do Código Aberto
A BlockSec trabalha com segurança on-chain desde o primeiro dia. Protegemos bilhões de dólares em ativos on-chain e vimos a mesma lição se repetir: segurança que não é incorporada na arquitetura desde o início sempre chega tarde demais.
AI Agents estão se tornando uma nova porta de entrada para transações on-chain. O espaço se move rápido, mas padrões de segurança mal existem. A maioria das equipes se concentra no que seu Agent pode fazer. Poucas perguntaram seriamente: se esse Agent for comprometido, a arquitetura pode limitar o raio de explosão?
O Web3 Companion é o esforço da BlockSec para canalizar anos de trabalho em segurança on-chain em uma arquitetura de Agentic Wallet. O código é totalmente aberto sob a licença MIT (atualmente rotulado como preview de pesquisa). A indústria precisa de um ponto de referência concreto de design de segurança agora. Como estruturar modelos de ameaças, como isolar chaves, até onde levar a defesa de transações: nenhuma equipe deveria ter que reinventar isso do zero. Estamos publicando o design completo para que a comunidade possa construir sobre ele.