原文

[Draft/Idea] Confidential Agent Policy Verdicts — mzf11125 (2026-07-24)

機密エージェントポリシー判定

機密エージェントポリシー判定 (Confidential Agent Policy Verdicts) は、自律エージェントのアクションに対する事前実行型の許可/拒否インターフェースを提案します。このインターフェースでは、オンチェーンで開示されることのないポリシーに対して、その決定がゼロ知識証明で証明されます。

著者: Muhammad Zidan Fatonie (@mzf11125), Faisal Firdani (@zexoverz), Maulana Asykari Muhammad (@WeissCurry)

概要

今日のイーサリアムにおけるエージェント認証には、2つの形態があります。1つはERC-8004のように、エージェントが行動した後にID、評判、検証アテステーション（証明）を記録する事後的なもの。もう1つは、ERC-8150やERC-8312のように、事前に特定の許可に署名した主体（principal）から権限が派生する委任ベース（mandate-based）のものです。

しかし、多くのデプロイメント（展開）はこのどちらにも当てはまりません。例えば、会社の経費カードを考えてみましょう。カード所有者は購入ごとに事前に署名しませんし、カードネットワークの不正防止ルールはカード所有者にも加盟店にも開示されません。権限は、第三者が保持する常設のルールセットから派生し、すべてのトランザクションに適用され、誰も再署名することなく更新され、意図的に秘密にされています。なぜなら、公開された不正防止ルールは、公開された回避ガイドとなるからです。

規制されたエージェントのデプロイメントも同様の形態をとります。オペレーターはスクリーニングルールを維持し、エージェントは相手方が署名したかどうかにかかわらずそれに従います。ルールは頻繁に変更され、それを公開することはその目的を損ないます。明白な回避策はどちらも失敗します。ポリシーをオンチェーンに置くと、阻止すべき敵対者に開示されてしまいます。オフチェーンオラクルが「許可された」と判断しても、ポリシーが適用されたという証拠は得られないため、その判定は任意の署名と区別できません。

ゼロ知識証明がこの問題を解決します。検証者は、コミットされたポリシーが正しく評価され、許可が返されたことを知りますが、その内容については何も知りません。

仕組み

1. エージェントがアクションを提案します。

2. エージェントではなく、ポリシー・ドメインのオフチェーンエンジンが、秘密のルールセットに対してそのアクションを評価します。エージェントはルールを保持しません。

3. 許可された場合、エンジンは、このアクションがコミットされたポリシーに対してチェックされ、結果が「許可 (ALLOW)」であったことを示すゼロ知識証明を生成します。この証明はポリシーの内容について何も開示しません。

4. オンチェーンのガードコントラクトが証明を検証します。

5. 有効であれば、アクションが実行されます。無効であれば、拒否されます。

ポリシーは、ERC-7812エビデンスレジストリ（Evidence Registry）にステートメントとして登録されたコミットメントとしてのみオンチェーンに存在します。チェーンをまたぐのは単一のルートであり、ルールそのものではありません。

この標準は、判定エンベロープ（verdict envelope）と検証インターフェースのみを定義します。ポリシー言語、証明システム、またはトランスポート（transport）は定義しません。

早期に検討すべき2つの選択肢

証明されるプログラムは、コンパイルされたポリシーではなく、ポリシーインタープリターです。 ポリシーが回路（circuit）にコンパイルされる場合、ルールが変更されるたびに新しい検証鍵（verification key）が生成され、それは更新ごとにすべてのチェーンで新しい検証者デプロイメント（verifier deployment）が必要になることを意味します。毎週変更されるルールセットの場合、これは不便というよりも失格となります。固定されたインタープリターを証明し、ルールセットをプライベートな証人（private witness）として渡すことで、プログラムコミットメントはポリシー更新全体で一定に保たれ、ERC-7812ルートのみが移動します。このコストは、インタープリターが単一のポリシーのスーパーセットを証明するため、証明が特注の回路（bespoke circuit）よりも高価になることです。このトレードオフにより、証明コストはドメインとともにオフチェーンに置かれ、他のすべての関係者から検証鍵の頻繁な更新（verification key churn）がなくなります。

ポリシーコミットメントは意図的に非ブラインド化されます。 これはERC-7812のブラインドパターン（blinding pattern）から逸脱しています。ブラインド化すると、ルールセットを保持する当事者でさえコミットメントを検証できなくなり、監査人への選択的開示パス（selective-disclosure path）が破壊されます。十分なルールセットのエントロピー（entropy）があれば、プリイメージ耐性（preimage resistance）のみで機密性要件を満たせます。

プライバシー要求の範囲

この標準は、アクションではなくポリシーを隠します。許可されたアクションは公開チェーン上で実行され、公開されます。保証されるのは、実行中のエージェントを含むどの観測者も、それを許可したルールを知ることができないという点です。

これは安全性プロパティ（safety property）ではなく、整合性プロパティ（integrity property）です。有効な証明は、コミットされたルールセットが評価されたことを確立しますが、そのルールセットが正しいか公平であるかについては何も確立しません。すべてを許可するルールセット（permit-everything ruleset）にコミットするドメインは、完全に検証される証明を生成します。

関連する標準との関係

• ERC-8004は、判定がバインドするエージェントIDを提供します。

• ERC-7812はエビデンスレジストリ（evidence registry）を提供します。これは抽象的に書かれており、後の提案がその上に特定のユースケースを構築できるように意図されていましたが、エージェントクラスター（agent cluster）ではまだ採用されていません。これがその橋渡しとなります。

• ERC-8312は重複するのではなく補完的です。判定は許可を付与し、委任は能力を付与し、両者は独立して保持されなければなりません。

• ERC-8150は最も近い隣接標準であり、これもゼロ知識で事前実行検証を行います。違いは権限のソースと秘密にあります。ERC-8150では、ユーザーがエージェントのバッチに署名するため、承認する当事者は何が承認されたかを正確に知っており、主体（principal）から隠すものはありません。ここでは、権限は相手方が署名しない常設の第三者ルールセットから派生し、その機密性が副次的な効果ではなく本質的な目的となります。

• ERC-8226は規制されたデプロイメントの動機を共有しますが、その委任はそれが拘束する当事者にとって判読可能なままであり、トークン化された規制資産にスコープされます。ここでのエンベロープは資産に依存せず（asset-agnostic）、任意の呼び出しをゲートします。ドメインは両方を使用する可能性があります。

• ERC-7579およびERC-6900は自然な統合インターフェースです。ガードは事前実行フック（pre-execution hook）または検証モジュール（validation module）として機能します。

• ERC-4337およびERC-7562は、[[glossary/validateUserOp|validateUserOp]]内でこれがどのように機能するかを制約します。未解決の問題を参照してください。

更新ログ

2026-07-24: 初版ドラフト、PRは未定

外部レビュー

2026-07-24現在、なし。

未解決の問題

• 2026-07-24: ERC-4337検証フェーズにおける配置。 [[glossary/validateUserOp|validateUserOp]]内のオンチェーン証明検証は、ERC-7562のストレージアクセスとガス制限を尊重する必要があります。さもなければ、バンドラー（bundler）が操作を破棄します。検証は定数コストでステート独立にできると信じていますが、完全なERC-7562ルールセットに対してチェックしておらず、バンドラー実装者からの意見を歓迎します。

• 2026-07-24: 非同期証明のレイテンシ。 証明生成は実行パス（execution path）に位置するため、ドメインのポリシーエンジンが到達不能な間、エージェントは行動できません。ERC-7412は構造化されたオフチェーン取得に適したパターンに見えますが、この標準がそれを規範的に参照すべきか、それともインテグレーター（integrator）に任せるべきか、まだ決定していません。

• 2026-07-24: インタープリターの忠実性は現在、証明されておらず、仮定されています。 ランタイム証明は、コミットされたプログラムが実行されたことを証明します。しかし、そのプログラムが主張するポリシー言語を忠実に実装していることは証明しません。ルールセットを無視して常に「許可 (ALLOW)」を返すインタープリターは、正しいインタープリターと全く同じように検証される証明を生成します。現在のドラフトでは、ドメインがプログラムキーにバインドされた、読み取り可能な参照定義に対する機械検証可能な等価性証明（equivalence proof）を公開することを推奨することで、この問題に対処しています。未解決の質問：このアテステーション（証明）メカニズムは、この標準が要求する独自のERCとなるべきか、それともインラインのままであるべきか？

• 2026-07-24: インタープリターの機密性は忠実性とは別の特性です。 正しいが情報漏洩のある（leaky）インタープリターは、公開出力やリバート動作がルールセットのどのブランチが発火したかによって変化し、すべての正確性チェックを満たしても、ポリシー構造を漏洩させます。証明時間は、証明の範囲外にあるため、私が最も自信のないチャネルです。

• 2026-07-24: ドメインレジストリは別のERCであるべきか。 IPolicyDomainRegistryは推奨されるコンパニオンとして指定されており、独立した実装がデフォルトで相互運用できるようにしていますが、コアインターフェースは3つのセマンティックフック（semantic hook）のみに依存しています。これを分割するとERC-7812の先例に従うことになりますが、この提案のファイナルへのパスを別のドラフトに結合することになります。

• 2026-07-24: 失効サービスレベルとしてのルートの陳腐化。 maxRootAgeは、スポークチェーン（spoke chain）上のミラーリングされたルートがハブ（hub）に遅れるために存在します。これをゼロに設定すると、同期ギャップ（sync gap）中に判定が機能しなくなります。高く設定すると、削除されたルールがその期間中、すべてのスポークでアクションを承認し続けます。この両方を回避する設定はなく、標準が上限を義務付けるべきか、ドメインが公開するに任せるべきかについて意見を求めています。

• 2026-07-24: クロスチェーンエージェントID解決はスコープ外であり、延期されます。agentIdは現在、判定が消費されるチェーン上で解決される必要があります。これを延期ではなく、ブロックするギャップ（blocking gap）と見なす人がいる場合に備えてフラグを立てています。

• 2026-07-24: interfaceIdはプレースホルダーであり、このドラフトを離れる前に最終決定されます。実行可能なテストスイートと2つのスポークを持つクロスチェーンデプロイメントを含む参照実装は進行中であり、まだ公開されていません。

特に求めているフィードバック

1. 証明されるプログラムとしてのインタープリターアプローチは正しい判断か、それとも私が見落としている検証鍵の頻繁な更新（verification key churn）を回避するコンパイル済み回路設計があるか？

2. ERC-7812からの非ブラインドコミットメントの逸脱が、その標準の作成者に予期せぬ問題を引き起こすか？

3. 証明生成と提出が分離されていることを考慮すると、有効な判定に対するメムプールのフロントランニングに対してエグゼキューターバインディングは十分か？

4. ERC-8004に取り組んでいる方へ：成功した消費後に提案される検証レジストリのアテステーション（証明）は、そのレジストリの意図された使用法に適合するか、それとも誤用か？

5. ERC-8150およびERC-8226の作成者へ：私が引いた境界線は正しいか、それとも3つの隣接する標準よりも皆に役立つ統合があるか？

1投稿 - 1参加者

トピック全文を読む