Companheiro Web3: A Carteira Agêntica Segura de Código Aberto

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Permitir que a IA execute transações on-chain para usuários é a tendência mais quente do mundo cripto agora. A Coinbase lançou as Carteiras Agênticas em fevereiro de 2026, e a McKinsey estima que o comércio mediado por Agentes de IA pode chegar a US$ 3–5 trilhões globalmente até 2030. Como o CEO da Coinbase, Brian Armstrong, declarou: Agentes de IA não podem abrir contas bancárias, mas podem ter uma carteira de criptomoedas.

O problema é que permitir que a IA opere ativos on-chain não tem nada a ver 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 esvaziar uma carteira inteira em um único bloco. Sem segurança, nenhuma funcionalidade importa.

A BlockSec tornou open-source o Web3 Companion, uma Carteira Agêntica com foco em segurança. Este artigo percorre o design de segurança por trás dele: por que as arquiteturas atuais de Carteiras Agênticas são fundamentalmente falhas, e como construímos a segurança na arquitetura da carteira desde o início.

Quão Perigosos São os Agentes Atuais: O Incidente OpenClaw

O que acontece quando um Agente de IA não tem fronteiras de segurança? O OpenClaw no início de 2026 responde a essa pergunta.

O OpenClaw é um Agente de IA de propósito geral open-source que acumulou 100.000 estrelas no GitHub em cinco dias. Funcionava bem como um Agente 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 Agente podia ler. Um único e-mail com injeção de prompt era suficiente para obtê-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 o controle total do Agente e de suas chaves por meio de uma página web maliciosa.

O marketplace de Skills era outro ponto fraco. Pesquisadores descobriram que 7,1% das Skills do ClawHub vazavam credenciais, e algumas foram claramente projetadas para esvaziar carteiras de criptomoedas.

A geração de números aleatórios também estava quebrada. O OpenClaw usava math/rand, um PRNG inicializado pelo relógio do sistema, em caminhos críticos de segurança. Pesquisadores demonstraram que dois valores de token consecutivos eram suficientes para reconstruir o estado interno e prever todos os futuros tokens e valores de desafio. Em alguns caminhos de código, isso se estendia até a recuperação de chaves da carteira.

Pior de tudo, não havia camada de política. Nada estava entre uma injeção de prompt e uma transferência de fundos. Zero interceptação.

A lição: arquiteturas de Agentes de IA de propósito geral não são seguras para transações Web3.

A Falha Fundamental nas Arquiteturas Atuais de Agentes de IA

Isso vai além do OpenClaw. Trocar de modelos ou escrever prompts mais rígidos não resolve o problema. As arquiteturas atuais de Agentes de IA 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 do sistema, mensagens de usuários, conteúdo de páginas web, até mesmo o nome de um token chegam como o mesmo fluxo de tokens. O modelo não tem um mecanismo confiável para separar "execute isso" de "apenas leia isso." Três consequências se seguem.

Primeiro, a injeção de prompt é insolúvel na camada do modelo. Atacantes podem esconder instruções em qualquer coisa que o Agente consuma: e-mails, comentários de contratos, páginas web, nomes de tokens. Se o Agente puder 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 Agente pode ser subvertida. Um LLM julgando a segurança de uma transação depende inteiramente do contexto. Envenene o contexto e o veredicto muda. Assinaturas maliciosas passam sem problemas.

Terceiro, Agentes funcionam ininterruptamente, consumindo continuamente entradas não confiáveis e capazes de executar transações de forma autônoma. A janela de ataque nunca se fecha, e uma única 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 a injeção de prompt 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 de arquitetura. Mesmo um modelo totalmente comprometido não deveria ser capaz de mover os fundos dos usuários.

A arquitetura de segurança do Web3 Companion é construída exatamente sobre essa ideia.

Modelo de Ameaças: O Agente Não É Confiável

O modelo de ameaças do Web3 Companion cabe em uma frase: o próprio Agente não é confiável. Toda a arquitetura assume que o Agente pode ser comprometido a qualquer momento.

Não dependemos de tornar o Agente resistente o suficiente para detectar cada ataque. A defesa na camada 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 inocente. Em vez disso, invertemos a suposição. O Agente está dentro do modelo de ameaças, e o restante do sistema é projetado para contê-lo. Mesmo que um atacante controle totalmente o Agente, os ativos do usuário permanecem seguros. Posicionamento em uma linha: A Carteira Agêntica Segura, uma carteira que trata seu próprio Agente 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 Agente jamais deve tocar nas chaves privadas. Chaves privadas são a única credencial que controla ativos on-chain. Se o Agente puder lê-las, um comprometimento significa chaves perdidas. As chaves devem residir onde o Agente arquiteturalmente não possa alcançar.

Princípio 2: Preparação não é autorização. Construir uma transação e aprová-la são dois atos separados. O Agente pode ajudar os usuários a entender o estado on-chain e montar intenções, mas a decisão de assinar pertence a um módulo de backend independente ao qual o Agente não pode acessar.

Princípio 3: Revisão é detecção, não execução. Simulação de transações, análise de calldata e rotulagem de endereços detectam padrões de ataque comuns e ajudam os usuários a entender o risco, mas não são o veredicto final. Simulações podem falhar, rótulos podem estar ausentes, e a própria análise do LLM é vulnerável à injeção de prompt.

Princípio 4: Políticas rígidas são o último recurso. Suponha que um Agente 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 aplicado por código ainda a bloqueia. O Agente não tem permissão para alterar esses limites.

Princípio 5: Sem evidência, sem execução. Uma varredura com falha não é aprovação. Dados ausentes não significam "seguro." Quando evidências de segurança estão ausentes, contraditórias, desatualizadas ou insuficientes, 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 Agente

O primeiro problema é simples. Queremos um assistente que prepare transações on-chain, mas dar a ele capacidade de assinatura entrega o poder de movimentar dinheiro real. Quase toda violação de Agente Web3 em 2025 e 2026 seguiu o mesmo roteiro: chaves privadas viviam dentro do processo do Agente, e os atacantes encontraram uma maneira de extraí-las.

Então reformulamos a pergunta: e se o Agente literalmente não pudesse assinar? Não "é instruído a não assinar," mas arquiteturalmente não pode. Controles de acesso em nível de software sempre podem ser contornados. Precisávamos de algo mais forte.

O Web3 Companion aplica isolamento em nível de processo. Apenas um componente toca nas chaves privadas: o Módulo de Assinatura Segura (SSM), um processo Go independente. A memória do processo do Agente, as variáveis de ambiente e o sistema de arquivos não contêm nenhum material de chave. Tudo que o Agente 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 o armazenamento de chaves, avaliamos três opções. Texto simples no disco: uma leitura do disco expõe a chave imediatamente. Rejeitado. Criptografia derivada de senha: requer nova entrada a cada reinicialização, impraticável para um serviço Docker de longa duração. Rejeitado. Escolhemos criptografia em envelope: cada chave de carteira é criptografada com sua própria chave de dados, e essa chave de dados é envolta 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 existem em texto simples apenas momentaneamente na memória do SSM e são zeradas logo após a assinatura.

Cada solicitação de assinatura percorre o mesmo caminho. Sem atalhos, sem desvios. 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 Agente, avaliação de política, aprovação por 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 de aleatoriedade criptográfica do SO. math/rand é proibido em todo código crítico de segurança, aplicado por testes e CI.

Segurança de Transações: Quatro Camadas de Defesa em Profundidade

O isolamento de chave privada cobre a segurança das chaves, mas os riscos em nível de transação permanecem. Um Agente comprometido pode montar uma intenção de transação com aparência perfeitamente legítima para enganar usuários ou burlar políticas de assinatura automática. A injeção de prompt não precisa da chave privada; ela só precisa fazer o sistema assinar uma transação maliciosa pelo fluxo normal.

A questão central: quando o Agente que prepara as transações pode estar comprometido, como detectar uma transação maliciosa?

Nenhuma camada de defesa isolada resiste por conta própria. Apenas simulação? Simulações falham, RPCs ficam indisponíveis, novos ataques ficam fora dos padrões conhecidos. Apenas revisão baseada em LLM? A mesma injeção que comprometeu o Agente compromete o revisor, já que ambos rodam em LLMs. Apenas um limite rígido fixo? Usuários legítimos batem em uma parede; um limite de US$ 100 em cada swap é inutilizável.

Combinamos todas as quatro camadas. Cada camada assume que todas as anteriores já falharam.

Camada 1: Simulação de Transação. Antes de assinar, o sistema simula a execução: decodificação de calldata, previsão de reversão, verificações de formato de campo. A simulação detecta problemas óbvios, mas tem pontos cegos. Novas técnicas de ataque e falhas de RPC podem derrotá-la.

Camada 2: Avaliação da Contraparte. Uma bateria de verificações estáticas tem como alvo a contraparte: correspondência de destinatário/valor, detecção de aprovação ilimitada, detecção de endereço de queima, chamadas de delegação inesperadas. A pontuação de risco de endereço é executada pelo serviço de conformidade x402 da BlockSec, onde o Agente 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 a decisões finais.

Camada 3: Aplicação de Política Rígida. Aplicação pura em código Go. O LLM não está envolvido, e o Agente 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 imediatamente. Alterar a própria política requer Passkey. Por quê? Se o Agente pudesse editar políticas, uma injeção elevaria o limite primeiro e depois esvaziaria 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 por ativá-la.

Isso significa que mesmo que todas as camadas de detecção sejam contornadas e um Agente totalmente comprometido assine uma transação maliciosa, a perda real é limitada pela política. Se o usuário definir o limite diário de assinatura automática como US$ 500, a perda máxima é de 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 reconhecimento facial). Nenhum exploit puramente de software pode falsificar isso.

As quatro camadas operam com desconfiança mútua. Cada uma assume que tudo antes dela já falhou. Uma simulação perfeita não relaxa a política. Uma política mal configurada não pula o Passkey. Cada camada se sustenta por conta própria.

Um detalhe fácil de ignorar: reutilização de veredicto. Uma técnica conhecida de ataque DeFi reproduz um veredicto 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 veredicto de segurança se aplica apenas à intenção exata que foi revisada. Se o Agente reconstruir uma transação, mesmo apenas alterando o valor ou o destinatário, o sistema a trata como uma nova intenção e reexecuta todas as verificações.

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:

Segurança por Design: A Filosofia por Trás do Open Source

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 está integrada na arquitetura desde o início sempre chega tarde demais.

Agentes de IA estão se tornando uma nova porta de entrada para transações on-chain. O espaço avança rapidamente, mas os padrões de segurança mal existem. A maioria das equipes foca no que seu Agente pode fazer. Poucos perguntaram seriamente: se este Agente for comprometido, a arquitetura consegue 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 Carteira Agêntica. O código é totalmente aberto sob a licença MIT (atualmente rotulado como prévia de pesquisa). O setor precisa agora de um ponto de referência concreto em design de segurança. 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 lançando o design completo para que a comunidade possa construir sobre ele.