論文要約：HDP（Human Delegation Provenance）

〜自律型 AI システムにおける人間による委任の真正性を検証するための軽量暗号プロトコル〜

この論文は、2026 年 3 月に Helixar Limited の Asiri Dalugoda 氏によって発表されたもので、自律型 AI エージェント（Agentic AI）システムにおける「人間の承認」と「最終的なアクション」の間の責任の欠如（Accountability Gap）を解決するための新しいプロトコル「HDP（Human Delegation Provenance）」を提案しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

---

1. 問題定義 (The Problem)

自律型 AI システムは、人間の指示を受け取り、オーケストレーター・エージェントがサブエージェントにタスクを委譲し、さらにツール実行エージェントがファイルシステムや API などの外部サービスにアクセスするという多段階のチェーンで動作しています。しかし、現在のシステムには以下の構造的な課題が存在します。

• 責任の断絶: 人間がオーケストレーターに承認を与えても、その承認が最終的なアクション（金融取引、コードコミット、メール送信など）にどの程度まで遡って正当化されているかを検証する標準的なメカニズムが存在しません。
• 監査の困難さ: 事後の監査において、「誰が」「いつ」「どの範囲で」承認したかを再構築できません。
• プロンプトインジェクションへの脆弱性: 悪意のある入力（プロンプトインジェクション）が、正当な委任された指示としてエージェントに実行されてしまうリスクがあります。エージェントは、指示が本当に人間によって承認されたものか、注入されたものかを区別できません。
• 既存規格の限界: OAuth 2.0 Token Exchange (RFC 8693) や JWT、UCAN などの既存の規格は、多段の委任チェーン、アペンディ・オンリー（追記のみ）な記録、およびオフラインでの完全な検証という要件を満たしていません。

2. 手法とプロトコル設計 (Methodology)

HDP は、人間の承認コンテキストを暗号的に記録・検証するための軽量なトークンベースのスキームです。その核心は以下の設計原則と構造にあります。

2.1 設計原則

• オフライン検証可能: 検証には発行者の公開鍵とセッション ID のみが必要で、ネットワーク呼び出し、レジストリ参照、第三者の信頼アンカーは不要です。
• 自己主権 (Self-Sovereignty): 中央機関への登録なしに、任意の組織が発行・検証可能です。
• 改ざん検知: ヘッダーから各ホップ（委任ステップ）までのすべてのフィールド変更を検知します。
• 最小限のフットプリント: Ed25519 と JSON に対応する言語であれば実装可能です。

2.2 トークン構造

HDP トークンは JSON 形式で、以下の 6 つの主要フィールドを持ちます。

1. Header: トークン ID、発行/有効期限、セッション ID、バージョン。
2. Principal: 承認した人間（Principal）の ID、タイプ（メール、UUID、DID など）、表示名。
3. Scope: 承認された意図（Intent）、許可されたツール、データ分類、ネットワークエグレス、最大ホップ数など。
4. Chain (委任チェーン): アペンディ・オンリーな配列。各エージェントの委任アクションを「ホップ」として記録します。
   • 各ホップには、シーケンス番号、エージェント ID、タイムスタンプ、アクションの要約、親ホップのインデックス、および署名が含まれます。
5. Signature: ルート署名（Ed25519）。ヘッダー、Principal、Scope、および空のチェーンに対して発行時に署名されます。
6. Hop Signatures: 各ホップは、それまでのすべての履歴（ルート署名を含む）に署名を付与します。これにより、チェーンのどの部分も改ざん不可能になります。

2.3 暗号学的構成

• 署名アルゴリズム: Ed25519 (RFC 8032) を使用。
• シリアライゼーション: RFC 8785 に準拠した JSON 正規化（Canonicalization）を使用し、署名対象のバイト列を決定論的に生成します。
• 検証プロセス: 7 つのステップ（バージョン確認、有効期限確認、ルート署名検証、ホップシーケンス整合性、各ホップの署名検証、最大ホップ数確認、セッションバインディング確認）を実行します。

3. 主要な貢献 (Key Contributions)

1. 新しいプロトコルの提案: 多段の AI エージェント委任チェーンにおける「人間由来の真正性（Human Provenance）」を証明する初の標準的なプロトコル。
2. 既存規格との明確な差別化:
   • OAuth 2.0 (RFC 8693): 点対点のトークン交換であり、アペンディ・オンリーな履歴を単一トークンに保持しない点、オンライン認証サーバーを必要とする点で HDP とは異なります。
   • JWT: 多段署名チェーンとセッションバインディングの仕組みを欠いています。
   • UCAN: 能力（Capability）の強制に焦点を当てており、DID インフラを必須としますが、HDP はオフライン運用と最小インフラを重視します。
   • IPP (Intent Provenance Protocol): 中央の失効レジストリや第三者の信頼アンカーを必要とするのに対し、HDP は不要です。
3. 実用性の確保: TypeScript SDK の公開、CrewAI や MCP への統合パターンの提示、および IETF インターネットドラフト（draft-helixar-hdp-agentic-delegation-00）への提出。
4. セキュリティ分析: 偽造、チェーン改ざん、リプレイ攻撃、プロンプトインジェクションに対する防御限界を明確に定義しました。

4. 結果と性能 (Results & Performance)

• 検証速度: 現代のハードウェアにおいて、Ed25519 の署名検証は 100 マイクロ秒未満で完了します。典型的な 10 ホップのチェーンにおける完全な検証は 2 ミリ秒未満で完了し、高スループットの AI パイプラインに適しています。
• トークンサイズ: チェーン長に比例して増加しますが、10 ホップのトークンでも約 4-8 KB と軽量です。
• 実装: 公開された TypeScript SDK は、トークン発行、ホップの拡張、7 ステップの検証パイプラインを提供しており、Python 統合も利用可能です。

5. 意義と将来性 (Significance & Future Work)

• 規制対応とリスク管理: AI ガバナンスフレームワークが成熟する中で、自律的なアクションの責任を特定の人間の承認事象に帰属させることは、法的・規制的なリスクを軽減する上で不可欠です。HDP はこのギャップを埋めます。
• セキュリティの基盤: プロンプトインジェクションを完全に防ぐものではありませんが、注入されたアクションが正当な委任チェーンに存在しない、または改ざんされたものであることを「証拠」として検出可能にします。
• 将来の拡張:
  • v0.2 の予定: 各エージェントが独自の鍵で署名する機能（マルチキー委任）や、閾値署名を用いた同時多者承認（M-of-N）の実装が計画されています。
  • 標準化: IETF の RATS ワーキンググループでの議論を通じて、OpenID 財団の自律型アイデンティティ作業との相互運用性を高めていく方針です。

結論

HDP は、自律型 AI システムが急速に普及する中で生じる「責任の空白」を埋めるための、軽量かつオフラインで検証可能な暗号プロトコルです。既存の規格では対応しきれない「多段委任」「追記専用」「人間由来の真正性」という要件を満たし、AI エージェントの行動に対する説明責任とセキュリティを確保する重要な基盤技術として位置づけられています。