是谁在发送此请求？Agent 身份验证入门 (Agent Auth 101) - Kamil Potrec, Keycard

하이라이트

• 传统服务账户本质上是一个拥有特权的权限池，而智能体的不确定性进一步放大了这一安全风险。

• 许多人在使用大语言模型智能体时，往往采用随意堆砌凭证的盲目做法，导致缺乏归属和撤销机制的凭证四处散落。

• 动态凭证机制（如 OAuth）和工作负载身份联盟能够将权限范围限定于特定的交互和工具中。

• 通过建立网关可以形成物理控制层，将凭证移出智能体的触及范围，从而实现即时吊销与精细控制。

• Keycard 构建了一个统一的控制平面，能够为智能体赋予身份、颁发令牌并提供策略与审计功能。

타임라인

1. 00:43 - 05:14

   智能体带来的凭证安全挑战

   用户和智能体在与各种工具和 MCP 服务器交互时，经常会将个人访问令牌或静态密钥留在各处。由于智能体具备自主推理和执行动作的能力，它们可能会在无意或恶意的情况下将数据发送给错误的对象。这种情况下，传统的服务账户和静态凭证无法提供明确的责任归属，从而带来了巨大的安全隐患。

   • 智能体通常需要 API 密钥和远程 MCP 服务器凭证来执行推理与工具调用。
   • MCP 服务器和后端服务往往依赖服务账户，导致权限过于集中。
   • 智能体的非确定性行为使得请求的发起主体难以界定，容易引发凭证滥用。
2. 05:14 - 08:20

   利用现有技术构建动态身份机制

   虽然过去传统的软件开发对这类身份验证要求较宽松，但具备自主执行能力的智能体彻底改变了这一现状。通过复用成熟的 OAuth 技术以及工作负载身份联盟，可以让凭证的生命周期变短，并且严格局限于正在使用的工具中。不过，当系统扩展到成百上千个 API 时，协调不同的授权服务器和委托流程变得非常棘手。

   • 通过 OAuth 等动态凭证机制，可以让智能体根据特定交互动态请求授权。
   • 使用工作负载身份联盟或私钥身份验证，使智能体在获取凭证前先进行身份验证。
   • 在规模化场景下，需要同时面对数百个不同的 API、多种类型的智能体以及复杂的归属问题。
3. 08:20 - 16:16

   软件开发包（SDK）的局限性与网关方案

   构建一个合格的智能体身份系统需要在身份签发、策略执行和审计日志等多个环节进行投入。由于编写共享库或 SDK 存在采用率不足、多语言适配困难以及无法防范智能体主动绕过等问题，行业需要更硬性的物理控制层。网关作为物理控制层位于网络路径上，不仅能将敏感凭证隐藏起来，还能对每一个请求进行动态拦截、精细权限控制以及即时吊销。

   • 完整的智能体身份验证系统需要包含独立身份、委派语义、短命凭证、联邦信任以及策略审计。
   • 仅仅依靠客户端 SDK 无法有效阻止执着的智能体去访问和管理环境内的凭证。
   • 通过引入网关可以将凭证移出智能体的执行环境，并实现即时吊销和精细控制。
4. 16:16 - 18:26

   Keycard 统一控制平面与参考实现

   为了避免所有人都在重复实现相同的功能，Keycard 提供了一个统一的控制平面，集成了身份赋予、令牌颁发、联邦集成和策略审计。演讲最后强调了单打独斗无法赢得安全这场比赛，并建议开发者访问相关网站了解参考实现，共同探讨如何解决智能体身份验证的问题。

   • Keycard 构建了统一的控制平面，提供智能体身份、令牌颁发、策略、审计以及客户端和服务端 SDK。
   • 智能体身份验证已是不可或缺的安全需求，开发者应当使用开放标准来保证互操作性。
   • 项目方在 agentbaseline.org 发布了软件工厂参考实现，供开发者参考与合作。