Break-glass／Emergency Access for AI Systems

packet_id: MANUAL-EA289-DRAIN-20261022-C1 revision_id: EA-289-RESEARCH-20261022-R1 status: RESEARCH_CANDIDATE / PRE_BRIDGE_AUDIT 確認日: 2026-10-22 JST

AIシステムの緊急アクセスとは、通常の管理経路が使用不能になった事故で、認可された人が復旧や封じ込めに必要な操作を行うための例外経路である。エージェントの権限エラーを自動的に回避する仕組みではない。通常の承認、ID連携、認証機器などが同時に使えない状況を想定し、誰が発動し、どこまで操作し、どの証跡を残して通常運用へ戻すかを事前に定める。

本稿の設計提案では、緊急経路を「いつでも使える回復能力」と「事故時に限定して許可する作業」に分ける。回復用アカウントそのものを通常の一時昇格と同じ方法で期限切れにすると、肝心の障害時に入口を失うことがある。一方、そのアカウントから発行する作業用資格情報、許可する変更、使用時間まで無期限にする理由はない。回復能力を維持しながら、実際の使用を狭く、検知可能にすることが中心となる。

Microsoft Entraの緊急アクセス資料[S1]は、通常管理者のロックアウトに備える複数の回復用アカウント、通常経路と異なる依存関係、強固な認証、使用監視、定期的な実動確認を説明している。PIMの配置計画[S2]でも緊急アカウントは通常の時間制限付き昇格と扱いが異なる。これらはEntraの製品設計に関する根拠であり、全製品共通のアカウント数や設定値を定める規格ではない。

AWSのrootユーザー資料[S3]は、rootが広い権限を持つことと、通常業務に使用せず必要な処理に限定して資格情報を保護することを示す。rootが存在するという理由だけで、それを全AI事故の回復経路として扱ってはならない。組織構成やアカウント種別、対象操作により使える経路は異なる。以上の製品固有の事実から、本稿では依存関係の分離と例外操作の制限を設計原則として導く。

発動条件は、通常の管理経路では解消できず、放置した損害が例外使用のリスクを上回る事象として記述する。例は、IDプロバイダーの障害で管理画面に入れない、誤った認可設定で管理者全員が拒否される、侵害されたエージェントを通常経路から止められない、といった状況である。単に処理が遅い、承認者の返事を待ちたくない、モデルが拒否した、といった事情は自動発動の条件にしない。

手順には、事故番号、発動理由、確認できた症状、影響する環境、実行責任者、承認者または代替責任者、許可操作、終了条件を含める。承認系自体が停止する場合の代替権限も事前に定める。障害が起きてから、その場にいる人が自分を承認者にする運用では責任境界が検証できない。

AIには症状の要約や復旧案の提示を補助させられるが、緊急資格情報を読ませたり、自己昇格を選択させたりしない。認可拒否を見たエージェントが回復経路へ切り替えると、通常の権限境界が実質的に失われる。緊急経路を呼べるツールも通常エージェントのツール集合から分離する。

回復用アカウントが別名でも、通常経路と同じSSO、同じ端末、同じ秘密保管庫、同じネットワーク出口に依存すれば、共通障害で使用不能になり得る。認証、資格情報保管、端末、通信、承認、監視について依存関係を描き、どの障害を回避する設計なのかを明示する。あらゆる依存関係を無制限に複製するのではなく、想定事故ごとの回復経路を確認する。

強い認証を外すことと、故障点を分離することは同じではない。通常の認証機器を失っても使える別の強固な手段を準備し、取得手順を記録する。資格情報を特定社員の私物電話だけに結び付けると、不在や退職で回復能力が失われる。保管場所の記録には秘密そのものを含めず、誰がどの条件で取得できるかと、取得が記録される仕組みを残す。

提供者の制御プレーン全体が停止している場合、別アカウントを用意してもAPIは復旧しない。その場合は、書き込みを停止する、承認済みの手作業へ移る、利用者に影響範囲を通知するなど、アクセス回復以外の継続策が必要となる。緊急アクセスとサービス復旧を同義にしない。

最初に自動化の書き込み、外部送信、連続再試行を止められるかを確認する。停止できないまま設定を直すと、調査中にもエージェントが状態を変え、事故原因と復旧操作が混ざる。停止、証拠保全、最小限の復旧、段階的な再開という順序を基本とし、例外は事故記録に理由を残す。

操作権限は対象環境、リソース、操作種類で絞る。回復用資格情報を直接アプリケーションの常設シークレットへコピーせず、可能なら限定された作業セッションを利用する。チャット、プロンプト、チケット本文、コマンド履歴へ秘密を貼り付けない。ログには実行者、時刻、対象、変更前後の識別情報、結果を残し、機密値は別のアクセス制御下で扱う。

例として、認可設定の誤更新で管理操作が拒否された場合は、事前に承認された設定へ戻す操作と、その結果の検証だけを緊急作業にする。事故のついでにモデルの更新やツール追加をまとめて行うと、復旧したのか別の変更で症状が隠れたのか判別しにくくなる。回復後の改善は別の変更として扱う。

回復経路の使用は頻度が低いからこそ、毎回確認対象にする。通常の監視基盤が停止しても認証ログや操作証跡を後から回収できるか、代替の通知先があるかを準備する。通知が届かない事故でアカウント使用も見えなくなるなら、その監視は回復経路の独立性を満たさない。

事故終了時には、追加した権限と作業セッションを解除し、必要な資格情報の交換を実施し、継続中のジョブや再試行が残っていないかを確認する。資格情報を交換した事実だけで既存セッションの失効を証明したことにはならない。対象サービスで有効な失効手段と反映状況を確認する。

さらに、緊急変更後の実効設定を承認済みの基準と照合する。事故中だけ許可したネットワーク、例外的なツール権限、一時的な監視除外が残ると、通常運用に戻ったという宣言と実態がずれる。残す変更は責任者が別途承認し、新しい基準として記録する。残さない変更は復旧を確認してから除去する。自動的に全差分を巻き戻すと、事故対応で必要だった防御まで失うため、差分ごとに判断する。

訓練は「アカウントが台帳にある」で終えない。隔離した検証環境で通常経路が使えない条件を作り、資格情報の取得、認証、必要な管理操作、通知の到着、証跡の回収、権限解除、通常状態への復帰まで確認する。強い操作はダミー対象で行い、本番の重要データを訓練の材料にしない。

受入記録には、想定事故と残った依存関係、実行した操作、所要時間、成功と失敗、確認者を残す。回復目標は業務上の許容停止時間に合わせて定める。本稿は製品や組織をまたぐ一律の回復時間を保証しない。定期確認に加え、ID設定、担当者、秘密保管、ネットワーク、対象AIサービスが変わった時点で経路を再確認する。

• 対象組織のID構成、緊急アカウント、保管方式、失効反映時間、実際の回復時間は未確認である。
• 本RUNでのロックアウト訓練、資格情報の使用、権限変更、AI停止・再開、通知到達試験はすべてNOT_RUN。資料確認と設計提案を実装済み統制と表現しない。
• 安全な記述は「通常経路の障害を想定して、独立した回復経路と使用後の統制を設計・検証する」。緊急アカウントが存在するだけで復旧可能、常設の強権限をAIへ渡してよい、と断言しない。
• 本文は調査候補であり、独立監査、採用、公開は未完了である。

[S1] Microsoft Learn, Manage emergency access accounts in Microsoft Entra ID, https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access 。確認日2026-10-22 JST。アカウント設定、認証、監視、検証の各節。製品固有の回復経路の根拠。

[S2] Microsoft Learn, Plan a Privileged Identity Management deployment, https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-deployment-plan 。同日確認。緊急アクセスと通常昇格の区別の根拠。

[S3] AWS IAM User Guide, AWS account root user, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html 。同日確認。root権限と日常使用を避ける取扱いの根拠。

旧退避文書1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84、2026-09-18 11:20 JST RUN、tab t.0:23385–25569内のEA-289見出し、原案位置t.0:48850、ARTIFACT_INDEX行265は所在監査の来歴である。LUNA_PRESEARCH_NOT_LOCATEDを既存の完成研究と解釈せず、今回の一次資料確認と本文作成を新規の調査成果として区別した。