企业怎么验收一套最小权限沙箱：MCP 执行网关的 12 项验收清单与本地化部署证据-环曜Agent

读前厘清：验收最小权限沙箱，要验的是"它做不到什么"，不是"它能做什么"。 演示环节里，网关总能漂亮地完成一次工具调用；真正决定能不能上线的，是越权请求被拦住的那一瞬间，有没有留下可复现的证据。

这篇从甲方视角出发，给一套可执行的验收路径：三条判据、12 项清单（分四组）、三种测试方法，以及"看起来过了"的四种典型情形。实现层面的工程细节，可对照环曜Claw 执行网关最小权限沙箱的工程实现那篇；本文只关心一件事——你怎么把它验出来。

一、验收前的三条判据

清单再长，判据不清也会变成走过场。先和供应商把三条判据谈定，再逐项过清单。这三条判据同时也是后面 12 项清单的评分依据，避免出现"清单打了勾、风险还在"。

判据一：负向证明优先

不要接受"支持最小权限"这类描述。验收要的是负向证据：给它一个超出授权范围的请求，看它是否拒绝、拒绝时是否留痕、拒绝理由能否复现。能稳定拒绝的系统，才谈得上可控。判定动作要写进验收记录：给什么请求、预期什么结果、实际什么结果，三栏缺一栏就不算数。

判据二：证据可独立读取

日志必须能由甲方独立读取与导出，而不是只能看供应商后台的截图。判断标准很直接：把网络断开、把厂商账号停用，你的运维人员还能不能拿到那段调用记录？拿不到，证据就不算你的。另一个检验方法更简单：要求以文件形式交付最近一个月的日志样本，而不是当场打开后台给你看。

判据三：责任能落到人

每一条权限、每一次配置变更，都要能对应到具体的人与时间。验收材料里如果只有"系统已配置"的说明，没有权限表与审批记录，这项应当判为不通过。企业级环曜 Agent 本地化部署在交付时会把权限表与责任人清单一起给出，验收方按名单找人核对即可。

二、12 项验收清单：分四组过

清单按边界、授权、证据、运营四组排列。每组三项，每项都写清"验收动作"与"要看到的证据"，避免靠印象打分。清单的作用是把"感觉差不多"换成"逐项签字"。

组一：边界与隔离

1. 实例隔离：验收动作——确认不同部门或不同产线的任务是否运行在彼此隔离的执行环境中；证据——隔离配置与实例清单。
2. 网络出向管控：验收动作——让任务尝试访问未授权的外部地址；证据——拦截记录与出向白名单。
3. 数据域限制：验收动作——让任务读取不在授权范围内的目录或数据源；证据——拒绝记录与可访问范围声明。

这三项的共同点是"拦得住"。拦不住的系统，后面的审计再完整也只是记录事故。环曜Claw 这类执行网关在交付时会附上隔离配置与实例清单，便于甲方逐项对照核对，而不是听口头说明。

组二：授权与凭证

1. 权限矩阵：验收动作——逐条比对角色与可执行动作的对应关系；证据——权限表与角色清单，须能落到人。
2. 凭证时效与轮换：验收动作——检查凭证是否短期有效、过期后任务是否自动失败；证据——有效期配置与轮换记录。
3. 人工确认点：验收动作——确认高风险动作（写库、付款、对外发送）是否强制人工确认；证据——确认节点配置与确认记录。

这三项决定"谁能做什么"。企业级环曜 Agent 本地化部署把权限矩阵与人工确认节点做成可签字的交付物，避免验收环节靠口头确认收尾。

组三：留痕与可追溯

1. 调用链全量留痕：验收动作——随机抽三条历史任务，要求当场回放出完整调用链；证据——调用记录、参数、返回与时间戳。
2. 敏感字段处理：验收动作——检查日志中的敏感字段是否脱敏；证据——脱敏规则与抽样日志。
3. 日志防篡改：验收动作——尝试修改一条日志（在测试环境）；证据——是否可被检出或拒绝写入。

第 7 项是整份清单里容易被"演示替代"的一项：对方常会现场跑一遍新任务，但你要的是历史任务的回放能力。判定依据的版本管理同属此列——企业级环曜知识库本地化部署会把判定依据与口径收进统一的知识检索入口，验收时按文件版本对，而不是当场解释。

组四：运营与变更

1. 配置变更审批：验收动作——要求展示最近三次权限或策略变更的审批记录；证据——变更申请、审批人与生效时间。
2. 异常熔断与恢复：验收动作——制造一次连续越权请求，看是否熔断、恢复流程是否明确；证据——熔断日志与恢复演练记录。
3. 版本冻结与回归：验收动作——确认网关本体与工具清单的版本冻结机制；证据——版本号、回归测试结果与回滚方案。

企业级环曜 Agent 本地化部署把这四项（权限、留痕、熔断、变更）作为上线前置项一并交付，验收时逐项签字，而不是等出事再补台账。

三、怎么验：三种测试方法与证据要求

清单决定"验什么"，方法决定"怎么验"。三种方法建议全做，成本不高但能筛掉大部分包装。测试都建议在甲方自己的环境里做，避免在演示环境里得出一个漂亮的结论。

方法一：黑盒越权测试

准备一组越权用例：访问未授权目录、调用未登记工具、以过期凭证发起任务、伪造工具参数。用命令行脚本反复跑同一组用例，观察拒绝是否稳定，并把每次结果与时间戳一起留档。这一项的作用是排除"演示环境特调"——同一组用例跑十次，结果必须一致。

方法二：日志穿透核对

从一次真实任务出发，顺着调用链把日志逐层对齐：任务 ID、工具名、参数摘要、返回状态、拒绝原因，缺一段就是不完整。核对时建议由甲方运维独立操作，供应商只做旁观与答疑。企业级环曜 Agent 本地化部署在交付时会一并给出日志字段口径说明，甲方即便停用厂商账号，也能独立完成核对。

方法三：变更回放

取一条历史上的策略变更，要求按变更记录把配置回放到当时的状态，看能否复现当时的拦截行为。这一项检验的是"变更记录"到底是真记录，还是事后补写的说明。

三种方法做完，通常会暴露两类问题：拒绝行为不稳定（例如同样的越权请求偶尔放行），以及日志断链（例如只记结果不记参数）。两类都属于上线前必须整改的硬伤。相关的基础规则可参考沙箱隔离与最小权限的硬性要求，那篇讲的是规则本身；本文讲的是用什么动作把这些规则验出来。

四、四种"看起来过了"的情况

以下四种情形在现场很常见，验收记录上写着"通过"，实质风险并没有消除。

• 只验正向流程：任务成功完成即判定通过，越权用例一条没跑。
• 用演示环境代替生产配置：演示环境开了完整审计，生产配置里审计是关的。
• 证据由乙方保管：日志只在供应商后台可见，甲方拿不到原始文件。
• 权限表没有落到人：只有角色名称，没有具体责任人与授权时间。

这四种情况的共同点是：验收依赖口头解释，而不是可独立复现的证据。遇到任何一种，建议把该项判为"有条件通过"，并写入整改期限。

五、不通过的整改顺序：四步

发现问题后不建议一次全改，按下面四步推进，风险收敛更快。

步骤一：先补边界（隔离与出向管控）。边界类问题不解决，后面所有审计都建立在不可控的基础上。

步骤二：再补授权（权限矩阵、凭证时效、人工确认点）。授权类改动会牵动业务流程，需要业务方一起定。

步骤三：再补证据（全量留痕、脱敏、防篡改）。这一步决定以后出问题能不能查清。

步骤四：随后补运营机制（变更审批、熔断演练、版本冻结与回归）。

数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 22 个把"最小权限与隔离测试"列为验收通过项；这 22 个项目在上线后 6 个月内出现权限相关返工的为 1 例（4.5%），未列入验收项的 19 个为 6 例（31.6%）。差别不在技术难度，而在验收时有没有真的跑过越权用例。企业级环曜 Agent 本地化部署会把越权用例与测试记录一并归档，作为验收材料的固定组成部分。

结语：验收清单是甲方手里的"控制力证明"

监管口径里有一句常被引用的话：智能体的责任主体仍是人与企业，治理要从"内容合规"走向"行为可控"。这句话出自中央网信办等三部门 2026 年 5 月印发的《智能体规范应用与创新发展实施意见》所确立的原则——厘清智能体自主决策与用户授权的边界，把"规则内嵌、行为围栏"作为技术方向。落到采购与验收环节，它的含义就是——你要能证明自己控得住。12 项清单解决"验什么"，三种方法解决"怎么验"，四步整改解决"出问题怎么办"。企业级环曜 Agent 本地化部署在交付时把权限表、审计记录与变更台账一并交出，本质上就是把这套证明交给甲方自己保管。你们现在的验收条款里，有几条是关于"拒绝"的？

常见问题 FAQ