GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
AIがユーザーに代わってオンチェーントランザクションを実行することは、現在クリプト業界で最もホットなトレンドです。Coinbaseは2026年2月にAgentic Walletsをローンチし、マッキンゼーの試算によるとAIエージェントが仲介するコマースは2030年までに世界全体で3〜5兆ドルに達する可能性があります。Coinbase CEOのブライアン・アームストロングが述べたように：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は完全にコンテキストに依存しています。コンテキストを汚染すれば判断が覆ります。悪意ある署名が素通りします。
第三に、エージェントは常時稼働し、信頼されていない入力を継続的に消費し、自律的にトランザクションを実行できます。攻撃ウィンドウは決して閉じず、一度の侵害で即座に資金を失う可能性があります。
セキュリティコミュニティで広く認識されていること：プロンプトインジェクションに解決策がない世界において、LLMに秘密鍵への直接アクセスを与えることは、ユーザー資産をいつでも乗っ取られる可能性があるコンポーネント内に残すことと同義です。モデル層は強化できないため、リスクはアーキテクチャ層で封じ込める必要があります。完全に侵害されたモデルでさえ、ユーザーの資金を動かすことができないようにすべきです。
Web3 Companionのセキュリティアーキテクチャはまさにこの考えに基づいて構築されています。
脅威モデル：エージェントは信頼されない
Web3 Companinoの脅威モデルは一文で表せます：エージェント自体は信頼されない。アーキテクチャ全体が、エージェントはいつでも侵害される可能性があるという前提に基づいています。
私たちは、エージェントをあらゆる攻撃を見抜けるほど強固にすることに依存しません。上述の通り、モデルレベルの防御は機能しません。今日モールスコードインジェクションを検出するよう訓練しても、明日には攻撃者はBase64、画像内のステガノグラフィックテキスト、あるいは無害に見えるPDFに切り替えます。代わりに、私たちは前提を逆転させました。エージェントは脅威モデルの内側に位置し、システムの残りの部分はそれを封じ込めるよう設計されています。攻撃者がエージェントを完全に制御したとしても、ユーザーの資産は安全に保たれます。一行での位置づけ：セキュアなAgentic Wallet、デフォルトで自身のエージェントを信頼せず、いかなる状況でも安全を保つウォレット。
この脅威モデルから、5つの設計原則を導き出しました。
原則1：エージェントは秘密鍵に触れてはならない。 秘密鍵はオンチェーン資産を制御する唯一の認証情報です。エージェントがそれを読み取れる場合、侵害は鍵の喪失を意味します。鍵は、エージェントがアーキテクチャ上到達できない場所に存在しなければなりません。
原則2：準備は認可ではない。 トランザクションを構築することと承認することは二つの別個の行為です。エージェントはユーザーがオンチェーンの状態を理解し、インテントを組み立てる手助けができますが、署名の決定はエージェントがアクセスできない独立したバックエンドモジュールに属します。
原則3：レビューは検出であり、執行ではない。 トランザクションシミュレーション、コールデータ分析、アドレスラベリングは一般的な攻撃パターンを検出し、ユーザーがリスクを理解するのに役立ちますが、最終的な判断ではありません。シミュレーションは失敗することがあり、ラベルが欠けていることもあり、LLM自身の分析もプロンプトインジェクションに対して脆弱です。
原則4：ハードポリシーは最後の砦である。 エージェントが10万ドルの送金を開始するよう騙され、セキュリティレビューが承認するよう操作されたとします。コードで強制された1日あたり1,000ドルの上限はそれでもブロックします。エージェントにはこれらの上限を変更する権限がありません。
原則5：証拠がなければ実行しない。 スキャン失敗はパスではありません。データが欠けていることは「安全」ではありません。セキュリティの証拠が欠如しているか、矛盾しているか、古いか、または不十分な場合、システムは停止し、明示的なユーザー確認を待ちます。
この5つの原則は、秘密鍵セキュリティとトランザクションセキュリティという2つのセキュリティモジュールを通じて実装されています。
秘密鍵の分離：エージェントがアーキテクチャ上到達できない
最初の問題はシンプルです。オンチェーントランザクションを準備するアシスタントが欲しいが、署名能力を与えることは実際のお金を動かす力を渡すことになります。2025年と2026年のほぼすべてのWeb3エージェント侵害は同じ手口に従っていました：秘密鍵がエージェントプロセス内に存在し、攻撃者がそれを抽出する方法を見つけました。
そこで問いを立て直しました：エージェントが文字通り署名できないとしたら？「するよう言われていない」ではなく、アーキテクチャ上できない。ソフトウェアレベルのアクセス制御は常にバイパスされる可能性があります。より強固なものが必要でした。
Web3 Companinoはプロセスレベルの分離を強制します。秘密鍵に触れるコンポーネントは一つだけです：Secure Signature Module（SSM）、独立したGoプロセスです。エージェントのプロセスメモリ、環境変数、ファイルシステムには鍵の素材は一切含まれません。エージェントが見るのはトランザクションインテントIDだけです。そのインテントに署名するようSSMに依頼できますが、その背後にある鍵を見ることは決してできません。
鍵の保存については、3つのオプションを評価しました。ディスク上のプレーンテキスト：ディスクの読み取り一つで鍵が即座に露出します。却下。パスワード派生暗号化：再起動のたびに再入力が必要で、長時間稼働するDockerサービスには実用的ではありません。却下。私たちはエンベロープ暗号化を選択しました：各ウォレット鍵は専用のデータキーで暗号化され、そのデータキーはマスターキー（AWS KMSまたはローカルAES-256）でラップされます。暗号化されたファイルが丸ごと持ち出されても、マスターキーなしには無用です。鍵はSSMメモリ内で一瞬だけプレーンテキストとして存在し、署名直後にゼロ化されます。
すべての署名リクエストは同じパスを通ります。ファストレーンも近道もありません。トランザクションは順番に7つのステップを経ます：委任チェック、シミュレーション、セキュリティチェック、エージェントセキュリティレビュー、ポリシー評価、Passkey承認、最後にSSM署名。一つのステップを完了しても次のステップはスキップされません。
言及する価値のある低レベルの詳細：システム内のすべてのランダムバイト（秘密鍵生成、AES-GCMノンス、認証トークン、WebAuthnチャレンジ）はOSの暗号学的乱数ソースであるcrypto/randから来ます。math/randはすべてのセキュリティクリティカルなコードで禁止されており、テストとCIによって強制されています。
トランザクションセキュリティ：4層の多重防御
秘密鍵の分離は鍵のセキュリティをカバーしますが、トランザクションレベルのリスクは残ります。侵害されたエージェントは、ユーザーを欺いたり自動署名ポリシーを騙したりするために、完全に正当に見えるトランザクションインテントを組み立てることができます。プロンプトインジェクションは秘密鍵を必要とせず、通常のフローを通じて悪意あるトランザクションに署名させるだけで十分です。
核心的な問いは：トランザクションを準備するエージェント自体が侵害されている可能性がある場合、悪意あるトランザクションをどのように検出するか？
どの単一の防御層も単独では持ちこたえられません。シミュレーションだけ？シミュレーションは失敗し、RPCがダウンし、新しい攻撃は既知のパターンの範囲外です。LLMベースのレビューだけ？エージェントを侵害した同じインジェクションがレビュアーも侵害します。両方ともLLMで動作しているからです。単純なハード上限だけ？正当なユーザーが壁にぶつかります。すべてのスワップに100ドルの上限は使えません。
4つをすべて重ねます。各層は、前のすべての層がすでに崩壊していると仮定します。
第1層：トランザクションシミュレーション。 署名前に、システムは実行をシミュレートします：コールデータのデコード、リバート予測、フィールドフォーマットチェック。シミュレーションは明らかな問題を検出しますが、盲点があります。新しい攻撃技術とRPCの停止はどちらもこれを無力化できます。
第2層：取引相手の評価。 静的チェックのバッテリーが取引相手を対象とします：受取人/金額の照合、無制限承認の検出、バーンアドレスの検出、予期しないデリゲートコール。アドレスリスクスコアリングはBlockSecのx402 コンプライアンスサービスを通じて実行され、エージェントはAPIキーやサブスクリプション不要でx402マイクロペイメントを介してラベルとリスクスコアを照会します。第1層と第2層を合わせると最も一般的な問題を検出できますが、どちらもバイパスされる可能性があります。その役割は意図的に検出と説明に限定されており、最終的な決定ではありません。
第3層：ハードポリシーの執行。 GoによるピュアコードでのEnforcement。LLMは関与せず、エージェントはルールを変更できません。トランザクションごとの上限、1日の予算、受取人ホワイトリスト、自動署名しきい値：1トランザクションあたり100ドルの上限に対して5,000ドルの送金はその場で拒否されます。ポリシー自体の変更はPasskeyが必要です。なぜか？エージェントがポリシーを編集できれば、一度のインジェクションでまず上限を引き上げ、次にウォレットを空にできます。自動署名はデフォルトでオフです。ユーザーが明示的にオプトインするまで、すべてのトランザクションには手動承認が必要です。
これはつまり、すべての検出層がバイパスされ、完全に侵害されたエージェントが悪意あるトランザクションに署名したとしても、実際の損失はポリシーによって制限されることを意味します。ユーザーが1日の自動署名しきい値を500ドルに設定していれば、最悪の損失はウォレット全体ではなく500ドルです。ポリシー層は、侵害を壊滅的なイベントから限定的な損失に変えます。
第4層：ユーザー確認（Passkey）。 ポリシーが手動承認を要求する場合、システムはWebAuthn検証（指紋または顔認証）を要求します。ソフトウェアのみの攻撃はこれを偽造できません。
4つの層は相互不信の上で動作します。各層は前のすべてがすでに失敗していると仮定します。完璧なシミュレーションがポリシーを緩めることはありません。誤設定されたポリシーがPasskeyをスキップすることはありません。各層は独立して機能します。
見落とされやすい詳細：判定の再利用。既知のDeFi攻撃手法は、変更されたトランザクションに対して古いセキュリティ判定を再利用します。Web3 Companinoは各書き込み操作を、監査可能な状態遷移を持つ一意のトランザクションインテントに紐付けます。セキュリティ判定は、レビューした正確なインテントにのみ適用されます。エージェントがトランザクションを再構築した場合、金額や受取人を変えるだけでも、システムはそれをまったく新しいインテントとして扱い、すべてのチェックを再実行します。
4つの防御層は、3つの独立した信頼境界に対応しています：秘密鍵、ポリシー、Passkey。いずれか一つの境界が侵害されても、他の2つは維持されます：
| 侵害された境界 | 残る保護 |
|---|---|
| エージェント（プロンプトインジェクション、RCE） | 鍵なし = 署名なし；ポリシーが上限超過をブロック；Passskeyが未承認の操作をブロック |
| セキュリティレビュー（判定が汚染される） | ポリシーは引き続き上限を強制；手動承認の操作には引き続きPasskeyが必要 |
| ポリシー（ユーザーの誤設定） | 手動承認の操作には引き続き生体認証が必要 |
| Passkey以外のすべて | 認証情報はハードウェアにバインドされている；攻撃者にはユーザーの物理的な存在が必要 |
設計によるセキュリティ：オープンソースの背後にある哲学
BlockSecは最初からオンチェーンセキュリティに取り組んできました。数十億ドルのオンチェーン資産を保護し、同じ教訓を繰り返し目にしてきました：最初からアーキテクチャに組み込まれていないセキュリティは、常に手遅れになります。
AIエージェントはオンチェーントランザクションへの新しい入口になりつつあります。この分野は急速に進化していますが、セキュリティ基準はほとんど存在しません。ほとんどのチームはエージェントに何ができるかに焦点を当てています。このエージェントが乗っ取られた場合、アーキテクチャが被害範囲を限定できるか？を真剣に問うチームはほとんどありません。
Web3 Companinoは、BlockSecが長年のオンチェーンセキュリティの取り組みをAgentic Walletアーキテクチャに注ぎ込む試みです。コードはMITライセンスの下で完全にオープンです（現在はリサーチプレビューとしてラベル付けされています）。業界には今すぐ具体的なセキュリティ設計のリファレンスポイントが必要です。脅威モデルの構造化方法、鍵の分離方法、トランザクション防御をどこまで推進するか：どのチームもこれらをゼロから再発明する必要はありません。コミュニティが上に構築できるよう、完全な設計を公開しています。
