クックブック: キルスイッチドリル

キルスイッチはエステート全体の拒否ゲートです。有効化は意図的に安価です — admin ティア、クォーラムなし — 合意を待つ停止は停止ではないからです。再有効化は意図的に高コストです: デュアルコントロール、ブレイクグラスなし。どちらの方向にもギャップがあることを午前3時に発見したくはないでしょう。

非本番テナントでのドリルが、停止ゲートがすべてのアクチュエーションシームを拒否し、保留中の承認がアトミックにキャンセルされ、再有効化が実際に2人の異なる人間を必要とすることを証明する唯一の安全な方法です。必要になる前に実行してください。

前提条件

• 非本番テナント。 ドリルは実際のエステート全体の停止を有効化します。ステージングまたは開発に対して実行し、本番には絶対に行わないでください。
• 最低3人の人間ユーザー。 (1) admin ティアの有効化者、(2) critical デュアルコントロールフロアを満たす2人の異なる再有効化承認者（editor 以上）、(3) 強制ポストレビューを閉じる関与していないポストレビュアー（editor 以上）。ポストレビュアーは有効化者でなければ承認者と重複できます。
• テストするガバナンス対象のアクチュエーションシームのリスト — deploy apply、orchestration fire、voice open、model execution、budget spend、およびカスタムで接続したサーフェス。

ステップ 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"}'

有効化は意図的に安価です: admin ティア、理由、承認クォーラムなし、ステップアップなし、ブレイクグラスなし。停止行が唯一の信頼できるソースになります。すべてのガバナンス対象のアクチュエーションゲートは各アクションでライブに参照し、読み取りエラー時にフェイルクローズドになります。

有効化と同一トランザクションで、すべての保留中のスコープ内アクチュエーション承認がキャンセルされます — 停止前の意図がエステート復帰直後に付与として実行されることはありません。タイムスタンプを記録してください。後で台帳を確認します。

ステップ 2: 拒否の検証

キルスイッチが有効化された状態で、エステートに接続されたすべてのガバナンス対象のアクチュエーションを試行します。各試行が拒否を返す必要があります。

テストすべきアクチュエーションシーム:

エステートがプロビジョニングしたすべてのシームをテストしてください。ガバナンスコアを通じてカスタムアクチュエーションサーフェスを接続している場合は、それらも含めてください。

引き続き動作すべきものも検証:

停止はエージェントエステートを停止しますが、ガバナンスコントロールは停止しません。ガバナンスアクションは引き続き利用可能です:

• アクセスマップの閲覧 — GET /v1/access-map は正常に返すべきです。
• 監査台帳の閲覧 — GET /v1/audit/export は、作成した有効化イベントを含む台帳を返すべきです。
• 承認の一覧 — 承認キューは閲覧可能です。以前保留中だった承認はキャンセルとして表示されるべきです。

アクチュエーションシームが拒否以外を返した場合、またはガバナンスアクションがブロックされた場合は、ドリルを停止して調査してください。キルスイッチにギャップがあります。

ステップ 3: エステートの再有効化

再有効化は一方的にはできません。critical ティアでの新たなデュアルコントロール承認が必要です: 2人の異なる人間、フリップ時に構造的に再検証。再有効化には意図的にブレイクグラスパスはありません — 「エステートが停止したまま」こそが安全な状態です。

有効化者（または任意の admin）が再有効化をリクエストします:

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 ティアの承認リクエストが作成されます。2人の承認者 — それぞれ異なる人間で、システムトークンを使用していない — が POST /v1/approvals/<request-id>/decide に {"decision": "approve"} で承認する必要があります。デュアルコントロールフロアはサーバーサイドで施行されます: 重複決定者ガードが1人の二重カウントを防止し、システムトークンは拒否されます（人間の保証がない）。ポリシーティアがダウングレードされても、構造的フロアは維持されます — critical なアクションは1人の承認者で通過できません。両方の承認が完了すると、エステートが再有効化されます。

ステップ 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>

台帳には、順序通りに以下が含まれるべきです:

1. 有効化イベント — admin、理由（“scheduled quarterly drill”）、タイムスタンプ、有効化セッションの保証レベル。
2. 承認キャンセル — 有効化と同一トランザクションでキャンセルされたすべての保留中のスコープ内承認。
3. 拒否イベント — 停止中に拒否された各アクチュエーション試行に1つ。
4. 再有効化リクエスト — critical ティアの承認リクエスト。
5. 2つの承認決定 — 承認者ごとに1つ、それぞれ異なる人間のIDを名指し。
6. 再有効化イベント — エステート復元。
7. ポストレビューイベント — 関与していないレビュアー、そのメモ、クローズタイムスタンプ。

すべてのレコードがチェーン整合性フィールド（seq、prev_hash、hash、sig）を持ちます。エントリの欠落や順序の乱れは台帳にギャップがあることを意味します — 実際のインシデントで信頼する前に調査してください。

頻度

ドリルは四半期ごとに実行してください。キルスイッチは最後の防衛線です。ギャップがある場合、インシデント中ではなく予定されたウィンドウで発見したいものです。他の継続性演習（バックアップリストア、フェイルオーバー、ブレイクグラス有効化）とともに、運用カレンダーにドリルを追加してください。

エステートが大幅に変更された場合 — 新しいアクチュエーションシームの接続、新しいテナントのプロビジョニング、ポリシーエンジンの交換 — 新しいサーフェスをカバーするために予定外のドリルを実行してください。

関連

• ガバナンス — 認可モデル、リスクティア、キルスイッチの設計。
• キルスイッチ — 製品用語でのエステート全体の拒否ゲート。
• ガバナンスと承認 — ライブ承認フローとデュアルコントロールのメカニクス。