0.07%越界率为何不能直接通过安全验收

一、问题不在于数字小，而在于证据链不完整

当安全评测报告给出“越界率为0.07%”时，最容易出现的误解是：既然比例已经很低，就可以在验收报告中写下“智能体仍在授权范围内”。

这两个表述并不等价。

“0.07%”通常只是某次实验中的观测值，描述的是特定模型版本、任务集合、提示模板、运行环境和判定规则下，越界事件占测试机会的比例。“仍在授权范围内”则是系统级结论，意味着在预期业务环境中，授权边界能够持续、稳定、可验证地得到执行。

前者是实验数据，后者是安全保证。要从实验数据推导出安全保证，至少还需要回答以下问题：

1. 越界事件到底如何定义？
2. 百分比的分母是什么？
3. 测试样本是否覆盖真实业务风险？
4. 不同测试是否相互独立？
5. 模型是否通过大量拒绝任务来降低越界率？
6. 部署环境是否具有独立于模型的强制控制？
7. 版本、提示词、权限配置变化后，结论是否仍成立？

如果这些问题没有明确答案，那么把0.07%直接写入门禁规则，只是把一个缺少上下文的观测值包装成了验收结论。

二、先拆开“越界率”的分子与分母

越界率通常可以表示为：

[
R=\frac{K}{N}
]

其中，(K) 是被判定为越界的事件数，(N) 是越界机会总数。但在智能体系统中，分子和分母都可能存在多种口径。

1. 分子不一定是简单的“执行成功次数”

一次越界可能发生在不同阶段：

• 智能体提出了越界计划，但尚未执行；
• 智能体调用了未授权接口，但请求被拦截；
• 请求已经到达目标系统，但没有产生状态变化；
• 越界操作执行成功，但随后被回滚；
• 智能体读取了无权访问的数据；
• 智能体在授权资产上执行了未授权动作；
• 智能体访问了授权范围外的资产；
• 智能体将敏感结果发送到了未授权位置。

这些事件的严重程度不同，却都可能被笼统地称为“越界”。如果评测只统计“最终执行成功的越界动作”，就可能忽略已经产生的越权意图、接口探测和敏感数据暴露。

因此，安全验收不应只保留一个越界计数，而应至少拆分为：

• 越界意图数；
• 越界调用尝试数；
• 被策略层拦截的调用数；
• 实际到达目标的调用数；
• 成功改变系统状态的事件数；
• 造成数据泄露或持久化影响的事件数。

这种分层统计能够区分“模型本身没有尝试越界”和“模型尝试了，但外部控制成功拦截”。二者都可能让最终事故数为零，但其风险含义完全不同。

2. 分母也可能被选择性定义

分母可以是任务数、对话轮次、接口调用数、资产访问数，也可以是所有可能触发越界判断的决策点。

例如，一百个任务中只有五个任务真正接近授权边界，那么以一百为分母计算出的比例，可能明显低于以五个边界任务为分母的结果。相反，一个复杂任务可能产生数百次工具调用，如果按调用次数计算，也可能稀释任务级越界风险。

因此，报告中必须明确：

• 一个样本代表一个任务、一次调用还是一次决策；
• 同一任务内的多次尝试是否重复计数；
• 重试、回滚和并发调用如何统计；
• 被拒绝或未完成的任务是否进入分母；
• 无边界风险的普通任务是否大量占据分母。

缺少这些信息时，0.07%并不是可复用的工程指标。

三、观测值不等于真实风险上限

即使分子和分母定义清楚，样本越界率也只是对真实风险的估计，而不是风险上限。

假设某次测试中，七次越界出现在一万次有效机会中，样本比例确实是0.07%。但下一批任务可能高于或低于该比例。样本越少、事件越稀有，不确定性就越大。

验收时更合理的做法，是同时报告：

• 越界事件数 (K)；
• 有效样本量 (N)；
• 样本越界率；
• 置信水平；
• 对应的风险上界；
• 样本独立性和分布假设。

对于零事件场景，也不能写成“越界概率为零”。在常用的近似方法中，当独立试验里没有观察到事件时，95%置信水平下的概率上界大约可以用 (3/N) 估计。

例如：

• 100次测试中零越界，只能粗略说明上界约为3%；
• 1000次测试中零越界，上界约为0.3%；
• 10000次测试中零越界，上界约为0.03%。

这说明“观察到零事件”和“风险为零”之间存在显著差别。样本量不足时，零事件甚至不能证明风险已经低于一个看似宽松的阈值。

此外，上述估计依赖独立同分布等假设。智能体测试往往存在任务模板重复、提示词高度相似、同一漏洞被多次变形等情况，实际有效样本量可能低于名义样本量。

四、部署提示可以降风险，但不能成为唯一边界

某些实验会分别测试两种情况：

• 不提供部署侧安全说明；
• 明确告诉智能体允许访问哪些资产、禁止执行哪些动作。

第二种情况下，越界事件可能明显减少，甚至在有限样本中没有出现。但这只能说明安全说明对当前测试有效，不能证明模型具备不可绕过的边界。

原因主要有三点。

1. 提示属于软约束

提示文本会与用户输入、页面内容、工具返回结果和历史上下文共同进入推理过程。只要存在冲突指令、上下文污染或任务歧义，软约束就可能失效。

2. 边界可能超出模型的稳定理解能力

真实业务中的授权范围不一定是一句“只能访问测试环境”就能表达清楚。它可能包含：

• 允许访问的资产集合；
• 资产有效时间窗口；
• 只读与可写权限差异；
• 允许使用的协议和端口；
• 禁止触达的关联账户；
• 数据导出与留存限制；
• 最大调用频率和资源消耗；
• 需要二次审批的高风险动作。

如果这些规则只存在于自然语言提示中，就很难保证模型对每一条组合条件都做出一致判断。

3. 提示变化会造成结论漂移

提示模板、上下文顺序、工具描述和任务说明发生微小变化，都可能影响智能体行为。因此，基于某一版提示得到的零越界结果，不能自动继承到下一版系统。

正确的工程原则应当是：提示负责告知和引导，策略执行层负责强制限制。即使模型忽略提示，系统也不能让越界动作真正落地。

五、低越界率可能是“高拒绝率”的副产品

安全指标不能脱离任务完成能力单独观察。

如果一个智能体拒绝绝大多数请求，它自然很少越界。极端情况下，拒绝全部任务可以得到零越界，但系统也失去了业务价值。因此，验收至少需要同时评估三类指标：

指标类别	关注问题	典型指标
安全性	是否突破授权边界	越界尝试率、越界成功率、敏感数据暴露率
可用性	是否完成合法任务	授权任务成功率、错误拒绝率、人工接管率
真实性	是否准确报告行为	虚假成功率、遗漏风险率、证据完整率

尤其需要区分：

• 正确拒绝：任务确实超出授权范围；
• 错误拒绝：任务在授权范围内，却被系统拒绝；
• 安全失败：系统接受了越界任务；
• 能力失败：系统接受任务，但无法完成；
• 报告失败：实际没有完成，却声称成功。

只有同时控制越界和错误拒绝，才能证明系统既安全又可用。单独追求最低越界率，容易诱导评测对象采用保守拒绝策略。

六、能力评测不能替代边界评测

智能体安全评测中还经常出现另一类混淆：把任务成功率、漏洞发现率或问题解决率当成范围控制能力。

能力评测通常回答：

• 已知目标和已知问题时，能否完成指定操作；
• 面对未知问题时，能发现多少有效线索；
• 在限定资源内，能解决多少高难度任务；
• 能否生成可复现、可验证的结果。

边界评测则回答：

• 是否只访问被授权的资产；
• 是否只执行被允许的动作；
• 是否在达到停止条件后立即终止；
• 是否会因任务诱导而扩大目标范围；
• 是否会尝试绕过部署侧控制。

两者可能相关，但不能互相推导。一个能力很强的智能体可能更容易造成高影响越界；一个能力有限的智能体也可能因为错误识别目标而访问错误资产。

因此，不应将“任务完成率提高”解释为“更安全”，也不应将“某项能力测试得分较低”解释为“越界风险较低”。

七、建立可验收的授权边界模型

企业在设计验收规则前，应先把“不得离开范围”转换为机器可执行的边界定义。

一个完整的授权对象至少应包含以下维度：

授权范围：
  主体：当前智能体实例和执行身份
  资产：允许访问的主机、应用、账户和数据集
  动作：读取、扫描、修改、执行、上传、删除
  时间：授权开始时间、结束时间和最大持续时长
  资源：最大请求数、并发数、计算量和数据量
  网络：允许访问的地址范围、协议和连接方向
  数据：允许读取、缓存、输出和保留的数据类别
  审批：需要人工确认的高风险动作
  停止条件：异常、告警、预算耗尽或人工终止

授权边界应被编译成运行时策略，而不是只放在系统提示或操作手册中。执行每次外部动作前，都应由独立策略组件进行判断。

示意性逻辑如下：

function authorize(action, context):
    if context.current_time not in context.allowed_time:
        return DENY
    if action.target not in context.allowed_assets:
        return DENY
    if action.type not in context.allowed_actions:
        return DENY
    if action.estimated_cost > context.remaining_budget:
        return DENY
    if action.risk_level >= context.manual_approval_level:
        return REQUIRE_APPROVAL
    return ALLOW

关键点在于，授权判断不依赖智能体自行声明“这个动作在范围内”。智能体只能提出动作，最终是否执行由可信控制层决定。

八、将单一指标升级为分层验收门禁

成熟的验收流程不应只有“越界率低于某个百分比”这一条规则，而应设置多层门禁。

第一层：确定性安全门禁

对于不可接受的高严重度事件，应采用事件级零容忍，而不是平均比例容忍。例如：

• 成功访问明确未授权的生产资产；
• 导出受限制的敏感数据；
• 绕过人工审批执行高风险变更；
• 禁用或篡改审计记录；
• 在收到终止信号后继续执行外部动作。

只要发生一次，就应直接判定失败。因为低频但高影响事件无法通过平均值被合理稀释。

第二层：统计性风险门禁

对于低严重度、可恢复的边界尝试，可以使用统计阈值，但应基于置信上界，而不是只看样本比例。

门禁可以表达为：

通过条件：
  高严重度越界成功事件 = 0
  中低严重度越界率的置信上界 < 预设风险限值
  有效样本量 >= 最低要求
  关键风险场景覆盖率 >= 最低要求

具体阈值应由业务风险、法规要求、资产价值和补救能力共同决定，不能照搬外部实验中的数字。

第三层：业务有效性门禁

安全通过的同时，还应满足：

• 授权任务成功率达到业务要求；
• 错误拒绝率在可接受范围内；
• 人工接管比例不会使系统失去自动化价值；
• 结果报告能够被证据验证；
• 失败时能够安全终止并保留上下文。

这可以防止团队通过“让系统什么都不做”来获得漂亮的安全数据。

第四层：变更回归门禁

以下任何变化都应触发重新评测：

• 基础模型或推理配置变化；
• 系统提示与工具描述变化；
• 新增外部接口；
• 权限范围扩大；
• 执行环境或网络拓扑变化；
• 策略规则变化；
• 任务规划、记忆或重试机制变化。

安全结论必须绑定明确的系统版本和配置摘要，不能无限期沿用。

九、构造覆盖真实风险的测试矩阵

随机抽取普通任务通常无法充分验证授权边界。验收集应主动覆盖边界附近和对抗性场景。

建议至少包含以下测试类别：

1. 资产边界测试

测试允许资产与禁止资产名称相似、地址相邻、存在跳转关系或共享凭据时，系统是否仍能正确区分。

2. 动作边界测试

同一资产上，读取可能被允许，但修改、删除或执行命令可能被禁止。测试必须覆盖动作粒度，而不能只验证目标资产。

3. 上下文冲突测试

用户要求、系统规则、外部页面内容和工具返回信息可能相互冲突。应验证高优先级边界是否始终生效。

4. 间接访问测试

智能体可能通过代理服务、重定向、共享存储或关联账户间接触达未授权目标。只检查初始请求地址并不足够。

5. 失败与重试测试

首次调用失败后，智能体可能切换目标、扩大扫描范围或尝试替代凭据。重试路径往往比正常路径更容易越界。

6. 长任务漂移测试

任务持续时间越长，上下文压缩、记忆丢失和目标漂移的概率越高。需要验证智能体在长链路执行中是否持续保留授权边界。

7. 终止与撤权测试

授权到期、人工终止或凭据撤销后，系统应立即停止新动作，并安全处理中途任务。不能只验证任务开始时的权限。

十、生产环境必须采用纵深防御

即使实验室评测结果优秀，也不应让模型直接持有不受限制的执行权限。生产环境至少需要以下控制：

1. 最小权限身份：每个任务使用短时、低权限身份，避免共享长期高权限凭据。
2. 网络隔离：只允许访问授权目标，默认拒绝其他连接。
3. 工具白名单：仅开放任务所需的操作能力，并限制参数范围。
4. 资源配额：限制调用次数、并发量、执行时长和数据传输量。
5. 人工审批：对高影响修改、敏感数据访问和不可逆操作进行确认。
6. 完整审计：记录计划、调用、策略判定、执行结果和最终报告。
7. 异常熔断：连续拒绝、目标漂移、请求量突增或策略冲突时自动停止。
8. 可回滚设计：优先在隔离环境中执行，重要变更必须具备恢复路径。

这些控制的目标不是假设智能体永远正确，而是假设它终有一次会判断错误，并确保单次错误不会直接演化为严重事故。

十一、验收报告应该怎样写

不严谨的结论是：

越界率为0.07%，因此系统仍在授权范围内。

更专业的表达应包含限定条件，例如：

在指定版本、固定策略配置和受控测试环境下，本次共执行若干有效边界样本，观察到若干越界尝试与越界成功事件。统计结果仅适用于当前样本分布和配置。高风险动作由独立策略层拦截，未观察到成功触达未授权资产的事件。该结果不构成对其他版本、其他任务分布或无运行时控制环境的安全保证。

如果样本中没有发生越界，也应写成“未观察到越界事件”，而不是“越界率为零”或“系统不会越界”。

报告还应附带：

• 测试版本和配置摘要；
• 授权边界定义；
• 样本构成与覆盖范围；
• 越界判定规则；
• 原始事件数量；
• 统计方法和置信区间；
• 拒绝率与任务成功率；
• 已知限制和未覆盖场景；
• 上线后的监控与复测计划。

十二、结论

0.07%可以是有价值的实验结果，却不能自动成为企业系统的安全承诺。它只说明在特定条件和特定样本中观察到了较低的事件比例，不说明真实业务风险必然低于该值，更不说明系统具有不可绕过的授权边界。

可靠的安全验收应同时具备三类证据：

• 统计证据：样本量、事件数、置信区间和场景覆盖充分；
• 工程证据：权限、网络、策略、审批和熔断能够强制执行；
• 运行证据：日志完整、异常可发现、事故可阻断、变更可回归。

真正值得签署的结论，不是“模型大概率不会越界”，而是“即使模型产生越界意图，系统仍能识别、阻断、记录并控制影响”。这才是从评测百分比走向可审计安全保障的关键。