实践手册：紧急停止开关演练

在非生产资产上运行安全的紧急停止开关演练——启动全资产停止、验证所有执行接口的拒绝、通过双人控制重新启用，并完成事后审查

紧急停止开关是全资产拒绝关口。启动被有意设计为低成本——管理员级别，无需法定人数——因为等待共识的停止不是停止。重新启用被有意设计为高成本：双人控制，无紧急越权。你不想在凌晨 3 点才发现任何方向上的缺口。

在非生产租户上的演练是证明停止关口拒绝所有执行接口、待处理审批被原子取消、以及重新启用确实需要两个不同人类的唯一安全方式。在需要之前运行它。

前提条件

一个非生产租户。 演练启动一个真正的全资产停止。在暂存或开发环境中运行，绝不在生产环境中。
最少三个人类用户。 (1) 一个 admin 级别的启动者；(2) 两个不同的重新启用审批者（editor 或以上），满足 critical 双人控制底线；(3) 一个未参与的事后审查者（editor 或以上），关闭强制事后审查。如果事后审查者不是启动者，可以与审批者重叠。
要测试的受治理执行接口列表 ——部署应用、编排触发、语音开启、模型执行、预算支出，加上你已连接的任何自定义界面。

步骤 1：启动紧急停止开关

启动者使用强制原因字符串激活紧急停止开关：

# API 调用——替换你的主机、端口和认证头。
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

启动被有意设计为低成本：管理员级别，一个理由，无需审批法定人数，无需升级认证，无需紧急越权。停止记录成为唯一的真实来源。每个受治理的执行关口在每次操作时实时查询它，在读取错误时视为已停止。

在与启动相同的事务中，每个待处理的范围内执行审批被取消——停止前的意图不能在资产恢复时变成已授予。记下时间戳；你稍后将检查账本。

步骤 2：验证拒绝

紧急停止开关启动后，尝试你资产中已连接的每个受治理执行。每个都必须返回拒绝。

要测试的执行接口：

接口	要尝试的操作	预期结果
部署	使用有效计划的 `POST /v1/deploy/apply`	拒绝
编排	`POST /v1/orchestration/fire`	拒绝
语音	`POST /v1/voice/open`	拒绝
模型执行	通过受治理路径的任何推理或模型调用	拒绝
预算支出	针对预算关口的任何支出操作	拒绝

测试你资产中已配置的每个接口。如果你有通过治理核心连接的自定义执行界面，也要包括它们。

还要验证什么必须仍然工作：

停止暂停代理资产，永远不暂停治理它的控制。治理操作保持可用：

读取访问映射 ——GET /v1/access-map 应正常返回。
查看审计账本 ——GET /v1/audit/export 应返回账本，包括你刚创建的启动事件。
列出审批 ——审批队列可读；之前待处理的审批应显示为已取消。

如果任何执行接口返回拒绝以外的内容，或任何治理操作被阻止，停止演练并调查。紧急停止开关有缺口。

步骤 3：重新启用资产

重新启用绝不单方面。它需要在 critical 等级进行新的双人控制审批：两个不同的人类，在切换时结构性地重新验证。故意没有紧急越权路径用于重新启用——“资产保持停止”就是安全状态。

启动者（或任何管理员）请求重新启用：

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

这创建一个 critical 等级的审批请求。两个审批者——每个都是不同的人类，都不使用系统令牌——必须通过 POST /v1/approvals/<request-id>/decide 以 {"decision": "approve"} 分别批准。双人控制底线在服务端执行：重复决策者防护阻止一个人计数两次，系统令牌被拒绝（无人类保证）。即使策略等级被降级，结构性底线也保持——critical 操作无法通过一个审批者。两个审批都到达后，资产重新启用。

步骤 4：验证恢复

重复步骤 2 中的每个执行尝试。每个现在应该成功（被允许，或路由到正常审批流程）。如果任何接口在重新启用后仍然被拒绝，重新启用没有完全传播——在签署演练完成之前进行调查。

步骤 5：关闭事后审查

由一个未参与的人类进行的强制事后审查是结构性要求，必须在另一次紧急停止开关启动之前完成。审查者必须不是启动者：

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

在此审查关闭之前，后续的紧急停止开关启动被阻止。这是设计使然——你不能通过堆叠启动来逃避审查。

在账本中检查什么

演练后，导出审计账本并验证完整的跟踪记录：

olivares audit export --format json --since <drill-start-timestamp>

账本应按顺序包含：

启动事件 ——管理员、原因（“scheduled quarterly drill”）、时间戳和启动会话的保证级别。
审批取消 ——在与启动相同的事务中取消的每个待处理的范围内审批。
拒绝事件 ——停止期间被拒绝的每个执行尝试各一个。
重新启用请求 ——critical 等级的审批请求。
两个审批决策 ——每个审批者一个，各命名不同的人类身份。
重新启用事件 ——资产恢复。
事后审查事件 ——未参与的审查者、他们的备注、关闭时间戳。

每条记录都携带链完整性字段（seq、prev_hash、hash、sig）。缺失或乱序的条目意味着账本有缺口——在真正的事件中信任它之前进行调查。

频率

每季度运行演练。紧急停止开关是最后的防线；如果它有缺口，你希望在计划窗口中发现，而非在事件期间。将演练添加到你的运营日历中，与其他连续性演练一起（备份恢复、故障转移、紧急越权激活）。

如果你的资产发生实质性变化——新的执行接口连接、新的租户配置、策略引擎切换——运行计划外演练以覆盖新界面。