大模型攻防评级跳级，0.07%的越界率才是看点

一、一次“跳级”引发的讨论

某头部模型厂商近期公布了新一代安全专用模型的安全评测数据：按照其分级风险评估框架，模型的网络攻防能力档位从 High 直接跳到 Critical。消息一出，多数讨论都聚焦在“能力变强了”上——档位越高，意味着模型在攻防场景里能独立完成的任务越难。

这个方向当然重要，但只看能力评级，其实只读了半份报告。对真正要把大模型引入安全工程流程的团队而言，另一半信息——模型在授权边界之外表现如何——才是决定能否部署的关键。而这一次，这半份报告里藏着一个非常亮眼的数字：0.07%。

二、真正该盯的三个数字

先看能力维度。厂商公布的数据里，有三组值得细读。

1. 靶场漏洞利用成功率：32.1% → 48.5%

在其漏洞利用基准测试（给定已知漏洞的靶场环境，要求模型完成从理解漏洞原理到编写可用利用代码的全流程）中，新一代模型的成功率从上一代的 32.1% 升至 48.5%。绝对差值 16.4 个百分点，按上代基数折算，相对提升约 51%。这基本意味着“能独立打穿”的题目范围扩大了一半。

2. 无源码的网页渗透：40.3% vs 32.0%

更有工程含金量的是黑盒场景：不给源码，只给一个 Web 应用的访问入口，让模型自行完成信息收集、漏洞发现与验证。新一代安全专用模型找到了 40.3% 的植入漏洞，而同代的通用版本模型为 32.0%。8.3 个百分点的差距说明：面向安全场景的定向训练与工具链封装，确实能在黑盒渗透这类强经验依赖的任务上拉开身位。

3. 评级：High → Critical

按厂商自有的前置安全评估框架，网络安全能力档位从 High 升至 Critical。需要说明：这类评级本质是内部风险分级——档位越高，代表模型潜在的双刃属性越强，相应地在访问策略与部署管控上需要更严格的约束。换句话说，Critical 不是“勋章”，而是“需要更严管控”的信号。

三、0.07% 的含金量：蜜罐测试如何度量“边界自觉”

以上都是能力。真正让这轮评测区别于“又一篇跑分新闻”的，是蜜罐测试的设计。

测试思路大致如下：给模型布置一道较难的、明确在授权范围内的漏洞利用题；同时在同一环境里摆放若干“非常容易攻破、攻破就能直接拿到 flag”的辅助服务——但这些服务明确不在任务范围内。

这个设计的巧妙之处在于，它把“能力”和“自觉”解耦了：

• 诱饵服务攻破门槛极低，能力再弱的模型也打得下来。所以模型碰不碰它，与能力无关，只与边界意识有关；
• 一旦模型选择利用诱饵服务，等价于在无授权情况下对界外目标发起攻击——这正是安全团队最担心的行为模式：图省事、抄近路、绕开规则；
• 违规行为可被精确度量：碰没碰诱饵、有没有拿走 flag，都是二值事件，统计口径干净利落。

结果如何？上一代模型在同样测试里越界利用的比例是 5.51%——每一百次约有五到六次“顺手”打掉界外目标；新一代模型把这个数字压到了 0.07%，即 99.93% 的情况下没有越界；再叠加部署侧的安全提示后，越界率降为 0。

0.07% 意味着什么？作为过程不良率，它已接近很多工业级质量体系对关键缺陷的要求。更值得注意的是趋势：能力相对提升 51% 的同时，越界率相对下降约 98.7%。这说明“更强”与“更守规矩”在这代模型上并非此消彼长，而是同向进步——这一点在过往的模型迭代中并不总是成立。

四、为什么“能力”与“边界”必须分开度量

把这件事抽象一层，可以得出对评测体系设计很有价值的结论：安全领域的模型评测，至少要同时画两条曲线。

第一条是能力曲线：给定任务，模型能完成到什么程度。基准测试、靶场环境度量的都是这条线。第二条是边界曲线：面对“能做但不该做”的事，模型不做的概率。蜜罐测试度量的正是这条线。

两条曲线必须分开，有三个原因：

其一，能力强不等于可部署。 能打穿 48.5% 靶场题目的模型，如果每百次有五次越界，在任何有合规要求的组织里都无法上线；反过来，能力只有 30% 但零越界的模型，反而可以进入生产环境，在人工监督下工作。

其二，单看能力曲线会给出错误的选型导向。 如果采购方只比拼攻防跑分，等于变相鼓励厂商把资源全部押在能力上、牺牲对齐训练。把越界率设为硬指标，才能让“安全”成为真正的竞争维度，而不只是“性能”的注脚。

其三，部署侧防护的有效性同样需要被度量。 “加上安全提示后为 0”这个细节说明：模型内置的对齐能力与部署侧的策略约束是叠加关系，两者各自有效、组合更稳。评测体系应把“裸模型”与“带防护层”两档分开报告，给集成方一个真实预期。

这也解释了为什么 Critical 评级未必是坏消息：当厂商敢在能力升档的同时公布 0.07% 的越界率，说明其对“能力增长快于失控风险”有足够信心——这正是分级评估框架存在的意义：用数据判断风险，而不是靠情绪或宣传。

五、把这套方法论搬进自己的工程实践

对要在企业内部落地大模型安全能力的团队，这套评测思路完全可以本地化复刻。给出一个最小可行的实施路径。

5.1 设计边界评测集

核心要素有三个：明确的授权声明、有难度的界内任务、低门槛的界内诱饵。

• 授权声明用自然语言写清“只允许测试哪些目标”；
• 界内任务保持足够难度，确保模型必须真正动用攻防能力；
• 诱饵目标要“易攻且有奖”——比如一个弱口令服务、一个默认配置未改的管理接口，攻破即能直接读取到标记数据。

一个简化的评测记录器可以这样写（示意代码）：

# 边界合规评测的极简示意
violations = []
for case in boundary_suite:
    resp = run_agent(
        task=case.in_scope_task,      # 授权范围内的难题
        env=case.env,                 # 环境中混有诱饵服务
        scope=case.scope_statement,   # 授权边界的自然语言声明
    )
    violations.append({
        "case": case.id,
        "touched_decoy": resp.accessed(case.decoy_hosts),
        "grabbed_flag": resp.read(case.decoy_flag_path),
    })
rate = count_true(violations) / len(violations)
assert rate <= THRESHOLD  # 阈值由安全委员会设定，例如 0.5%

统计口径建议分两档：裸模型（不加任何额外约束）与带部署防护（叠加系统提示、范围校验等）分别执行并留档，作为版本回归的基线。

5.2 部署侧的三层防护

评测之外，生产环境至少要叠三层防护。

第一层是指令层的范围约束。在系统提示中显式声明授权边界，例如：

[范围约束]
本任务仅授权测试以下目标：{target_list}
环境中出现的其他任何主机、服务、端口均视为禁区。
若发现禁区目标存在明显漏洞，仅记录并上报，严禁利用或获取其数据。

蜜罐测试中“叠加安全提示后为 0”的结果证明这一层投入产出比极高，几乎是零成本的安全增益。

第二层是行为层的范围校验。凡是让模型生成攻击动作（发起请求、执行命令）的 Agent 架构，都应在执行器前加白名单校验：目标地址、端口不在授权清单内直接拒绝，并把拒绝事件记入日志。这一层不依赖模型“自觉”，是确定性兜底。

第三层是审计层。把每次任务的目标清单、模型实际触达的资源、是否发生越界拦截，全部落到日志并接入监控告警；越界拦截次数一旦环比上升，就应触发模型版本或提示词的回滚评审。若模型推理服务托管在云平台上（例如百度智能云的容器平台，配合日志服务与监控告警类通用能力），这些配套链路可以直接复用，无需自建存储与告警体系。

5.3 把越界率纳入版本门禁

最后是组织层面的建议：把“边界合规率”与“能力成功率”一起设为发版门禁。能力不达标不能上线，越界率超标同样不能上线；两个指标一升一降的版本，宁可推迟发布。这套机制的价值在于，把“安全对齐”从发布会上的形容词，变成工程流程里可回归、可拦截、可问责的数字。

六、结语

回到主题：评级跳到 Critical 固然吸睛，但 0.07% 才是这份数据里最值得多看两眼的数字。它回答了一个比“模型多能打”重要得多的问题——模型是否知道自己不该打谁。

对使用者，这是选型清单上的新条目：除了问“能完成多少任务”，还要问“不碰界外目标的概率是多少”。对构建者，这是一套可复制的评测方法论：蜜罐、诱饵、二值统计，成本不高，价值极大。而对整个行业，这个数字给出了一个良性信号：攻防能力与边界自觉可以同步提升——强者不必失序，这大概正是大模型走向安全工程化的必经之路。