5 篇博文 含有标签「identity」

在你关停（sunset）一个智能体（agent）六个月后，一名安全审计员在团队的 Slack 上发消息问：“为什么这个 OAuth 应用仍然拥有公司 Google Workspace 的读取权限？”没人认得这个应用名称。有人 grep 了代码库——没有匹配项。有人检查了部署清单——也没有匹配项。最终，一位前任产品经理（PM）想了起来：那是会议摘要原型，一个在第三季度被砍掉的产品。面向用户的界面早已被删除。但 OAuth 授权、BigQuery 中的服务账号、Pinecone 索引、Slack 告警路由、Datadog 仪表盘、Splunk 保存的搜索、充满客户转录文本的评估数据集——所有这一切依然存在，依然已授权，也依然在计费。

这就是凭证残留问题，它是智能体时代最主要的运营失效。你发布的每一个智能体都会在各供应商、内部服务和数据系统中创建出一圈资源。当你通过删除代码来退役一个智能体时，你移除的可能仅占其创建内容的五分之一。剩下的部分作为“幽灵基础设施”留在生产环境中，无人认领、无人负责，而且最危险的是，它们依然持有凭证。

当你第一次将 MCP 服务器接入真实的生产系统时，你会发现教程中轻描淡写的一点：该协议赋予了智能体（Agent）能力，但并没有给工具服务器一个每个审计日志都要求的答案——这是代表哪个人执行的操作？ 你可以在不解决这个问题的情况下交付一个可运行的演示 demo，但如果不解决它，你无法向受监管的企业交付产品。而这两种状态之间的鸿沟，几乎完全是一个伪装成 OAuth 问题的分布式系统问题。

团队在这个鸿沟中寻求的解决方案，大致按尝试顺序排列，就像是把 OAuth 工作组十五年来一直警告的每一种反模式都游览了一遍。在 MCP 服务器环境中共享服务账号；将长期有效的个人令牌粘贴到配置中；或是乐观地认为“我们只需转发用户的会话 Cookie，让下游服务去处理就好”。每种方案在预发环境中都有效。但在安全审查第一次真正介入时，每种方案都会以不同的方式崩盘。

安全部门花了十年时间才彻底终结了“全能服务账号”。分限令牌、短期凭据、JIT 访问、逐操作审计——这整套最小权限方案终于落地并稳固下来。然而，AI 团队接入了一个智能体，提示词要求提供工具目录，于是工程师请求了平台所能发放的最广泛的 OAuth 作用域。已被弃用的模式换了一身新衣服又回来了，而这次调用 API 的主体是一个没人确定该如何限定作用域的随机循环。

这个智能体拥有日历、文件存储、CRM 和部署流水线的读写权限，因为 API 表面无法预先枚举。令牌是长效的，因为没人接入刷新路径。审计日志记录的是持有者，而非具体操作。IAM 负责管理人类和服务的身份，平台团队负责工作负载身份，AI 团队负责智能体的实际权限，而这三方集合的交集却无人管辖。

调出你今天早上的 SSO 日志。每一条 Slack 消息、每一个 GitHub PR、每一项日历邀请、每一次 CI 运行、每一条 Jira 评论——它们都显示着与人类手动输入完全相同的信息：一个人的名字、一个会话令牌（session token）、一行绿色的“身份验证成功”。从审计的角度来看，你根本无法分辨哪些行为来自人类，哪些来自人类启动后便置之不理的智能体。这就是“幽灵员工”问题，而且过去 12 个月里上线了智能体的团队几乎都面临这个问题。

导致这一问题的捷径是结构性的，而非疏忽大意。当你将智能体接入工具时，最简单的凭证就是工程师环境中现有的那个——他们的个人访问令牌（personal access token）、OAuth 会话或绑定设备的 SSO Cookie。替代方案则是一项平台级工程：配置一级身份（first-class identity）、在每个下游服务中进行联邦认证、将其接入审计流水线、构建针对每个实例的撤销机制。这些工作无法在一个 Sprint 内完成，也不会出现在功能路线图中。因此，智能体选择了“借用”。

大多数 AI Agent 架构都存在一个悄无声息的安全问题，直到出了事才会被发现。你构建了 Agent，用应用现有的服务账户凭证将其接入内部 API，上线生产，然后继续下一个任务。Agent 正常运行，用户很满意。而与此同时，在你的审计日志里，一个服务账户身份正在悄悄触碰 Agent 曾经需要访问的每一条客户记录、每一张账单表和每一份内部文档——却没有任何痕迹说明是哪个用户发起了什么请求，又是为什么。

这不是一个理论风险。当安全事件发生，或者当监管机构询问"3 月 14 日谁访问了这份数据"时，答案每次都一样：[email protected]。每一个操作、每一次请求、每一次读写——全部归结为同一个身份。审计记录在技术上是正确的，但在取证层面毫无用处。