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