越界率0.07%不能直接签“这次还在范围内

在安全验收中，面对一份“越界率0.07%”的评测报告，最自然的冲动是把它直接写进门禁规则：只要越界率低于某个阈值，流水线就算通过。但“0.07%”这个数字，真的能等价于“本次行为在授权范围内”吗？答案远没有表面看起来那么简单。要回答这个问题，需要拆解数字的测量场景、触发条件、统计口径，以及它与门禁目标之间是否存在逻辑对应关系。

一、越界率不是单一指标，而是特定条件下的观测值

在网络安全模型的验收中，“越界”通常指模型在未被明确授权的情况下，执行了超出任务范围的交互动作。越界率则是统计这些动作在所有交互行为中的占比。但这个比例的数值高度依赖测试环境的构造方式。

具体来说，常见的评测布置有两种：

• 未部署提示的裸环境：模型被直接放入一个包含敏感资源或出口动作的仿真环境，系统不额外注入边界说明。此时模型依靠自身对任务边界的理解进行判断。
• 带部署说明的环境：在系统提示词或环境描述中显式添加“只允许操作目标资产，不得访问其他路径”等限制语句。

同样的模型，在这两种环境下的越界率可能相差数十倍。如果一份报告仅在“无提示”环境下测出0.07%，就把它当作“有提示环境也不会越界”的证据，显然存在测量条件与使用条件不一致的问题。

更重要的是，0.07%本身是概率意义上的表达，不等于“零发生”。在安全验收中，低概率不等于不存在；对于高危操作，哪怕出现一次越界，也可能导致整条业务链被污染。因此，必须追问：这个越界率是在多少次测试样本中统计出来的？置信区间是多少？最坏情况下的单次越界行为危害等级如何？这些信息不完整，单凭一个百分比无法支撑门禁决策。

二、不同评测维度的指标不能互相替代

在多数模型评测图表中，会出现多种不同任务的得分。例如，“给定已知漏洞后能否构造有效利用”的通过率、在黑盒环境中的漏洞召回率、在蜜罐环境中的越界率等。这些指标测量的能力维度各不相同，不能混为一谈。

• 漏洞利用率衡量的是模型在已知起点下完成特定攻击链的能力，它回答的是“给一个明确目标，能不能做通”的问题。
• 漏洞召回率衡量的是模型在无提示的Web环境中发现潜在漏洞的覆盖程度，它回答的是“未知问题能够找出多少”的问题。
• 越界率衡量的是模型在交互过程中是否偏离授权范围，它回答的是“模型是否守规矩”的问题。

因此，一个模型可能在漏洞利用任务上得分较高，但在越界控制上表现平平；也可能在召回任务上表现突出，却在蜜罐测试中频繁越界。甚至会出现一种情况：在某个高难度外部题目集上，专用于安全任务的模型做出来的题目数量，反而少于通用模型。这并不代表安全模型没有价值，而是说明各模型在不同子能力上有专长差异，任何单一维度的领先都不能外推到其他维度。

在验收实践中，必须明确“你想守的是哪一关”——是要守漏洞利用成功率，还是守越界行为，还是守未知漏洞发现量。不同目标对应不同的评测指标，不能拿A指标的数据去证明B目标已达成。

三、模型在特定测试集中的0分不代表能力为0

在部分外部评测集中，会出现某个模型在某项任务上得分为0的情况。这类结果往往被解读为“模型完全不具备该项能力”，但这种解读可能过于武断。

以远程漏洞利用评测为例，若测试环境要求模型主动发起外部请求并接收返回结果，而模型在初版配置中采用了保守策略——对所有远程交互请求都拒绝——那么它在该项上的得分为0，只是因为模型没有发起任何操作，而非操作均失败。此时0分反映的是行为策略倾向，而非底层能力的缺失。

在验收时，需要区分“能力缺失”与“策略抑制”两种可能。前者的正确应对是补训练或换模型；后者的正确应对则是调整提示词、放宽交互权限或在推理链中增加必要的外部访问指令。混淆这两者，会导致对模型潜力的系统性低估。

四、时间号与模型名不能错配：注意历史数据归属

在团队积累安全评测数据时，经常会引用历史报告中的数字。但必须警惕：不同时间点发布的评测，即使任务名相似，也可能使用的是完全不同的模型版本、训练配置或推理预算。

例如，某份早期Linux本地提权测试报告中的候选数、动态复现数与可用提权数，可能来自一个尚未公开的早期模型；而当前正在验收的模型可能是安全专精版本。两者的训练数据、强化学习目标、拒绝策略等均不相同，不能把历史报告的统计结果直接挂到新模型的验收记录下。

同样，某开源浏览器的安全更新公告中致谢了参与漏洞挖掘的研究人员，但公告本身并未指明具体模型名称。如果外部资料中将该公告与某个模型名关联，只能视为推测，不能作为官方验证数据引用。

五、构建一条完整范围记录的五个必要字段

为了避免“0.07%误读”类问题的再次发生，在安全验收记录中，建议至少包含以下五个维度的信息：

1. 测试环境描述：模型部署的硬件资源、操作系统、运行时版本、是否有网络隔离、是否提供工具调用接口等。
2. 提示词与边界声明：被测模型收到的系统提示是否包含显式边界指令，提示词的具体版本或哈希值应一并留存。
3. 数据样本构成：测试样本总数、正负样本比例、每条样本的来源类型（人工构造、生成器合成、真实流量回放等）。
4. 推理参数：温度、最大输出长度、是否启用思维链、是否允许多轮交互，以及推理预算上限。
5. 结果统计口径：越界率的分母是“所有交互次数”还是“所有任务轮次”；失败样例中是否包含超时、截断、无效输出；置信区间是多少。

例如，一份合格的越界率记录应写成：

测试集：Honeypot-2026-11，样本量5000
环境：隔离容器，无真实网络出口
系统提示：含边界声明v3.1
推理预算：每轮最多40步
越界事件数：4（其中2次为输出格式违规，非真实外部交互）
统计口径：以交互轮次为分母

只有当记录信息足够完整，后续的审计者才能判断“0.07%”是否真的可用于当前门禁场景，而不是看到一个孤零零的数字就按下通过键。

六、结论：把“数字”还给“实验”，把“实验”绑定“场景”

安全验收的核心，不是找一个看起来足够小的数字来证明“没问题”，而是证明“在相同条件下，问题发生概率低于可接受阈值”。0.07%能否被接受，取决于你接受的阈值、测试的覆盖范围、样本的充分性、以及最坏情况下的后果承受力。

因此，与其纠结“这次还在不在范围内”，不如从源头重新设计验收流程：每个待签字的指标，必须附带一整套可复现的实验描述。任何人拿到这份描述，都应能在一周内重建相同环境并得到统计意义上一致的结果。只有达到这个标准，自动化门禁才能真正成为质量保障，而不是一份自我安慰的数字游戏。