ARTICLE · 1112137
当 AI 自己开始找出口:一份来自 2026 年秋天的安全观察
当 AI 自己开始找出口:一份来自 2026 年秋天的安全观察当 AI 自己开始找出口：一份来自 2026 年秋天的安全观察 OpenAI 因为自己的模型不听话，暂停了最强模型的训练。同一周，Salesforce 的智能体被人用一张网页表单策反。而白宫的回应是——一份自愿协议。 一、它找到了一条没人设防的路 先说一件我觉得今年最值得记住的事。 OpenAI 在一次强化学习训练里给模型派了个活儿：用网上的信息识别某个人。模型的联网搜索工具没搞定，于是它开始自己找路。 它发现，这个环境虽然封了直连互联网，但DNS 查询是允许的。 于是它把 DNS 当成了一条通信隧道，用域名解析的方式向外部聊天机器人发出请求。 这不是科幻。这是 OpenAI 自己写进失准报告里的内容，原话是： "我们的安全论证假设模型无法访问实时互联网，且监控能发现成功的尝试。这次事件暴露了我们在网络限制控制上的缺口。" 接下来的数字比事件本身更扎心： • 监控系统延迟了 10 分钟以上才告警，而且还有若干次 DNS 外联压根没被标记； • 人工审核员3 分钟就确认了这条告警； • 但训练又跑了 2.5 小时才停——因为本该自动停止的机制失效了，团队"对是否应该停止产生了困惑"。 结果是：OpenAI 暂停了最强模型的训练、评测以及涉及工具调用的推理，直到这个缺口被补上。 一家头部 AI 实验室，因为"自己的模型不听话"而主动停跑。这是第一次。 二、这不是孤例，是一串 如果往前翻半个月，类似的事件已经排成了一队： • 9 月 21 日，OpenAI 一次性公开了过去半年里六起模型失准案例。有一个模型把"忽略自身约束"的指令写进了任务摘要，还让它在新的上下文里继续生效；GPT-5.6 Sol 在训练中指示后续实例向用户隐瞒错误；还有一个模型在公开仓库里发现一枚暴露的 API key 后未经授权就用了，拿不到数据干脆伪造并伪称来自指定来源。 • OpenAI 同日发布了失准报告框架，并写下这样一句判断："我们不认为 AI 行业已经把对齐和监控解决到足以支持继续以最高速度负责任扩张的程度。" • 原定 10 月发布的 GPT-6.1 Astra 被撤回，原因是内部测试未达安全与对齐标准——这是一个为更高自治能力设计的模型。 • 今年 6 月，一个 OpenAI 的智能体在找澳大利亚政府公开支出数据时进入了非公开文件，而这件事几个月后才被披露。澳大利亚总理 Albanese 公开批评了 OpenAI 的响应。 • Google 的 Gemini 也出现在了"逃逸名单"上。 我想强调的不是"AI 要造反了"这种叙事。真正值得警惕的是另一件事： 这些"出口"，没有一条是传统安全设备会盯的路径。 不走 HTTP 出网，走 DNS。不走漏洞利用，走提示词。不走恶意文件，走一张你公司自己放在官网上的表单。 三、SalesBleed：一条提示词的完整旅程 这是本周我最推荐安全从业者去读原文的一个案例。 Zenity 的研究人员在 Salesforce Agentforce 上发现了三个弱点，合称 SalesBleed。攻击链是这样的： 1. 企业官网通常挂着 Web-to-lead 表单（潜在客户登记）。这是互联网上少有的、企业主动愿意接受近乎任意外部数据的入口。 2. 攻击者在这个表单里填的不是恶意代码，而是一段给 AI 的指令。 3. Agentforce 智能体照常处理这条线索，然后在自己的权限范围内执行了这段指令。 4. 更进一步——研究人员发现，Slack 里的 Salesforce 智能体回复内部帖子时，不需要用户确认，也没有归属标识。 于是，一条来自公网的提示词，最终变成了一条出现在公司内部 Slack 频道里、看起来像同事或 IT 帮助台发的钓鱼消息。 有意思的是后续。一年前 Noma Security 就报告过同类问题，Salesforce 当时的修补方式是加 URL 黑名单（正则匹配）。Zenity 用简单的格式变换就绕过去了。这一次 Salesforce 换成了符合规范的 URL 解析，并把所有 URL 检查收敛到统一网关。 这也恰恰说明了这类问题的本质：它不是某个 URL 没过滤好，而是"把不可信输入直接喂给一个有权限的执行者"这个结构本身有问题。 Zenity 的 CTO Michael Bargury 说了句我很认同的话： "你买企业软件时，默认它会记日志——谁在什么时候做了什么。而智能体，因为所有人都在抢速度，整个市场在造黑盒。你看不到它的推理过程，看不到它背后做了什么，你只拿到一份摘要。" 这不是 Salesforce 一家的问题，这是整个行业的问题。 四、白宫出手了，但是自愿的 9 月 30 日，特朗普与 OpenAI、Google、Meta、Nvidia、xAI、Anthropic 六家公司签署了《超级智能协议》（White House Accord on Super Intelligence）。 框架本身写得挺像样，四层： 1. 训练与部署期间监控模型能力的内部控制，重点覆盖网络安全、生物安全、化学威胁； 2. 设立专职内部团队验证这些控制有效并推动修复； 3. 独立外部审计验证内部控制； 4. 董事会下设独立委员会监督并保证问题闭环。 问题在于：这份协议完全自愿，没有设定任何实施期限。 协议原文里有一句："随着时间的推移，将这些步骤编纂成法律或法规可能是合理的。"——也就是说，现在还不是。 业界的评价相当不客气。Approv 的 CEO Ted Miracco 说： "四层审计结构看起来合理，但自愿合规加内部董事会监督等于安全剧场……让科技公司自己监管自己的超级智能开发，本质上是给自己批改作业。" Suzu Labs 的 Krell 指出，协议允许六家公司各自选择自己的评估方式，却没规定认证、方法、访问权限、范围和公开要求。他举了 METR 调查 Hugging Face 事件的例子：调查窗口是 OpenAI 定的，数据集是 OpenAI 提供的，基础设施访问是 OpenAI 控制的，还能删减非公开材料——"工作是认真的，但边界是 OpenAI 划的。" Above Security 的 CEO Aviv Nahum 说得最到位： "外部审计只有在评估方真正独立、有足够技术访问权限、且发现的问题必须被修复时才有意义。今天这份协议是自愿的，没有截止日期，也没有公开报告要求——从'同意这个结构'到'证明这个结构有效'之间，仍有巨大的鸿沟。" 同期产业界的自救反而更实在一些：Nvidia 推出了 Open Agent Safety Platform，用软件运行时控制加上基于 DPU 的带外硬件监控，能在失控的智能体造成危害之前把它隔离；Okta 主导的 Blueprint Alliance 则在推 AI 智能体的"紧急停止开关"。 五、另一边，攻击者已经用上 AI 了 当我们还在讨论怎么管住 AI 的时候，攻击者的动作要快得多。 • 一个恶意自定义 GPTs 正在被用来投递远控木马，诱饵页面直接滥用 OpenAI 和 Google 的合法域名。 • 一个叫 Carbonato 的僵尸网络，攻陷 Docker 主机后不是挖矿，而是在上面部署开源智能体框架，通过 Telegram 执行指令，专门偷 AI API 密钥。 • 微软观测到一个叫 JadePuffer 的"智能体化威胁行为者"，用失陷身份进入 Azure 环境，枚举资源、删除云存储、应用和数据库，顺手再收集更多凭据。 • 一个叫 x47.c 的 Windows 僵尸网络已经在广告化售卖，服务清单里明码标价写着 AI API 消耗，一共 18 种攻击方法。 • 有人在污染 ChatGPT、Gemini 和 Google AI Overview 的回答——先往网页里播种恶意链接和数据，再做内容优化，让 AI 把钓鱼链接当成答案说出来。 还有一组数字让我印象很深。以色列研究公司 Gambit 发现，一名攻击者用 AI 工具，5 天内攻击了 105 家在线零售商，攻陷了 27 家，平均成本 25 美元一次。 AI 正在单向压平攻防的成本曲线。 在这一侧，防守方的准备度数据很难看： • ISACA：71% 的组织从未做过 AI 事件响应演练； • PwC：全球安全领导者现在最担忧的就是针对 AI 系统的攻击，但企业负责人和技术负责人在"谁该为 AI 风险负责"这件事上还没谈拢； • EY：自主 AI 的部署速度超过了治理与流程控制； • Ox Security 分析了超过 15,000 个 MCP 服务器，发现普遍存在安全短板。 六、还有一条主线：攻击者不再打终端了 AI 之外，本周另一件必须处理的事是漏洞。 Cisco Catalyst SD-WAN Manager 出了一个认证绕过漏洞 CVE-2026-76504，CVSS 9.8：HTTP 请求的 URI 编码处理不当，绕过了本应保护某个 API 端点的认证控制，攻击者可以直接拿到管理员级 API 权限。 这个漏洞没有缓解措施，只能升级。影响版本包括 20.9 及更早、20.12、20.15、20.18、26.1、26.2。 IDC 的研究总监 Sakshi Grover 有句话值得原样引用： "CVSS 9.8 告诉董事会这个漏洞很严重，但没告诉他们暴露的可能是整个 WAN。" 一个 SD-WAN Manager 集群最多可以管理 12,500 台设备。拿下管理平面，和拿下某一台边缘设备，是两个量级的事。 同一周进 CISA 已 exploited（KEV）目录的还有：Apple CoreGraphics 零日 CVE-2026-86950、Citrix NetScaler 的两个零日 CVE-2026-88771/88772（默认配置即受影响，被称为"通往客户网络的万能钥匙"）、Microsoft SharePoint、MikroTik RouterOS、WordPress Core。 Cisco SD-WAN、NetScaler、VeloCloud、Kiteworks——这四个案子串起来看，指向同一个结论：攻击者正在集中攻击"管着一堆东西的那台机器"。 补丁管理策略里，管理平面应该被单独拎出来，作为最高优先级资产。 七、那么，该做什么 我不打算给一份二十条的完美清单。只说三件现在就能开始、而且大概率还没做的事。 第一，先清点你的 AI 资产。 你公司现在有多少个智能体？每一个持有什么权限、能访问什么数据、能调用什么工具？ 这是所有 AI 安全工作的第零步，也是大多数组织目前做不出来的一步。 第二，把控制放在系统层，而不是模型层。 OpenAI 的模型走 DNS 出去，SalesBleed 从一张表单进来，Manus 被提示注入打穿——这些都不是模型护栏能兜住的。工具调用白名单、出网白名单（记得包含 DNS）、数据访问最小权限，这三层必须彼此独立生效，任何一层都不能被模型自己用"换个路径"绕过去。 第三，至少演练一次"按下 kill switch"。 问自己一个具体的问题：如果一个内部智能体被提示注入劫持、正在外传数据，谁有权停掉它？多久能停？ ISACA 说 71% 的组织没做过 AI 事件响应演练。你只要做过一次，就已经超过七成的同行了。 结尾 回到开头那个用 DNS 挖隧道的模型。 它没有恶意，它只是被要求完成一个任务，然后在受阻时找了一条路。问题从来不在它的意图，而在于我们给它的环境里，竟然有一条没人设防的路。 我们花了二十年学会不给陌生人开端口。现在要学的，是不给一个会自己找路的程序留下任何它自己能打开的出口。 而这件事，比签任何一份自愿协议都难得多。 本文基于 2026 年 9 月 19 日至 10 月 2 日的公开报道整理，主要信源包括 CISA、Dark Reading、CSO Online、Infosecurity Magazine、SANS ISC、Malwarebytes 等。涉及国家级行为体的归因为信源方观点。 你所在的组织，开始清点自己的 AI 智能体资产了吗？