HDP: A Lightweight Cryptographic Protocol for Human Delegation Provenance in Agentic AI Systems

HDP：為代理式 AI 系統設計的輕量級人類委派來源加密協議

原始論文：HDP: A Lightweight Cryptographic Protocol for Human Delegation Provenance in Agentic AI Systems 作者：Asiri Dalugoda (Helixar Limited, Auckland, New Zealand) arXiv ID：2604.04522v1 日期：2026-03 / 提交 2026-04-06 授權：CC BY 4.0 相關資源：

• IETF Internet-Draft: draft-helixar-hdp-agentic-delegation-00
• TypeScript SDK: @helixar_ai/hdp
• 規格網頁：https://helixar.ai/labs/hdp

標籤：Agentic AI Security Cryptographic Protocol Ed25519 Delegation Provenance Prompt Injection IETF

摘要

代理式 AI 系統 (Agentic AI Systems) 越來越常代替人類主體 (Human Principal) 執行有後果的動作 (Consequential Actions)，透過多步的自主代理 (Autonomous Agents) 鏈委派任務。然而目前沒有任何標準解決一個基本的問責缺口 (Accountability Gap)：如何驗證委派鏈中的終端動作確實是由某位人類主體授權、經過什麼委派鏈、在什麼範疇下。

本文提出 HDP (Human Delegation Provenance，人類委派來源) 協議 — 一個輕量級的基於權杖 (Token-based) 方案，以密碼學方式在多代理系統中捕捉並驗證人類授權上下文。一個 HDP 權杖：

1. 將人類授權事件綁定到一個 session；
2. 以只能追加 (Append-only) 的鏈記錄每位代理的委派動作為一個已簽章的 hop；
3. 讓任何參與者只需以簽發者的 Ed25519 公鑰和當前 session 識別碼即可驗證完整來源紀錄。

驗證完全離線 (Offline)，不需要任何註冊中心查詢 (Registry Lookup) 或第三方信任錨 (Trust Anchor)。我們把 HDP 置於既有委派協議版圖中，指出它相對於 OAuth 2.0 Token Exchange (RFC 8693)、JSON Web Token (RFC 7519)、UCAN 與 Intent Provenance Protocol (draft-haberkamp-ipp-00) 的獨特設計定位，並證明現有標準未能解決代理式流水線的多跳 (Multi-hop)、只能追加、人類來源需求。HDP 已作為 IETF Internet-Draft (draft-helixar-hdp-agentic-delegation-00) 發布，並提供公開的 TypeScript 參考 SDK。

關鍵字：代理式 AI、委派來源、密碼學授權、多代理系統、提示注入 (Prompt Injection)、Ed25519、人機迴圈安全、IETF、授權權杖。

1 引言

代理式 AI 系統自 2023 年以來部署速度急劇加快。LangChain [1]、CrewAI [2]、AutoGen [3] 以及 OpenAI 的 Assistants API 等框架讓開發者能組合流水線：人類指令傳給協調代理 (Orchestrator Agent)，它分解並委派子任務給特化子代理，後者再呼叫能存取檔案系統、資料庫、API 和外部服務的工具執行代理 (Tool-execution Agents)。這類系統的生產部署如今每天執行數以千計的重大動作 — 金融交易、程式碼提交、郵件發送、資料修改 — 而在動作層級的人類監督極少。

這種架構造成一個結構性問責缺口 (Structural Accountability Gap)。當一位人類授權協調代理、協調代理委派子代理、子代理再委派工具執行代理時，最初的人類授權會逐漸與終端動作脫鉤 (Disconnected)。目前沒有任何標準機制，讓下游代理能驗證：它被指示執行的動作確實是由某位人類主體授權、在什麼範疇下、沿著什麼委派鏈抵達這項指令。

這個缺口帶來三個具體的操作後果：

1. 事後稽核無法重建「誰在什麼時候批准了什麼」。
2. 代理無法在執行時區分合法的委派指令與注入的指令 [4, 5]，使提示注入攻擊 (Prompt Injection Attack) 能偽裝成已授權的委派。
3. 自主動作的問責無法歸屬到具體的人類授權事件，在 AI 治理框架日趨成熟的背景下造成監管風險 [6, 7]。

我們提出 HDP (Human Delegation Provenance) 協議 — 一個輕量級的基於權杖方案，專門設計來填補這個缺口。HDP 定義一個 JSON 權杖結構，它：(1) 記錄人類主體、其宣告的授權範疇 (Declared Authorization Scope) 與 session 綁定 (Session Binding)；(2) 為委派鏈中每一位代理累積一個加密簽章的 hop 紀錄；(3) 允許任何接收者只用簽發者的 Ed25519 公鑰和當前 session 識別碼即可驗證完整鏈結。驗證完全離線，不需任何網路呼叫、註冊中心查詢或第三方信任錨。

本文結構如下：第 2 節調查相關研究並確認 HDP 占據的設計點；第 3 節提出威脅模型；第 4 節完整描述協議；第 5 節分析安全性質；第 6 節討論實作考量與參考成品；第 7 節呈現限制與未來工作；第 8 節總結。

2 相關研究與動機

2.1 代理式系統中的授權缺口

代理式 AI 的身份與存取管理 (Identity and Access Management, IAM) 挑戰吸引越來越多關注。OpenID Foundation [8] 將代理委派列為優先問題，指出現有協議在表達錯綜複雜的委派序列（代理可能建立子代理或同時代表多位主體）上力不從心。ISACA [9] 將此形容為「即將到來的授權危機 (Looming Authorization Crisis)」，觀察到傳統 IAM 框架依賴的既有範疇對動態代理運作需求而言過於粗糙且靜態。Strata [10] 回報在一般企業中，非人類身份的數量比人類多出約 50:1，且有 80% 的 IT 領導者回報代理出現超出預期的行為。

這些分析有共同診斷：現有授權框架是為人對系統 (Human-to-system) 互動設計的，無法捕捉代理式流水線的多跳、只能追加、人類來源需求。HDP 就是為了明確地解決這個結構性需求而設計的。

2.2 OAuth 2.0 Token Exchange (RFC 8693)

RFC 8693 [11] 定義了安全權杖交換的協議，包含委派語意 (Delegation Semantics)。它定義 act 宣告來表達某主體代替另一主體執行動作，並支援 act 宣告的巢狀來表示委派鏈。RFC 8693 是現有最接近 HDP 使用案例的標準。

HDP 與 RFC 8693 是互補而非競爭。RFC 8693 在 OAuth 2.0 授權伺服器上下文中管理存取權杖簽發，需要可抵達的權杖端點 (Token Endpoint)。HDP 管理來源紀錄本身，它伴隨代理任務旅行，無論認證機制為何。三個架構差異重要：

1. RFC 8693 委派是點對點：每次交換產生新權杖。HDP 在單一權杖內攜帶只能追加的鏈，讓完整委派歷史能從單一成品驗證。
2. RFC 8693 需要授權伺服器可用；HDP 驗證完全離線。
3. RFC 8693 未提供代理任務授權所需顆粒度的人類特定授權綁定或範疇來源。

2.3 JSON Web Token (RFC 7519) 與 JWT Bearer 權杖

JSON Web Token (JWT) [12] 提供廣泛用於代理系統中代理對代理認證的通用簽章格式。基於 JWT 的代理委派做法，如 Agentic JWT [13]，將動作綁定到認證過的意圖，但在指令抵達動作層之後無法防止注入後的範疇擴張。HDP 與 JWT 在三點不同：

1. HDP 權杖攜帶只能追加、多方簽章的委派鏈，沒有 JWT 等價物。
2. HDP 使用 RFC 8785 Canonical JSON 做簽章，而非 base64url 編碼的 header.payload。
3. HDP 的驗證流水線是特定於代理領域的，包含 session 綁定、hop 驗證與最大 hop 數檢查。

2.4 UCAN (User Controlled Authorization Networks)

UCAN [14] 定義基於能力 (Capability-based) 的授權權杖系統，使用與 JWT 共享的鏈式委派。UCAN 和 HDP 共享「委派鏈」概念但在範疇與設計目標上差異很大：UCAN 是通用能力授權系統，其委派鏈編碼由接收系統強制執行的可執行能力。HDP 專門是人類授權代理的來源紀錄 — 它不主張能力執行，也不需要 UCAN 所要求的 DID (Decentralized Identifier) 基礎設施。對於重視離線可運作與最小基礎設施額外負擔的部署，HDP 呈現一個更低複雜度的設計點。

2.5 Intent Provenance Protocol (IPP)

Intent Provenance Protocol [15] (draft-haberkamp-ipp-00) 解決與 HDP 相同的根本問題，並使用 Ed25519 簽章與只能追加的來源鏈。HDP 和 IPP 不互通，在部署情境上做出不同的架構權衡：

1. 撤銷：IPP 要求代理在每次動作前向中央撤銷註冊中心輪詢；HDP 使用帶 session 綁定的短壽命權杖，任何時刻都不需要註冊中心。
2. 信任錨：IPP 權杖包含一個「創世印章 (Genesis Seal)」，以密碼學方式把每個權杖連結到規格作者在特定 URL 的公鑰，將自主託管部署綁定到第三方密鑰；HDP 沒有創世印章，也不強加任何外部信任錨。
3. 身份模型：IPP 強制符合 W3C DID Core 的主體識別碼；HDP 支援不透明識別碼 (Opaque Identifier) 作為一等選項。

2.6 提示注入與問責表面

提示注入 (Prompt Injection) — 代理環境中的惡意內容凌駕其預期行為 — 是 HDP 來源做法針對的主要實務攻擊類別。Greshake 等 [4] 展示間接提示注入能在真實世界 LLM 應用中帶來資料竊取與服務中斷。Lee 和 Ryoo [5] 展示在多代理系統中，注入的提示能以蠕蟲式傳播模式在代理間自我複製。Ferrag 等 [16] 提出一套統一分類法涵蓋 30 多種攻擊技術，跨越輸入操縱、模型破壞與協議漏洞，明確地將以密碼學來源追蹤作為一種緩解方向。2025 AI Agent Index [17] 指出在調查的 30 個已部署代理系統中，只有 ChatGPT Agent 一個實作了任何形式的密碼學請求簽章，這個缺失使得證明代理實際做了什麼變得顯著更困難。

HDP 不在語意層預防提示注入。它提供的是證據軌跡 (Evidence Trail)，讓注入的動作在事後稽核中可被偵測：一個沒有有效 HDP 權杖卻執行的注入動作可歸因於遺失的委派事件；一個帶有偽造 hop 記錄在鏈中的注入動作可被偵測，因為偽造需要簽發者的私鑰。這把 HDP 定位為問責的基礎設施，而不是針對注入的完整防禦。

2.7 並行研究

Prakash [18] (arXiv:2603.24775) 從形式方法觀點獨立檢視代理式 AI 系統的授權來源。該工作確認的威脅模型與本文的缺口分析大致一致，代表對此問題的趨同共識。兩項工作提出不同技術進路：HDP 優先考量離線可驗證性與最小基礎設施，Prakash 的框架強調形式驗證性質。我們視為兩者為互補貢獻。

3 威脅模型

HDP 設計用來解決一個特定、有界的威脅：多代理流水線中終端代理動作與其原始人類授權事件之間的脫鉤。

3.1 攻擊者模型

我們考慮能做以下事的攻擊者：

• (A1) 透過間接提示注入 [4] 把對抗內容注入到代理的輸入流中，包括網頁、文件、資料庫欄位與 API 回應；
• (A2) 攔截並檢視代理之間傳輸的權杖；
• (A3) 嘗試在不同 session 中重放 (Replay) 擷取到的權杖；
• (A4) 嘗試偽造或修改權杖以聲稱錯誤的授權；
• (A5) 嘗試在委派鏈中插入偽造的 hop。

我們不建模：擁有簽發者 Ed25519 私鑰的攻擊者（密鑰外洩是操作安全問題，不是協議問題）；能破解 Ed25519 簽章安全或 SHA-512 碰撞抗性的攻擊者；能竄改 session 建立通道的攻擊者（假設由傳輸層機制保障）。

3.2 資產與目標

HDP 保護的資產：

• (P1) 人類授權事件的完整性，包括主體身份、宣告範疇與 session 綁定；
• (P2) 委派鏈的完整性，確保記錄的 hop 準確反映實際委派歷史；
• (P3) 權杖的不可重放性，跨 session 與過期後都不可重放。

HDP 不保護：權杖以外的代理行為；動作相對於宣告範疇的語意正確性（此為應用層關切）；權杖內容的機密性（權杖是簽章，不是加密）。

3.3 主要攻擊情境

HDP 設計偵測的四種主要攻擊情境：

• (S1) 代理執行某動作時沒有有效的 HDP 權杖，表示未經授權或注入的指令。
• (S2) 偽造權杖呈現錯誤的人類主體或範疇，透過根簽章驗證可偵測。
• (S3) 被竄改的鏈（某 hop 被修改或移除），透過 hop 簽章驗證可偵測。
• (S4) 來自先前 session 的重放權杖，透過 session 綁定阻擋。

4 協議規範

4.1 設計原則

HDP 根據五個有序原則設計：

1. 離線可驗證性 (Offline Verifiability)：驗證只需公鑰與 session ID。任何步驟都不需要網路呼叫、註冊中心查詢或第三方端點。這使其能在氣隙環境 (Air-gapped)、具間歇連線的邊緣部署和延遲敏感流水線中使用。
2. 自主主權 (Self-sovereignty)：任何組織都能簽發與驗證 HDP 權杖，無須向中央機構註冊或錨定第三方密鑰。
3. 防竄改證據 (Tamper Evidence)：從 header 到任何 hop 的任何欄位被修改，都能由驗證流水線偵測。
4. 最小足跡 (Minimal Footprint)：協議可用任何支援 Ed25519 和 JSON 的語言實作。
5. 設計隱私 (Privacy by Design)：主體身份欄位在結構上與稽核相關欄位可分離。

4.2 權杖結構

一個 HDP 權杖是個 JSON 物件，有六個頂層欄位：

{
  "hdp" : "0.1",
  "header" : { "token_id", "issued_at", "expires_at", "session_id", "version" },
  "principal" : { "id", "id_type", "display_name", "poh_credential" },
  "scope" : { "intent", "authorized_tools", "data_classification",
              "network_egress", "persistence", "max_hops" },
  "chain" : [ "hop_1", "hop_2", ... "hop_n" ],
  "signature" : { "kid", "alg", "value" }
}

圖 1：HDP 權杖的頂層結構

4.2.1 Header

Header 攜帶：

• UUID v4 的權杖識別碼 token_id；
• Unix 毫秒時間戳 issued_at（簽發時間）和 expires_at（過期時間，預設 24 小時）；
• session_id — 簽發者與代理框架在權杖簽發前已帶外建立 (Out-of-band) 的 session 識別碼；
• version — 鏡像頂層 hdp 欄位的版本字串；
• 可選的 parent_token_id — 用於重新授權鏈 (Re-authorization Chaining)。

4.2.2 Principal

Principal 物件以必要的 id 和 id_type 識別授權人。支援的 id_type 值：

• opaque — 應用自定義，沒有解析語意；
• email；
• uuid；
• did — W3C DID [19]；
• poh — 人性證明 (Proof-of-Humanity) 憑證。

HDP 不強制特定身份模型。did 類型為具有既有 DID 基礎設施的部署提供支援，但非必要。可選欄位包括 display_name 和 poh_credential。

4.2.3 Scope

Scope 物件記錄人類授權了什麼，由根簽章覆蓋，簽發後不得修改。必要欄位：

• intent — 自由格式自然語言授權陳述；
• data_classification — 以下之一：public、internal、confidential、restricted；
• network_egress（布林值）；
• persistence（布林值）。

可選欄位：authorized_tools、authorized_resources、max_hops。

代理動作對宣告範疇的語意驗證是應用層關切；HDP 提供紀錄，不提供執行。

4.2.4 Chain

鏈陣列是只能追加的。每個 hop 記錄：

• 序列索引 seq（從 1 開始）；
• 代理識別碼與類型；
• 可選的代理指紋；
• Unix 毫秒時間戳；
• 人類可讀的動作摘要；
• 父 hop 索引（根人類授權為 0）；
• hop_signature。

代理不得移除或修改既有條目。seq 中的間隔是協議違規。

4.3 加密構造

HDP 所有簽章都使用 Ed25519 [20] (RFC 8032)，以 RFC 8785 JSON Canonicalization Scheme [21] 提供確定性序列化。所有二進位欄位使用 Base64url 編碼 (RFC 4648 [22]，無 padding)。

4.3.1 根簽章

根簽章在權杖建立時計算，覆蓋 header、principal、scope 與空 chain。程序：

1. 建構未簽章的權杖物件；
2. 依 RFC 8785 序列化為 canonical JSON，不含 signature 欄位；
3. 在 canonical 位元組上計算 Ed25519 簽章；
4. base64url 編碼後附加為 signature.value。

簽章的有效負載對任何驗證者都是確定性可回復的。

4.3.2 Hop 簽章

每個 hop 攜帶 hop_signature，把新 hop 紀錄綁定到整個累積委派歷史與根簽章。簽章有效負載被建構為一個 JSON 陣列：

[root_sig_value, hop_1, ..., hop_(n-1), new_hop_unsigned]

其中之前已簽章的 hop 連同其 hop_signature 欄位一起被納入，而新 hop 不含其 hop_signature。這種不對稱至關重要：驗證者必須精確重建這個有效負載結構。按 RFC 8785 序列化後，以延伸代理的私鑰簽章。在 HDP v0.1 中，所有簽章都使用簽發者的密鑰；多密鑰委派 (Multi-key Delegation) 為 v0.2 計劃的功能。

鏈式構造意味著每個 hop 簽章都覆蓋所有先前的 hop 與根簽章。任何欄位事後修改、或插入偽造 hop，都會導致被竄改的 hop 及其後所有 hop 的驗證失敗。

4.4 驗證流水線

驗證者必須執行七個有序步驟。任何步驟失敗都導致立即拒絕：

1. 版本檢查；
2. 過期檢查對當前時間；
3. 根簽章驗證使用簽發者的公鑰；
4. hop 序列檢查（檢查間隔與重複）；
5. 每個 hop 的簽章驗證使用 4.3.2 節的有效負載重建程序；
6. max_hops 檢查對鏈長度；
7. session 綁定檢查，比較 header.session_id 與驗證者當前的 session。

一個可選的第八步驗證 Proof-of-Humanity 憑證（若已配置）。

驗證所需的完整信任狀態是：簽發者的 Ed25519 公鑰（32 bytes）、當前 session 識別碼、當前時間。任何步驟都不需要網路呼叫。這是一個強力的架構保證，使其能在氣隙、邊緣與延遲敏感環境中使用。

4.5 重新授權與多主體委派

長時間運行的 session 可能耗盡 max_hops、需要範疇擴展，或對高風險動作觸發重新授權 (Re-authorization)。新權杖透過在簽章前把 header.parent_token_id 設為先前權杖的 token_id 來取代 (Supersede) 原權杖。父子連結由新根簽章加密覆蓋，建立可稽核的範疇演化譜系。

多主體聯合授權 (Multi-principal Joint Authorization) 透過循序鏈結 (Sequential Chaining) 達成：人類 A 簽發權杖 T1；人類 B 簽發 parent_token_id 等於 T1 的權杖 T2。每個權杖都獨立簽章。驗證需要分別驗證每個權杖、驗證 parent_token_id 連結，以及驗證共享的 session_id。這提供可稽核的聯合授權，無需門檻簽章 (Threshold Signature) — 每位主體的授權都是獨立的簽章成品。

4.6 傳輸

HDP 權杖可透過 X-HDP-Token HTTP 標頭（base64url 編碼的 JSON），或透過參考以 X-HDP-Token-Ref（UUID token_id，搭配伺服器側儲存）傳輸。權杖不得在 URL 查詢參數中傳輸。簽發者可在 /.well-known/hdp-keys.json 發布 Ed25519 公鑰。IETF I-D 中已請求為兩個 header 欄位與 application/hdp-token+json 媒體類型申請 IANA 註冊。

5 安全分析

5.1 權杖偽造

偽造的權杖（header、principal 或 scope 欄位與原始簽發不同）會在驗證流水線第 3 步失敗。這一步的安全歸結為 Ed25519 在選擇訊息攻擊下的不可偽造性 (Existential Unforgeability under Chosen-Message Attack, EUF-CMA)。Ed25519（於 RFC 8032 規定）建立在 Curve25519 上，以 SHA-512 為雜湊函數。在隨機神諭模型下，Ed25519 的 EUF-CMA 安全性來自 Curve25519 離散對數問題的困難性 [23]。沒有簽發者私鑰的攻擊者無法為任何被修改的權杖產生有效的根簽章。

5.2 鏈竄改

對任何 hop 的修改（包括欄位修改、移除、重新排序，或插入偽造 hop）都會導致被竄改的 hop 及其後所有 hop 的簽章驗證失敗。這源自 4.3.2 節的鏈式構造：每個 hop 簽章都覆蓋所有先前的 hop 與其簽章。安全性歸結為 Ed25519 的 EUF-CMA，與 5.1 節論證相同。沒有簽發者私鑰的攻擊者無法偽造有效的 hop 簽章。

5.3 重放攻擊防禦

HDP 提供兩個正交的重放防禦：

1. 時間過期 (Temporal Expiry)：expires_at（預設 24 小時）確保捕捉到的權杖在有限視窗後失效。
2. Session 綁定 (Session Binding)：session_id 確保權杖只在簽發給它的特定 session 內有效。

兩者合起來確保被偷的未過期權杖對攻擊者只在原始 session 內有用。對於高安全性需求的應用，應使用分鐘級而非小時級的短權杖壽命。

5.4 提示注入緩解邊界

HDP 緩解但不完全防止提示注入（見 3.1 節攻擊者 A1）。一個使代理執行動作卻沒有延伸 HDP 鏈的注入動作會產生可偵測的間隙：終端動作缺少對應的委派紀錄。帶有偽造 hop 的注入動作可被偵測，因為偽造需要簽發者的密鑰。然而，一個複雜的注入指令使合法代理記錄一個真實的 hop、但動作摘要誤報了實際意圖，僅靠協議無法偵測。這種語意驗證邊界是應用層的責任。

5.5 隱私性質

Principal 物件可能包含個資 (PII)。簽發者應在接收代理不需要人類可讀身份時，使用不透明識別碼並省略 display_name。principal 與稽核相關欄位的結構分離讓實作能從轉發的權杖中剝離 principal。被剝離的權杖必須被標記為僅稽核 (Audit-only)，不得 被呈現給簽章驗證，因為移除 principal 會使根簽章失效。當 principal.id 包含可識別資訊時，HDP 權杖可能構成 GDPR Article 4(1) 下的個人資料；實作應套用適當的保留控制。

5.6 密鑰管理需求

所有 HDP 安全保證都依賴於簽發者 Ed25519 私鑰的機密性。實作必須把私鑰存放在秘密管理器、HSM 或等價的安全飛地 (Secure Enclave)。私鑰不得存放在原始碼、設定檔或生產環境變數中。密鑰輪替 (Key Rotation) 透過簽發新密鑰 kid 值的新權杖來支援，同時保留舊密鑰在驗證者密鑰集合中直到所有用該密鑰簽章的權杖過期。

6 實作與部署

6.1 參考實作

HDP v0.1 的參考實作以 TypeScript SDK 形式在 npm 上公開：@helixar_ai/hdp。SDK 提供權杖簽發、hop 延伸與七步驟驗證流水線。也提供 CrewAI 與 MCP 的 Python 整合。實作使用 noble-ed25519 做 Ed25519 運算，並使用符合 RFC 8785 的確定性 JSON canonicalization 實作。

6.2 整合模式

HDP 在協調層與代理式協調框架整合。典型整合模式：

1. 人類主體在 session 初始化時透過簽發者 SDK 簽發權杖；
2. 權杖附加到傳給協調代理的任務上下文；
3. 流水線中每位代理在收到權杖後驗證、帶上其預期動作摘要延伸鏈，並把延伸的權杖傳給下游代理；
4. 終端工具執行代理在執行動作前驗證完整鏈。

建議在每個 hop 驗證；對效能受限的部署，僅在終端代理驗證也是可接受的。

6.3 效能特徵

Ed25519 簽章驗證計算成本低，在現代硬體上小於 100 微秒 [24]。RFC 8785 JSON canonicalization 對權杖大小為 $O(n)$。對典型的 10 跳委派鏈，完整驗證在小於 2 毫秒完成，使 HDP 適用於高吞吐代理式流水線。權杖大小隨鏈長度線性增長；典型欄位值的 10 跳權杖約為 4–8 KB。

6.4 IETF Internet-Draft

HDP 協議已作為 IETF Internet-Draft (draft-helixar-hdp-agentic-delegation-00) 提交至 RATS (Remote ATtestation procedureS) 工作小組。I-D 定義了規範性協議規格、HTTP 標頭欄位與媒體類型註冊的 IANA 考量，以及本文第 2 節調查的相關研究比較。草案截至 2026 年 3 月為 active 狀態，可在 IETF Datatracker 取得。

7 限制與未來工作

7.1 v0.1 的單密鑰簽章

HDP v0.1 所有 hop 簽章都使用簽發者的密鑰，意味著代理不使用自己的密鑰簽章。這簡化了密鑰管理，但也意味著 hop 簽章只能證明 hop 在簽發者處被記錄，不能證明 特定代理產生它。HDP v0.2 將引入每代理密鑰綁定 (Per-agent Key Binding)，透過門檻或多簽章方案啟用能證明特定代理身份的 hop 簽章。

7.2 語意範疇執行

HDP 記錄人類授權了什麼，但不執行它。代理的動作在語意上是否與 scope.intent 一致是應用層關切。與 MI9 [25] 或 CaMeL [26] 等執行時策略執行系統的整合是自然延伸：HDP 提供來源紀錄，而執行時系統用它作為稽核輸入來偵測範疇違規。

7.3 多主體同時授權

目前多主體模型使用循序鏈結，要求主體按順序行動。計劃的 v0.2 延伸將引入同時多簽章原語 (Simultaneous Multi-signature Primitives)，使用門檻簽章方案，啟用 M-of-N 人類授權而無須循序依賴。

7.4 標準化路徑

IETF I-D 目前是個人提交狀態。進入 RATS 或相關 WG 的工作小組採用需要社群審查與經證明的實作。部署經驗的回饋將啟發未來修訂。與新興的 OpenID Foundation 代理式身份工作 [8] 對齊是互通性的優先事項。

8 結論

我們提出了 Human Delegation Provenance (HDP) 協議，解決多代理 AI 系統中一個結構性問責缺口：終端動作與其原始人類授權的脫鉤。HDP 提供一個輕量級、可離線驗證、自主主權的權杖方案，以密碼學方式把人類授權事件綁定到代理式委派鏈。我們把 HDP 置於既有委派與授權協議版圖中，證明了現有標準未能解決代理式流水線的多跳、只能追加、人類來源需求，並分析了 HDP 針對相關威脅模型的安全性質。

代理式 AI 系統能力與部署的增長使得 HDP 所解決的問責缺口成為日益增長的營運與監管風險。正如 Ferrag 等 [16] 所指出，密碼學來源追蹤是 LLM-代理生態系中浮現的一類協議漏洞的被確認緩解方向。2025 AI Agent Index [17] 記錄了在 30 個調查的已部署代理系統中，只有一個實作了密碼學請求簽章。HDP 為此能力提供了一個最小、可部署的基礎。

HDP 規格作為 IETF Internet-Draft 發布。TypeScript 參考 SDK 與 Python 整合已公開。歡迎關於協議設計的社群回饋、IETF 工作小組參與和部署經驗回報。

參考文獻

• [1] Chase, H. et al. LangChain: Building applications with LLMs through composability. GitHub Repository. https://github.com/langchain-ai/langchain. 2022.
• [2] CrewAI. Multi-agent orchestration framework. https://github.com/crewAIInc/crewAI. 2024.
• [3] Wu, Q. et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversation. arXiv:2308.08155. 2023.
• [4] Greshake, K. et al. Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security. 2023.
• [5] Lee, D. and Ryoo, M. Prompt Infection: LLM-to-LLM prompt injection within multi-agent systems. arXiv:2410.07283. 2024.
• [6] EU Artificial Intelligence Act. Regulation (EU) 2024/1689. Official Journal of the European Union. 2024.
• [7] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology. 2023.
• [8] OpenID Foundation. Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world. OpenID Foundation Whitepaper. 2025.
• [9] ISACA. The Looming Authorization Crisis: Why Traditional IAM Fails Agentic AI. ISACA Industry News. 2025.
• [10] Strata Identity. Agentic AI Security: A Guide to Strategies for AI Agent Security. https://www.strata.io. 2026.
• [11] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and Liu, C. OAuth 2.0 Token Exchange. RFC 8693. IETF. January 2020. DOI: 10.17487/RFC8693.
• [12] Jones, M., Bradley, J., and Sakimura, N. JSON Web Token (JWT). RFC 7519. IETF. May 2015. DOI: 10.17487/RFC7519.
• [13] Goswami, A. Agentic JWT: Binding agent actions to authenticated intent. In: Survey of Agentic AI and Cybersecurity. arXiv:2601.05293. 2026.
• [14] UCAN Working Group. User Controlled Authorization Network (UCAN) Specification v1.0. https://github.com/ucan-wg/spec. 2024.
• [15] Haberkamp, M. Intent Provenance Protocol (IPP). Internet-Draft draft-haberkamp-ipp-00. IETF. 2024.
• [16] Ferrag, M.A. et al. From Prompt Injections to Protocol Exploits: Threats in LLM-Powered AI Agents Workflows. arXiv:2506.23260. 2025.
• [17] Casper, S. et al. The 2025 AI Agent Index: Documenting Technical and Safety Features of Deployed Agentic AI Systems. arXiv:2602.17753. 2026.
• [18] Prakash, S. Authorization Provenance in Agentic AI Systems. arXiv:2603.24775. 2026.
• [19] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and Allen, C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation. July 2022.
• [20] Josefsson, S. and Liusvaara, I. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032. IETF. January 2017. DOI: 10.17487/RFC8032.
• [21] Rundgren, A., Jordan, B., and Erdtman, S. JSON Canonicalization Scheme (JCS). RFC 8785. IETF. June 2020. DOI: 10.17487/RFC8785.
• [22] Josefsson, S. The Base16, Base32, and Base64 Data Encodings. RFC 4648. IETF. October 2006. DOI: 10.17487/RFC4648.
• [23] Bernstein, D.J. and Lange, T. SafeCurves: Choosing safe curves for elliptic-curve cryptography. https://safecurves.cr.yp.to. 2014.
• [24] Bernstein, D.J. et al. Ed25519: High-speed high-security signatures. Journal of Cryptographic Engineering 2(2). 2012.
• [25] MI9 Project. Agent Intelligence Protocol: Runtime Governance for Agentic AI Systems. arXiv:2508.03858. 2025.
• [26] Debenedetti, E. et al. CaMeL: Defeating Prompt Injections by Design. arXiv preprint. 2025.
• [27] Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. IETF. March 1997.
• [28] Helixar Limited. HDP TypeScript Reference Implementation (@helixar_ai/hdp). npm. https://www.npmjs.com/package/@helixar_ai/hdp. 2026.
• [29] Helixar Limited. Human Delegation Provenance Protocol (HDP) v0.1 Specification. https://helixar.ai/labs/hdp. 2026.

術語對照表