GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
AIがユーザーに代わってオンチェーントランザクションを実行するというのは、今まさに暗号資産界で最も注目されているトレンドだ。Coinbaseは2026年2月にAgentic Walletsをローンチし、マッキンゼーの試算によれば、AIエージェントが仲介する商取引は2030年までに世界全体で3〜5兆ドル規模に達する可能性があるという。Coinbase CEOのBrian Armstrongが述べたように、AIエージェントは銀行口座を開設できないが、暗号資産ウォレットなら持てる。
問題は、AIにオンチェーン資産を操作させることが、カレンダーやメールを管理させることとは根本的に異なるという点だ。オンチェーントランザクションは不可逆だ。返金もチャージバックもない。悪意ある署名が一つあれば、ウォレット全体が1ブロックで空になる。セキュリティなくして、いかなる機能も意味をなさない。
BlockSecは、セキュリティを最優先に設計したAgentic WalletであるWeb3 Companionをオープンソースとして公開した。本記事では、その背後にあるセキュリティ設計を解説する。現在のAgentic Walletのアーキテクチャが根本的に欠陥を抱えている理由と、ウォレットのアーキテクチャにセキュリティをゼロから組み込んだ方法について説明する。
現在のエージェントはどれほど危険か：OpenClawインシデント
AIエージェントにセキュリティの境界がなければ何が起きるか？2026年初頭のOpenClawがその答えを示している。
OpenClawは、5日間でGitHubスター数が10万を突破したオープンソースの汎用AIエージェントだ。汎用エージェントとしては十分に機能していたが、Web3トランザクションに触れた瞬間、あらゆるセキュリティ上の欠陥が露わになった。
秘密鍵はエージェントが読み取れるローカルファイルにプレーンテキストで保存されていた。それを奪うには、プロンプトインジェクションメール一通で十分だった。
署名には隔離がなかった。信頼されていないウェブページを取得するプロセスとトランザクションに署名するプロセスが同一だったため、RCEの脆弱性一つで攻撃者は悪意あるウェブページを通じてエージェントと鍵の両方を完全に掌握できた。
Skillsマーケットプレイスも弱点だった。研究者たちはClawHub Skillsの7.1%が認証情報を漏洩させており、一部は暗号資産ウォレットを空にすることを意図して設計されていたことを発見した。
乱数生成も壊れていた。OpenClawはセキュリティ上重要なパスでシステムクロックをシードとした疑似乱数生成器（PRNG）であるmath/randを使用していた。研究者たちは、連続する2つのトークン値があれば内部状態を復元でき、以降のすべてのトークンおよびチャレンジ値を予測できることを示した。一部のコードパスでは、これがウォレット鍵の復元にまで及んだ。
最悪だったのは、ポリシー層が存在しなかったことだ。プロンプトインジェクションと資金移動の間には何も存在しなかった。遮断機能はゼロだった。
教訓：汎用AIエージェントのアーキテクチャはWeb3トランザクションには安全でない。
現在のAIエージェントアーキテクチャの根本的な欠陥
これはOpenClawに限った話ではない。モデルを切り替えたり、プロンプトをより厳格にしたりしても問題は解決しない。現在のAIエージェントアーキテクチャには本質的なセキュリティ上の欠陥がある。LLM自体が常に露出した攻撃対象領域なのだ。
根本原因：LLMは命令とデータを区別できない。システムプロンプト、ユーザーメッセージ、ウェブページのコンテンツ、トークンの名前でさえ、すべて同じトークンストリームとして届く。モデルは「これを実行せよ」と「ただ読め」を確実に分離するメカニズムを持たない。そこから三つの帰結が生じる。
第一に、プロンプトインジェクションはモデル層では解決不可能だ。攻撃者はエージェントが取り込むあらゆるものに命令を隠せる。メール、コントラクトのコメント、ウェブページ、トークン名。エージェントがトランザクションに署名できるなら、インジェクションが一つ成功するだけでいたずらが窃盗に変わる。
第二に、エージェント自身のSkillsベースのセキュリティレビューも覆される可能性がある。トランザクションの安全性を判断するLLMは完全にコンテキストに依存している。コンテキストを汚染すれば判断が逆転する。悪意ある署名が素通りになる。
第三に、エージェントは24時間365日稼働し、継続的に信頼されていない入力を消費しながら自律的にトランザクションを実行できる。攻撃ウィンドウは決して閉じず、一度の侵害が即座に資金損失につながりうる。
セキュリティコミュニティの広い合意は次の通りだ。プロンプトインジェクションに治療法がない世界で、LLMに秘密鍵への直接アクセスを与えることは、いつでも乗っ取られうるコンポーネントの中にユーザー資産を置き去りにすることに等しい。モデル層を堅牢化することはできないため、リスクはアーキテクチャ層で封じ込めなければならない。モデルが完全に侵害されたとしても、ユーザーの資金を動かせてはならない。
Web3 Companionのセキュリティアーキテクチャはまさにこの考えに基づいて構築されている。
脅威モデル：エージェントは信頼されない
Web3 Companinoの脅威モデルは一文で表せる。エージェント自体は信頼されない。アーキテクチャ全体は、エージェントがいつでも侵害されうるという前提の上に成り立っている。
私たちはエージェントをあらゆる攻撃を見抜けるほど堅牢にすることには頼らない。上述の通り、モデル層の防御は機能しない。今日モールスコードによるインジェクションを捕捉できるよう訓練しても、明日の攻撃者はBase64、画像内のステガノグラフィーテキスト、または一見無害なPDFに切り替える。代わりに私たちは前提を逆転させた。エージェントは脅威モデルの内側に位置し、システムの残りの部分はそれを封じ込めるよう設計されている。攻撃者がエージェントを完全に支配したとしても、ユーザーの資産は安全に保たれる。一行で表すなら：The Secure Agentic Wallet——自身のエージェントをデフォルトで信頼せず、いかなる状況においても安全を維持するウォレット。
この脅威モデルから、五つの設計原則を導出した。
原則1：エージェントは秘密鍵に触れてはならない。 秘密鍵はオンチェーン資産を制御する唯一の認証情報だ。エージェントがそれを読み取れるなら、侵害は鍵の喪失を意味する。鍵はエージェントがアーキテクチャ上到達できない場所に存在しなければならない。
原則2：準備は承認ではない。 トランザクションを構築することと承認することは別の行為だ。エージェントはユーザーがオンチェーンの状態を理解し、インテントを組み立てる支援ができるが、署名の決定はエージェントがアクセスできない独立したバックエンドモジュールに属する。
原則3：レビューは検出であり、強制ではない。 トランザクションシミュレーション、calldataの分析、アドレスのラベリングは一般的な攻撃パターンを検出しユーザーがリスクを理解するのに役立つが、最終的な判断ではない。シミュレーションは失敗することがあり、ラベルが存在しないこともあり、LLM自身の分析もプロンプトインジェクションの影響を受けうる。
原則4：ハードポリシーが最後の砦だ。 エージェントが10万ドルの送金を開始するよう騙され、セキュリティレビューがそれを承認するよう操作されたとしよう。コードで強制された1日あたり1,000ドルの上限がそれでもブロックする。エージェントにはこの上限を変更する権限がない。
原則5：証拠なし、実行なし。 スキャンの失敗はパスではない。データが欠如していることは「安全」ではない。セキュリティ証拠が存在しない、矛盾している、古い、または不十分な場合、システムは停止してユーザーの明示的な確認を待つ。
この五つの原則は、秘密鍵セキュリティとトランザクションセキュリティという二つのセキュリティモジュールを通じて実装される。
秘密鍵の隔離：エージェントからアーキテクチャ上到達不可能に
最初の問題はシンプルだ。オンチェーントランザクションを準備するアシスタントが欲しいが、署名能力を与えると本物の資金を動かす力を渡してしまう。2025年と2026年のWeb3エージェント侵害のほぼすべてが同じ手口をたどった。秘密鍵がエージェントプロセス内に存在し、攻撃者がそれを抽出する方法を見つけた。
そこで私たちは問いを立て直した。エージェントが文字どおり署名できないとしたら？「するなと言われている」のではなく、アーキテクチャ上できない状態に。ソフトウェアレベルのアクセス制御は常にバイパスされうる。より強固なものが必要だった。
Web3 Companinoはプロセスレベルの隔離を強制する。秘密鍵に触れるコンポーネントはただ一つ、スタンドアロンのGoプロセスであるSecure Signature Module（SSM）だ。エージェントのプロセスメモリ、環境変数、ファイルシステムには鍵素材が一切存在しない。エージェントが知るのはトランザクションインテントIDだけだ。エージェントはSSMにそのインテントへの署名を要求できるが、その背後にある鍵を見ることは決してできない。
鍵のストレージについては三つの選択肢を評価した。ディスク上のプレーンテキスト：ディスクの読み取りで即座に鍵が露出する。却下。パスワード由来の暗号化：再起動のたびに再入力が必要で、長時間稼働するDockerサービスには非実用的。却下。私たちが選んだのはエンベロープ暗号化だ。各ウォレット鍵はそれぞれのデータキーで暗号化され、そのデータキーはマスターキー（AWS KMSまたはローカルAES-256）でラップされる。暗号化されたファイルが丸ごと持ち出されたとしても、マスターキーなしでは無意味だ。鍵はSSMのメモリ内でのみ一時的にプレーンテキストとして存在し、署名直後にゼロクリアされる。
すべての署名リクエストは同じ経路をたどる。近道も例外もない。トランザクションは順番に七つのステップを経る。委任チェック、シミュレーション、セキュリティチェック、エージェントセキュリティレビュー、ポリシー評価、Passkey承認、そして最後にSSM署名。一つのステップを完了しても、次のステップがスキップされることはない。
一つ言及に値する低レベルの詳細がある。システム内のすべてのランダムバイト（秘密鍵生成、AES-GCMノンス、認証トークン、WebAuthnチャレンジ）はOSの暗号学的ランダムソースであるcrypto/randから生成される。math/randはセキュリティ上重要なすべてのコードで禁止されており、テストとCIによって強制されている。
トランザクションセキュリティ：四層の多層防御
秘密鍵の隔離は鍵のセキュリティをカバーするが、トランザクションレベルのリスクは依然として残る。侵害されたエージェントは、ユーザーを欺いたり自動署名ポリシーを悪用したりするために、完全に正当に見えるトランザクションインテントを組み立てることができる。プロンプトインジェクションは秘密鍵を必要としない。通常のフローを通じて悪意あるトランザクションに署名させるだけでいい。
核心的な問いはこうだ。トランザクションを準備するエージェント自体が侵害されているかもしれない場合、悪意あるトランザクションをどうやって検出するか？
単一の防御層では持ちこたえられない。シミュレーションだけ？シミュレーションは失敗し、RPCはダウンし、新しい攻撃手法は既知のパターンの外にある。LLMベースのレビューだけ？エージェントを侵害したのと同じインジェクションがレビュワーも侵害する。両者ともLLM上で動作するからだ。フラットなハード上限だけ？正当なユーザーが壁にぶつかる。すべてのスワップに100ドルの上限では使い物にならない。
私たちは四つすべてを重ねる。各層は、自分より前のすべての層がすでに崩壊していると仮定する。
第1層：トランザクションシミュレーション。 署名前にシステムが実行をシミュレートする。calldataのデコード、リバート予測、フィールドフォーマットチェック。シミュレーションは明らかな問題を検出するが盲点がある。新しい攻撃手法とRPCの障害はどちらもそれを無効化しうる。
第2層：取引相手評価。 一連の静的チェックが取引相手を対象とする。受取人/金額の照合、無制限承認の検出、バーンアドレスの検出、予期しないデリゲートコールの検出。アドレスリスクスコアリングはBlockSecのx402 コンプライアンスサービスを通じて実行され、エージェントはAPIキーやサブスクリプション不要でx402マイクロペイントを通じてラベルとリスクスコアを照会する。第1層と第2層を合わせて一般的な問題の大半を検出できるが、どちらもバイパスされうる。その役割は意図的に検出と説明に限定されており、最終決定ではない。
第3層：ハードポリシー強制。 GoによるピュアなコードE強制。LLMは関与せず、エージェントはルールを変更できない。トランザクションごとの上限、日次予算、受取人ホワイトリスト、自動署名閾値：1トランザクションあたり100ドルの上限に対して5,000ドルの送金はその場で却下される。ポリシー自体の変更にはPasskeyが必要だ。なぜか？エージェントがポリシーを編集できれば、インジェクション一つでまず上限を引き上げ、その後ウォレットを空にできてしまう。自動署名はデフォルトでオフになっており、ユーザーが明示的にオプトインするまですべてのトランザクションに手動承認が必要だ。
これが意味するのは、すべての検出層がバイパスされ、完全に侵害されたエージェントが悪意あるトランザクションに署名したとしても、実際の損失はポリシーによって上限が設けられているということだ。ユーザーが日次自動署名閾値を500ドルに設定していれば、最悪ケースの損失はウォレット全体ではなく500ドルだ。ポリシー層は侵害を壊滅的なイベントから有界の損失へと変える。
第4層：ユーザー確認（Passkey）。 ポリシーが手動承認を要求する場合、システムはWebAuthn認証（指紋または顔認証）を必要とする。ソフトウェアのみのエクスプロイトではこれを偽造できない。
四つの層は相互不信のもとで動作する。各層はその前のすべてがすでに失敗していると仮定する。完璧なシミュレーションがあってもポリシーは緩まない。ポリシーの設定ミスがあってもPasskeyはスキップされない。各層は独立して成立する。
見落とされがちな詳細が一つある。判断の再利用だ。既知のDeFi攻撃手法は変更されたトランザクションに対して古いセキュリティ判断を再生する。Web3 Companinoは各書き込み操作を監査可能な状態遷移を持つ固有のトランザクションインテントに紐付ける。セキュリティ判断はレビューした正確なインテントにのみ適用される。エージェントがトランザクションを再構築した場合、金額や受取人を変えるだけでも、システムはそれをまったく新しいインテントとして扱い、すべてのチェックを再実行する。
四つの防御層は三つの独立した信頼境界にマッピングされる。秘密鍵、ポリシー、Passkeyだ。単一の境界が突破されても、他の二つは成立している。
| 突破された境界 | 残存する保護 |
|---|---|
| エージェント（プロンプトインジェクション、RCE） | 鍵なし＝署名不可；ポリシーが上限超えをブロック；Passkeyが未承認操作をブロック |
| セキュリティレビュー（判断が汚染された） | ポリシーが依然として上限を強制；手動承認操作は依然としてPasskeyが必要 |
| ポリシー（ユーザーの設定ミス） | 手動承認操作は依然として生体認証が必要 |
| Passkey以外のすべて | 認証情報はハードウェアにバインドされており、攻撃者にはユーザーが物理的に存在する必要がある |
設計によるセキュリティ：オープンソースの背後にある哲学
BlockSecは創業当初からオンチェーンセキュリティに取り組んできた。私たちは何十億ドルものオンチェーン資産を保護し、同じ教訓が繰り返されるのを目にしてきた。アーキテクチャに最初から組み込まれていないセキュリティは、常に遅すぎる形でやってくる。
AIエージェントはオンチェーントランザクションへの新しい玄関口になりつつある。この分野の動きは速いが、セキュリティ標準はほとんど存在しない。ほとんどのチームは自分たちのエージェントが何をできるかに焦点を当てている。このエージェントが乗っ取られた場合、アーキテクチャは被害範囲を限定できるかと真剣に問いかけたチームは少ない。
Web3 Companinoは、BlockSecが長年のオンチェーンセキュリティの取り組みをAgentic Walletアーキテクチャに結集させた成果物だ。コードはMITライセンスのもとで完全にオープンになっている（現在はリサーチプレビューとして表示）。業界には今すぐ具体的なセキュリティ設計の参照点が必要だ。脅威モデルの構造化方法、鍵の隔離方法、トランザクション防御をどこまで推し進めるか——これらをゼロから再発明しなければならないチームがあってはならない。私たちはコミュニティがその上に構築できるよう、完全な設計を公開する。
