文章总结： 企业部署AI工具后SOC告警四个月增长685%，其中94.1%为无效噪声，真实攻击仅占0.02%。AI使用行为触发大量误报，但存在权限绕过、隧道开放等真实风险。建议优化旧检测规则、隔离运行AI工具，并区分用户与agent行为。 综合评分： 85 文章分类： 安全运营,威胁情报,安全建设,解决方案

企业全面部署AI工具，SOC相关告警四个月暴涨685%

FreeBuf

2026年9月14日 18:00 上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

过去一年，企业SOC中出现了一类全新告警，增速远超告警流中的其他所有类型：这类告警由AI工具和Agent触发，并非针对AI的攻击，只是企业使用AI过程中留下的常规日常痕迹——小到开发人员运行coding Agent，大到非技术员工将消费级AI工具登录到企业账号，都会触发这类告警。

我们梳理了多个企业环境中的AI相关活动，两个核心数字可以概括后续所有结论：目前AI相关告警仅占SOC总告警量的0.43%，但这一占比每月都在攀升，2026年2月至6月期间总量增长685%。AI告警是当前告警流中占比很小的一部分，同时也是增速最快的一部分。

这类告警值得安全团队关注的核心原因不是体量，而是结构。我们将SOC中Agent触发的所有告警分为三类：真实攻击、安全风险、无效噪声，占比分别为0.02%、5.8%、94.1%。也就是说，在我们调研的所有数据中，利用AI Agent发起的真实攻击占比极低。到目前为止，AI给SOC带来的主要负担并非数据泄露事件，而是大量看起来危险、实则几乎无威胁的告警洪峰，以及一小部分隐藏在这些告警背后、容易被掩盖的真实风险暴露。

本文将结合脱敏案例逐一分析这三类告警，所有客户名称、主机名、用户名、身份标识均已移除，攻击指标均已做无害化处理。

Part01

AI使用催生两类行为

告警全部汇入SOC

企业内部的AI应用并非单一行为，而是同时存在两种差异极大的使用模式。

第一类是技术人员的使用行为：开发人员安装的coding Agent会拉起shell、读取凭证存储、打开网络隧道、下载软件包、运行安全工具，这些都属于合法工作范畴，但在检测引擎看来，这些行为和入侵早期阶段的特征完全无法区分。这类行为触发的告警占比最高，是AI告警中的主要组成部分。

第二类是普通员工的使用行为：员工向第三方AI应用授予OAuth权限、共享信息、将文档粘贴到生成式AI工具中。这类行为触发的告警很少，几乎不会触发端点检测规则，但却是企业数据外泄的主要渠道。

两类行为触发的告警最终都会进入SOC，乍看之下都属于需要警惕的风险，安全团队的核心工作就是从中区分出真实信号和无效噪声。

Part02

AI告警四月内增长达685%

AI告警当前占比不高，但增速极快。我们共梳理了约1690万条SOC告警，其中约7.3万条（占0.43%）与AI相关。单看这个数字，似乎占比很低，不足为虑。

本系统观测到的每月AI相关告警数量

AI告警量呈单调上升趋势，每个完整统计月的数值都高于前一个月，2026年5月增速明显加快。在跨区域统计口径稳定的窗口期（2月至6月），告警总量增长685%。0.43%只是当前的起点，远不是终点。如果团队按照当前体量配置AI告警处置资源，不出一个季度就会出现资源不足的问题。

AI告警的结构失衡问题和增速趋势同样明显：几乎所有AI触发的告警都是无效噪声。

本次研究中，我们对所有AI相关告警对应的底层活动逐一分类：真实攻击指已确认的失陷事件；安全风险指尚未造成失陷、但真实存在的暴露面（比如coding Agent运行时关闭了权限防护机制）；无效噪声指AI Agent普及前编写的检测规则，被合法AI行为触发产生的误报。按照这个标准，94.1%的AI相关告警都是无效噪声，5.8%为真实安全风险，仅0.02%为真实攻击。

AI相关告警的最终分类占比统计

我们还统计了无人工介入的自动化处置流程对这类告警的处理情况。当告警进入自动分诊平台时，系统会做出两个独立判断：

• 判定结果：评估活动的危险程度，分为良性、可疑、恶意三类，其中79.8%的告警被判定为良性。
• 处置动作：决定后续处理方式，分为静默（自动关闭，不推送给分析师）、标记待跟进、升级人工处置三类，其中81.7%的告警被自动静默。

所有AI相关告警中，仅5.4%会升级到人工分析师处置，其余仅标记为待跟进。

高严重级别的告警不一定代表真实威胁。比如所有将Windows二进制文件Expand.exe标记为“横向移动工具投递”的“严重”级别告警中，有55%都来自同一家客户的单条检测规则。研究人员排查后发现，这是开发人员的coding Agent在搭建shell环境，属于这类工作的正常行为。

所有SOC都应当吸取这个教训：不能直接采信AI活动触发的告警严重级别标签，必须持怀疑态度逐一核实。

Part03

真实攻击占比仅0.02%

真实攻击指已发生的失陷事件，或是攻击者借企业AI应用之势发起的攻击行动。这是所有企业高管最先关注的类别，但占比极低，仅占AI相关告警的0.02%。

我们在这类告警中发现的真实威胁，没有一起是由企业自有AI Agent导致的失陷。所有标题为“AI Agent运行mimikatz”“编码工具发起反向shell”“凭证窃取”的告警，经排查均为开发人员的合法操作，或是检测规则误触发，这类案例我们会在噪声部分详细说明。

真正的攻击并非利用AI本身发起，而是借AI普及的趋势实施：比如正在活跃的钓鱼活动，就将AI品牌名作为诱饵。在研究窗口期内，我们在多家客户环境中，以及后续拓展的新客户环境中，都观测到了AI主题的恶意邮件，发件人冒充头部AI企业。这类诱饵之所以有效，正是因为AI普及让员工对这些品牌非常熟悉，对相关通知习以为常。员工现在已经习惯收到这些产品发来的邮件，这正是攻击者利用的心理。

我们还发现了一些特殊案例：部分工具或命令的执行通常意味着真实攻击（或渗透测试），但这些案例中调用工具的是Claude、Codex等产品。因此分析师排查时，还需要确认Agent运行这些工具的原因，判断是否是攻击者利用Agent发起的真实攻击。这类案例包括：

• 商务场景下以Anthropic为诱饵的钓鱼邮件。这类邮件的主题通常为“RE: Anthropic合作审批与付款”，邮件内容谎称发件方与Anthropic存在待结算的合同或发票，让大额付款请求看起来合理合法。Anthropic既不是发件方，也不是威胁来源，只是攻击者编造发票诈骗剧情时用的幌子。
• 伪造Google/Gemini Ads邀请的钓鱼邮件。这类邮件伪装成可信的商务工作区邀请，诱导收件人接入看似官方的Gemini Ads环境。但发件方和回复所用的基础设施与Google无关，依托可疑域名gemini-advertisers[.]com运行，属于典型的品牌冒充攻击，目的是诱导用户访问恶意站点。
• 冒充OpenAI发送“2026 OpenAI合作伙伴峰会”邀请的钓鱼邮件，发件地址为[email protected]。虽然邮件中的URL依托合法的zoom.us基础设施运行，但攻击者利用邮件内容和注册流程，为虚假邀请增加可信度。

冒充OpenAI的钓鱼邮件

设备码钓鱼攻击

• AI IDE Cursor的活动曾从正常编码操作转向不安全的底层系统行为：当时Agent可能正尝试完成调试或排障任务，却调用了已知的凭证转储技术（通过comsvcs.dll实现MiniDump），可能泄露进程内存中的敏感凭证。从进程链Cursor.exe → powershell.exe → rundll32.exe、临时.ps1脚本以及内存转储命令来看，这款IDE自动执行了一系列操作，初衷可能是辅助开发，但实际却给端点带来了严重的凭证访问风险。

这三类案例有一个共同规律：排查得越深入，所谓的“攻击”就越会被具体场景消解，这正是AI时代告警分诊的核心特征。

Part04

不安全使用占比5.8%

约5.8%的AI相关告警最值得安全团队关注。这类告警检测的是AI工具的不安全使用行为，暂时不一定造成了失陷，但风险真实存在：Agent完全按照用户指令运行，没有攻击者介入，但其行为已经实实在在地将企业或用户暴露在风险中。

这类风险的核心诱因是用户启动Agent时开启了权限绕过标识，也就是让Agent执行操作前不再询问用户确认。很多用户选择信任Agent，认为它不会破坏设备或执行危险命令，但过往经验和本次研究数据都显示，很多情况下Agent会尝试执行高风险命令，且大多能成功，将企业和用户暴露在极大的风险中。值得注意的是，如果用户要开启权限绕过模式运行Agent，我们不建议在无额外防护的情况下直接运行，应当额外配置安全约束（也称为harness），通过编程方式阻止Agent执行高风险命令。

本系统观测到的权限绕过标识使用占比

我们排查的所有样本中，这类Agent调用都是开发人员的合法工作行为，这正是风险的关键所在。这种配置和此前公开披露的一起供应链攻击的前提条件完全一致：当时攻击者的恶意代码能够自由执行，就是因为用户启动coding Agent时关闭了权限确认提示。这种风险和主观恶意无关，本质是很多客户环境中都普遍存在安全护栏失效的问题，只等Agent某次运行的代码不是良性程序，就会引发安全事件。值得注意的是，这类开启权限绕过的Agent调用，同时也是误报的最大来源。

我们还发现了其他几类不安全使用场景：

• AI IDE开放反向隧道：某企业环境中，一款AI代码编辑器拉起PowerShell进程，启动ngrok并使用用户自身的认证令牌，向公网开放了一条命名反向隧道。虽然用户初衷是善意的，但这确实构成了真实的风险暴露。
• Agent转储整个macOS钥匙串读取单个令牌：某Agent为读取自身及云服务存储的凭证，执行security dump-keychain > /tmp/命令，将所有存储的密钥写入临时文件，导致全部敏感信息短暂暴露。
• 向AI Agent授予OAuth权限：员工向AI Agent授予OAuth权限，不仅可能将敏感信息共享给第三方服务商，还会增加提示注入攻击或AI账号失陷导致的未授权数据访问风险。我们在多个租户中观测到大量用户向ChatGPT授予OAuth应用权限的告警，以及“新应用首次登录：OpenAI”事件；在某家客户环境中，还出现了大量生成式AI上传行为触发的数据保护告警。这些行为绝大多数是良性的，但这正是企业数据流向第三方模型的入口，而且几乎不会被端点工具检测到。

Part05

无效噪声占比超九成

无效噪声是占比最高的类别，达到94.1%，占比高出其他类别一个数量级，直接决定了SOC会不会被告警淹没。这类噪声并非随机产生，而是有明确规律：AI Agent普及前编写的检测规则，现在会对Agent的常规工作行为触发高优先级告警。Sophos此前的报告也提到过，这并非SOC领域第一次出现这类问题。

最典型的例子来自AI厂商的官方软件。经代码签名验证的正版Anthropic Claude Desktop安装包，在多家客户环境中触发了EDR的高优先级规则，包括“检测到勒索软件操作”“编码PowerShell下载执行”等。但该安装包完全合法，只是安装行为刚好匹配了检测规则中描述的勒索软件特征。

这类误报的核心是Agent行为触发的规则，经排查全部是开发人员按正常用途使用工具导致的：

• coding Agent更新以及开发人员使用Agent的行为，触发了“检测到勒索软件操作”告警。触发告警的二进制文件是合法的、经过签名的软件包，看起来类似勒索软件的行为，实际是Electron/Squirrel安装程序的正常活动，以及开发工具的常规操作。

• node.exe进程启动OpenAI Codex CLI Agent时携带–yolo或–dangerously-skip-permissions参数，触发了ClickFix、DisableTools以及DLL注入检测规则。

• 常规开发者自动化操作触发了“PowerShell可能创建反向TCP shell”告警。对应的进程树符合正常开发者自动化操作的特征，并非真实反向shell：父进程是经过签名的OpenAI Codex沙箱二进制文件，拉起powershell.exe后又启动了cmd.exe、python.exe和conhost.exe。对应的PowerShell命令为明文形式，显示为良性编排逻辑：在127.0.0.1上检查本地端口，选择可用端口，从项目目录启动Python脚本，将标准输出和标准错误写入artifacts目录下的本地日志文件。

误报率是这类告警的核心问题。在触发频率最高的AI行为检测规则中，良性行为的占比从77%到99%不等，有数条检测规则对AI行为的误报率超过80%。

良性AI行为触发的检测规则误报情况

唯一的例外恰好印证了这个规律：ClickFix检测是唯一一个高风险占比更高的规则簇，良性占比仅37%。这一现象的原因也和前文提到的权限绕过风险直接相关：该规则专门检测携带–yolo参数启动的coding Agent。即便是这些看起来“高度仿真攻击”的告警，溯源后也属于合法AI使用行为。

Part06

SOC需优化检测规则

基于本次分析，所有SOC的首要工作非常明确：调优噪声最高的旧检测规则，也就是那些会对Agent常规工作触发高严重级告警的规则。其次，企业需要制定明确的政策，划定可以共享给第三方AI平台的信息范围——和管理其他第三方平台的要求一致；基于这些政策，团队应当主动排查权限绕过标识、未授权隧道、高风险OAuth授权，而不是等告警触发后再响应。

第二项工作难度更高，因为它涉及告警分诊流程本身的改变。AI工具会使用用户的凭证在用户设备上执行命令，本质是代表用户操作，因此触发的告警都会被归因到用户身上，但很多情况下用户根本不知道这些操作发生过。在AI普及之前，用户设备上在用户不知情的情况下执行可疑操作，通常意味着攻击者已经接管设备的概率很高。现在SOC团队需要多一层判断：首先要确认可疑操作是用户本人执行的，还是AI Agent或工具执行的。

要区分用户行为和Agent行为，同时避免Agent接触到不应访问的凭证和敏感信息，我们建议在隔离环境中运行AI工具，比如Docker容器或虚拟机，限制Agent的可访问范围，也更容易将Agent行为和用户自身活动区分开。

Part07

AI告警洪峰易掩盖真实风险

综合三类告警的情况，企业落地AI后的SOC运营现状可以总结为三点：

• 真实攻击（0.02%）：我们排查的所有确认攻击事件中，没有一起是由企业自有Agent发起的。已发现的真实攻击活动都是从外部借AI普及的趋势实施，比如利用员工已经信任的AI品牌制作钓鱼诱饵，而非直接利用Agent本身。
• 安全风险（5.8%）：风险真实存在、持续发生，且几乎不会被常规告警发现。Agent运行时关闭了权限防护机制、向公网开放隧道、过度暴露存储的密钥、将企业数据发送给第三方模型，这些都还不算安全事件，但全部属于真实的风险暴露。
• 无效噪声（94.1%）：这是当前最主要的运营负担。对大多数SOC来说，当前投入产出比最高的工作不是新增检测规则，而是调优现有旧规则，避免开发人员运行coding Agent时触发最高级别的告警。

一个略显残酷的事实是：到目前为止，AI普及并没有带来大量AI驱动的失陷事件，反而带来了一波告警洪峰。这类告警当前占总告警量的比例不高，但六个月内增长了18倍，且绝大多数是误报；与此同时，还有一小部分真实的风险暴露隐藏在告警洪流中，通常会被误报掩盖。如果SOC将每一个Agent行为都视为潜在入侵，就会在误报上耗尽所有精力，反而更容易忽略真正需要关注的ngrok隧道或钥匙串转储行为。

因此，未来的工作重点与其说是检测AI攻击，不如说是在告警量逐月翻倍增长、让团队不堪重负之前，先教会检测引擎识别什么是正常的AI行为。能否理解这一差异，决定了SOC是能跟上AI普及的节奏平稳扩容，还是会被告警洪流彻底淹没。

参考来源：

When the Whole Company Adopts AI: What It Does to Your SOC

https://thehackernews.com/2026/09/when-whole-company-adopts-ai-what-it.html

#

推荐阅读

#

电报讨论

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：FreeBuf 《企业全面部署AI工具，SOC相关告警四个月暴涨685%》