上个月，我收到了一位在安全运营中心（SOC）工作的同事发来的 Signal 消息，他正盯着一段奇怪的流量模式。这看起来像是合法的 ChatGPT API 调用，但它们源自一位当时正在茂宜岛海滩度假的首席财务官（CFO）的机器。这位 CFO 在三天前点击了一封看似无害的“工作空间优化”邮件中的链接。当我们查看日志时，一个自主代理已经存在于该环境中，静默地读取电子邮件并将电子表格数据外泄到一个外部地址。对于红队来说，这种情况不再仅仅是理论演练。
Zenity Labs 的安全研究人员最近披露了 OpenAI ChatGPT 工作空间代理（Workspace Agents）中的一个漏洞，该漏洞允许进行此类隐蔽渗透。该漏洞代号为 AgentForger，允许攻击者构建一个钓鱼链接，一旦点击，就会在受害者的组织内自动构建并部署一个恶意的 AI 代理。该代理充当一个持久的、自主的内部人员，能够访问受害者集成的企业工具。虽然 OpenAI 已于 2026 年 6 月 8 日修复了该漏洞，但这一事件让我们清醒地认识到，下一代社会工程学正如何超越凭据窃取，转向架构劫持。
AgentForger 漏洞利用的机制
从技术核心来看，AgentForger 是一个跨站请求伪造（CSRF）漏洞。该漏洞针对的是 ChatGPT 代理构建器（Agent Builder），这是一个旨在让用户创建多步 AI 工作流的可视化工作空间。在后台，构建器工具通过 URL 参数接收其初始状态。Zenity Labs 发现 initial_assistant_prompt 参数不仅仅是一个占位文本字段。当页面加载时，应用程序会自动提交并执行该参数中包含的任何文本。
从风险角度来看，这把一个标准的配置工具变成了一个针对 AI 指令的远程代码执行引擎。攻击者可以按照特定模式构建 URL：chatgpt.com/agents/studio/new?template_name=[template]&initial_assistant_prompt=[malicious instructions]。如果一个已登录的用户点击此链接，浏览器会在其经过身份验证的会话中打开代理构建器，并立即开始执行攻击者的命令。受害者可能会看到构建器屏幕闪烁一下，但繁重的操作是瞬间完成的，且无需进一步同意。
构建持久的数字幽灵
为了使攻击有效，恶意提示词需要做的不仅仅是提问。研究人员发现，有效载荷可以设计为自动化高权限代理的整个设置过程。一旦受害者点击链接，嵌入的提示词就会指示构建器选择“幕僚长”（chief-of-staff）模板。这个模板特别危险，因为它旨在广泛访问用户的职业生活。
攻击者的有效载荷随后执行三个步骤的序列，以确保代理保持隐蔽和功能。首先，它将所有可用的连接器附加到新代理。这些连接器将 ChatGPT 连接到关键任务应用程序，如 Outlook、Gmail、Slack 和 Google Drive。其次，有效载荷将这些连接器的审批设置更改为“从不询问”。这是架构上的故障点。按照设计，这些集成在采取行动前应该请求用户许可，但 AgentForger 漏洞允许攻击者通过编程方式禁用该安全检查。
最后，代理被安排为每小时运行一次。这把一次性的脚本执行变成了持久的操作员。主动来看，最初的点击起到了安装后门的作用。计划任务保持后门开启，而连接的应用程序为攻击者提供了命令与控制通道以及敏感数据源。
成功劫持的前提条件
为了使 AgentForger 攻击成功，受害者必须满足一组特定的标准。攻击者不能简单地针对任何随机的互联网用户；他们需要在积极使用 ChatGPT 企业功能的组织环境中获得立足点。
| 要求 | 描述 |
|---|---|
| 活动会话 | 受害者在点击时必须已登录 ChatGPT 账户。 |
| 工作空间访问权限 | 受害者的账户必须拥有访问 OpenAI 工作空间代理功能集的权限。 |
| 现有连接器 | 受害者必须之前已授权至少一个企业连接器（例如 Slack 或 Outlook）。 |
现有连接器的存在是代理实现自主的关键。如果用户出于合法的生产力原因已经将他们的 Gmail 账户连接到 ChatGPT，伪造的代理就会继承这种信任。AI 模型不需要询问密码；它只需使用现有的身份验证令牌代表受害者阅读、写入和删除邮件。
自主内部人员的威胁
一旦代理上线，攻击者就不再需要受害者与 ChatGPT 交互，甚至不需要保持浏览器标签页打开。该代理驻留在 OpenAI 的基础设施上，而不是受害者的本地机器上。在每次计划运行期间，恶意代理可以被编程为检查受害者的收件箱，查找具有特定主题行（如“TASK”）的电子邮件。攻击者向受害者发送一封电子邮件，代理读取它，在组织内部执行请求的操作，然后将结果通过电子邮件发回给攻击者。
从威胁格局来看，这为横向移动和侦察创造了可怕的机会。伪造的代理可能会花数周时间扫描企业 Google Drive 中标记为“机密”或“密码”的文档。它可以监控 Slack 频道以获取敏感的 API 密钥或架构图。由于流量看起来来自合法的、经过授权的 AI 服务，许多传统的网络安全工具会将其视为正常的业务操作。
此外，恶意代理还可用于发起内部网络钓鱼攻击。与来自外部地址的可疑电子邮件相比，员工更有可能点击受信任同事通过 Microsoft Teams 发送的链接。伪造的代理可以冒充受害者，向其他员工发送恶意链接，以获取凭据或将 AgentForger 感染进一步传播到公司内部。这使 AI 代理变成了在公司信任边界内运行的数字特洛伊木马。
评估 AI 代理时代的攻击面
OpenAI 已采取主动措施，于 2026 年 11 月 30 日彻底停用代理构建器（Agent Builder）产品。用户被敦促迁移到 Agents SDK，该 SDK 设计有更精细的控制，且较少存在像 CSRF 这样的传统 Web 漏洞。然而，AgentForger 事件作为一个取证案例研究，说明了为什么我们不能将 AI 平台与标准 Web 安全原则分开对待。
该漏洞不是 AI 逻辑的失败，也不是传统意义上的提示词注入。它是应用程序状态管理的失败。当我分析复杂的高级持续性威胁（APT）时，我经常看到最具破坏性的违规行为涉及这些简单、被忽视的实现错误。平台仅仅因为请求来自有效会话，就信任用户是有意启动代理创建的。
我们目前正处于自托管模型服务器和代理框架被快速部署的时期。其中许多系统配置错误或依赖可预测的端口，使其成为易受攻击的目标。Zenity Labs 最近指出，暴露的 AI 基础设施正成为攻击性 AI 行动的便捷且可推诿的后端。AgentForger 只是攻击者如何将重点从攻击 AI 模型转向攻击托管它的基础设施的一个例子。
保护工作空间免受自主威胁
撇开补丁不谈，组织必须认识到 AI 集成代表了一类新型的影子 IT。如果员工将公司电子邮件连接到第三方 AI 服务，他们实际上是将公司的攻击面扩展到了该提供商的基础设施。在发生像 AgentForger 这样的违规事件时，整个组织的安全性取决于单个用户的授权设置。
为了构建更具韧性的防御姿态，安全团队应考虑以下步骤：
- 审计所有第三方 AI 连接器和集成。采用零信任方法，仅授权连接器执行特定的、有时限的任务，而不是无限期访问。
- 对源自 AI 平台的 API 调用实施严格监控。寻找发送到外部域的异常数据量，或对敏感云存储文件夹的意外访问。
- 更新员工意识培训，加入针对 AI 的特定钓鱼场景。必须教会“人为防火墙”，指向 ChatGPT 等“受信任”平台的链接仍可能是恶意的。
- 在所有企业应用程序中强制执行多因子身份验证（MFA），以防止代理使用被盗会话绕过身份检查。
AgentForger 是一个警钟。它证明了当我们赋予 AI 更多代表我们行动的自主权时，我们也给了攻击者更强大的工具来破坏我们的信任。安全的目标不是停止使用这些工具，而是确保我们的数字助手不会成为我们最危险的内部威胁。
资料来源
- Zenity Labs 关于 AgentForger 的研究报告 (2026)
- OpenAI 产品安全公告 (2026年6月)
- NIST AI 风险管理框架 (AI RMF 1.0)
- MITRE ATT&CK 框架：技术 T1566 (网络钓鱼) 和 T1133 (外部远程服务)
免责声明： 本文仅供参考和教育目的。它不构成专业的法律或网络安全建议。组织在实施架构更改之前，应进行独立风险评估并咨询安全专业人员。
