HITL ゲートは、高リスクのエージェントアクションが人間の判断なしに進行しないことを保証します。このクックブックでは、ガバナンス対象のアクションがリクエストを発火させる瞬間から、リスクティア解決、人間の決定、ブレイクグラスのエスケープバルブまで、承認ライフサイクル全体を解説します。これにより、本番環境で遭遇する前にすべての可動部分を追跡できます。
認可モデルをまだ読んでいない場合は、ガバナンスから始めてください。ガイドガバナンスと承認はオペレーターの観点から同じ機構をカバーしています。このページはステップバイステップのリファレンスです。
リクエストのライフサイクル
承認リクエストは deny-closed でタイムボックス化されて開かれます。pending で開始し、有効期限を持ち、十分な数の人間が決定するまで何も認可しません。リクエストは自身の基準を下げることができません — 一致する承認ポリシーが閾値とタイムアウトの権威です。
リクエストは、正確なツールコールペイロードのプランハッシュにバインドされます。これは TOCTOU 対策です: リクエストと決定の間に基盤となるアクションが変更された場合、ハッシュが一致せず承認をバインドできません。古い承認が異なるアクションを認可することはありません。
リスクティア解決
4つのティアが、ガバナンス対象のアクションに必要な人的コントロールの量を決定します:
| ティア | 意味 |
|---|---|
low / medium | 明示的な承認ポリシーによってのみ割り当てられる — デフォルトでここに該当するものはない |
high | 承認キューに到達するすべてのもののデフォルト。1人の人間の承認が必要 |
critical | 必須の2人制フロア（NIST SP 800-53 AC-3(2) デュアル認可） |
ティアはすべての決定時にライブポリシーセットから再導出されます。保存されたスナップショットからは読み取られません。ポリシー変更は即座に有効になります。古い行が現在の分類よりも低い基準を保持することはできません — これは構造的に deny-closed です。
組み込みの critical セットは真に不可逆的なものをカバーします: 本番デプロイとリタイア、データ削除と消去、セキュリティ施行とキルスイッチの変更、鍵の管理とローテーション、NHI のオフボーディング。
明示的な risk_tier を持つ承認ポリシーは、アクションごとにデフォルトを上げたり下げたりできます。ただし、critical なアクションをデュアルコントロールフロア以下に下げることはできません。
ステップバイステップ
1. ガバナンス対象のアクションがリクエストをトリガー
ガバナンス対象のアクション — deploy apply、agent fire、バジェットオーバーライド、または承認ポリシーに一致する任意のアクション — が承認エンジンに到達します。エンジンは pending 状態で新しいリクエストを開きます。
2. リクエストがプランハッシュにバインド
リクエストは正確なツールコールペイロードのハッシュを記録します。このプランハッシュバインディングが TOCTOU 対策です: 決定はリクエストが作成されたアクションのみを認可します。
3. リスクティアが現在のポリシーから解決
エンジンがライブポリシーセット（RBAC、ネイティブ ABAC、および任意の外部 PDP）を評価してリスクティアを導出します。ティアは以前の評価からキャッシュされることはありません。
4. 人間のレビュアーが決定
十分なロールを持つ人間が approve または deny を発行します。サーバーはこの時点で、安定したユーザーIDに基づいて3つの不変条件を施行します:
- 職務の分離。 リクエスターは自身のリクエストを決定できません。これは安定したユーザーIDに基づいており、1人の個人が変更できるクレデンシャル文字列ではありません。
- 重複決定者ガード。 ユニークインデックスが重複決定者の競合を防止します — 1人の人間が閾値に対して1回のみカウントされます。
- 有効期限がバインドします。 期限切れのリクエストは、スイープが有効期限を実体化する前でも、バインディング決定を受け取ることはできません。有効ステータスはすべての決定で再導出されます。
5. クリティカルアクション: AAL3 によるデュアルコントロール
critical ティアの場合: 閾値は2人の異なる人間の承認者にフロア設定されます。フロアは作成時（保存された閾値が2未満で開始することはできない）と決定時に再適用されます（アクションがクリティカルになる前に作成されたリクエストでも、1人の人間で通過できない）。
各決定者は新しいハードウェア検証済みセッションを持つ必要があります — WebAuthn または PIV ステップアップ（AAL3）。システムトークンには人間の保証がなく、拒否されます。
6. 決定が台帳に記録
すべての決定は、リクエストの決定証跡に不変の行を追記し、かつ決定、結果のステータス、決定が行われたリスクティアを記録する台帳イベントを追記します。台帳は追記専用でハッシュチェーン化され、Ed25519 で署名されています — 履歴の書き換えは暗号的に検出可能です。
有効期限
有効期限は読み取り時に導出され、一度だけ書き込まれるものではありません。期限切れのリクエストは、バックグラウンドスイープが有効期限を実体化していなくても、バインディング決定を受け取ることはできません。有効ステータスは常に再導出されるため、遅いスイープは外観上の遅延であり、セキュリティギャップではありません。
ポリシー設定
承認ポリシーにより、アクションクラスごとにデフォルトのリスクティアをオーバーライドできます。明示的な risk_tier を持つポリシーは、アクションを high から low に移動したり、medium を critical に引き上げたりできます。唯一の制約: critical をデュアルコントロールフロア以下に下げることはできません。不可逆的なアクションの2人制要件は構造的であり、設定可能ではありません。
ブレイクグラス
クォーラムに到達できない場合 — 2人目の承認者が眠っている午前3時のインシデント — ブレイクグラスが監査されたエスケープバルブを提供します。構造的に目立つように設計されています。
有効化にはすべてが必要:
- 有効化者は admin であり、常に実在の人間 — システムトークンは拒否されます。
- 新しい AAL3 ステップアップ（WebAuthn または PIV）。
- 同一トランザクションで記録される書面による正当化理由。
- 前提条件としてのアクティブに記録されたセッション。
タイムボックス化: 付与はデフォルト1時間、ハードキャップ24時間です。それ以上必要な緊急事態は運用モードであり緊急事態ではなく、通常のデュアルコントロールを経る必要があります。
すべての使用が記録されます。 ブレイクグラス下で取られた各アクションは、不変の行と付与、アクション、対象を名指しする台帳イベントを追記します。ブレイクグラス下で進行したアクションは、適切に承認されたものと永続的に区別可能です。
強制的なポストレビュー。 以前の付与が未レビューの間は新しい付与を有効化できません。レビューは有効化者とは異なる人間が行う必要があります。緊急事態を積み重ねて精査を回避することはできません。
ブレイクグラスは欠けているクォーラムを緩和しますが、明示的な拒否をオーバーライドすることはありません。 誰かが意図的に拒否したリクエストは拒否のままです。
記録されるもの
すべての決定 — approve、deny、expire、またはブレイクグラスの使用 — は2つの場所に追記されます:
- リクエストの決定証跡: リクエスト自体の不変の決定行のシーケンスで、各行が決定者、判定、タイムスタンプを持ちます。
- 監査台帳: 決定、結果のリクエストステータス、決定が行われたリスクティアを記録するハッシュチェーン化され Ed25519 で署名されたイベント。
両方の書き込みは状態変更と同一トランザクションで発生します。台帳が暗黙的に忘れるガバナンス対象の決定を行うことはできません。
関連
- ガバナンスと承認 — 同じ機構をカバーするオペレーターガイド。
- ガバナンス — 認可モデル、自己監査の姿勢、キルスイッチのメカニクス。
- クックブック: キルスイッチドリル — エステート全体の拒否ゲート演習。
- キルスイッチ — 緊急停止の製品ページ。