AI Agentのリスクを検証する規格「ERC-8126」
こんにちは、FractonのKeitaです。
前回寄稿したERC-8183の解説に続いて、同じくAI agent向けの標準、最近ぽつぽつ注目を集めてるProtocol, ERC-8126について解説していきます。
ERC-8126は、Ethereumの標準提案で、AIエージェントの技術的リスクを比較可能な形で公開するための検証規格として、初稿が25年の1月にLeigh Cronian ( CybercentryというAIエージェントのサイバーセキュリティ専門プロジェクトの主導者 )によって公開され、ERC-8004の台頭の影響を受けて26年3月に再度議論が一定活発になってきています。
1) 8004, x402との関係性
まず、ERC-8126と8004, x402との関係性としては以下のように整理できます。
ERC-8004 は「そのエージェントは誰か、どこで見つかるか、どんな評判や検証履歴を持つか」を扱う、アイデンティティと信頼の基盤です。Identity Registry、Reputation Registry、Validation Registry という3つのレジストリを持ちます。
ERC-8126 は、その上で「この特定のエージェントは技術的にどれくらい危ないか」を、本記事で後述するプロセスを通じて0から100の簡易的なリスクスコアに圧縮する規格です
26年のEthereum Magicians内での議論では、Agentの登録部分はERC-8004に寄せ、ERC-8126は純粋な verification standardに絞る方向へ議論が進んでいます。
x402 は上記規格の中で、支払いレールの役割を果たします。
2) 8126の仕組み
現行の公開ドラフトに基づいてを、時系列のフローに基づいて大まかな仕組みはいかのように構成されます。
エージェントの登録 (via ERC-8004)
まず、ERC-8004レジストリに登録された
agentIdを受け取り、provider (下記記載) がtokenURI(agentId)を解決して walletAddress, endpoint, contractAddress, stakingContractAddress (任意)などのメタデータを取り出します。また後述するフローの結果は必要に応じて ERC-8004 の Validation Registry に post できるようになっています。
Agentの検証リクエストが provider に送られる
Agent Owner が EIP-712 署名で登録し、レジストリが
AgentRegisteredを emit し、その後 Verification Provider に検証依頼を出します。検証費用が必要な場合、 x402 と EIP-3009 の gasless payment が8126では推奨されています。重い検証ロジックはオンチェーンではなくオフチェーンで基本実行されます。( 理由として仕様では、複数 provider の競争、複雑ロジックの許容、検証基準のupdateの容易性などを挙げています。)
Agentの検証プロセス
検証は4つのレイヤーに分かれます。ERC-8126は「エージェントが本当に安全か」そのものを証明するのではなく、「ある provider が、定義済みの最大4つの観点から検証を行った」ことのattestationを標準化する役割を果たします。(＝検証の存在と結果記載のformatを揃える規格であり、検証のアルゴリズムそのものを統一しているわけではありません。検証方法はprovider に委ねられます。)
① ETV, Ethereum Token Verification
contractAddressがすでに存在する場合に走る検証で、指定チェーン上にコントラクトが存在するか、既知の脆弱性パターンがないかを見て、0から100のリスクスコアを返します。OWASP SCSVS準拠が推奨です。② SCV, Staking Contract Verification
stakingContractAddressがある場合に走り、ステーキング機構、報酬分配ロジック、リエントランシーやフラッシュローン攻撃などの典型脆弱性を見ます。これも0から100で返します。③ WAV, Web Application Verification
常時走り、HTTPS endpoint が応答するか、共通脆弱性がないか、SSL 証明書が妥当かを見ます。OWASP WSTG や Web Top 10 に沿うことが推奨されています。④ WV, Wallet Verification
常時走り、wallet にトランザクション履歴があるか、threat intelligence database に載っていないかを見て、0から100で返します。新規ウォレットや履歴の薄いエージェントには不利になりやすい設計です。
検証結果が PDV(Private Data Verification) で ZK proof 化される
その後、各 verification result を PDV に通し、ZKP に変換します。ここで公開されるのは、要約されたスコアや proof ID で、脆弱性の生データや threat hit の詳細は秘匿される設計です。getAgentProofsは wallet holder か registrant しか見られず、getAgentInfoとgetAgentVerificationは公開です。つまり、公開されるのは「大枠の成績表」、隠されるのは「採点の詳細答案」です。ERC-8126は、「詳細は非公開のまま、検証済みであることだけを暗号学的に示す」設計に寄せています。Ethereum Magicians内の開発者間の議論でも、ERC-8004 の汎用 Validation Registry よりも、8126 のほうが sensitive details を tighter に gate できるという説明がされています。
任意: QCV(Quantum Cryptography Verification)
QCV は任意のレイヤーで、機微な verification data を量子耐性寄りに保護する追加実装として定義されています。仕様上は AES-256-GCM または同等の “post-quantum encryption algorithm” を使い、record_idとdecryption_urlを返すとされています。ただし、ERC-8126のQCVは、対称暗号、鍵交換、長期秘匿性をまとめて一語で扱っており現実的な設計としてはまだ粗い段階で、将来の改稿余地が大きい箇所になっています。
最終的にoverall risk score に集約
overall risk score は「applicable な verification score の平均」です。スコア帯は 0-20 が Low, 21-40 が Moderate, 41-60 が Elevated, 61-80 が High, 81-100 が Critical です。これは主に8004のようなagent discovery UI で短時間で比較する際に参照される目的です。検証の詳細を参照する前に「いま支払っていいか」「この agent に API key を触らせていいか」を瞬時に判断できる目的で役に立ち余す。作者のLeigh CroniaはEthereum Magicians内 で、overall risk scoreはpayment-heavy flows, 特に x402 支払いの際に役に立つと説明しています。
ここまでのプロセスを一連の流れとして簡単に整理すると以下のようになります。
エージェントの登録(via ERC8004)
provider に検証を依頼
ETV, SCV, WAV, WV が条件に応じて走る
結果を集約して risk score を出す
詳細は PDV 経由で ZK proof 化し、proof ID と要約結果だけを公開
必要なら x402 と EIP-3009 で gasless に検証費用を払う
相手は onchain あるいは provider API から「この agent のリスクはどれくらいか」を照会する
3) ERC-8126のスコープ範囲外:
まず、ERC-8126が基本的に標準化しているものは、検証観点の名前、最低限の MUST/SHOULD 要件、スコアのレンジ、公開/非公開のデータ境界、イベントや照会インターフェース、そして x402/EIP-3009 を使った支払いの推奨です。
逆に標準化していないものは、provider がどう脆弱性検出を実装するか、どの threat intelligence DB を参照するか、ZKP 回路をどう設計するか、各リスク要因の重みをどう較正するか、どれくらい頻繁に再検証するかなどの実際の検証方法です。仕様は provider agnostic を明言していて、実装の自由度を残しています。
上記に記した通り、当初の提案では、Agentの登録の手法とregistryを標準に含めていましたが、26年にERC-8004 が traction を得たことを踏まえ、ERC-8126から独自の Agent Registry を完全に外し、agent identity を一元化しつつ、8126のsecurity verification を modular に差し込めるように変更しました。ERC-8004 が identity/trust substrate に徹し、ERC-8126 が security attestation layer に徹する、という明確な責務分離を目的にしています。
4) 8126の代替手段:
ここまでの内容を踏まえると、8126の役割は以下の4つに集約されます。
(1) エージェントの canonical な入力対象を決めること
(2) ETV/SCV/WAV/WV という固定観点でセキュリティ検証すること
(3) ZKP を通して詳細を秘匿したまま証拠を配布すること
(4) 最後に人間や他エージェントがクイックに判断できる 0–100 の比較可能なスコアに集約すること
単なるattestation や identity そのもの(すでに他の汎用基盤が成熟してる領域)として捉えるよりも、その独自性を”AIエージェント向けに security semantics を固定している点”に絞ると一定役割がクリアになります。つまり「最低でも何をcheckしたのか」を 上述のETV/SCV/WAV/WV で揃え、OWASP系の観点を推奨し、詳細は PDV/ZKP 側に閉じ、表には比較可能なoverall risk score を出す、といった“security passport” 的な役割と捉える考え方です。提案者のLeigh Cronianも ERC-8004 との比較の中で、8126の価値を「generic validation ではなく prescriptive AI security service」に置いています。
上記を踏まえ、今後Ethereumネイティブな手段の中で8126の代替になりうるものは例えば以下が挙がってきます。
1) ERC-8004 + 8126相当の validator profile
→ 8126のような別の単独規格ではなく「ERC-8004上で8126相当のバリデータ仕様を定義する形」です。現状Ethereumネイティブな手段としては、一番有力な方向の一つです。8126の完全な代替になるというよりは、「8004を基盤に、8126の検証と score semantics を profile として載せる」ような形に落ちつく可能性があります。
2) attestation rail としての代替: EAS / Verax / Sign Protocol etc.
EASは、現状8126のようなAI agent security passportの機能そのものは内包していませんが、自由に登録されたschema に従って、onchain attestation、EIP-712 署名ベースの offchain attestationを扱え、attestation を配る土台として今でも「すぐに作って動かせる」という点で有力な手段です。
VeraxやSignはそれぞれEVM外への対応可能な点で、よりgenericなattestation protocolとして候補の一つには上がるが、EASや8126に比べるとEthereum内での特化という点では少し序列が下がる印象です。
5) まとめ
ここまでのEthereumのAgent周りの標準では、まず8004やx402が一定定着してきたと言える中で、次に重要になるテーマとして「どのresourceやagentがAgent毎の目的に合致するか、そのqualityを評価し、参照可能にし、より精度の高いdiscoveryに繋げる方法」に議論が移っていると思います。そうなった時に上記に記したように、8126は事前に一定固定化された観点で評価するフレームをmodular的に提供する1つの選択肢として、興味深いです。
一方リアルな話、8126は前回紹介した8183やx402、8004に比べて、まだ仕様上固まりきってない部分も多く、標準化にはまだ時間がかかりそうというのが現状の客観的な評価だと思います。（とはいえ、agentの検証インターフェースに徹した提案に改善されてから、また再度注目が戻ってきていると思います。）
今後このagentの検証仕様のデファクトがどの方向に向かっていくのか :
8004上で拡張定義される形で落ち着くのか、別のattestation protocol(EAS, Sign, Veraxなど )がAI Agent用の標準を出して台頭するのか、8126の議論がより詳細化されて進展するのか、または目的ごとにsplitする形で各仕様の棲み分けが明確になっていくのか、注目です。
それでは👋