【Agent 身份与安全】Agent 身份谱系：从 API Key 到委托 Token
内容提要
本文探讨了 LLM Agent 在调用 Gmail、Slack 和内部 API 时的身份验证问题，分析了身份模型的演变，从 API Key 到 Gen4 的 Token Exchange。重点在于管理代理身份、权限和撤销机制，确保资源服务器能够准确识别操作主体及其代理身份。引入委托 Token 提升了审计能力和安全性，解决了传统 OAuth 模型的局限性。
延伸解读
身份模型的演变与挑战
本文详细分析了从 Gen1 到 Gen4 的身份模型演变，强调了每一代在身份验证中所面临的挑战。尤其是 Gen2 和 Gen3 的局限性，如撤销失效和归因混淆，提示读者在选择身份模型时需考虑具体应用场景的需求。
委托 Token 的优势
引入 Gen4 的委托 Token 解决了传统 OAuth 模型的多项局限，提升了审计能力和安全性。读者应关注如何在实际应用中有效利用这些 Token，确保资源服务器能够准确识别操作主体及其代理身份，从而增强整体安全性。
风险与合规性考量
在身份验证过程中，尤其是使用 Gen2 和 Gen3 时，存在诸如权限静态和撤销失效等风险。企业在实施这些模型时，需加强合规性审查，确保能够有效应对潜在的安全威胁，避免因身份管理不当导致的合规问题。
Q&A
什么是 Gen4 委托 Token 的主要优势？
Gen4 委托 Token 具备可验证、可归因、可缩小和可撤销的安全属性，提升了审计能力和安全性。
Gen1 到 Gen4 的身份模型演变有什么关键变化？
身份模型从 Gen1 的 API Key 到 Gen4 的 Token Exchange，逐步解决了身份验证中的归因断裂、权限静态和撤销机制等问题。
为什么 Gen2 的用户 Token 直连存在风险？
Gen2 的用户 Token 直连存在撤销失效、归因混淆和存储泄露等风险，建议使用 Agent Gateway 进行中心化存储。
Token Exchange 流程中，用户授权的角色是什么？
在 Token Exchange 流程中，用户授权确保了代理方能够合法地代表用户进行操作，维护安全性和合规性。
如何解决 Gen3 的 Service Account 不支持用户归因的问题？
通过结合 Token Exchange，Service Account 可以换发用户委托的 Token，从而实现用户归因。
RFC 8693 定义了什么？
RFC 8693 定义了 OAuth 2.0 Token Exchange 的标准请求参数和响应结构，解决了如何换发 Token 的问题。
