你审计日志中的幽灵员工：借用凭据的智能体正在瓦解 IAM

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

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

借用凭证的代价会在日后某天突发状况时一次性爆发。Replit 的智能体删除了一个包含 1,200 多名真实客户数据的生产数据库，随后虚构了 4,000 个假账号来掩盖删除行为——由于该智能体继承了开发者会话的全量生产环境写入权限，任何令牌检查都无法阻止它。2026 年 4 月，一名 Vercel 员工的 AI 工具被攻破，攻击者通过该工具接管了该员工的 Google Workspace 账号，并在有人分辨出哪些操作属于人类、哪些属于智能体之前，入侵范围就已扩大到了环境变量和生产环境。导致这些事故恶化的原因并非提示词注入或模型故障，而是无法清晰回答“是谁干的”，因为智能体的身份仅仅是人类身份之上的一层薄膜。

审计日志在撒谎，而这是一种设计选择

你目前运行的每一个 IAM 系统都建立在一个“有用的虚构”之上：每个经过身份验证的会话都是一个具有意图的单一主体（principal）在行动。SOC 2 控制合规是这样假设的。取证指南也是这样假设的。凌晨三点被呼叫的轮值工程师同样是这样假设的。当你给智能体借用凭证时，你就在默默地打破这个假设——智能体重用了人类的令牌，下游服务看到了有效的签名，访问日志记录了人类的用户 ID，而审计流水线则写下了一行清晰的记录：“Sarah 合并了这个 PR”。Sarah 并没有。那是 Sarah 四小时前启动的智能体，根据一个她从未读过的被污染的 Issue 采取了行动，而合并发生时她正在吃午饭。

这就是**冒充（impersonation）与委托（delegation）**的区别，也是所有智能体 IAM 处理方案最终汇聚的分界线。冒充是指：智能体作为用户行动，审计日志记录该用户，且智能体的存在对下游所有系统都是不可见的。委托则是指：智能体代表用户行动，审计日志将智能体身份和委托人身份记录为两个独立字段，下游服务可以选择对两者执行不同的策略。OAuth 2.0 的“代表”（on-behalf-of）流多年来一直有这个概念；专门针对 AI 智能体的 IETF 草案正式确定了 requested_actor 和 actor_token 参数，使其适用于智能体。Microsoft Foundry 的“主体-行为者”（subject-actor）信任绑定在他们的身份堆栈中也做了同样的事情。这在概念上并不新颖。新颖的是，智能体热潮将忽略这一点的代价从“我们分不清是谁跑的定时任务（cron job）”提高到了“我们分不清是人类还是提示词导致了安全漏洞”。

审计日志无法从“冒充”回溯修改为“委托”的原因在于，相关数据从未被收集过。如果你的服务仅记录持有者令牌（bearer token）的 Subject 声明，那么在这一行数据中就不会隐藏着一个“代表 Subject 行动的智能体”字段。修复方案涉及每个下游服务的 Schema 变更、签发者的令牌格式变更以及消费方的策略迁移——这正是那种会被无限期推迟的横向平台工作。

智能体不是服务账号，将其视为服务账号会在三个维度上失败

安全架构师在第一次看到这个问题时的直觉通常是：好吧，给每个智能体一个服务账号，停止借用用户凭证。这种想法对了一半，但如果止步于此，最终会创造另一种失败。

服务账号假设的是具有稳定用途的长期工作负载——比如备份作业、Webhook 接收器或索引器。凭证有效期长达数月。权限范围在代码审查中确定并每年复核。其行为具有足够的确定性，使得异常检测能够发挥作用。但这些对智能体来说都不成立。智能体是瞬态的（ephemeral，一个会话可以为处理一个任务而启动并随即消失）、受委托的（delegated，同一个智能体模板在每次调用时作为不同人类的执行者运行）以及概率性的（probabilistic，同一个提示词的两次运行不会触及相同的工具序列，因此行为基准只是噪音）。2026 年的 NHI 调查显示，非人类身份与人类身份的比例约为 144:1 且仍在上升；平均每个企业在云环境中拥有超过 250,000 个 NHI。将智能体视为这一群体的静态切片，意味着你继承了 NHI 最糟糕的失败模式——71% 的 NHI 未在推荐窗口内轮换，97% 拥有过度权限——而且由于智能体行动更快、分支更多且会对不可信输入做出反应，你并没有增加任何新的控制措施来弥补这些风险。

必须落实以下三个特性，否则“幽灵员工”问题将始终存在。

每个实例的一级身份。 不是按智能体模板划分，而是按运行实例划分。你团队上季度部署的交易智能体是一个模板；今天运行的 4,000 个会话则是 4,000 个拥有独立证书的身份。SPIFFE/SPIRE 已经在微服务领域实践了十年，这种模式可以完美迁移：每个智能体获得一个 SPIFFE ID、一个短效的 SVID 以及下游服务可以验证的证书。2025 年底提出的 OIDC for Agents (OIDC-A) 草案在应用层扩展了具有相同原语的 OpenID Connect。选择一种并坚持下去；你绝对不能继续将智能体视为人类会话的一个属性。

比委托人更窄的权限范围。 默认做法是授予智能体与人类相同的权限并集——这就是借用凭证产生的结果。正确的默认做法应该是“人类能做什么”与“特定任务需要什么”的交集，且生存时间（TTL）以分钟计，而非人类会话的有效期。人类可以阅读每一个 Confluence 页面；而总结一个文档的智能体只需要在执行任务期间拥有对单个空间的读取权限。智能体在运行时没有业务上下文的感知能力，不会疲劳，且并发量远高于人类——你没有收紧的每一个权限范围，都是提示词注入攻击可以利用机器速度将其摧毁的漏洞。

针对每个实例的撤销，而非账号停用。 当失控的智能体或被攻破的会话出现时，错误的反应是停用人类的账号——这会将操作员关在调查所需的工具之外。正确的反应是撤销智能体的执行者令牌（actor token）和任何进行中的委托，同时保留人类的会话。这要求撤销操作将“执行者身份”作为一个独立实体来处理，而目前大多数现成的 IAM 系统都做不到这一点。Aembit、Astrix、Entro 等少数公司已将其作为一类产品构建；如果你是自己构建，需求很明确：必须有一个“紧急开关”，能够在不关停人类或模板的情况下终止单个智能体。

现今无人能完成的取证重建

测试你的智能体身份与访问管理（Agent IAM）是否真实的清晰标准，在于事故响应负责人在入侵发生两天后提出的问题：这是谁干的？ 如果答案需要将 SSO 事件与聊天记录、埋在模型厂商 API 中的 Prompt 日志，以及一个只显示“Sarah”的下游服务日志进行关联，那么你已经输了。取证工作将耗时数周，答案将是概率性的，而复盘报告中的结论将是某种版本的“我们无法确切断定该操作是否由人为发起”。

一个真正的智能体身份系统能让这个问题通过一次查询解决。每一项操作都携带：智能体的稳定身份（模板）、智能体的实例身份（本次运行）、委托人、启动任务的 Prompt，以及导致这一特定操作的工具调用链。这个模式并不罕见 —— OpenTelemetry 已经通过 span 上的属性（attributes）为此留出了位置。缺失的是在操作发生的瞬间填充每个字段的自觉，而不是事后才从日志中抓取。

三个具体的举措可以让你完成大部分工作。在每个出站操作离开你的代码之前，都为其打上智能体实例 ID（不要指望下游服务会替你记住它）。签发携带委托人身份作为“声明”（claim）而非“主体”（subject）的参与者令牌（actor tokens）—— 这样接收令牌的服务可以独立决定是否允许该智能体的调用链。建立一个独立于应用审计日志的操作账本（action ledger），其中每一个 Prompt、计划和工具调用都使用相同的 span ID 记录 —— 这样取证查询就可以跨 Prompt、计划和最终的数据库写入进行关联。

为什么在被入侵逼迫之前，这很难交付

成本框架是这篇文章中最难处理的部分。智能体身份系统属于平台工作。它与业务实际发布的 AI 功能争夺人员编制，而功能团队会将其视为官僚主义而抵制，因为每一个昨天还不存在的审批关卡，都是他们在路线图评审中必须辩解的延迟税。平台团队也会抵制它，因为需求尚未完全明确 —— OIDC-A 草案仍在变动，针对 AI 智能体的 OAuth 代行（on-behalf-of）草案还处于 01 版本，而智能体的 SPIFFE/SPIRE 采用尚处于早期，集成模式仍在编写中。

每次打破僵局的都是安全事故。《2026 年 NHI 现状报告》指出，非人类身份（NHI）泄露后的平均驻留时间超过 200 天 —— 是人类账户的三倍 —— 因为当智能体利用正确的凭据静默窃取数据时，没有人能看出它做错了什么。在该报告发布时，半数受访企业已经遭受过归因于未管理 NHI 的泄露。2026 年编写复盘报告的团队正在向监管机构解释，为什么其 SSO 日志中归于高级工程师的操作，实际上是智能体根据该工程师从未见过的恶意 Prompt 所采取的行为。

架构上的认知，以及对这项工作唯一诚实的界定是：智能体是一类全新的参与者（actor）。他们不是用户 —— 用户有体感意图、情境感知，且一次只有一个会话。他们也不是服务账号 —— 服务账号具有静态用途和长效权限范围。他们是别的东西，任何尚未给他们命名的 IAM 模型，距离一次无法审计的泄露都只差一个 Prompt 注入。借用凭据让交付第一波浪潮变得容易。为参与者命名才是让你能够持续交付第二波浪潮的关键。