外观
SUDP：避免 Agent 持有可复用密钥的操作委托协议
摘要
SUDP（Secret-Use Delegation Protocol）针对 Agent 为用户调用 API、消息或云服务时的“授权即暴露”问题：若可复用 Token 或由它派生的材料进入 Agent 运行时，一次提示词注入或工具侧失陷就可能转化为持续账户权限。该协议让 Agent 仅提出规范化操作，由用户用新鲜认证器确认，再由独立 Custodian 使用密钥完成受限的一次操作。
论文把问题形式化为 Agent Secret Use，并给出授权完整性与密钥保密性的七项性质。作者在给定签名、AEAD、WebAuthn PRF、操作规范化和 Custodian 状态完整性等假设下证明其中六项；第七项仍依赖硬件根运行时。结论是协议约束，不是对现有 Agent 或 OAuth 部署已经安全的实测证明。
协议定位与核心差异
原研究贡献是将“Agent 可以请求一项用户授权的密钥操作、但不能获得可再次使用的授权材料”定义为独立问题，并把用户、请求方与持有密钥的 Custodian 分离。现有的秘密管理、scope、Token Exchange 和运行时监控各自覆盖部分风险，但没有共同规定操作绑定、单次消费、授权人可见性和请求方不可取得可复用能力这一组合目标。
本站分析认为它与一般短期 Token 委托的差异在于：授权对象不是抽象 client 或 scope，而是预先规范化的具体操作；密钥始终留在 Custodian。首个需要修复的控制是执行侧把可复用凭据暴露给不可信请求方，因此归入身份、认证与授权委托，而不是提示词注入入口或工具选择问题。
架构和消息流程
- 请求方
R（Agent 运行时）生成完整且规范化的操作o，但不读取密钥。 - 授权人
U在可信呈现中查看o的目标、范围、绑定数据和有效期，并用认证器生成一次性授权。 - Custodian
T校验授权与新鲜度，以内部保存的用户密钥执行o，消费该授权并清除临时材料。 - 外部服务只接收由
T发出的操作；R最多获得结果或回执，不能得到可重放的密钥、grant 或派生凭据。
协议的关键前提是操作序列化不能遗漏任何会影响权限的字段，用户看到的呈现必须忠实于该序列化，且 T 的单次消费状态不可被并发绕过。若这些前提不成立，签名本身不能阻止“用户批准 A、执行 B”。
安全风险
威胁对象是能影响 Agent 上下文或工具输出的攻击者。传统架构中，攻击者诱导 Agent 发起越权 API 调用后，运行时已经持有可复用密钥，后续调用不必再次经过用户确认。SUDP 不声称消除上游诱导：它把后果限制为请求一项必须被用户确认、且可由 T 重新核对的操作。
作者定义的性质包括操作与授权绑定、单次使用、授权可见性、请求方不接触密钥、秘密材料不因协议交互泄露，以及密钥轮换/撤销条件。它们不覆盖被攻陷的 Custodian、被欺骗的用户确认界面、外部服务本身不正确执行操作等情形。
实现与验证建议
论文给出参考实现，并以 WebAuthn PRF、签名、AEAD 和 HPKE 实现实例；协议证明以标准密码学假设为条件。本站未独立运行该实现。
部署验证应故意向 Agent 注入伪造工具说明、重放已消费 grant、替换操作参数和并发兑换请求，检查 T 是否拒绝；同时核对用户界面显示的对象、金额、资源和期限与 o 的规范化字段逐字一致。应记录授权、消费、拒绝和撤销事件，但日志不得记录密钥或可重放授权材料。
局限与待验证问题
- 证明依赖 Custodian 状态完整、可信渲染和操作字段完整性；这些是实现与产品界面最容易偏离的前提。
- 论文的保证是协议级的，未对主流 Agent 框架、OAuth 提供方或真实高频审批工作流做可用性实验。
- 用户逐次确认可能造成审批疲劳；如何安全地批量化仍需要受限委托、撤销和服务端策略的实证。
- 公开实现和形式化论证属于作者材料，尚无独立复现；因此本文采用 moderate 证据等级。