HDP：用于代理AI系统中人类授权可追溯性的轻量级加密协议 HDP: A Lightweight Cryptographic Protocol for Human Delegation Provenance in Agentic AI Systems
HDP协议通过轻量级token解决多代理AI系统的人类授权可追溯性问题
前置知识
Ed25519
Ed25519是一种基于Curve25519椭圆曲线的数字签名算法，使用SHA-512作为哈希函数，提供选择消息不可伪造性（EUF-CMA）安全保证。签名过程产生$(R, S)$对，其中$R$是随机点，$S$是基于私钥、消息和$R$的计算值。验证过程使用公钥$A$检查等式$8S B = 8 R + H(\text{message}, R) A$是否成立，其中$B$是基点。Ed25519的优势在于密钥生成快、签名确定性强、验证速度快，且对侧信道攻击有良好抵抗力。
HDP协议使用Ed25519进行所有签名操作，包括根签名和跳签名。理解Ed25519的安全属性对于理解HDP的防伪造和防篡改能力至关重要。
JSON Canonicalization Scheme (RFC 8785)
RFC 8785定义了一种确定性的JSON序列化方法，确保相同的JSON对象总是产生相同的字节序列。它规定了排序规则（对象键按Unicode代码点排序）、空格处理（移除不必要空格）、数字格式化（使用最短表示）和转义规则。例如，键为$b$和$a$的对象会被规范化为$a$在前$b$在后的顺序。对于数组，保持元素顺序不变。这种规范化确保了不同的实现序列化相同的JSON对象时产生相同的字节序列，这是数字签名正确工作的前提。
HDP使用RFC 8785进行JSON签名前的规范化，这是验证流程能够确定性地重建签名载荷的关键。理解规范化对于理解HDP如何防止结构篡改很重要。
多跳授权链
多跳授权链是指授权通过多个代理层层传递的过程。在代理AI系统中，人类授权给编排器代理，编排器分解任务后授权给子代理，子代理再授权给工具执行代理。每一跳都形成一个授权记录，形成链条$L = [h_1, h_2, \ldots, h_n]$，其中每个跳$h_i$包含代理标识、动作摘要和时间戳。这种多跳结构提供了完整的授权历史，使得终端动作可以追溯到原始的人类授权事件。
HDP的核心创新就是在token中携带完整的多跳授权链。理解授权链的概念对于理解HDP如何解决代理AI系统的可问责性缺失问题非常关键。
会话绑定
会话绑定是将token与特定会话标识符关联的技术，防止token在会话间被重放。HDP在header中包含session_id字段，验证时必须与验证者维护的当前session_id匹配。即使攻击者截获了有效的token，也无法在不同的会话中使用它，因为session_id验证会失败。会话ID通常在token签发前通过带外方式在签发者和代理框架之间建立，确保其安全性。会话绑定与时间过期形成了两个正交的重放防御机制。
会话绑定是HDP两大重放攻击防御机制之一（另一个是时间过期）。理解会话绑定对于理解HDP如何防止token重放攻击很重要。
追加-only链
追加-only链是一种只允许在末尾添加新元素、不允许修改或删除已有元素的数据结构。HDP的chain字段是追加-only的，每个代理只能向链末尾添加新的hop记录，不能修改、删除或重新排序已有的hop。跳签名覆盖所有前序跳和根签名，使得任何篡改都会导致后续所有跳的验证失败。seq字段的递增确保了跳的顺序性，任何gap都会被检测为协议违规。这种设计保证了授权历史的完整性和不可篡改性。
追加-only链是HDP防篡改保证的核心。理解这个概念对于理解HDP如何确保授权历史的完整性很重要。
研究动机
当前代理AI系统面临一个根本性的可问责性缺失问题：当人类授权给编排器代理，编排器再授权给子代理，子代理进一步授权给工具执行代理时，原始的人类授权与终端动作之间的连接逐渐断开。根据Strata的报告，非人类身份数量在平均企业中约为人类的50倍，80%的IT领导者报告代理的行为超出预期。OpenID Foundation将代理授权列为优先问题，指出当前协议难以表示代理可能建立子代理或同时代表多个主体的复杂授权序列。ISACA将其描述为迫在眉睫的授权危机，因为传统IAM框架依赖于预先定义的范围，这些范围过于粗粒度和静态，无法处理动态代理操作需求。
本文的目标是HDP协议的目标是提供一种轻量级的基于token的方案，用于在多代理系统中加密捕获和验证人类授权上下文。具体来说，HDP定义了一种JSON token结构，该结构在签发时记录人类主体、声明的授权范围和会话绑定，为授权链中的每个代理累积一个加密签名的跳记录，允许任何接收者仅使用签发者的Ed25519公钥和当前会话标识符来验证完整的可追溯性记录。
与已有工作不同的是，HDP的独特切入角度是专注于多跳、追加-only、人类可追溯性需求。OAuth 2.0 Token Exchange（RFC 8693）是点对点的，需要授权服务器可用性。JWT不提供追加-only链。UCAN需要DID基础设施。IPP要求轮询中央撤销注册表。HDP提供离线可验证性、自我主权、最小基础设施开销的设计点。
核心方法
HDP方法的核心思想是创建一个自包含的JSON token，将人类授权事件与代理授权链绑定，并支持完全离线验证。技术路线包括：使用Ed25519进行所有签名，使用RFC 8785进行JSON规范化，通过会话绑定和过期时间防止重放，通过追加-only链结构和跳签名链防止篡改，通过七步验证流水线确保安全性。验证只需要签发者的公钥和会话ID，无需网络调用或第三方信任锚。
HDP的核心创新在于将完整的多跳授权链编码到单个token中，使用追加-only链结构和跳签名链来确保完整性。跳签名构造是关键技术点：每个跳签名覆盖所有前序跳（包含它们的hop_signature）和新跳（不包含其hop_signature），这种不对称性确保每个跳签名覆盖整个授权历史。任何跳的追溯性修改或伪造跳的插入都会导致被篡改的跳和所有后续跳的验证失败。
方法步骤详情
HDP协议的工作流程包括token签发、链扩展和验证三个阶段。签发阶段：构造unsigned token对象（包含hdp、header、principal、scope、空chain），按照RFC 8785序列化（排除signature字段），使用Ed25519私钥签名，附加签名。链扩展阶段：构造新跳记录（包含seq、agent_id、action_summary等），构建签名载荷为数组[root_sig_value, hop_1, ..., hop_(n-1), new_hop_unsigned]，序列化，签名，追加到chain数组。验证阶段：执行七个有序步骤：版本检查、过期检查、根签名验证、跳序列完整性检查、跳签名验证、max_hops检查、会话绑定检查。
技术新颖性
HDP的技术新颖性体现在多个方面。签名构造创新的载荷不对称性确保完整性。离线可验证性降低部署复杂度，只需要32字节公钥和会话ID。自我主权设计无需中央注册，任何组织可签发和验证token。追加-only链提供强可追溯性，代理不能修改或删除现有条目。会话绑定与过期提供重放防御，形成两个正交机制。顺序链接实现多主体联合授权，无需阈值签名。结构分离支持隐私保护，符合GDPR要求。
实验结果
HDP协议通过安全分析和性能评估展示了其有效性。安全分析表明，HDP可以防御token伪造、链篡改和重放攻击。Token伪造会在验证步骤3失败，安全性归结为Ed25519的EUF-CMA。链篡改会导致被篡改的跳和所有后续跳的跳签名验证失败。重放攻击由临时过期和会话绑定防御。性能分析表明，Ed25519签名验证在当代硬件上在100微秒内完成，对于典型的10跳授权链，完整验证在2毫秒内完成，token大小约为4-8KB。HDP已作为IETF Internet-Draft提交，参考TypeScript SDK已发布。
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Ed25519签名验证 | 验证时间 | 100微秒 | N/A | N/A |
| 完整验证（10跳链） | 验证时间 | 2毫秒 | N/A | N/A |
| 10跳token | 大小 | 4-8KB | N/A | N/A |
局限与改进
作者承认了HDP的几个局限性。首先，HDP v0.1使用签发者密钥进行所有跳签名，意味着代理不使用自己的密钥签名，跳签名只证明跳是在签发者记录的。HDP v0.2将引入每代理密钥绑定。其次，HDP记录人类授权什么但不强制执行，代理动作是否与scope.intent语义一致是应用层关注点。第三，当前多主体模型使用顺序链接，要求主体按顺序行动。计划的v0.2扩展使用阈值签名方案实现同时多签名。
独立分析的弱点
HDP的几个弱点值得改进。单密钥签名限制：HDP v0.1使用签发者密钥进行所有跳签名，不证明特定代理的身份。改进方向：HDP v0.2计划引入每代理密钥绑定，使用阈值或多签名方案实现每代理身份认证。语义范围强制执行缺失：HDP只记录授权，不执行它。改进方向：与运行时策略强制执行系统集成，如MI9或CaMeL。多主体授权顺序依赖：当前多主体模型使用顺序链接。改进方向：使用阈值签名方案实现同时多签名。缺少撤销机制：HDP依赖短生命周期token与会话绑定。改进方向：可选支持撤销注册表或令牌撤销列表。
未来方向
作者提出的未来工作包括：HDP v0.2功能：每代理密钥绑定，同时多主体授权使用阈值签名方案。标准化路径：推进到RATS或相关工作组的工作组采用，这需要社区审查和演示实现。集成扩展：与运行时策略强制执行系统集成。基于成果的可延伸方向：跨框架互操作性，高级撤销机制，多租户支持，性能监控和分析，形式化验证使用Tamarin或ProVerif，与区块链集成提供额外不可篡改保证，AI治理合规支持EU AI Act。
复现评估
HDP的复现性评估如下。开源情况：参考TypeScript SDK（@helixar_ai/hdp）已在npm发布，Python的CrewAI和MCP集成也已可用。IETF Internet-Draft包含了协议规范。数据：论文提供了协议规范的完整描述，包括token结构、签名构造和验证流水线。算力要求：HDP的实现要求很低，任何支持Ed25519和JSON的语言都可以实现。性能分析表明，Ed25519签名验证在100微秒内完成，完整验证（10跳链）在2毫秒内完成。难度：复现HDP的难度较低，因为协议规范完整，参考SDK已发布，实现依赖于成熟的加密库。
论文图表
图1展示了HDP token的顶层JSON结构，包含六个顶级字段：hdp（协议版本，如0.1）、header（携带生命周期和会话绑定，包含token_id、issued_at、expires_at、session_id、version和可选parent_token_id）、principal（识别授权人类，包含id、id_type、可选display_name和poh_credential）、scope（记录授权意图和约束，包含intent、authorized_tools、data_classification、network_egress、persistence、max_hops）、chain（委托跳的追加-only数组，每个跳包含seq、agent_id、agent_type、timestamp、action_summary、parent_hop_index和hop_signature）、signature（携带根Ed25519签名，包含kid、alg、value）。
这张图对理解HDP的核心设计非常关键，它展示了token的整体架构，解释了HDP如何将人类授权、范围、委托链和签名组合到一个自包含的结构中。理解这个结构是理解后续签名构造和验证流程的基础。特别是chain字段的追加-only特性和signature字段的根签名作用，以及它们之间的关系，对于理解HDP的安全机制至关重要。