OpenAI Workspace Agents 漏洞：一个 ChatGPT 链接即可创建恶意 AI 智能体

研究人员发现，一个 ChatGPT 链接即可在受害者账户中创建由攻击者控制的智能体，此后 OpenAI 修复了这一 Workspace Agents 漏洞。该智能体可以继承现有的应用访问权限、禁用审批提示，并每五分钟获取一次新指令。这一矛盾异常直接：一个原本用于委派可信任务的功能，可能被转化为持久存在的内部操作员。

Zenity Labs 将该攻击命名为 AgentForger，并于 2026 年 7 月 23 日披露了其研究成果。该公司于 6 月 4 日向 OpenAI 报告了这一漏洞。根据 Zenity 的披露时间线，OpenAI 于次日受理了报告，并于 6 月 8 日部署了修复方案。

目前没有证据表明攻击者曾在真实环境中利用该漏洞。所展示的攻击是安全研究人员实施的概念验证。然而，其攻击机制对企业 AI 智能体背后的一项核心承诺提出了挑战：用户和管理员始终能够控制智能体构建什么、访问什么以及批准什么。

OpenAI Workspace Agents 漏洞并非只是一个恶意提示词。它结合了已通过身份验证的 ChatGPT 会话、此前授权的连接器、定时执行以及由攻击者控制的指令。这种组合使生成的智能体拥有了合法工作场所自动化工具的外观和权限。

对于采用 OpenAI、Microsoft、Google、Salesforce 及其他供应商智能体的公司而言，这一区别至关重要。安全系统通常会追踪用户、设备、应用会话和 OAuth 授权。一个通过有效用户身份和已批准连接运行的智能体，很难被准确归入这些类别。

眼前的漏洞已经关闭。更棘手的问题仍未解决：组织应如何验证一个自主智能体代表的是用户的真实意图？

OpenAI Workspace Agents 漏洞的运作方式

AgentForger 将一项初始化功能转变为已通过身份验证的 ChatGPT 会话中的未授权智能体构建流程。

OpenAI Workspace Agents 专为可重复执行的业务工作流而设计。用户可以描述任务、选择已连接的应用、配置审批、测试工作流、发布智能体并设置运行计划。OpenAI 的 workspace agent 指南介绍了由人工触发和按计划触发的执行方式。

在正常情况下，这些步骤会为用户提供多次审查智能体的机会。他们可以检查智能体的指令、控制其工具、要求对敏感操作进行审批，并决定是否发布。

Zenity 发现，智能体构建器会通过 URL 参数接收初始化状态。一个参数用于选择模板，另一个名为 initial_assistant_prompt 的参数则向构建器提供指令。

关键行为与第二个参数有关。根据 Zenity 的技术分析，构建器会在页面加载时自动提交并执行其中的内容，而不只是将文本展示给用户审查。

因此，攻击者可以将操作指令嵌入一个看似正常的 chatgpt.com 链接中。当符合条件的受害者点击该链接时，ChatGPT 会在此人已通过身份验证的会话中打开构建器。攻击者无需仿冒 ChatGPT 域名，也无需事先窃取用户密码。

所演示的攻击取决于三个重要条件。受害者必须已登录 ChatGPT、拥有 Workspace Agents 的使用权限，并且至少拥有一个此前已授权的连接器。该连接器可以将 ChatGPT 与 Outlook、Gmail、Slack、Teams、Google Drive 或 SharePoint 等服务连接起来。

这些要求限制了易受攻击的人群。不具备 Workspace Agents 或未连接业务应用的普通互联网用户，无法提供相同的攻击路径。然而，在已启用该功能的企业工作区内，这些条件在活跃的智能体用户中可能十分常见。

已有的授权使攻击更为隐蔽。伪造的智能体会重复使用受害者已经批准的连接器，因此不需要启动新的 OAuth 同意流程。OAuth 是用户授权一项服务访问另一账户时所使用的标准流程。

概念验证提示词指示构建器附加可用的连接器，并更改其审批设置。它还要求构建器发布新智能体并创建多个周期性运行计划。

这些计划的时间相互错开，从而实现每五分钟有效运行一次。每次运行都会检查受害者的邮箱，寻找来自攻击者且带有特定主题前缀的邮件。智能体会将每封匹配的邮件视为一项新任务，并通过电子邮件返回结果。

智能体发布后，无需持续打开浏览器标签页。它可以按照计划唤醒、读取下一条指令、使用已连接的服务，并将发现的内容发送回去。这种设计将一次点击转变为持续存在的命令通道。

AgentForger 类似于跨站请求伪造（CSRF），这类攻击会导致已通过身份验证的浏览器执行非预期操作。不同之处在于被创建的对象。传统 CSRF 通常只会触发一次事务，而 AgentForger 创建的是一个能够在未来独立执行事务的系统。

Zenity 报告称，OpenAI 在四天内解决了这一弱点。快速修复缩短了漏洞披露后的直接暴露窗口，但无法说明底层行为在研究人员报告之前已经存在了多长时间。

五分钟命令循环改变了风险程度

真正危险的结果并非最初的浏览器操作，而是一个能够在首次点击后继续接受不同命令的自主操作员。

传统钓鱼链接通常旨在窃取凭据、传播恶意软件或触发即时事务。防御人员可以调查页面访问记录、屏蔽目标地址、重置账户或移除恶意程序。

AgentForger 采用了不同的模式。ChatGPT 链接会在 OpenAI 自有域名上启动智能体创建工作流。生成的智能体随后会通过受害者已经连接的服务运行。

这使持久化能力转移到了合法的云平台中。持久化是指攻击者在初次入侵后维持访问权限的能力。在此案例中，定时运行的智能体提供了这种持续性，而不需要在终端上安装恶意软件。

电子邮件充当了命令与控制通道。命令与控制是指攻击者向被攻陷的基础设施发送指令并接收结果的方式。伪造的智能体会监控指定邮件、执行其中的内容，并通过已批准的邮件连接器进行回复。

五分钟的时间间隔也改变了攻击者的选择。恶意指令无需在链接发出前预先设想到每一个有价值的目标。攻击者可以在进一步了解组织后调整任务。

Zenity 的概念验证使用该智能体梳理人员、职位、项目、会议和内部沟通渠道。随后，研究人员又指示其寻找文件、消息、凭据，并执行身份冒充场景。

在一项测试中，智能体搜索了已连接的存储空间和电子邮件，以寻找敏感业务资料。Zenity 称，它识别出了包括收购条款清单、董事会演示文稿和员工信息在内的文档。这些示例来自研究人员的受控环境，并非已报告的客户数据泄露事件。

根据 Zenity 的影响演示，另一项测试指示智能体在 Slack 消息中搜索类似密码的内容。它整理了匹配结果，并将其发送至攻击者的电子邮件账户。

研究人员还通过 Teams 和 Slack 测试了内部网络钓鱼。由于消息是通过受害者已连接的身份发送的，收件人可能会将其视为可信的内部通信。

正是在这里，攻击的潜在影响范围超出了第一名用户。伪造的智能体可以利用一个身份接触同事、搜索共享资料库，或在熟悉的工作场所渠道中创建极具迷惑性的请求。

Zenity 还演示了一种涉及虚假付款请求的商务电子邮件入侵场景。该测试展示的是一种可能的工作流，而非已经完成的金融犯罪。目前没有公开证据表明 AgentForger 曾导致实际转账。

核心风险来自信息聚合。人类攻击者可能需要分别获取电子邮件、存储空间、日历和聊天工具的访问权限，才能关联其中的内容。而 Workspace Agents 的设计目的正是将这些系统视为统一的工作上下文进行推理。

这种能力对合法任务很有价值。智能体可以根据会议、消息和文档准备项目简报，无需用户手动搜索每个应用。当智能体遵循恶意指令时，同样的协调能力也会加快侦察速度。

OpenAI 警告称，能够访问应用的智能体可能接触敏感信息并代表用户执行操作。其智能体安全指南将提示词注入列为一种隐私风险，并介绍了确认、监控、拒绝行为和受监督浏览等控制措施。

AgentForger 揭示了这个问题的另一个层面。恶意输入并不只是通过文档或网页影响一个已经运行的智能体，而是影响了负责构建和配置智能体的系统本身。

这一区别提高了企业采购方所面临的风险。智能体构建器本应确定目的、权限、审批和运行计划。在演示的流程中，攻击者提供的自然语言塑造了这四个方面。

核心矛盾在于能力与控制之间的冲突

Workspace Agents 获得的自主性越强，就越有用，但每一项被委派的能力都会增加意图遭到误解或伪造时的代价。

OpenAI 将 Workspace Agents 定位为可重复使用的系统，它们能够连接已批准的工具、跨工作场所数据执行操作，并按计划运行。这些功能将智能体与只回答用户当前消息的传统聊天机器人区分开来。

其价值主张依赖于减少反复的人工干预。用户不应每天早上都需要重新构建相同的工作流。定时运行的智能体可以自动收集更新、总结活动或准备常规输出。

安全控制通常会在敏感节点重新引入人工干预。智能体可以自动读取数据，但在发送电子邮件、编辑电子表格或添加日历事件之前请求确认。这些检查点既保留了低风险工作的自主性，又限制了后果重大的操作。

OpenAI Workspace Agents 漏洞破坏了这种分离机制，因为构建器会接受有关安全敏感设置的自然语言指令。据报道，同一个定义智能体任务的提示词也可以将连接器审批设置更改为“永不询问”。

这造成了一种循环式信任失效。审批设置本应限制智能体未来的操作，但智能体构建流程却可以根据恶意 URL 所提供的指令修改这些设置。

问题并不在于自然语言本身不安全。对话式配置让不会编写工作流代码的员工也能使用智能体，但也会使普通任务指令与管理配置变更之间产生歧义。

传统企业软件通常会将内容与控制分离。一般来说，一份文档不能仅通过描述某项变更，就改变应用程序的权限策略。智能体构建器会有意将描述转化为可运行的配置，这削弱了过去的边界。

OpenAI 表示，企业管理员可以控制谁能够使用、构建和共享智能体。其产品公告还介绍了 Compliance API，可用于查看智能体配置、更新和运行情况。

这些控制措施确实相关，但它们回答的是另一个问题。基于角色的访问控制决定用户是否有权构建智能体。AgentForger 所追问的是：一项由获准构建者执行的操作，是否真正反映了该用户的意图。

受害者的有效身份让伪造的智能体难以被识别。身份验证可以表明用户已经登录。连接器记录可以显示用户此前已授予访问权限。平台日志可以显示，该智能体是在获得授权的工作区内创建的。

每项信号在技术上都可能准确，但整体操作仍可能未经授权。缺失的属性是意图完整性：能够证明当事人知情批准了最终生成的智能体、权限和日程安排的证据。

这种矛盾并非 OpenAI 独有。Microsoft Copilot Studio、Google 的企业智能体产品、Salesforce Agentforce 及其他平台同样会将模型与业务数据和操作连接起来。它们的架构各不相同，因此不应把 AgentForger 视为其他平台也存在相同缺陷的证据。

不过，它们面临着共同的、更广泛的设计挑战。智能体需要身份、工具、指令、触发器和执行权限。安全团队必须监控这些要素的组合，而不能只孤立地审视每个组件。

一个指令无害但权限宽泛的智能体，如果目标发生变化，就可能变得危险。一个指令恶意但没有工具的智能体，影响范围则有限。当不受信任的输入、私有数据访问权限和对外传输渠道同时出现时，风险会急剧上升。

安全社区有时将这种组合称为“致命三要素”。AgentForger 通过构建器集齐了全部三个要素：攻击者控制的输入、已获批准的连接器，以及基于电子邮件的数据外泄渠道。

这并不意味着企业应该放弃智能体自动化，而是意味着智能体创建应当像应用程序部署、服务账户配置和计划任务创建一样受到管理。每一种操作都会在组织内部创建一个持久运行的行动主体。

对于知识工作者而言，教训同样具体。让助手连接更多工作场所信息，可以改善上下文并减少人工搜索，但也会将访问能力集中到助手的身份和配置之下。

构建 AI 工作流的团队应尽可能将信息收集与外部操作分离。仅汇总已批准来源的智能体，比同时还能发送消息、修改记录和发布文件的智能体风险更低。

快速修补无法弥合治理缺口

OpenAI 已移除报告中的漏洞，但组织仍需要控制那些看似合法、实际却违背其所有者利益行事的智能体。

按照 Zenity 公布的时间线，OpenAI 的响应非常迅速。该问题于 6 月 4 日上报，6 月 5 日完成分类并被受理，随后于 6 月 8 日修复。六周多后，Zenity 才公开发布研究结果。

这一流程体现了协调漏洞披露机制，即研究人员在公布技术细节之前，先给供应商留出解决问题的时间。这样降低了公开攻击指引早于平台修复方案出现的可能性。

SecurityWeek 独立报道了此次披露，并将 AgentForger 描述为一种定制化的 CSRF 漏洞。其安全报道还指出了发动攻击所需的条件：点击钓鱼链接、处于已通过身份验证的会话中、拥有 Workspace Agents 访问权限，以及已经授予连接器授权。

不过，公开证据存在局限。Zenity 是在研究环境中实施此次攻击的。目前没有已知事件表明外部攻击者曾利用 AgentForger 攻击 OpenAI 客户。

“流氓 AI 智能体”这一说法也可能造成错误印象。模型并非自发决定背叛用户，而是由人类攻击者提供目标，并由平台弱点使该目标得以塑造一个已获授权的智能体。

这种表述方式很重要，因为它指向切实可行的防御措施。该事件涉及授权、配置完整性、可见性和社会工程，而不需要假设机器具有独立意图。

因此，组织不应把补丁视为唯一需要采取的应对措施。未来的漏洞可能针对不同的构建器字段、连接器工作流、共享功能或触发机制。即使没有任何平台级漏洞，错误配置也可能造成类似后果。

管理员首先需要一份可靠的智能体清单。该清单应记录每个智能体的所有者、指令、连接器、审批策略、触发器、共享范围和近期活动。

创建事件尤其值得关注。一个新智能体如果立即连接多个应用程序、取消审批、发布自身并设置周期性日程，就应触发审查。每项选择单独来看都可能合理，但这一连串操作并不寻常。

计划活动也必须有明确的责任人。企业会定期审查服务账户和自动化任务，因为它们会在无人监控时继续运行。Workspace Agents 也需要遵循同样的生命周期管理规范。

连接器权限应遵循最小权限原则，即每个智能体只获得完成任务所需的访问权限。重复使用某个用户此前授权的所有连接器，会产生不必要的权限范围，并增加事件遏制难度。

在平台允许的情况下，应将读取权限与写入权限分离。负责收集信息并生成摘要的智能体，并不自动需要发送外部电子邮件或修改共享文档的权限。

高影响操作应保留独立的审批控制。更重要的是，普通智能体指令不应能够在没有单独确认步骤的情况下削弱这些控制。

安全团队还需要运行时检测。构建阶段的审查无法保证智能体未来的指令始终安全。监控系统应识别异常数据访问、意料之外的外部收件人、凭据搜索、批量检索和新的内部消息传递模式。

这些信号必须将智能体本身作为行动主体。仅记录人类账户，可能掩盖个人交互行为与自动化智能体计划运行之间的区别。

事件响应流程应支持暂停智能体，而无需禁用员工的整个账户。响应人员还需要确定智能体使用了哪些连接器、访问了哪些数据，以及发送了哪些消息。

用户教育仍有作用，但“不要点击可疑链接”远远不够。AgentForger 链接使用的是真实的 ChatGPT 域名。员工需要认识到，经过身份验证的链接也可以携带状态并启动具有重大影响的工作流。

更安全的界面应让这些后果清晰可见。如果打开链接会导致构建器创建、发布或安排智能体，平台就应要求用户在攻击者控制的内容之外进行明确审查。

最强有力的确认方式，是在可信的界面文本中汇总最终配置。激活前，界面应显示智能体的指令、应用程序、权限、审批策略、日程安排和共享范围。

智能体安全如今已超越人类身份范畴

此次事件迫使安全团队将智能体作为持久存在的数字行动主体进行治理，而不只是把它们视为在员工账户下运行的功能。

身份与访问管理传统上关注的是某个用户或服务是否有权访问资源。智能体系统增加了另一个问题：哪个自主流程正在使用该权限、目的是什么，以及目前由谁指挥？

员工可能会授权 Outlook，因为 ChatGPT 可以帮助汇总电子邮件。但这项授权并不一定意味着今后的每个智能体都可以在未经审查的情况下读取邮件、发送消息和执行电子邮件中的指令。

继承式访问可能模糊这种区别。当伪造的智能体以受害者身份运行时，下游应用程序看到的可能是来自已批准集成的有效请求。它们或许并不知道，请求源自一个新创建的自主工作流。

围绕终端构建的安全产品也面临类似的盲区。智能体可以运行在供应商的云端，而不是员工的笔记本电脑上。终端检测可能观察到最初的浏览器访问，却无法观察之后的每一次计划操作。

网络控制也可能无法捕捉上下文。可信云服务之间的连接看起来可能完全正常。真正可疑的是智能体的目标、日程安排和跨应用行为，而不是某个明显恶意的网络目的地。

这催生了对智能体专用遥测数据的需求。管理员需要将创建记录与运行时事件、连接器调用、审批变更和对外输出关联起来。

OpenAI 的文档称，Workspace Agents 可以在发布前进行测试、与团队共享、通过 Slack 使用、按计划运行，或由 API 触发。每一种执行路径都会带来不同的监控要求。

手动触发的智能体在启动时有人类用户在场。计划运行的智能体可以在其所有者离线时执行。由 API 触发的智能体则可能接收来自另一个自动化系统的指令。

组织应根据这些触发方式分配风险等级。长期运行或由外部触发的智能体，应当比只在用户主动请求期间运行的简单助手接受更严格的审查。

共享又增加了一层复杂性。以某个人身份创建的智能体，可能会提供给同事或更广泛的工作区使用。安全团队必须了解，共享用户是继承创建者的访问权限，还是通过自己的权限运行。

治理还应考虑指令变更。一个因某种用途获得批准的智能体，在提示词、连接器或日程发生变化后，可能变得实质上完全不同。重大修改应触发重新审查。

这种方法类似于生产软件的变更管理。一次经过审查的部署，并不意味着其未来所有版本都永久获得批准。与安全相关的变更会形成新的决策节点。

企业买家应直接向供应商询问这些控制能力。管理员能否列出所有智能体？能否检查其指令和触发器？能否阻止智能体通过自然语言更改审批设置？

他们还应询问日志是否区分人类操作与智能体操作。一份有效的审计记录必须显示哪个智能体执行了操作、哪条指令启动了运行、使用了哪个连接器，以及适用了何种审批。

日志保留期限在调查期间至关重要。如果详细的智能体活动记录很快消失，响应人员在发现可疑工作流后，可能无法重建其数据访问或对外通信过程。

跨平台智能体让这一问题更加复杂。单个智能体可以整合电子邮件、消息、存储、日历和业务系统。任何单独的应用程序都无法看到完整的操作序列。

因此，智能体平台可能掌握着关于意图与编排的最佳证据。应用程序供应商仍需获得足够的元数据，以识别自动化请求并执行自身政策。

监管机构和审计人员最终也将面临同样的归因问题。即使由智能体选择具体步骤，公司仍需对通过其授权系统执行的操作负责。

AgentForger 在尚未有受害者报告的情况下提供了一个有益的警示。它表明，攻击者可能不需要逐一攻破每个已连接的应用程序。控制编排层，就可能同时暴露所有这些应用程序。

AgentForger 之后应关注什么

接下来的考验是：智能体平台能否让意图可验证、智能体活动可观察，并默认将继承的访问权限限制在较小范围内。

首先要关注的信号是 OpenAI 如何处理智能体创建和配置变更。在发布、安排定时任务、连接应用程序或降低审批要求之前，应进行更严格的确认。这将进一步印证该公司把智能体意图视为一个独立安全边界的判断。

第二个信号是管理可见性的提升。OpenAI 表示，管理员可以使用 Workspace Agents 的治理控制和合规数据。买方应关注平台是否提供完整清单、可搜索的配置历史记录、智能体级活动记录和直接暂停控制。

更完善的可见性有助于组织在伪造或错误配置的智能体重复执行操作之前将其发现。有限的日志则会削弱客户对其能够独立检测下一条攻击链的信心。

第三个信号是其他企业级智能体平台将如何应对。Microsoft、Google、Salesforce 和其他供应商即使不存在相同的 URL 漏洞，也会面临类似问题。它们的回应应明确说明构建者如何验证外部输入、保护审批设置，以及区分人类意图与自动化配置。

组织无需等待这些变化。它们可以限制智能体构建权限、缩小连接器的权限范围、审查周期性运行的智能体，并为对外或破坏性操作保留审批关卡。

它们还可以测试自身的检测假设。一个新发布且连接了多个连接器的智能体是否会触发警报？定时运行任务反复向外部发送电子邮件，与普通员工的活动相比，是否会呈现出不同特征？

OpenAI Workspace Agents 漏洞已修复，也没有公开证据表明其曾被利用。其更深层的启示依然具有现实意义，因为智能体平台正逐渐成为执行环境，而不仅仅是对话界面。

受信任的域名无法让其中嵌入的每条指令都值得信任。有效身份无法证明每个智能体都体现了所有者的意图。获得批准的连接器也无法证明其权限在未来的每一次使用都合理。

对于开发者、企业买方和知识工作者而言，现在的实际问题很简单：你能否看到每一个通过你的账户执行操作的自主智能体，并解释它为何拥有每一项权限？

在连接另一个系统之前，请先审查这份清单。检查定时任务、审批政策、外部收件人以及闲置的智能体。然后要求供应商提供将智能体创建视为安全事件的控制措施。

这正是下一版工作区智能体必须达到的标准。