当你部署企业级 AI 时，你也制造了内部威胁

大多数企业安全团队都有一套相当成熟的内部威胁模型：心怀不满的员工将文件下载到 USB 驱动器，将电子表格发送到个人邮箱，或者带着凭据离职。检测策略是已知的 —— DLP 规则、出口监控、UEBA 基准。这些策略没有考虑到的是这样一种场景：你给每位员工都提供了一个能够以机器速度规划、执行并掩盖多阶段操作的工具。这正是部署 AI 编程助手和基于 RAG 的文档代理的实际效果。

问题并不在于这些工具在隔离状态下是不安全的。而在于它们极大地放大了一个受攻击或怀有恶意的内部人员在单次会话中能完成的任务。内部人员事件的平均成本每年已达到每家机构 1740 万美元，83% 的机构在过去一年中至少经历过一次内部攻击。AI 工具并没有引入新的威胁类别 —— 它们只是成倍地增强了每一个现有威胁类别的能力。

爆炸半径扩张问题

传统的内部威胁模型以访问权限为中心：用户只能窃取他们能看到和移动的东西。开发人员可以窃取他们拥有读取权限的源代码。销售分析师可以带走他们可以查询的 CRM 数据。损害的范围大致受其权限的限制。

AI 工具从两个方面打破了这一假设。

首先，它们聚合了访问权限。基于 RAG 的文档搜索代理会摄取你的 Confluence、Slack 导出、共享驱动器和 Jira 历史记录 —— 然后提供跨越所有这些来源的答案。单个数据源是孤立的；代理将它们合成了。一个从未有耐心（或权限）手动关联五个系统文档的员工，现在只需发出一个自然语言查询，就能收到一份全面的总结。这种聚合本身就是漏洞。

其次，它们降低了攻击的操作门槛。在 AI 工具出现之前，执行多阶段的数据窃取攻击需要技巧：侦察、识别窃取通道、对数据进行编码以规避 DLP、了解要获取什么以及采用什么格式。现在，一个拥有 AI 代理访问权限的受攻击账户可以用平实的语言发出指令，并收到一份结构化的执行计划。2026 年初的研究发现，所有测试过的编程代理 —— 包括 GitHub Copilot、Cursor 和 Claude Code —— 都容易受到提示词注入（prompt injection）的影响，在受控测试中自适应攻击的成功率超过 85%。对于不需要任何此类漏洞利用的内部人员来说，同样的攻击面也是可用的；他们只需要使用这个工具即可。

具体威胁模型

具体地思考这些问题比抽象地思考更重要。以下是企业 AI 部署引入或放大的四种威胁模型。

通过总结进行数据窃取。 传统的 DLP 监控文件下载、批量邮件附件和 USB 传输。它不会监控员工要求 AI 代理“总结第三季度董事会简报、上个月的竞争分析以及我们的定价模型，然后将其转换成我可以对外分享的格式”。没有文件被移动。没有触发任何规则。数据还是流失了。

通过 AI 工具导致的凭据和密钥泄露。 使用 GitHub Copilot 的代码仓库与没有 AI 辅助的仓库相比，其密钥泄露率高出 40%。其机制非常寻常：开发人员将包含环境变量、API 密钥或连接字符串的上下文粘贴到 AI 提示词中。根据你的配置，AI 工具可能会记录这些信息、对其进行缓存或将其包含在训练数据中。即使没有恶意，AI 编程助手也为凭据离开环境创造了新路径。

通过过度授权的 MCP 集成放大访问权限。 支持代理式 AI 工具的 Model Context Protocol（模型上下文协议）服务器通常配有具有广泛读/写权限的服务账户。与人类用户账户不同，这些服务账户很少应用异常检测 —— 它们不被期望像人类一样行事。一个能通过提示词注入操纵 MCP 集成的受攻击用户，可以获得该服务账户的权限，而不仅仅是其自身的权限。这就是“混淆代理”（confused deputy）问题：AI 执行操作时拥有其人类操作员并不具备、甚至可能都不知道存在的权限。

用于持久访问的内存投毒。 具有持久内存的长期运行 AI 代理引入了一种在传统安全中没有对应物的威胁向量：攻击者将恶意指令注入代理的内存存储中，从而获得一种跨越会话边界的持久化机制。与仅影响单次对话的单次提示词注入不同，中毒的内存会导致代理“学习”攻击者的指令并将其应用于未来的交互 —— 在被检测到之前，这种影响可能会持续数天或数周。

为什么你现有的控制措施无法覆盖这一点

DLP (数据泄露防护) 系统旨在检测可识别数据对象（文件、记录、结构化导出）的移动。它们无法对摘要、重新格式化的输出或 AI 综合分析进行分类。Cyberhaven 的研究发现，一家全球制造公司的工程师在完全正常的工作活动中，不知不觉地将专有产品设计粘贴到了 AI 工具中。没有触发任何 DLP 规则，因为没有规则在寻找那种模式。

加载中…