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

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Permitir que IAs executem transações on-chain em nome dos usuários é a tendência mais quente do mundo cripto atualmente. A Coinbase lançou as Agentic Wallets 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 disse o CEO da Coinbase, Brian Armstrong: nas próprias palavras dele: Agentes de IA não podem abrir contas bancárias, mas podem ter uma carteira cripto.

O problema é que deixar uma IA operar 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 Agentic Wallet com foco em segurança. Este artigo apresenta o design de segurança por trás dele: por que as arquiteturas atuais de Agentic Wallets 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 caso OpenClaw no início de 2026 responde a essa pergunta.

O OpenClaw é um Agente de IA de propósito geral e código aberto 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 vieram à tona.

As chaves privadas ficavam em texto simples em arquivos locais que o Agente podia ler. Um único e-mail com injeção de prompt foi 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 controle total do Agente e de suas chaves por meio de uma página maliciosa.

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

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 mostraram que dois valores de token consecutivos eram suficientes para reconstruir o estado interno e prever todos os tokens e valores de desafio futuros. Em alguns caminhos de código, isso se estendia até a recuperação de chaves de carteira.

O pior de tudo: não havia camada de políticas. Nada havia entre uma injeção de prompt e uma transferência de fundos. Zero interceptação.

A conclusã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 modelo ou escrever prompts mais rigorosos 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 de sistema, mensagens do usuário, conteúdo de páginas web, até mesmo o nome de um token — tudo chega 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 seguem.

Primeiro, a injeção de prompt é insolúvel na camada do modelo. Atacantes podem ocultar instruções em qualquer coisa que o Agente consuma: e-mails, comentários de contratos, páginas web, nomes de tokens. Se o Agente pode assinar transações, uma única injeção bem-sucedida transforma uma brincadeira em roubo.

Segundo, a revisão de segurança baseada em Skills do próprio Agente pode ser subvertida. Um LLM avaliando 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 24 horas por dia, consumindo continuamente entradas não confiáveis e capazes de executar transações de forma autônoma. A janela de ataque nunca 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, num 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 fortalecida, o risco deve ser contido na camada de arquitetura. Mesmo um modelo completamente comprometido não deve ser capaz de mover os fundos do usuário.

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 robusto o suficiente para detectar cada ataque. A defesa na camada do modelo não funciona, como demonstrado acima. Treine-o para capturar 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 o pressuposto. O Agente fica dentro do modelo de ameaças, e o restante do sistema é projetado para contê-lo. Mesmo que um atacante controle completamente o Agente, os ativos do usuário permanecem seguros. Posicionamento em uma linha: The Secure Agentic Wallet, uma carteira que trata seu próprio Agente como não confiável por padrão e permanece segura independentemente das circunstâncias.

A partir desse modelo de ameaças, derivamos cinco princípios de design.

Princípio 1: O Agente jamais deve tocar nas chaves privadas. As chaves privadas são a única credencial que controla os 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 assinatura 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ção, 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 a 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 verificação com falha 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 chaves privadas e segurança de transações.

Isolamento de Chaves Privadas: Arquiteturalmente Inacessível ao Agente

O primeiro problema é simples. Queremos um assistente que prepare transações on-chain, mas dar-lhe capacidade de assinatura entrega o poder de mover dinheiro real. Quase todas as violações de Agentes Web3 em 2025 e 2026 seguiram o mesmo padrão: as chaves privadas viviam dentro do processo do Agente, e os atacantes encontravam uma forma de extraí-las.

Então reformulamos a questão: e se o Agente literalmente não puder assinar? Não "recebeu instrução para 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 robusto.

O Web3 Companion aplica isolamento em nível de processo. Apenas um componente toca as chaves privadas: o Secure Signature Module (SSM), um processo Go independente. A memória de processo do Agente, as variáveis de ambiente e o sistema de arquivos não contêm nenhum material de chave. Tudo o que o Agente vê é um ID de intenção de transação. Ele pode solicitar ao SSM que assine 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 reinserção a cada reinicialização, impraticável para um serviço Docker de longa duração. Rejeitado. Escolhemos a criptografia de envelope: cada chave de carteira é criptografada com sua própria chave de dados, e essa chave de dados é encapsulada 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 percorre o mesmo caminho. Sem atalhos, sem acesso privilegiado. 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íticas, 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 chaves privadas, nonces AES-GCM, tokens de autenticação, desafios WebAuthn) vem de crypto/rand, a fonte aleatória criptográfica do sistema operacional. math/rand é proibido em todos os códigos críticos de segurança, aplicado por testes e CI.

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

O isolamento de chaves privadas cobre a segurança das chaves, mas os riscos no nível de transação permanecem. Um Agente 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. A injeção de prompt não precisa da chave privada; ela só precisa fazer o sistema assinar uma transação maliciosa por meio do fluxo normal.

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

Nenhuma camada de defesa única se sustenta sozinha. Apenas simulação? Simulações falham, RPCs caem, 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 ficam bloqueados; um limite de US$ 100 em cada swap é inutilizável.

Combinamos todas as quatro camadas. Cada camada assume que todas as camadas 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 quedas 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 destruição, chamadas de delegação inesperadas. A pontuação de risco de endereços é 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 à detecção e explicação, não a decisões finais.

Camada 3: Aplicação de Políticas Rígidas. Aplicação puramente 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, limites 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 única 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 completamente 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 em US$ 500, a perda máxima é de US$ 500, não a carteira inteira. A camada de políticas transforma um comprometimento de um evento catastrófico em uma perda delimitada.

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 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 de ataque DeFi conhecida reutiliza 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 ele revisou. Se o Agente reconstruir uma transação, mesmo que 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 se mapeiam em 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: a segurança que não é incorporada à 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 se move 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 esse 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 para uma arquitetura de Agentic Wallet. 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 de 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 tudo isso do zero. Estamos lançando o design completo para que a comunidade possa construir sobre ele.