一次面向在线产品的众测
9 月 15 日，2026 年人工智能大模型安全众测结果在国家网络安全宣传周的人工智能安全治理论坛上揭晓。活动动员了 2467 名白帽子，对国内 54 款大模型及智能体应用产品进行漏洞测试，并按开源大模型、大模型应用、Claw 类智能体应用三个赛道分别发布结果。
一个容易被忽略的细节是测试对象的形态：主要针对实时在线运行的产品，而不是离线样本。这意味着测出来的问题带着真实部署环境的成分，而不只是实验室条件下的理论缺陷。
873 个漏洞，其中约七成属于 AI 特有类型
活动累计发现各类安全漏洞 873 个，其中大模型及智能体应用特有漏洞 608 个，占比 70%。
剩下约三成是传统类型的问题——配置错误、权限缺陷、常见 Web 层漏洞等。这个结构本身说明一件事：AI 产品并没有因为「新」而绕开基础安全问题，只是在新问题之上又叠了一层。
大模型侧的三类典型风险
发布结果把大模型与大模型应用的典型漏洞风险归成三类。
一类是提示注入类漏洞，普遍存在，仍是大模型最常见的问题。它的特殊性在于自然语言既是数据也可以是指令，两者从同一个通道进来，边界天然模糊。
二类是信息泄露类漏洞，多发，且安全风险较大。
三类是不当输出处理类漏洞，部分产品存在，且危害较重。问题不在模型说了什么，而在系统拿到模型输出之后怎么处理它。
智能体侧的三类风险不太一样
Claw 类智能体应用被单列一个赛道，风险类型也有区别。一类是代理身份与权限滥用类漏洞，频发且隐患较大；二类是代理目标劫持类漏洞，特点是隐蔽，可以导致非预期的高危操作；三类是非预期代码执行类漏洞，部分产品存在且危害较重。
把两组放在一起看，差别相当清楚。模型侧的风险主要发生在「输入到输出」这一段，智能体侧的风险主要发生在「授权到执行」这一段。前者防的是内容，后者防的是行为边界。
这类活动能证明什么，不能证明什么
它能证明的是漏洞类型的存在与分布结构，以及「AI 特有漏洞已占到多数」这个判断。这些数据对产品方安排修复优先级有直接参考价值。
它不能直接证明的是各产品之间的相对安全水平。不同产品的功能范围、暴露面与在线流量并不相同，同一数量级的漏洞个数在可比性上需要打折扣；公开结果也只列出了「漏洞风险较少」的产品，并没有公布完整排名。
此外，测试策略与覆盖范围会影响发现结果。这类活动的价值更接近「发现了一批真实问题」，而不是「给产品排了座次」。
把「AI 特有」单独统计，意义在哪里
这次发布里比较有意思的一个统计设计，是把「大模型及智能体应用特有漏洞」单独拉出来计数。608 与 873 的关系，回答的其实是「这些产品面对的新问题占到多大比例」。
如果只报总数，读者很容易把它和传统软件的安全水位放在一起比较。分开统计之后，两层事实可以同时成立：一层是配置、权限、依赖这些老问题依然存在；另一层是提示注入、目标劫持这类新问题已经占据了主要位置。两层的处置方式并不相同——老问题靠常规安全工程补齐，新问题需要在架构层面重新设计边界。
这个区分对产品方的价值在于，它避免了「基础合规过了就没问题」这种误判。
众测这种机制，衡量的是哪一类问题
众测的组织方式决定了它能发现什么。数千名外部白帽子在有限时间窗口里各自试探，最容易被挖出来的是那些入口明显、可复现、不依赖内部信息的问题。
这恰好覆盖了提示注入与权限滥用两类——它们都可以从外部构造输入触发，不需要拿到源码或部署细节。换句话说，这次结果里最突出的几类风险，与测试机制本身的偏向是一致的。
反过来说，它不容易发现那些需要长期观察、需要内部数据、或者需要多条链路组合才会暴露的问题。所以把这次结果读成「产品的安全问题清单」是合适的，读成「产品的安全水平评级」就过头了。
另一个不常被注意到的设计是：测试对象为实时在线运行的产品。这让发现的问题具备真实的触发条件，而不是靠推演得出。代价是测试窗口与流量环境受产品现状限制，各产品被覆盖的深度并不均匀。
从这份结果里读不出什么
有一件事需要提前说清楚：这次结果没有公布各产品的逐项数据，也没有给出漏洞的严重度分布。它公布的是优秀产品名单、优秀白帽子与测试团队，以及典型漏洞风险的类型归纳。
因此它更适合用来判断「该往哪个方向投入」，而不是用来横向比较具体产品。对做采购的人来说，这份结果更接近一份需要关注的议题清单。
开源模型与产品应用，评测口径并不相同
三个赛道里，「开源大模型」与「大模型应用」测的不是同一类对象。开源模型测的是权重本身的能力边界——在给定输入下会不会被诱导、会不会带出训练数据里的信息。大模型应用测的是围绕模型的整套工程：检索链路、工具调用、权限校验、输出处理。
同一款底层模型，包成不同产品之后暴露面可以差很多。这就是把两者分开统计的必要性——否则「模型安全」与「产品安全」会被混成一件事，而它们的修复路径完全不同：前者依赖模型迭代，后者依赖工程改造。
对使用方来说，这个区分对应一句更实操的话：不要因为底层模型换成了更安全的一版，就假定自家产品的风险跟着下降。
测试侧的组织方式本身也在变化
组织方在总结里提到一条方向：以 AI 赋能网络安全众测，构建人机协同的众测模式。这句话透露的是测试侧的效率问题——面对数量不断增长的产品与功能，纯人工的漏洞挖掘很难保持覆盖速度。
这个方向如果落地，会带来一个连带问题：由 AI 发现的漏洞，其复现与验证也需要相应的流程。否则报告数量上升，并不等于有效发现上升。
可以带走的几条
其一，把提示注入当成常态风险，而不是边缘问题。它在大模型类产品里依然是出现最多的一类。
其二，智能体产品要把权限边界当成核心防线。身份权限滥用与目标劫持都发生在授权环节。
其三，输出处理需要单独设计。模型输出进入下游系统之前，应当有一道明确的校验。
其四，上线前引入外部安全评估。这次众测的前提是产品在线运行，说明测试发生在真实部署形态上。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。