信頼できないAIエージェントの構築：ERC-8004セキュリティ監査ガイドライン

ERC-8004（トラストレスエージェント）標準規格がイーサリアムメインネットに正式導入されたことで、AIエージェントのアイデンティティとレピュテーション管理は、検証可能かつトラストレスな新たな段階に入りました。この標準規格は、アイデンティティレジストリ、レピュテーションレジストリ、検証レジストリという3つのコアレジストリを通じて、エージェントにオンチェーン上で検証可能な「アイデンティティシステム」を提供します。本稿では、ERC-8004の技術的詳細を踏まえつつ、セキュリティ監査の観点から各レジストリの主要なリスクを分析し、開発者と監査担当者に実践的な監査ガイドを提供します。

技術的な詳細と監査のポイント

ERC-8004 の鍵は、次の 3 つのレジストリエントリにあります。

1. アイデンティティレジストリ

URIStorage 拡張機能を備えた ERC-721 に基づく最小限のオンチェーンハンドルは、エージェントの登録ファイルに解決され、各エージェントに移植可能で検閲に耐性のある識別子を提供します。

ERC-8004アーキテクチャでは、アイデンティティレジストリはERC-721上に構築され、URIStorage機能を拡張します。つまり、各エージェントはチェーン上の固有のNFTに対応しており、このNFTはAgentIDと呼ばれます。

開発者がエージェントを作成する際、レジストリコントラクトの`register`関数を呼び出して新しいAgentIDを生成します。このトークンは、オフチェーンに保存されたJSONファイル（いわゆる「エージェント登録ファイル」）を指す`tokenURI`にバインドされます。登録ファイルは厳格な仕様に準拠する必要があり、通常、以下の3つのコア要素が含まれます。

- 名前、説明、アバター URL などの基本情報。

- プロキシがアクセスできるネットワークアドレスであるサーバーエンドポイントは、HTTP、WebSocket、Libp2p、A2A、MCP などの複数のプロトコルをサポートします。

- 機能宣言。これは、イメージ生成、裁定取引、コード監査など、エージェントが実行できるタスクのリストです。

自己宣言だけでは信頼を確立するには明らかに不十分であるため、ERC-8004ではドメイン検証メカニズムが導入されています。エージェントは、宣言したドメインの下、パス/.well-known/agent-card.jsonに署名ファイルをホストする必要があります。オンチェーンレジストリはこのリンクを検証し、オンチェーンのAgentIDを対応するDNSドメインにバインドします。このステップは、フィッシングやなりすまし攻撃を防ぐために非常に重要です。エージェントはドメインの所有権を恣意的に主張することはできず、制御を証明するために暗号署名を使用する必要があります。

監査の焦点:

● setTokenURI 関数のアクセス制御をチェックして、プロキシ所有者または承認されたロール (onlyOwnerAfterMint など) のみが URI を更新できることを確認します。

● URIが不変ストレージソリューション（IPFSやArweaveなど）をサポートしていることを確認してください。集中型のHTTP接続を使用する場合は、DNSハイジャックを防ぐためにドメイン制御のセキュリティを評価してください。

● ヌルポインターまたは無効な URI によって発生するコントラクト例外を回避するために、URI 形式の有効性を検証します。

● 署名の偽造やリプレイ攻撃を防ぐために、ドメイン名の署名を検証する際に、契約で暗号署名検証（EIP-712 など）が厳密に実行されているかどうかを確認します。

● ドメイン所有権証明書の有効期限メカニズムをチェックして、長期有効な署名が再利用されるのを防ぎます。

● 単一障害点や操作を回避するために、ドメイン名解決プロセスが集中オラクルに依存しないことを確認します。

2. 評判レジストリ

フィードバックシグナルの公開と受信のための標準インターフェース。スコアリングと集約はオンチェーン（コンポーザビリティ）とオフチェーン（複雑なアルゴリズム）の両方で行われ、プロキシスコアリング、監査ネットワーク、保険プールといったプロフェッショナルなサービスエコシステムを実現します。

これは、登録されたAIエージェントを評価し、フィードバックを提供するために使用されます。シンプルなフィードバックはオンチェーンで送信され、より複雑なフィードバックはオフチェーンで送信され、集約されたフィードバックはオンチェーンのデータベースにアップロードされます。

ERC-8004は、「Payment-Proof Linking」メカニズムを通じて、悪意のある評価操作を防ぐこともできます。エージェントAがエージェントBのレビューを完了すると、「giveFeedback」関数が呼び出されます。この関数は、評価（0～100）とレビューハッシュだけでなく、「paymentProof」フィールド（通常はx402トランザクションのハッシュ）も受け入れます。これにより、レビュー操作のコストが非常に高くなり、シビル攻撃の可能性が大幅に低減されます。最終的には、システム全体が、安定した高品質のパフォーマンスを持つエージェントに自然に報いることになります。

監査の焦点:

● `giveFeedback` 関数が `paymentProof` パラメータを必須としていること、およびそれが有効な x402 トランザクションハッシュ（または他の支払い標準に準拠している）であることを確認します。単一の支払いが複数回評価されることを防ぐため、支払い証明が再利用されないようにしてください（例：使用されたハッシュを記録する）。

● スコアの範囲（0 ～ 100）が契約レベルで強制されているかどうかを確認し、境界を超えるスコアによって集計ロジックが破綻するのを防ぎます。

● オフチェーン集約アルゴリズムの操作に対する耐性を評価します。たとえば、中央値、極端な値の除去、加重平均を使用するかどうか、異常な動作（短期間で大量の評価を行うなど）にペナルティを課すかどうかなどです。

● 不正行為の証拠を提出するためにオンチェーン証拠やサードパーティのオラクルに依存しているかどうかなど、没収の条件が明確かつ検証可能かどうかを確認します。

● ペナルティロジックに中央集権的な権限（管理者が担保資金を恣意的に没収できるなど）が含まれていないこと、およびペナルティのトリガー条件がスマートコントラクトによって自動的に実行されることを確認します。

● エージェントが罰金や没収に直面する前に緊急に資金を引き出すことを防ぐために、預金引き出しのロックアップ期間と条件をテストします。

3. レジストリを検証します。

独立した検証チェック (zkML 検証、TEE オラクル、信頼評価など) を要求および記録するための共通フック。

評判は過去を反映しますが、リスクの高いシナリオ（大規模な資金移動など）では、履歴だけでは不十分です。検証レジストリは、エージェントが第三者または自動システムによる検証結果を提出することを可能にします。これらのシステムは、ステーキングセキュアな推論再実行、zkMLバリデータ、TEEオラクルなどのメカニズムを使用して、リクエストを検証または拒否します。

最初のモデルは、ゲーム理論に基づくセキュリティ設計に基づく暗号経済検証です。エージェントは、レジストリに一定量のネイティブトークンまたはステーブルコインをステークする必要があります。エージェントが義務を履行できなかった場合、または誤った結果を提示した場合、バリデータネットワークは不正の証拠を提出し、スマートコントラクトを起動してステークされた資金を自動的に没収することができます。このモデルは、データスクレイピングやシンプルなAPIサービスなど、結果は容易に検証できるものの計算プロセスが不透明なタスクに適しています。

2つ目のモデルは暗号検証であり、数学的原理に基づいたセキュリティ設計です。TEE（Trusted Execution Environment）認証により、エージェントはIntel SGXやAWS Nitroといったセキュアで堅牢なハードウェア環境で実行できます。検証レジストリは、ハードウェアからのリモート認証レポートを保存・検証することで、エージェントが実行しているコードが、特定のコードが真正かつ改変されていないバージョンであることを証明します。

zkML（ゼロ知識機械学習）は、暗号検証手法の1つです。エージェントは推論結果とともにゼロ知識証明を提出します。この証明は、オンチェーン検証コントラクトによって非常に低コストで検証可能であり、出力が特定の入力下で特定のモデル（Llama-3-70Bなど）によって生成されたことを数学的に保証します。これにより、「モデル置換」攻撃（サービスプロバイダーが高性能モデルを使用していると主張しながら、実際にはコスト削減のために低次元モデルを使用している攻撃）を防止できます。

監査ポイント

暗号経済検証の場合は、以下の点を確認する必要があります。

● 不正行為の証拠提出期間を確認する：検証者は、証拠を検知して提出するのに十分な時間がありますか？期間が短すぎると悪意のある行為を見逃してしまう可能性があり、期間が長すぎると資金が長期間ロックされる可能性があります。

● 不正証明を検証するための裁定ロジック：マルチ署名バリデータセットに依存しているか？もしそうなら、選択されたバリデータの分散化の程度と閾値設定を検討する必要がある。裁定が完全にオンチェーンで行われる場合、裁定の根拠（オンチェーンで検証可能な結果など）が存在し、明確であることを確認する必要がある。

● 低コストの悪意ある行為（担保が不十分で、不正行為による利益が損失をはるかに上回る場合など）を防止するために、担保の額がリスクに見合っていることを確認します。

TEE 認証の場合は、以下の点を確認する必要があります。

● 期限切れの証明が受け入れられないように、契約で TEE 証明の有効性が検証されているかどうかを確認します (例: タイムスタンプやブロックの高さを含む)。

● 証明コンテンツにプロキシのコードハッシュと入出力ダイジェストが含まれているかどうかを確認し、証明が特定のタスクにバインドされ、タスク間の再利用を回避できるようにします。

● TEE証明の検証ロジックが外部オラクル（Intel IASなど）に依存しているかどうかを評価します。依存している場合は、オラクルのセキュリティと分散性を監査します。

zkML 検証の場合は、以下を確認する必要があります。

● 契約が監査済みの zk 検証ライブラリ (SnarkVerifier など) を統合し、特定の証明システム (Groth16、PLONK など) の検証キーを正しく構成していることを確認します。

● 検証契約がモデル置換攻撃を防ぐために適用可能なモデルと証明の入力範囲を制限しているかどうかを確認します（例：証明は小さなモデル用に生成されているが、大きなモデルの出力であると主張するなど）。

● 証明生成における分散化の程度を評価する：単一の証明者に依存しているか？複数の証明者が存在する場合、悪意のある証明者を防ぐためのコンセンサスメカニズムを設計する必要がある。

結論

ERC-8004はAIエージェントの信頼を確立するための標準規格であり、そのセキュリティはオンチェーン・エージェント・エコシステム全体にとって極めて重要です。セキュリティ監査には、3つのレジストリの設計意図と潜在的なリスクを深く理解する必要があります。さらに、コントラクト間の相互作用の複雑さと一般的な脆弱性も無視できません。ERC-8004が「トラストレス」という約束を真に実現し、自律エージェントの未来のための安全な基盤を築くためには、包括的かつ厳格な監査が不可欠です。