AI 的第三次浪潮：协同工作同事打破了曾对 Agent 有效的安全模型
原创 TokenSecurity 2026-10-08 08:00 美国
发布时间：2026年9月30日
作者：Token Security
我们不再拥有耗费数年去适应变革的奢侈了。AI 驱动的工作方式一个月接一个月地不断演变；以至于在短短三年内，我们已经经历了与工作相关的 AI 的几个截然不同的浪潮，而下一波浪潮已不再只是浮现于地平线上，而是近在眼前。
首先出现的是基于会话范围（session-scoped）的聊天，其风险在于模型说了什么。接着是基于任务范围（task-scoped）的智能体，其风险在于模型做了什么。广义上讲，这就是我们目前所处的阶段，但目标靶心已经转移到了别处。真正具备持久性（persistent）的 AI 协同工作助手（coworkers）即将到来，随之而来的将是现有访问控制模型的瓦解。
正如在这个领域中所常见的那样，你可以从 AI 公司的用词中看出他们想要走向何方。微软将 agent 称为“数字同事（digital colleagues）”，而 OpenAI 的 Sam Altman 早在感觉像是上辈子的 2025 年 2 月，就勾勒出了虚拟同事（virtual co-workers）的蓝图。
这一愿景正在成为现实，我们需要调整我们的安全模型，以应对 AI 同事工作方式上的根本变化。
1. 持久性改变了一切
你应该尽早为此做好规划。几年来，我们尚能将 AI 硬塞进现有的访问控制模型中，但一个独立工作的“真正”同事需要一种全新的思考方式。
自主 agent 型同事将需要前置化的访问权限分配（access front-loading），或者一种对机器更友好（且安全）的权限配置方式。因为只有在有真人随时进行审查的情况下，一事一议（case-by-case）操作才行得通。真正的数字同事不能事事依赖常规审批，但应当能够在执行任务需要时请求额外的访问权限。
当前，为 AI agent 量身定制专属身份的配置方式仍远非主流。标准做法依然是使用 OAuth 授权、会话内交接（in-session hand-offs）以及服务账户（service accounts）。前两种选项通常将人类视为主体实体；而第三种则很少专门为 agent 创建。
持久性还在另一个层面上导致了数字同事凭证的风险状况（risk profile）发生变化：它们本质上正在变成一种常驻特权（standing privilege），就像人类员工一样。我们将需要管理它们的生命周期，包括至关重要的注销（deprovisioning）步骤，以确保安全。
此外还要考虑权限蔓延（access creep）问题。如果一个数字同事是持久存在的，它势必会不断积累来自不同项目的权限。对人类而言，权限蔓延是身份治理中最古老且未解决的难题；而对机器而言，情况必然会糟糕得多--这既是因为权限累积的速度，也是因为 agent 倾向于使用赋予给它们的所有权限。Agent 可能会将多个合理的授权组合在一起，形成某种无人意图给予它们的整体访问权限。
2. 每个人都需要去适应
企业并不是唯一需要适应第三波 agent 工作流的主体。目前，两个部署最广泛的 agent 平台并未为其 agent 颁发独立的凭证。无论是 Anthropic 还是 OpenAI，都没有在其托管的聊天产品中运行 OAuth 客户端凭证授权（client credentials grant）；而 ChatGPT 连接器（connectors）则直接拒绝服务账户和 JWT 断言（assertions）。
两者确实允许开发者通过其 API 向 agent 传递静态的 Bearer token，但这离真正的身份相去甚远。
结果是，AI 系统不仅拥有原本针对人类正常配置的全部常驻特权，而且日志也被污染了。当 AI 在其人类授予的特权下采取行动时，在任何审计追踪中，该人类通常会被记录为操作执行者。
保留“人在回路（human-in-the-loop）”的意图不仅影响了 AI，也给人类带来了负担。OAuth 假设人类会阅读授权确认屏幕并批准固定范围的权限列表。而 agent 很少会对初始权限感到满意；它们会在运行时发现工具并尝试使用它们。
每隔几分钟确认一次敏感操作既令人烦恼，又构成了安全风险，因为人的注意力是有限的。
3. 构建协同工作同事的人明确表达了他们的需求
OpenAI 的 ChatGPT Work 与 Codex 产品负责人 Tara Seshan 在 2026 年 8 月的 Lenny's Podcast 中，阐述了究竟是什么让 agent 变得真正有用。
模型智能只是其中的一部分。其余部分归结为她所描述的“基础务实（meat and potatoes tactical）”工作：访问数据、云基础设施以及可靠性。
她的比喻是：你招聘了一位同事，然后把他关在一个没有 Google Docs、Slack 或公司数据库访问权限的房间里。那个同事是不会有工作效率的。她认为，一个孤立的云端 agent 出于同样的原因也是毫无用处的。
她在需求上的判断是正确的。如果想要实用型的同事，必然要和人类员工一样，接触同一套系统。
Seshan 还描述了她的 agent 衍生出子 agent（spawning sub-agents）来并行化处理工作，以及在不久的将来，她的 agent 与协同工作同事的 agent 围绕共享任务展开协作。这两个都是合理的演进方向，但前提是假设存在一个目前尚不存在的身份模型。
当一个人的 agent 将工作移交给另一个人的 agent 时，执行操作的凭证属于刚好启动该链路的那个人类。
4. 谷歌在 2024 年构建了正确的模型，但从未正式发布
在 2024 年 5 月的 I/O 大会上，谷歌演示了一个名为 Chip 的 Workspace agent。Chip 拥有自己的 Workspace 账号、指定的角色、配置好的权限以及明确的目标集合。它加入聊天室，并根据其能看到的历史记录做出回答。
Workspace 副总裁 Aparna Pappu 当时表示，在“agent 化（agentive）”体验（如虚拟队友）能够应用到产品中之前，谷歌还有很多工作要做。Chip 最终停留在演示阶段。
谷歌（及其所有竞争对手）最终发布的是由协同工作者继承人类权限的 agent。
5. 应该怎么做
平台厂商已经开始进行适应性调整。微软推出了 Entra Agent ID，具备原生 agent 身份和指定的人类赞助者（sponsor）。Okta 在 Universal Directory 中增加了 agent 身份，配备短生命周期、具象化范围的 token 以及撤销路径。SailPoint 和 CyberArk 也推出了类似的产品。缺点是每个厂商都只在其自身的生态圈内保障 agent 的安全。
如果你希望做到平台无关（platform-agnostic），身份控制是你可以执行策略的唯一事实上的检查点，因为身份管辖着对每一项操作的访问。以下是你应该做的五件事：
寻找隐蔽的协同工作同事（shadow coworkers）。注册登记只能捕获那些有人记得去登记的 agent。通过它们的认证流量来检测它们。
给每个持久性 agent 一个独立的身份。如果它以人类身份进行认证，下游控制措施就无法区分两者，任何调查也无法正确归因操作。
记录人类所有者。带有有效凭证的无主（orphaned）agent 是与 agent 相关的常驻特权最常见的来源。
针对 agent 本身限制访问范围，而非启动它的人。一个读取 Jira 的 agent 不应该只因为启动它的工程师恰好同时拥有云提供商的写入权限，就持有同样能写入该云提供商的 token。
预先决定它的生命周期（何时失效）。数字同事不是基于特定项目的，因此它们不会绑定在项目上，但并不意味着你应该将它们配置为永久存在。假设它们“属于”的一个团队被解散了，或者负责某个 agent 的员工离职了--在创建 agent 时就写下这些条件，同时设置一个闲置期限，超时后它将自行过期。
6. 第三波浪潮对你的要求
对于第一波浪潮（风险由模型的输出驱动），我们有提示词过滤、安全栏（guardrails）和输出分类。对于第二波浪潮（具备基于动作的风险和人在回路的流程），重点在于访问控制和审批。第三波浪潮则移走了人类，留下了访问权限。
压力即将升级。Seshan 所描述的情景中，agent 可以衍生子 agent，并跨团队协作。一个人的同事可能很快就会把工作移交给另一个人的同事。只有在协同工作同事拥有独立身份的前提下，这些移交才是可治理的。换句话说：在给它安排工作之前，先给它发一张工牌。
对于我们在 Token 的团队而言，我们已经在根据 OAuth 授权、API 密钥和登录流量，识别您环境中运行的 AI agent 和 MCP 服务器（包括那些未经注册的）。我们为每个 agent 提供独立的身份和人类所有者，对其凭证进行范围限定和轮换，并在所有者离职或其处于闲置状态时将其注销。
（完）
本文转载自微信公众号「安全行者老霍」，查看原文。版权归原作者所有，如有侵权请联系删除。