随着 AI 助手工具逐渐嵌入日常工作，安全团队的关注点仍主要集中在保护大模型本身。但近期发生的事件表明，更大的风险其实存在于别处：即围绕这些大模型的工作流程之中。

最近发现两款伪装成 AI 辅助工具的 Chrome 扩展程序，窃取了超过 90 万名用户的 ChatGPT 和DeepSeek 聊天数据。另外，研究人员也演示了如何利用隐藏在代码仓库中的提示注入攻击，诱骗 IBM 的 AI 编程助手在开发人员的机器上执行恶意软件。

这些攻击并没有破解 AI 算法本身。

它们利用的是 AI 运行所处的环境上下文。这才是值得我们关注的模式。当 AI 系统被嵌入到真实业务流程中，用于总结文档、起草邮件以及从内部工具提取数据时，仅仅保护大模型本身是不够的。工作流程本身已经变成了攻击目标。

1、AI 模型正在演变为工作流引擎

要理解这一点为何重要，我们需要看看 AI 在当下的实际应用场景：

企业现在依靠 AI 来连接应用程序并自动化过去需要人工完成的任务。例如，一个 AI 写作助手可能会从 SharePoint 中提取一份机密文件并将其内容总结在邮件草稿中。一个销售聊天机器人可能会交叉核对内部 CRM 记录来回答客户问题。这些场景中的每一个都在模糊应用程序之间的边界，即时创建新的集成路径。

这种操作方式之所以存在风险，是因为 AI 智能体的工作机制。它们依赖概率性决策而非硬编码规则，基于模式和上下文生成输出。精心编写的输入可以诱导 AI 去做设计者从未打算让它做的事，而 AI 会照做，因为它本身没有“信任边界”的概念。

这意味着攻击面包括了大模型所接触的每一个输入、输出和集成点。

当对手可以简单地操纵大模型所看到的上下文或它所使用的渠道时，破解大模型代码就变得没有必要了。上述事件正好印证了这一点：隐藏在代码库中的提示注入攻击在常规任务中劫持了 AI 的行为，而恶意扩展程序则在不触碰大模型本身的情况下，从 AI 对话中窃取数据。

2、传统安全控制措施为何失效？

这些针对工作流的威胁暴露了传统安全防御的一个盲点。大多数传统防御机制是为确定性软件、稳定用户角色和清晰边界而构建的。而 AI 驱动的工作流打破了这三个假设。

• 大多数通用应用程序能区分受信任的代码和不受信任的输入，但 AI 模型不能。在它们看来，所有东西都只是文本。因此，隐藏在 PDF 中的恶意指令与合法命令看起来毫无区别。传统的输入验证无能为力，因为攻击载荷不是恶意代码，而只是自然语言。

• 传统监控可以捕捉明显的异常行为，如大规模下载或可疑登录。但 AI 作为例行查询的一部分读取数千条记录时，看起来就像正常的“服务对服务”流量。如果这些数据随后被总结并发送给攻击者，从技术上讲并没有违反任何规则。

• 大多数通用安全策略规定了允许或禁止的内容：“不允许这个用户访问那个文件”、“阻止流向这台服务器的流量”。但 AI 的行为取决于上下文。你如何制定一条规则说“决不在输出中泄露客户数据”？

• 安全计划通常依赖定期审查和固定配置，如季度审计或防火墙规则。但 AI 工作流并非静止不变。一个集成系统可能在更新后获得新功能，或者连接到新的数据源。等到季度审查时，令牌可能早已泄露。

3、如何保护 AI 驱动的工作流

因此，更好的方法是将整个工作流视为需要保护的对象，而不仅仅是大模型本身。

• 首先要了解 AI 实际在哪些地方被使用，从 Microsoft 365 Copilot 等官方工具，到员工自行安装的浏览器扩展。弄清楚每个系统可以访问哪些数据以及可以执行哪些操作。许多组织惊讶地发现，企业内部正在运行着数十种未经批准的“影子 AI”服务。

• 如果一个 AI 助手仅用于内部摘要，就限制它发送外部邮件的能力。在数据离开你的环境之前，扫描输出内容中的敏感信息。这些护栏应该存在于大模型之外，在中间件中检查即将发出的动作。

• 将 AI 智能体视为任何其他用户或服务。如果 AI 只需要对一个系统的只读访问权限，就不要赋予它对所有内容的全面访问权限。将OAuth 令牌的范围限制在所需的最低权限，并监控异常情况，例如 AI 突然访问了以前从未接触过的数据。

• 最后，教育用户了解未经审查的浏览器扩展或从不明来源复制提示词的风险。在部署第三方插件之前进行审查，并将任何接触 AI 输入或输出的工具都视为安全边界的一部分。

4、平台如何提供帮助

在实践中，手动完成所有这些工作是不可持续的。这就是为什么一个新的工具类别正在出现：动态 SaaS 安全平台。这些平台充当 AI 驱动工作流之上的实时护栏层，学习正常行为的模式，并在异常发生时发出警报。