Intezer AI SOC 警报激增，但几乎全是噪声
尽管在 Intezer 的研究中仅占全部安全警报的 0.43%，其 AI SOC 警报量仍在 2026 年 2 月至 6 月间增长了 685%。矛盾已经十分明显：企业 AI 并未带来许多安全团队担心的、由智能体驱动的大规模入侵潮，反而产生了迅速增长的大量合法活动，而这些活动常常看起来像一次入侵。
Intezer 审查了多个企业环境中的约 1,690 万条警报，其中约 7.3 万条涉及 AI 工具或智能体。其研究人员将 94.1% 归类为噪声，5.8% 归类为真实安全风险，只有 0.02% 属于真正的攻击。
这种失衡的一边是既有检测逻辑，另一边则是正常的 AI 辅助工作。Claude、Codex、Cursor、ChatGPT 及类似工具能够启动进程、处理文件、调用 shell 并连接服务。若脱离用户意图来观察，这些行为很像攻击者活动。
结果不只是安全运营中心（SOC）的工作量增加，而是一个上下文问题。团队必须在误报淹没真正重要的风险暴露之前，区分合法的智能体活动与不安全的智能体行为。
Intezer AI SOC 警报的增长速度远超其占比所暗示的程度
关键数字并非 AI 当前在警报总量中的占比，而是这种增长的速度与构成。
根据 Intezer 的 AI 警报研究，与 AI 相关的活动在审查的 1,690 万条警报中产生了约 7.3 万条。这使其相较于已涌入企业 SOC 的终端、身份、电子邮件、云端和网络警报，仍是一个较小的类别。
不过，在稳定的报告周期内，与 AI 相关的月度警报量持续增长。Intezer 测得，2026 年 2 月至 6 月间增长了 685%。该公司将这一趋势描述为单调增长，即每一个完整月份都高于前一个月。
这一轨迹之所以重要，是因为企业采用 AI 并不需要正式的全公司部署。员工可以通过 OAuth 连接消费级聊天机器人，从而允许应用访问获批的账户资源。开发者也可以安装会立即开始与本地系统交互的编程智能体。
每项操作都会新增一个遥测数据来源，也可能触发早在通用智能体开始运行于员工电脑之前就已创建的规则。
Intezer 将由此产生的警报分为三类。噪声指触发既有检测的合法活动；安全风险指没有确认遭到入侵的不安全行为或风险暴露；真实攻击则需要有实际攻击者行动的证据。
噪声以 94.1% 占据主导。安全风险占 5.8%，确认攻击约占 0.02%。这些分类来自 Intezer 的平台和方法论，因此独立研究可能得出不同的比例。
内部处置数据也显示了同一模式的另一层面。Intezer 表示，79.8% 的 AI 相关警报被判定为良性。其自动化系统抑制了 81.7% 的警报，未将其呈交给人工分析师便直接关闭。
仅有 5.4% 被升级交由分析师处理。其余警报被标记为需要后续跟进，而非立即视为安全事件。
这些结果支持采用自动化分诊，但也揭示了一项依赖条件：自动化必须理解智能体、其用户与正在执行任务之间的关系。单凭进程名称或命令，很少能提供这种上下文。
一名客户通过单条检测规则，产生了数据集中所有被标记为严重的 AI 相关警报中的 55%。该规则将 Windows 二进制文件 Expand.exe 识别为可能用于横向传输的工具。
进一步检查发现，一款编程智能体正在准备 shell 环境。尽管各个技术信号看起来像攻击者行为，但对于这一工作流而言，该活动是正常的。
传统的严重性标签会将这些警报排在分析师队列的前列。上下文则使它们更适合自动关闭。当同一种模式在数千个终端上反复出现时，这种差异会带来高昂成本。
该研究并不表明所有高严重性 AI 警报都是无害的。它表明，当检测逻辑无法识别正常的智能体行为时，严重性便失去了意义。
这是 SOC 负责人面临的首个运营变化。AI 活动需要独立基线，包括获批工具、预期父进程、常见目标地址和允许执行的操作。没有这一基线，采用率的增长就会变成虚假紧急警报的增长。
全公司范围的 AI 采用正在改变警报流的形态
企业 AI 同时制造了两条安全数据流：高调的智能体执行活动，以及企业数据的低调流动。
高调的数据流主要来自技术用户。编程智能体能够创建脚本、启动解释器、安装软件包、检查代码仓库、打开端口或执行开发工具。每项操作都可能像是入侵中的某个阶段。
开发者可能要求智能体启动本地测试服务器。智能体可能启动 PowerShell、寻找未使用的端口、运行 Python，并将输出重定向到项目日志中。终端产品先看到的是异常进程链，之后才看得到无害的开发目标。
Intezer 发现，已签名的 OpenAI Codex 沙盒二进制文件会产生这种模式。在准备本地项目环境时，PowerShell 随后启动了 cmd.exe、python.exe 和 conhost.exe。
一条常规规则将这一序列解读为可能的反向 shell。但命令文本实际上显示的是在 127.0.0.1 上进行的本地编排；127.0.0.1 是用于访问同一台计算机的回环地址。
安装程序也会产生类似的冲突。Intezer 报告称，合法的 Claude Desktop 安装程序触发了与勒索软件行为和编码 PowerShell 执行相关的检测。其代码签名确认了软件包身份，但行为规则仍将该安装序列视为可疑。
这并不意味着行为检测已经过时。已签名软件可能变得恶意，可信应用也可能被滥用。这意味着，在分析师能够判定意图之前，检测结果需要辅助上下文。
低调的数据流则来自非技术人员的采用。员工可以授权某项 AI 服务访问企业账户、上传文档，或将敏感资料粘贴进提示词。这些行为可能永远不会产生异常的终端进程。
Intezer 观察到，多个租户向 ChatGPT 授予了 OAuth 同意授权。它还发现首次登录某个 OpenAI 应用的情况，以及某一客户中涉及生成式 AI 上传的数据保护警报集群。
大多数事件是良性的。尽管如此，它们仍代表企业信息正在流入终端无法直接控制的服务。
这一区别解释了为何仅封锁少数可执行文件无法解决企业 AI 安全问题。一部分风险存在于进程中，另一部分则存在于浏览器会话、身份权限、软件集成和数据流里。
因此，有效的资产清单不能只有获批应用列表。它必须关联用户、身份、智能体、扩展程序、OAuth 授权、数据目的地，以及每项工具可访问的资源。
这项工作超出了 SOC 的范围。身份团队管理同意授权和访问权限；数据治理团队界定敏感信息；工程负责人决定哪些智能体配置可以接受。
采购和法务团队评估第三方数据处理条款。业务管理者则决定员工是否拥有切实可用的获批替代方案。
SOC 仍是这些信号汇聚的节点。当某个工具启动可疑命令、建立隧道连接或接触受保护信息时，SOC 会收到警报。
全公司采用也改变了归因的含义。在通用智能体出现之前，以用户账户身份执行的命令通常反映该用户本人，或反映攻击者对该账户的控制。
智能体引入了第三个行动者。它以用户的权限运行，却可能选择用户从未审查过的命令。活动归属于该账户，但并不完全反映账户持有者的直接操作。
这一差距对于事件时间线尤其重要。分析师需要了解命令是由人类输入、由获批智能体生成，还是由恶意内容操纵智能体所致。
安全团队还需要持久的组织上下文。可搜索的工程知识库可以保留获批工作流和本地技术决策。不过，文档必须与当前的身份和终端证据相连，才能支持分诊工作。
运营目标并非对每条提示词实现完美可见性，而是在不超出必要范围监控员工的前提下，获得足够经过验证的上下文，以区分获批工作、不安全行为和对抗性活动。
传统检测逻辑正与正常智能体行为发生冲突
核心竞争并非人工分析师与自动化之间的竞争，而是传统检测逻辑与 AI 智能体上下文之间的竞争。
安全产品通常检测的是技术手法，而不是意图。无论由哪种应用发起，凭据访问、命令执行、持久化、隧道通信和数据收集依然危险。
AI 智能体使这一模型变得复杂，因为如今的合法工具会执行过去主要与管理员、渗透测试人员和攻击者相关的行为组合。这种重叠是结构性的，而非偶然。
Intezer 发现，在噪声最多的 AI 相关检测组中，良性比例介于 77% 至 99% 之间。多条规则在 AI 生成行为上的误判率超过五分之四。
其中一个例子涉及通过 Node.js 启动的 OpenAI Codex，并带有 --yolo 或 --dangerously-skip-permissions 等标志。由此产生的活动触发了与 ClickFix、工具被禁用和 DLL 注入相关的检测。
权限绕过标志会取消智能体执行操作前的审批提示。开发者使用它们来减少中断，但同样的便利性也削弱了一道重要的控制边界。
ClickFix 警报集群是 Intezer 噪声发现中的一个例外。只有 37% 的此类警报属于良性。这并不意味着每条警报都是攻击，但使该集群更具调查价值。
这正是简单允许列表失效的地方。将 Codex、Claude 或 Cursor 宣布为可信，确实可以减少噪声，但也可能掩盖经由这些工具发起的不安全操作。
更安全的方法是评估完整链路。SOC 应考虑已签名应用、发起用户、智能体配置、请求任务、子进程、访问资源、网络目的地以及最终的数据移动。
MITRE 的 AI 威胁矩阵反映了这一更广泛的视角。它涵盖智能体工具调用、凭据窃取、提示词注入、反向 shell，以及通过 AI 相关机制进行的数据外泄。
这些技术说明，获批智能体不能获得永久性的全面信任。工具本身可能合法，但某一次具体调用仍可能不安全。
因此，检测工程必须变得更具条件性。在已知开发代码仓库中启动本地服务器可能是常规行为；同一个解释器若在财务部门工作站上创建外部隧道，则应得到不同处置。
编程智能体读取自身配置令牌可能符合预期；将完整的 macOS 密钥链导出至临时文件，则与该任务并不相称。
Intezer 观察到了完全相同的模式。一名代理在尝试获取已存储凭据时，使用 security dump-keychain 并将输出重定向到临时位置。
预期任务并不需要恶意意图。所选择的方法仍暴露了超出必要范围的信息，并在磁盘上形成了一个有价值的目标。
另一个案例涉及一款 AI 代码编辑器：它启动了 PowerShell，随后启动 ngrok——一种可创建可从互联网访问的隧道的服务。它使用员工的身份验证令牌打开了一条具名反向隧道。
用户的目的可能是正当的故障排查或开发。但这一操作确实建立了一条从公共互联网进入企业环境的路径。
第三个案例涉及 Cursor 发起的一条进程链，其中使用了已知的内存转储方法。Cursor 启动 PowerShell，后者调用 rundll32.exe 以及 comsvcs.dll 中的 MiniDump 功能。
该技术能够从进程内存中提取机密信息。即使代理出于调试目的选择它，这种行为也会带来值得调查的凭据访问风险。
这些案例支持一种基于操作与边界、而非仅依据产品名称的策略。即使是获批代理，也应面对针对凭据存储、生产系统、公共隧道和敏感代码库的限制。
隔离可以有所帮助。Intezer 建议，在工作流程允许时，将 AI 工具运行在受限环境中，包括容器或虚拟机。
容器会将进程及其定义的资源和访问边界打包在一起。虚拟机则提供独立的运行环境，在许多配置中具备更强的隔离性。
两种控制措施都并非绝对可靠。容器可能配置错误，虚拟机仍需要身份、网络、存储和更新控制。但二者都能减少代理默认可访问的资源数量。
它们还能改善归因能力。来自指定代理环境的活动，更容易与用户日常桌面活动区分开来。
这一变化需要谨慎衡量。团队应按检测规则、代理、配置和业务部门跟踪误报率，也应记录哪些抑制规则后来需要修正。
一味降低告警量并不代表成功。真正有用的衡量标准是：调优是否在不掩盖凭据访问、外部暴露或敏感数据流动的前提下，消除了可预测的噪声。
静默的 AI 安全风险比高调告警更重要
Intezer 数据中影响最重大的 AI 风险，往往是暴露风险，而非已确认的入侵或最高严重级别告警。
Intezer 将 AI 相关总体中的 5.8% 归类为真实安全风险。这些事件并未证明攻击者已经获得访问权限，而是显示了可能使后续入侵造成更大损害的条件。
权限绕过是一个核心例子。无需审批提示即可运行的代理，可能在用户看到具体细节前执行一长串操作。
当代理读取不可信代码、网站、工单、电子邮件或文档时，这种设计会变得更加危险。隐藏在这些来源中的恶意指令可能影响代理的选择。
提示注入是试图让模型遵循嵌入其输入中的敌对指令的行为。当代理能够使用工具或访问业务数据时，这类问题会更加严重。
间接注入可能通过用户从未视为指令的内容传入。网页或代码库文件中可能包含面向代理、而非人类读者的文本。
NIST 的生成式 AI 概况建议在系统生命周期内对 AI 风险进行治理、映射、衡量和管理。这一模型适合企业代理，因为风险会跨越技术与组织边界。
终端告警可能揭示最终执行的命令，却遗漏影响模型的内容。身份日志可能显示 OAuth 授权，却无法说明后续哪些文档进入了该服务。
数据泄露防护产品或许能看到一次上传，却不了解其业务目的。每种工具都只观察到事件的一个片段。
SOC 需要关联这些片段。在可用遥测条件允许的情况下，它应将用户、代理、提示来源、权限、进程活动、目标位置和数据分类关联起来。
这并不要求收集每位员工的全部对话。隐私和比例原则依然重要。组织应采集执行既定政策和调查重大风险所需的最低限度证据。
明确的政策同样重要，因为同一操作在不同部门可能带来不同后果。上传公开的营销文案，与上传客户记录、未发布的财务信息或包含机密信息的源代码，并不相同。
获批工具并不会消除这种差异。企业级许可可以改善管理控制，但无法决定每一份数据是否都适合放入每一个提示中。
OAuth 同意授权也值得同等关注。OAuth 允许用户授权应用程序，而无需交出密码。由此产生的令牌仍可能提供对邮件、文件、日历或其他服务的大量访问权限。
合法 AI 应用请求的权限范围可能超出当前任务所需。遭入侵的账户或被操控的代理随后可能以员工从未预期的方式使用这些权限。
SOC 团队应审查高风险同意授权、不寻常的首次使用应用，以及跨越敏感系统的权限。他们还应为用户请求已获批准的集成提供快速通道。
如果治理推进过慢，员工就会绕过它。这会形成影子 AI，即在既定组织批准与监督之外运行的工具或使用方式。
答案不是不加区分地禁止。禁令可能减少可见活动，却会将有用工作推入个人账户和未受管理的浏览器会话。
安全团队需要一条具备适当控制措施、切实可行的合规路径。员工应了解可使用哪些工具、可共享哪些信息，以及何时代理需要隔离环境。
CISA 及国际合作伙伴在其 AI 安全指南中，同样强调了责任归属、透明度和安全设计。这些原则适用于供应商，但企业买方也需要对其进行评估。
采购问题应涵盖日志记录、保留期限、模型训练、访问范围、管理控制、事件通知和数据删除。在可能的情况下，技术测试应验证重要声明。
随后，SOC 操作手册必须将政策转化为调查步骤。看到一条陌生隧道的分析师，应能迅速识别负责的代理、用户、任务和目标位置。
操作手册不应仅因获批工具启动了该操作，就自动关闭事件。它应判断该操作是否仍处于批准的边界之内。
同样的原则也适用于凭据访问。代理通过获批代理服务读取有限的机密信息，与导出整个凭据存储并不相同。
这种以操作为中心的模型既能保留有价值的检测，又能减少可避免的噪声。它还使告警与组织实际决定管理的风险保持一致。
Intezer 的数据尚未证明什么
Intezer 的发现是有价值的运营快照，但并非企业 AI 风险的普遍衡量标准。
该研究覆盖了连接到 Intezer 平台的环境中可见的告警。它并不代表每一家企业、每一种安全技术栈、每个行业、每个地区或每种 AI 部署方式。
Intezer 未在文章中公布完整的客户数量或按行业划分的详细数据。它还对客户、主机、用户和标识符信息进行了匿名化处理。
这保护了组织，但限制了独立复现。除 Intezer 披露的案例外，读者无法判断某个大型环境对各个类别的影响程度。
这项研究也衡量的是告警，而非所有 AI 活动。未触发已连接控制措施的操作，可能不会出现在数据集中。
这对基于浏览器的工具、个人账户、未经批准的扩展程序，以及终端产品无法观察到的数据交换尤为重要。与可执行代理活动相比，低调使用可能被低估。
因此，94.1% 的噪声比例应当用于指导检测调优，而不应被视为普遍的误报率。其他组织可能拥有不同的代理、政策、用户或遥测能力。
0.02% 的攻击占比同样需要谨慎解读。它并不表明 AI 代理天生安全，也不表明代理辅助攻击在所有环境中都微不足道。
它表明，在这一特定 AI 相关告警总体中，已确认攻击极为罕见。Intezer 表示，这些已确认攻击中没有一起源于某个组织自己的代理导致入侵。
它识别出的真实攻击使用了熟悉的 AI 品牌作为网络钓鱼诱饵。攻击者冒充 Anthropic、Gemini 和 OpenAI 等名称，因为员工越来越熟悉并信任它们。
其中一封电子邮件提及所谓的 Anthropic 合作及付款请求。另一封则使用虚假的 Gemini 广告邀请，并采用与 Google 无关的基础设施。
第三封冒充 OpenAI 合作伙伴活动，同时使用合法的 Zoom 基础设施，让邀请看起来更可信。在每个案例中，AI 的采用强化了诱饵，而非提供新的攻击技术。
这种区别很有价值，但可能发生变化。更广泛的代理权限、更强的自主能力和更深入的业务集成，都会增加操控行为的后果。
该数据集中缺乏大量已确认的代理导致入侵，并不能证明未来部署仍将安全。它只是用于观察这一转变的基线。
供应商激励也值得关注。Intezer 销售 AI SOC 平台和自动化分诊服务。其研究自然会突出可通过上下文调查和自动化解决的问题。
这并不会使数据失效。但这意味着，买方在改变控制措施之前，应将结果与自身遥测数据、红队发现和事件历史进行比较。
安全团队应测试自动化判定在自身环境中是否仍然准确。他们应抽样检查被抑制的告警、复核不确定分类，并监控与先前决策相矛盾的后续证据。
他们还应记录已验证结果与供应商声明之间的差异。例如，Intezer 表示其更广泛的平台可以大规模调查告警，但本研究并未独立验证每一项性能声明。
更困难的问题涉及缺失信号。SOC 可以调优掉可见噪声，却仍然缺乏对未经授权的浏览器工具或高风险数据共享的覆盖。
这正是告警减少不能作为唯一成功指标的原因。团队还需要衡量代理资产清单覆盖率、高风险权限数量、敏感上传趋势，以及将操作追溯至其来源所需的时间。
一个告警更少、却无法洞察 OAuth 或浏览器活动的组织，并不一定提升了安全性。它可能只是将风险转移到了未被衡量的渠道之外。
三项信号将显示 SOC 是否正在适应
下一项考验是：安全团队能否比 AI 活动扩张得更快地改善上下文能力。
第一项信号是与代理相关检测的误报表现。SOC 负责人应衡量调优前后最嘈杂规则的良性活动比例。
一次成功的改进，应减少已知安装程序、本地开发服务器和获批进程链产生的重复告警，同时保留对权限绕过、凭证导出、外部隧道及异常数据流动的审查。
如果良性事件比例下降，而漏报事件没有增加，说明 SOC 正在学习正常的 AI 行为。如果分析师仍不断手动关闭相同模式的告警，说明 AI 的采用速度仍快于检测工程的建设速度。
第二项信号是企业在身份、浏览器、终端、云和数据控制方面的覆盖范围。仅列出已安装的编程代理，并不等于拥有完整的 AI 资产清单。
团队应关注新的 OAuth 授权、首次 AI 应用登录、未受管理的扩展、个人账户使用情况，以及代理与敏感代码库之间的连接。
改进覆盖范围起初会暴露更多隐蔽风险。这种暂时性的增长不应被误认为安全状况恶化。更好的度量通常会先让既有风险显现，随后控制措施才会降低风险。
第三项信号是，代理部署是否默认采用受约束的执行方式。权限提示、受限凭证、隔离环境和有限的网络访问构成了可衡量的边界。
组织应关注带绕过标志启动的代理占比。即使控制措施阻止了执行，也应监测代理尝试执行被禁止命令的频率。
绕过率下降，将更有力地表明治理正在落地为实际运营。若该比例持续增长，则说明便利性仍优先于隔离控制。
安全测试应纳入真实的代理工作流，而不只是测试模型提示词。评估可将不受信任的指令置于代码、文档、工单或网页内容中，并观察代理的响应。
目标是测试整个系统，其中包括身份权限、工具、记忆、外部内容、执行控制、日志记录和人工审批。
Intezer AI SOC 告警为这一转变提供了早期视角。标题中的结果乍看令人安心，但仅此而已。已确认的攻击较为罕见，但暴露面和运营噪声已经快速增长。
对 SOC 团队而言，眼下的问题很具体：他们能否识别正常的代理行为，同时又不对代理给予无差别的信任？
应先从产生最多重复良性告警的检测规则着手。然后，将这些调优结果与权限绕过、凭证访问、隧道、OAuth 授权和敏感数据上传进行对比。如果这些高价值信号变得更容易识别，说明 SOC 正在适应。如果告警数量下降，但可见性仍然零散，表面上的改善只是不确定性变得更安静。
