原文
Execution receipts for AI agents: off-chain evidence, on-chain roots, and verifiable session proofs — pipavlo82 (2026-06-06)
皆さん、こんにちは。
AIエージェント向け実行レシートに関する議論を提案したいと思います。
現在のエージェントに関する多くの作業は、アイデンティティ、レピュテーション、パーミッション、支払い、ツール実行に焦点を当てています。これらは重要ですが、本番環境のエージェントシステムには別の層が必要だと考えています。
「エージェントが実際に何をしたかの検証可能な記録」
コーディングエージェントやツール使用エージェントにとって、問題は単に次のことではありません。
「このエージェントはタスクを実行できるか？」
それはまた、次のことでもあります。
「ユーザー、他のエージェント、または検証者が後で何が起こったかを確認できるか？」
問題点
AIエージェントは現在、以下のことができます。
- ファイルの変更
- コマンドの実行
- ツールの呼び出し
- パッチの生成
- デプロイの準備
- APIとの対話
- 潜在的に影響の大きいアクションのトリガー
しかし、セッションが終了した後、ユーザーはエージェントの出力（アウトプット）を信頼するか、手動でログを検査する必要があることがよくあります。
本番環境での使用、特にエージェントがコードベース、ウォレット、インフラストラクチャ、または有料ツールを横断して動作する場合、レシート層が必要です。
レシートモデル
セッションレシートは、次のような構造化された証拠をキャプチャできます。
- タスク / プロンプト
- ワークスペースまたはプロジェクトのコンテキスト
- エージェント/ランタイムのメタデータ
- スコープまたはパーミッション
- 変更されたファイル
- 差分ハッシュ
- コマンド/ツールの概要
- 検証者入力
- 完全な証拠JSON
完全な証拠は、デフォルトでオフチェーンに保持されるべきです。
その証拠から、決定論的なレシートハッシュ/ルートを計算できます。
完全なエージェント証拠（オフチェーン）
→ 正規のレシートJSON
→ 決定論的なレシートハッシュ/ルート
→ コンパクトなオンチェーンアンカー
→ 後でルートを再計算することによる検証
目標は、プライベートなプロンプト、コード、ログ、または完全なワークフローをオンチェーンに置くことではありません。
目標は次のとおりです。
プライベートな証拠はオフチェーンに
公開コミットメントはオンチェーンに
検証は再計算によって
セッション / ワークフローのルート
より大きなエージェントセッションの場合、単一のアクションレシートでは不十分です。
セッションには多くのアクションが含まれる場合があります。
receipt_1_hash
receipt_2_hash
receipt_3_hash
...
これらはマークルツリーにバッチ処理できます。
多くのレシート/証拠アイテム
→ リーフとしてのレシートハッシュ
→ マークルツリー
→ sessionRoot / workflowRoot
→ オンチェーンアンカー
これにより、より大きなワークフローにコミットする1つのコンパクトなルートが得られます。
検証者は後で次のことができます。
- レシートJSONをロードする
- 正規化する
- 「receiptHash」を計算する
- 「sessionRoot」/「workflowRoot」に対してマークル証明を検証する
- そのルートをオンチェーンアンカーされた値と比較する
エージェントのアイデンティティ / レピュテーションとの関係
これは、エージェントのアイデンティティ、レピュテーション、および検証レジストリを補完するものだと考えています。
アイデンティティ/レピュテーションは次の問いに答えることができます。
「このエージェントは誰で、過去にどのように振る舞ったか？」
実行レシートは次の問いに答えます。
「このエージェントはこの特定のセッションで何をしたか？」
どちらも有用であると思われます。
エージェントは良いレピュテーションを持つことができますが、ユーザーは特定のコード変更、ツール呼び出し、デプロイメントステップ、または有料アクションに対して検証可能なレシートを必要とする場合があります。
プロトタイプ
私たちはStealth/CYPHESでこのパターンをプロトタイプ化しています。
GitHub - CYPHES-ATP/Stealth: Verifiable coding agent.
検証可能なコーディングエージェント。
現在のプロトタイプの方向性：
- ローカルレシート証拠
- 決定論的なレシートルート計算
- Sepoliaでのレシートルートアンカーデモ
- 複数のレシート/証拠アイテムを1つのセッション/ワークフロールートにバッチ処理するためのローカルマークル証明デモ
- 完全な証拠はオフチェーンに保持
- ルート/ハッシュのみがオンチェーンにアンカーされる
重要な境界線：
「フルワークフローはオンチェーンではない。 ルート/ハッシュはオンチェーンである。 検証はルートを再計算することによって行われる。」
コミュニティへの質問
以下の点についてフィードバックをいただけると幸いです。
- 実行レシートルートは、エージェント検証証拠の一種として扱われるべきでしょうか？
- セッション/ワークフローのルートは、後でレジストリにプラグインできる独立したアテステーション層としてモデル化されるべきでしょうか？
- エージェントレシートにとって、どのような正規化フォーマットが適切でしょうか？
- 最小限の検証者インターフェースはどのようなものになるべきでしょうか？
- レシートルートは、エージェント、ユーザー、バリデーター、または共有レジストリのいずれによって直接アンカーされるべきでしょうか？
- プロンプト、コード、ログを漏洩させることなく、プライベートな証拠バンドルをどのように参照すべきでしょうか？
要するに：
「「エージェントを信頼する」のではなく、 レシートを検証する。」
検証可能なエージェント実行について他の人々がどのように考えているか、そしてレシートルート/セッションルートがより広範なイーサリアムエージェントスタックに適合するかどうかについて興味があります。
1投稿 - 1参加者