Web3 Companion: The Open-Source Secure Agentic Wallet

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Letting AI execute on-chain transactions for users is the hottest trend in crypto right now. Coinbase launched Agentic Wallets in February 2026, and McKinsey estimates AI Agent-mediated commerce could reach $3–5 trillion globally by 2030. As Coinbase CEO Brian Armstrong put it: AI Agents can't open bank accounts, but they can own a crypto wallet.

The problem is that letting AI operate on-chain assets is nothing like letting it manage calendars or emails. On-chain transactions are irreversible. No refunds, no chargebacks. A single malicious signature can drain an entire wallet in one block. Without security, no feature matters.

BlockSec has open-sourced Web3 Companion, a security-first Agentic Wallet. This article walks through the security design behind it: why current Agentic Wallet architectures are fundamentally broken, and how we built security into the wallet architecture from the ground up.

How Dangerous Are Current Agents: The OpenClaw Incident

What happens when an AI Agent has no security boundaries? OpenClaw in early 2026 answers that question.

OpenClaw is an open-source general-purpose AI Agent that picked up 100,000 GitHub stars in five days. It worked well as a general-purpose Agent, but the moment it touched Web3 transactions, every security gap showed up.

Private keys sat in plaintext in local files the Agent could read. One prompt-injection email was all it took to grab them.

Signing had no isolation. The same process that fetched untrusted web pages could also sign transactions, so a single RCE vulnerability let an attacker take full control of both the Agent and its keys through a malicious webpage.

The Skills marketplace was another weak spot. Researchers found 7.1% of ClawHub Skills leaked credentials, and some were outright designed to drain crypto wallets.

Random number generation was broken too. OpenClaw used math/rand, a PRNG seeded by the system clock, on security-critical paths. Researchers showed that two consecutive token values were enough to reconstruct the internal state and predict every future token and challenge value. In some code paths, this extended all the way to wallet key recovery.

Worst of all, there was no policy layer. Nothing stood between a prompt injection and a fund transfer. Zero interception.

The takeaway: general-purpose AI Agent architectures are not safe for Web3 transactions.

The Fundamental Flaw in Current AI Agent Architectures

This goes beyond OpenClaw. Switching models or writing stricter prompts does not fix the problem. Current AI Agent architectures carry an inherent security flaw: the LLM itself is a permanently exposed attack surface.

The root cause: LLMs cannot tell instructions apart from data. System prompts, user messages, web page content, even a token's name all arrive as the same token stream. The model has no reliable mechanism to separate "execute this" from "just read this." Three consequences follow.

First, prompt injection is unsolvable at the model layer. Attackers can hide instructions in anything the Agent ingests: emails, contract comments, web pages, token names. If the Agent can sign transactions, one successful injection turns a prank into theft.

Second, the Agent's own Skills-based security review can be subverted. An LLM judging transaction safety relies entirely on context. Poison the context and the verdict flips. Malicious signatures sail through.

Third, Agents run around the clock, continuously consuming untrusted input and capable of executing transactions autonomously. The attack window never closes, and one breach can mean immediate fund loss.

The security community broadly agrees: giving an LLM direct access to private keys, in a world where prompt injection has no cure, amounts to leaving user assets inside a component that could be owned at any moment. Since the model layer cannot be hardened, risk must be contained at the architecture layer. Even a fully compromised model should not be able to move user funds.

Web3 Companion's security architecture is built on exactly this idea.

Threat Model: The Agent Is Untrusted

Web3 Companion's threat model fits in one sentence: the Agent itself is untrusted. The entire architecture assumes the Agent can be compromised at any time.

We do not rely on making the Agent tough enough to spot every attack. Model-level defense does not work, as shown above. Train it to catch Morse-code injections today; tomorrow attackers switch to Base64, steganographic text in images, or a benign-looking PDF. Instead, we flipped the assumption. The Agent sits inside the threat model, and the rest of the system is designed to contain it. Even if an attacker fully controls the Agent, user assets stay safe. One-line positioning: The Secure Agentic Wallet, a wallet that treats its own Agent as untrusted by default and remains secure regardless.

From this threat model we derived five design principles.

Principle 1: The Agent must never touch private keys. Private keys are the sole credential controlling on-chain assets. If the Agent can read them, a compromise means lost keys. Keys must live where the Agent architecturally cannot reach.

Principle 2: Preparation is not authorization. Building a transaction and approving it are two separate acts. The Agent can help users understand on-chain state and assemble intents, but the signing decision belongs to an independent backend module the Agent cannot access.

Principle 3: Review is detection, not enforcement. Transaction simulation, calldata analysis, and address labeling catch common attack patterns and help users understand risk, but they are not the final verdict. Simulations can fail, labels can be missing, and the LLM's own analysis is itself vulnerable to prompt injection.

Principle 4: Hard policies are the backstop. Suppose an Agent is tricked into initiating a $100,000 transfer and the security review is manipulated into approving it. A code-enforced daily limit of $1,000 still blocks it. The Agent has no permission to change these limits.

Principle 5: No evidence, no execution. A failed scan is not a pass. Missing data is not "safe." When security evidence is absent, contradictory, stale, or insufficient, the system halts and waits for explicit user confirmation.

These five principles are implemented through two security modules: private key security and transaction security.

Private Key Isolation: Architecturally Unreachable by the Agent

The first problem is simple. We want an assistant that prepares on-chain transactions, but giving it signing ability hands over the power to move real money. Nearly every Web3 Agent breach in 2025 and 2026 followed the same playbook: private keys lived inside the Agent process, and attackers found a way to extract them.

So we reframed the question: what if the Agent literally cannot sign? Not "is told not to," but architecturally cannot. Software-level access controls can always be bypassed. We needed something stronger.

Web3 Companion enforces process-level isolation. Only one component touches private keys: the Secure Signature Module (SSM), a standalone Go process. The Agent's process memory, environment variables, and filesystem hold zero key material. All the Agent ever sees is a transaction intent ID. It can ask SSM to sign that intent, but it can never see the key behind it.

For key storage, we evaluated three options. Plaintext on disk: a disk read exposes the key immediately. Rejected. Password-derived encryption: requires re-entry on every restart, impractical for a long-running Docker service. Rejected. We chose envelope encryption: each wallet key is encrypted with its own data key, and that data key is wrapped by a master key (AWS KMS or local AES-256). Even if the encrypted files are exfiltrated wholesale, they are useless without the master key. Keys only exist in plaintext momentarily inside SSM memory and are zeroed right after signing.

Every signing request walks the same path. No fast lane, no shortcut. A transaction passes through seven steps in order: delegation check, simulation, security check, Agent security review, policy evaluation, Passkey approval, and finally SSM signing. Completing one step never skips the next.

One low-level detail worth mentioning: every random byte in the system (private key generation, AES-GCM nonces, auth tokens, WebAuthn challenges) comes from crypto/rand, the OS cryptographic random source. math/rand is banned in all security-critical code, enforced by tests and CI.

Transaction Security: Four Layers of Defense in Depth

Private key isolation covers key security, but transaction-level risks remain. A compromised Agent can assemble a perfectly legitimate-looking transaction intent to fool users or game auto-signing policies. Prompt injection does not need the private key; it just needs to get the system to sign a malicious transaction through the normal flow.

The core question: when the Agent that prepares transactions might itself be compromised, how do you catch a malicious transaction?

No single defense layer holds up on its own. Simulation alone? Simulations fail, RPCs go down, novel attacks fall outside known patterns. LLM-based review alone? The same injection that compromised the Agent compromises the reviewer, since both run on LLMs. A flat hard limit alone? Legitimate users hit a wall; a $100 cap on every swap is unusable.

We layer all four together. Each layer assumes every layer before it has already fallen.

Layer 1: Transaction Simulation. Before signing, the system simulates execution: calldata decoding, revert prediction, field format checks. Simulation catches obvious issues but has blind spots. New attack techniques and RPC outages can both defeat it.

Layer 2: Counterparty Assessment. A battery of static checks targets the counterparty: recipient/amount matching, unlimited-approval detection, burn-address detection, unexpected delegate calls. Address risk scoring runs through BlockSec's x402 compliance service, where the Agent queries labels and risk scores via x402 micropayments with no API key or subscription required. Layers 1 and 2 together catch most common problems, but both can be bypassed. Their role is deliberately scoped to detection and explanation, not final decisions.

Layer 3: Hard Policy Enforcement. Pure code enforcement in Go. The LLM is not involved, and the Agent cannot modify the rules. Per-transaction caps, daily budgets, recipient whitelists, auto-signing thresholds: a $5,000 transfer against a $100 per-transaction limit is rejected on the spot. Changing the policy itself requires Passkey. Why? If the Agent could edit policies, one injection would raise the cap first, then drain the wallet. Auto-signing is off by default; every transaction requires manual approval until the user explicitly opts in.

This means that even if every detection layer is bypassed and a fully compromised Agent signs a malicious transaction, the actual loss is capped by policy. If the user sets the daily auto-signing threshold to $500, the worst-case loss is $500, not the entire wallet. The policy layer turns a compromise from a catastrophic event into a bounded loss.

Layer 4: User Confirmation (Passkey). When policy demands manual approval, the system requires WebAuthn verification (fingerprint or face). No software-only exploit can forge this.

The four layers operate on mutual distrust. Each one assumes everything before it has already failed. Perfect simulation does not relax policy. Misconfigured policy does not skip Passkey. Every layer stands on its own.

One detail that is easy to miss: verdict reuse. A known DeFi attack technique replays an old security verdict against a modified transaction. Web3 Companion binds each write operation to a unique transaction intent with auditable state transitions. A security verdict applies only to the exact intent it reviewed. If the Agent rebuilds a transaction, even just changing the amount or recipient, the system treats it as a brand-new intent and reruns all checks.

The four defense layers map onto three independent trust boundaries: Private Key, Policy, and Passkey. Any single boundary breach leaves the other two standing:

Security by Design: The Philosophy Behind Open Source

BlockSec has worked on on-chain security since day one. We have protected billions of dollars in on-chain assets and seen the same lesson repeat: security that is not baked into the architecture from the start always arrives too late.

AI Agents are becoming a new front door to on-chain transactions. The space moves fast, but security standards barely exist. Most teams focus on what their Agent can do. Few have seriously asked: if this Agent gets owned, can the architecture limit the blast radius?

Web3 Companion is BlockSec's effort to channel years of on-chain security work into an Agentic Wallet architecture. The code is fully open under the MIT license (currently labeled research preview). The industry needs a concrete security design reference point now. How to structure threat models, how to isolate keys, how far to push transaction defense: no team should have to reinvent these from zero. We are releasing the full design so the community can build on it.