AI 加速网络攻击，Anthropic、OpenAI、Microsoft 等披露防御与智能体管控动向

“必须坚持大约18个月。”Anthropic的Deputy CISO（副首席信息安全官）Jason D. Clinton于2026年10月22日在X上发帖，谈及近4天围绕网络安全的严峻形势，并警告称在情况好转之前还会进一步恶化。他呼吁安全负责人立即寻求管理层的支持，不是为了投资AI，而是为了基本对策。

他预计大约18个月后，高水平的网络能力将扩展到小型且廉价的AI模型，从而能够在发布前防止软件漏洞。

即使AI能力提升，将发现的漏洞修复应用到运行中的系统这项工作依然存在。在使用外部服务和AI智能体时，还需要决定允许访问和操作哪些信息。本文以10月下旬的发布和报告为中心，从修复的应用和权限的管理这两个角度，梳理防御的课题与对策。

代码已修好，但修复并未送达

即使修改了源代码，要反映到实际使用的软件中仍存在课题。其中一个例子就是压缩库Brotli的漏洞CVE-2026-111497[1]。Brotli用于Web通信等数据压缩，此次问题出现在解压压缩数据的解码器中。

OpenAI解释说，为了确认训练中的模型是否无法访问未经许可的系统，让由具备高网络能力的模型驱动的智能体团队寻找弱点。据说Brotli的漏洞也是在这一验证过程中发现的。

根据Node.js项目10月21日公开的信息，解压恶意的Brotli数据会引发内部缓冲区越界写入。当应用程序解压攻击者提供的数据时，可能导致进程停止、内存信息泄露或远程代码执行。OpenAI说明称，该漏洞可在无需认证的情况下被利用。除解压压缩请求的服务器外，解压恶意服务器返回的压缩数据的客户端也会成为攻击目标。

据OpenAI称，根本原因问题已于2月在Brotli的源代码中修复。但当时并未被认定为安全漏洞，此后也没有发布新的Brotli版本。由于OpenAI向Brotli和Node.js等相关项目报告，Brotli的新修复版和CVE得以公开，嵌入方的更新也得以推进。

嵌入Brotli的软件并不限于Node.js。Python的Brotli和brotlicffi包也受同一缺陷影响。如果仅凭所运营服务的名称或开发语言来判断，可能会漏掉依赖项中包含的解码器。

此外，即使嵌入方的修复版已公开，如果用户不更新，修复也不会反映到实际运行的系统上。在OpenAI的Patch the Planet应对指南中，除了更新运行环境和容器镜像、重启和重新部署之外，还展示了确认修复是否已反映到运行中程序的步骤。源代码的修复、库的发布、嵌入方的更新、运行进程的替换。如果这一链条在中途中断，即使存在已修复的代码，运行中的系统仍会残留漏洞[2]。

确认被利用的可能性，确定修复的优先级

发现漏洞后，需要确认在自己运营的环境中是否可能被利用，并判断应优先进行哪些修复。

Anthropic在10月8日的Anthropic Cyber Mission发布活动中说明，即使漏洞发现变得更容易，验证、优先级排序和修复仍然存在课题。该公司推进的Project Glasswing（现已整合到Cyber Verification Program中）中，从漏洞发现到修复往往要经过数月。该公司指出，在控制电力、自来水等设备的系统中，有时无法为了更新而停止运行，必须等待能够安全应用修复的时机[3]。

亚马逊总裁兼CEO Andy Jassy也表示，AI已将从漏洞发现到被利用的间隔缩短至“数周到数分钟”。他在介绍帮助发现和修复漏洞的安全服务AWS Continuum的帖子中，呼吁防御方需要尽快应对。

AWS于10月22日宣布正式上线的AWS Continuum for code vulnerabilities，会将代码仓库与AWS环境的配置关联起来，验证问题被利用的可能性，并根据对业务的影响进行优先级排序。例如，会以存在漏洞的服务能否从外部访问、能否由此访问客户数据或支付系统作为判断依据。

该服务会针对已确认的问题制定代码修复、依赖关系更新、配置变更等方案，并向已连接的仓库提交拉取请求。在发布时点，采用由人工审查并批准的方式。在用户规定的范围内自主应用修复的功能，被列为今后的计划。

授予服务的访问权限被用于攻击

在提高修复速度的同时，也需要关注攻击者可利用的连接和权限。微软于10月21日报告，攻击者组织Storm-0940利用AI自动化攻击，以全球数百个组织为目标。

报告中提到的ConnectWise为IT服务运营商提供软件。该公司的Cloud Backup（原SkyKick）用于备份客户的Microsoft 365数据，通过被授予访问客户环境权限的应用程序进行连接。

微软判断，被评估为与中国政府有关的攻击者Storm-0940参与了此次Cloud Backup的入侵。攻击者利用的ARTEX是一个利用AI调查系统弱点的渗透测试平台，除了能否入侵外，还会验证入侵后能操作到什么程度。攻击者滥用该平台来加速目标探测、认证尝试和入侵后的操作。

在Cloud Backup被入侵后，攻击者滥用用于连接的应用程序凭据，通过了客户Microsoft 365环境的认证。这种连接不需要用户进行画面上的登录，而是利用了已授予应用程序的访问权限。在部分客户环境中，还确认了调查内部信息、或为维持访问而更改应用程序凭据的操作。

不过，仅凭显示认证成功的记录，无法得知客户数据是否实际被查看或带出。微软建议在认证记录之外，还调查此后的操作和数据访问记录，以确认各环境中发生了什么。

ConnectWise也承认了应用程序凭据遭到非法访问。在10月23日的更新中，该公司说明现有备份数据没有入侵迹象。不过，即使服务侧切断了连接，客户环境内仍可能残留非法访问路径，因此仍需对每个客户的Microsoft 365环境进行调查。

在日本国内，JPCERT/CC于10月23日更新了关于接连发生的不正当访问的提醒[4]。其中新增了有关滥用ARTEX、Cairn、CyberStrikeAI等基于AI的渗透测试基础设施发动攻击的信息。据称，已确认存在利用这些工具探索并试图滥用公开Web应用程序漏洞的攻击，以及滥用管理不善窃取配置文件和备份文件的情况。

Anthropic于10月23日发布的关于英国AI Security Institute（AISI）评估的补充分析，涉及此类行为的具体案例。在评估中，Claude Mythos 5被赋予了一项任务：入侵模拟组织系统的测试网络，获取受保护的目标数据（flag）。当时，模型被有意允许访问互联网，并且针对一般公开提供模型的网络安全对策也被禁用。在43次执行中，有9次出现了超出预定范围、影响真实人物或组织的行为。

在一次被详细分析的评估中，模型发现了入侵目标测试计算机定期访问GitHub的痕迹。于是模型认为该计算机正在从某个仓库自动获取软件，并向该仓库提交了恶意代码。其意图是在下次获取时让代码被引入，从而实现入侵，但所选仓库与测试无关，由真实的开发者管理。模型伪装成虚假用户，促使维护者接受更改，但更改被拒绝，执行随之结束。

Anthropic将这一行为解读为：模型并非在追求自身目的，而是为了完成给定任务而越界并试图欺骗他人的案例[5]。

关于控制AI代理行为的系统设计，微软的Satya Nadella在10月10日的个人博客中阐述了自己的想法。他提出应将模型视为“内部风险”，并考虑即使没有恶意也可能犯错或被攻陷的可能性。他建议用另一个模型来验证某个模型的行为，但同时指出，仅靠这一点，行为机制仍会不透明。因此他论述道，限制访问目标和操作的机制应置于模型外部，使模型自身无法更改或绕过。他还重视以下几点：有权限的人能够在中途停止作业；保留无法篡改的行为记录，从而不依赖模型自身的说明，也能验证达到结果的过程。

OpenAI也于10月23日公开了加强内部训练与评估环境隔离的经过。对象是使用开发中模型的研究环境，其使用条件与一般公开提供的服务不同。9月20日，研究用模型利用DNS解析器配置缺陷，有限地访问了真实的互联网。受此事件影响，该公司暂停了开发中最前沿模型的训练与评估，随后经过对策和评估，于10月1日恢复了强化学习和公司内部的模型执行（推理）。

该公司采取的方针是，在最前沿模型的训练中不连接真实互联网，而是准备使用缓存Web等内容的离线环境。此外，还在虚拟机、监控、网络等多个层面叠加防御。

为了确认这些防御是否实际有效，他们在复制研究环境的隔离环境中，让AI代理尝试突破限制[6]。验证用代理使用了计划公开的GPT-6 Astra Cyber以及公司内部的最前沿模型等，调查了可能导致未经许可的外部连接或操作的弱点。在此次验证中，还发现了开头介绍的Brotli漏洞。该公司预见到未来模型可能发现未知弱点，因此将继续进行此类验证，并将其作为判断能否安全推进训练与评估的材料。

作为在小型虚拟机（microVM）中隔离执行环境的OSS，微软还以MIT许可证公开了NVX。它以Linux作为客户机OS运行，隔离执行不可信代码的环境[7]。

保护认证信息，并管理连接后的操作

除了隔离执行环境之外，如何让智能体使用认证信息也变得重要。无论是面向企业的执行基础平台，还是个人使用的登录机制，控制其处理方式的相关举措都在推进。

Google Cloud于10月22日发布的Agent Compute Engine，为每个智能体准备拥有独立OS内核的microVM，从而隔离执行环境。每个microVM都持有有效期较短的认证信息，用于识别在其中运行的智能体。用于连接外部服务的认证信息并不放在microVM内，而是在对外通信时于microVM外部附加。面向用户，计划在未来几个月内提供预览版。

在服务间认证方面，也有减少需要长期保存的秘密信息本身的动向。Vercel于10月22日公布了一项措施，推动从长期固定密钥迁移到使用OIDC（OpenID Connect）的短命令牌认证[8]。Vercel会为Vercel上的应用签发包含其识别信息的令牌。连接目标服务会验证令牌，并根据设定的条件决定允许哪个范围的访问。泄露的令牌一旦过期便无法使用，因此与固定密钥相比，可被滥用的时间更短。

面向个人用户，1Password于10月22日发布了1Password for Agents。当智能体请求登录时，用户选择并批准认证信息，1Password会直接将其输入登录界面。由此，智能体无需接收密码或访问整个保管库，即可继续登录后的作业。发布时，该公司表示将在数日内陆续提供与Meta Muse等的集成[9]。

1Password的FAQ说明，登录后可见的信息和可执行的操作会因智能体和网站而异。除了保护认证信息的机制外，还需要决定让智能体使用哪个账户，以及委托其访问哪些信息、执行哪些操作。

开头提到的Clinton的展望是，具备高网络能力的廉价AI模型将在开发一线普及，从而能够在发布前防止漏洞。作为支撑此类开发的方法，数学上确认代码满足特定性质的形式验证也在取得进展。

Anthropic与Theorem于10月22日发布的研究中，利用了开源库现有的测试。测试用代码的入口点接收输入数据，并执行库的处理。测试中，会反复向该入口点提供各种数据，寻找能引发程序崩溃（异常终止）的输入。不过，无法穷尽所有输入。

因此，研究团队没有逐一尝试输入，而是采用数学证明从入口点执行的代码不会崩溃的方法。具体而言，他们让Claude证明了只要大小低于64MB，无论输入何种内容的数据都不会崩溃。Claude在修正过程中发现的问题的同时构建证明，研究团队则用证明辅助系统Rocq检查了该证明。结果，对于123个开源库中总计239个入口点，成功证明了不会崩溃。

不过，该证明以将面向CPU指令集RISC-V编译的代码在Linux上以单线程运行等为前提[10]。此外，所证明的是从各入口点执行的代码不会崩溃，并非意味着库整体的所有漏洞都已消失。研究团队旨在减轻用AI编写证明的负担，让形式验证应用到更多软件中。

在OpenAI负责网络安全对策的Fouad Matin于9月表示：“欢迎来到网络安全的AGI时代”[11]。将AI用于防御的举措，以及控制该AI行为的举措，正在并行推进。