大模型还没闯祸，编排层先失守了
AWS 紧急修复开源 AI 智能体编排平台 Loom 的三个漏洞，可导致未鉴权管理员接管与 OAuth2 凭证泄露；同期 CNCERT 通报 54 款大模型测出 873 个漏洞，三成仍是传统安全问题。本文拆解这两起事件背后的共同信号：AI 安全的第一波风险，正集中在模型之下的编排层与凭证体系。
大模型还没闯祸，编排层先失守了
AWS 悄悄发了一波安全更新，修的是自家开源 AI 智能体编排平台 Loom 的三个漏洞——最严重的一个，允许未认证的管理员接管。几乎同一时间，CNCERT 通报了对 54 款大模型的测试结果：873 个漏洞，其中 30.4% 仍是传统安全漏洞。
两件事放在一起看，结论其实很冷静：AI 安全的第一波真实事故，大概率不会发生在大模型的权重文件里，而是发生在我们为它搭的那层脚手架上——编排、鉴权、凭证、内部服务调用。模型还在「学做人」，托举它的基础设施已经先被摸到了门把手。
这篇文章，我们把这两条线索拆开看。
🧩 一块开源编排平台，三个直通管理员的路标
金句：智能体越能干，它的管理面就越像一座金矿。
先看事件本身。据 GBHackers 报道（参见文末参考来源 [1]），AWS 在安全公告中披露了 Loom 平台的三个漏洞，风险指向非常清晰：
| 风险点 | 影响 | 官方处置 |
|---|---|---|
| 未认证管理员接管 | 攻击者无需登录即可获得管理权限 | 升级至 1.7.0 |
| OAuth2 凭证泄露 | 平台托管的第三方凭证可被读取 | 升级至 1.7.0 |
| 内部服务访问 | 可触达本不应暴露的内部接口 | 升级至 1.7.0 |
“编辑注：Loom 漏洞对应的 AWS 安全公告具体编号，以 AWS 安全公告官方页面（https://aws.amazon.com/security/security-bulletins/ ）检索「Loom」结果为准；发布前请核实并在此处补入公告编号与直达链接。
注意一个细节：AWS 强烈要求用户升级所有 Loom 部署和 fork 分支到 1.7.0 版本。「fork 也要升」这五个字，暴露了开源供应链在 AI 时代的真实处境——官方仓库打了补丁，但散落在各家公司私有仓库里的 fork，补丁是够不着的。
这三个漏洞组合起来，不是三个独立问题，而是一条完整的攻击链：
拿下一个编排平台的管理权限，等于同时拿到了所有挂在这个平台上的智能体的「大脑权限」和「手脚权限」。做渗透的人都知道，这种管理面漏洞的性价比极高——不需要鱼叉邮件，不需要钓密码，一个未鉴权接口就够了。
从近年各编排平台的版本迭代节奏与公告密度不难看出一个趋势：智能体编排平台上线节奏非常快，安全评审往往赶不上功能迭代，「先跑起来再说」是普遍心态。Loom 这次没有造成公开的入侵事件通报，属于在窗口期内被自己人先发现了。下一个平台未必有这个运气。
📊 873 个漏洞里，三成是老面孔
金句：攻击者从不关心你的模型有多先进，只关心你的暴露面有多老旧。
再看 CNCERT 这份通报（参见文末参考来源 [2]）：54 款大模型，测出 873 个漏洞。最有信息量的不是总数，而是结构——30.4% 仍是传统安全漏洞。
需要明确的是：官方通报目前仅披露了「30.4% 为传统安全漏洞」这一比例，其余约 69.6% 漏洞的具体分类构成，待官方分类披露。在此之前，任何对其余部分构成比例的估算都只是推测，本文不作猜测，仅保留可核实的信息。
这个数字戳破了一个流行的迷思：很多人以为 AI 安全是一套全新的学问，要重新学一遍。但三成传统漏洞意味着，注入、越权、信息泄露、组件缺陷这些老问题，只是换了场景继续发生。
文章开篇素材里那句话值得反复咀嚼：AI 安全并非另起炉灶。做过 Web 安全的人都清楚，一个系统里有模型，不代表模型是唯一入口；只要它有 API、有管理后台、有身份体系、有文件处理，传统的攻击面分析框架就全部适用。
这对安全从业者是好消息，也是坏消息。
好消息是：Web 安全十几二十年积累的方法论——资产测绘、鉴权审查、渗透测试、漏洞管理流程——大部分可以直接迁移。网安生不需要推倒重来，把原来那套功力对准新的攻击面即可。
坏消息是：很多公司在建 AI 系统时，把传统安全团队排除在了流程之外。模型团队自己搭服务、自己开接口、自己管密钥，安全评审形同虚设。从公开的技术博客与岗位描述看，不少智能体项目由模型团队全程主导，安全职能是否前置难以核实——这本身就是值得警惕的信号。
🔑 OAuth2 凭证，智能体时代的万能钥匙串
金句：给智能体每加一分自主权，就要多配一串钥匙。
Loom 这三个漏洞里，最值得展开的是 OAuth2 凭证泄露。
想一想智能体是怎么工作的。一个编排平台上的智能体，要干活就需要权限：调 GitHub 要 token，读数据库要连接串，发邮件要 OAuth2 授权。这些凭证集中托管在编排平台里，本质上是一把串起来的万能钥匙。
于是攻击面出现了结构性变化：
| 传统架构 | 智能体编排架构 |
|---|---|
| 凭证分散在各应用，各自为政 | 凭证集中托管在编排平台 |
| 打穿一个应用，拿到一份凭证 | 打穿编排平台，拿到全部凭证 |
| 权限边界按应用划分 | 智能体权限边界模糊且动态 |
| 审计看应用日志 | 审计要看模型调用与工具调用链 |
这就是身份与访问安全圈最近反复讨论的问题：智能体是非人类身份增长最快的类别，而大多数公司的 IAM 体系里，根本没有给它们准备好位置。凭证怎么轮换、权限怎么收敛、异常调用怎么发现，多数团队还没有答案。
Loom 的漏洞把这个矛盾具象化了：一个未鉴权的管理接口，加上集中托管的 OAuth2 凭证，等于把整栋楼的钥匙挂在门外的挂钩上，旁边还贴了张「内部房间分布图」（内部服务访问）。
产业层面的判断是：凭证治理会成为 2025 年之后 AI 安全投入的第一优先级，排在模型加固之前。因为攻击者永远走成本最低的路——与其费劲越狱模型，不如直接偷它的钥匙。
🏗️ Agent 技术栈的责任真空地带
金句：模型出事找模型厂商，编排层出事找谁？
把 Loom 事件放到整个智能体技术栈里看，会发现一个尴尬的责任真空：
模型层有模型厂商兜底；但编排层呢？Loom 是开源项目，AWS 发布了公告和补丁，可使用的责任边界在哪里——是平台维护者、云厂商，还是自己 fork 了一把就去跑的企业？
开源世界的惯例是「按现状提供」（as-is），出了漏洞厂商发公告就算尽了义务。但智能体编排平台不是普通的开源工具，它是生产系统的控制面。用 as-is 的心态去跑控制面，等于把生产环境的钥匙交给一个不签 SLA 的第三方。
这里面有三重产业风险：
1. fork 失修风险。 官方补丁到 1.7.0，fork 出去改过代码的企业，合并上游补丁的成本可能高到宁愿硬扛。开源供应链的「分叉即分险」，在 AI 基础设施上会加倍放大。
2. 默认配置风险。 编排平台为了开箱即用，管理面往往配置宽松。企业拿来做 PoC 很顺手，直接上生产就是隐患——从 PoC 到上生产之间如果没有一道安全基线检查，默认配置「原样上生产」几乎是大概率事件。
3. 补丁触达风险。 传统软件有强制更新渠道，开源编排平台依赖用户自己盯公告。安全公告淹没在 GitHub Release 里，是常态。
由此可以推演一个产业机会：智能体基础设施的安全加固，会催生一批新生意——编排平台的安全基线审计、非人类身份管理（NHI）、智能体专用的密钥托管与最小权限方案。这条赛道的买家，就是每一个准备把智能体放进生产环境的企业。
🛠️ 防御者现在该做的四件事
金句：别等模型学坏，先检查门锁。
落到操作层面，基于这两起事件，给防御者四条可执行的建议：
第一，立刻盘点智能体编排资产。 用的是哪个平台、什么版本、有没有 fork 改造、暴露在哪个网段。Loom 的教训很直接：官方已经给出明确动作——全部部署和 fork 升级到 1.7.0。还没盘清楚资产清单的团队，连升级都无从谈起。
第二，把编排平台当作最高等级资产来管。 管理面不该直接暴露公网，鉴权必须上强认证，访问要过跳板和审计。这没什么新技术，全是老功夫——恰恰说明传统安全流程在 AI 场景完全够用，缺的只是执行。
第三，重构凭证托管。 OAuth2 token、数据库凭证不该明文躺在编排平台里。接入密钥管理系统，做最小权限、定期轮换、异常使用告警。给智能体的每一个工具调用授权，都问一句：它真的需要这么大权限吗？
第四，把传统漏洞管理流程平移过来。 CNCERT 那份 873 个漏洞的通报已经说明问题——30.4% 的传统漏洞，用现有的扫描、渗透、修复流程就能覆盖大头。AI 特有的攻击面（提示注入、工具滥用等）可以增量补充，但不必等一套「全新方法论」才开始动手。
综合公开案例与已披露事件的经验，已经跑通的企业有一条共同路径：AI 项目立项即拉安全团队进流程，成本最低、效果最好。事后补救的代价，通常是事前的数倍。
小结：安全的本质没变，只是换了承重墙
Loom 的三个漏洞和 CNCERT 的 873 个漏洞通报，指向同一个判断：当前 AI 安全的主战场，不在模型权重里，而在模型之下的编排层、身份层和基础设施层。
这是行业的青春期烦恼——技术狂奔，地基未稳。但这也是安全从业者的机会窗口：传统攻防功力在这里非但没有贬值，反而是最稀缺的资产。
向前看一步：随着智能体获得更多自主执行权，编排平台会成为新的「域控制器」级别资产，围绕它的攻防、合规与产品生态，在未来一两年会快速成形。现在把门锁好的人，届时会感谢今天的自己。
而无论攻防双方的技术如何演进，本文讨论的两个事件其实已经给出了行动顺序：先盘资产、先管凭证、先跑通传统流程，再谈 AI 特有的新攻防。顺序对了，安全感才会真正落地——这不是悲观，而是一个从业者对行业最务实乐观的期待。
参考来源
1. AWS Loom 平台安全更新：据 GBHackers 相关报道（发布前请以实际报道 URL 核实补入）；AWS 安全公告官方页面：https://aws.amazon.com/security/security-bulletins/ （公告编号待以官方页面核实后补入具体编号与直达链接）。
2. CNCERT 大模型安全测试通报：CNCERT/CC 国家互联网应急中心官网：https://www.cert.org.cn/ （通报标题与编号待以官网发布页核实后补入，核实路径：官网「通报与预警」栏目检索）。
“编辑说明：原文中「据多位接近云厂商安全团队的人士透露」「据业内人士私下交流」「据接近多家智能体创业公司的人士透露」「据多位安全顾问的观察」等无法核实的匿名信源表述已删除或改写为基于公开信息的分析；873 个漏洞构成比例图中「AI 特有攻击面漏洞约七成」为推测性内容，已改为「待官方分类披露」。其余信源（GBHackers 报道、AWS 公告、CNCERT 通报）已列入参考来源，具体编号与链接发布前需逐一核实。