AIエージェントにシークレットが混入したときの対処法：アクセス権の失効、監査、安全な復帰

本手順は、2026年9月16日時点のドキュメントに基づいて検証されています。

自律型エージェントが git diff などのコマンドを実行したり、ローカルの設定ファイルを読み込んだり、あるいは環境変数のダンプを誤ってモデルのプロンプトに直接含めてしまうと、シークレットは信頼境界の外へ流出してしまいます。このような状況では、バックグラウンドスクリプトを停止し、侵害された認証情報を無効化し、ログの技術的限界を考慮しながら監査を行い、最小権限の原則に従って環境を安全に再起動する必要があります。

通常の設定とコンテキスト漏洩の切り分け

インシデント対応を開始する前に、通常のAPI利用と実際のセキュリティ侵害を正しく切り分けることが不可欠です。

通常の運用では、ツールの言語モデルへのリクエストを認証するために、APIキーは想定されたモデルプロバイダーの認可フィールド（例えば OPENAI_API_KEY や ANTHROPIC_API_KEY などの環境変数）にのみ渡されます。また、ANTHROPIC_BASE_URL や OPENAI_BASE_URL のような変数は、ネットワークのエンドポイントアドレス（endpoint/base URL）を定義するものであり、シークレットや認証トークンそのものではありません。

これに対しモデルを介した漏洩とは、GitLabのパーソナルアクセストークン、AWS IAMの長期アクセスキー、SSHの秘密鍵、データベースの認証トークン、社内ネットワークトークンなど、モデル利用とは無関係なインフラシークレットが、ユーザープロンプト、対話コンテキスト、添付ファイル、あるいはユーティリティの出力ストリーム（stdout/stderr）に混入し、外部サービスへと実際に送信されてしまう事象を指します。すべての中間プロキシやゲートウェイが悪意を持っていると頭から決めつけるべきではありませんが、隔離された境界の外へシークレットが送信された以上、即座に局所化・封じ込めを行う必要があります。

初動対応：プロセスの停止とインシデントの記録

最優先事項は、これ以上のデータ送信を防ぐことです。

1. ローカルのエージェントプロセスを終了し、関連するバックグラウンドタスク（cronジョブ、CI/CDの自動化スクリプトなど）を停止します。
2. シークレットそのものは記載せず、侵害された認証情報の種類、最初のリクエストのおおよその時刻、タスク/セッションの識別子、送信先ネットワークのエンドポイントアドレスといったインシデントのメタデータのみをローカルレポートに記録します。
3. 漏洩した平文のキーを、サポートチャットへ送信したり、確認のためにニューラルネットワーク（AI）へ再送したりしないでください。

キーの失効および再発行の操作はすべて、信頼できるワークステーションから、各プロバイダーの公式管理コンソールを介してのみ実行する必要があります。

サービス種別ごとのアクセス権失効手順

各プラットフォームは、それぞれ異なるアーキテクチャ上の仕様に基づいて分離と権限の無効化を実装しています。

モデルアクセスキー（OpenAI API）

公式のOpenAIによるAPIキーの安全性に関するベストプラクティスに従い、侵害が疑われる場合はキーのローテーションとリソース消費状況の確認が必要です。

漏洩が疑われる場合、侵害されたキーを最優先で失効させます。

1. 直ちにOpenAIのAPIキー管理Webインターフェースにアクセスし、侵害されたキーを失効（Revoke/Delete）させます。これにより、依存サービスに制御された一時的なダウンタイムが発生するものの、それ以降の不正な呼び出しを即座にブロックできます。完全な監査の完了や、すべての利用環境における時間のかかる設定更新を待って失効を先送りにすることは避けてください。
2. 新しいキーを生成し、各サービスの設定を更新します。
3. Usageダッシュボードを開き、特定された曝露期間（exposure window）内のアクティビティを分析し、想定される通常操作と照合します。

GitLabのパーソナルアクセストークン

パーソナルアクセストークンに関するGitLabのドキュメントによると、パーソナルアクセストークンを失効させると、そのトークンは即座に無効化されます。

1. GitLabのインターフェースで、右上のアバターアイコンをクリックし、Edit profile > Access > Personal access tokens の順に進みます。
2. 有効なトークンの一覧テーブルから侵害された識別子を見つけ、Revoke をクリックします。

GitLabの Rotate 機能は古いトークンを無効化しますが、以前のスコープ（権限範囲）設定はそのまま維持されます。侵害されたトークンに過剰な権限が付与されていた場合は、ローテーションではなく完全に失効させた上で、最小限のスコープを設定した新しいトークンを作成する必要があります。トークンの詳細ページには、最終使用日および直近5件の一意なアクセス元IPアドレスが表示されます。ただし、これらの指標の更新にはシステム上の遅延が生じる点に留意してください。

AWSアクセスキー（IAMアクセスキー）

IAMキーの無効化手順は、アクセスキー保護に関するAWSのガイドおよびIAMユーザーのアクセスキー管理のドキュメントに規定されています。

1. AWS Management Consoleにサインインし、IAM > Users に移動して、Security credentials タブを開きます。
2. Access keysセクションで侵害されたキーの識別子を探し、ステータスを Deactivate に変更します。
3. 制御が回復したら、Delete をクリックしてキーを削除します。

[!IMPORTANT] キーのステータスを Deactivate に設定すると、この長期的な認証情報で署名された新規リクエストの受付は停止されますが、以前に発行された一時的な認証情報（AWS STSトークン）は無効化されず、アクティブなセッションも自動的には終了しません。「Revoke active sessions」アクションは該当するIAMロールのセッションにのみ適用され、IAM Identity Centerのアクティブセッションやその他の種類のSTSトークンは、それぞれの認証機構に従って個別に失効させる必要があります。また、セキュリティ管理者は AWS CloudTrail および get-access-key-last-used 操作を用いてAPI呼び出しのログを照合しなければなりません。インシデントの対応中に、検証されていない破壊的な一括削除CLIコマンドを実行しないでください。

OpenSSH鍵と認証

OpenSSHの認証手順は、マニュアル man sshd(8) および sshd_config(5) に記載されています。

1. 管理者は、すべてのサーバーの認証ファイルから侵害された公開鍵を削除する必要があります。ファイルのパスは AuthorizedKeysFile ディレクティブによって定義されます（デフォルトは ~/.ssh/authorized_keys ですが、インフラによっては一元管理されたファイルやSSH CAによる証明書検証が設定されている場合があります）。
2. 変更を加える前に、自身のアクセスが締め出されるのを防ぐため、独立したバックアップ接続経路（プロバイダーのWebコンソールやout-of-band managementなど）が利用可能であることを確認してください。
3. 公開鍵を削除すると新しい接続の確立は拒否されますが、すでに確立されているアクティブなセッションは切断されません。

who コマンドは疑似端末（TTY）が割り当てられているユーザーのみを表示するため、セッションの完全なインベントリにはなりません。トンネル、ポートフォワーディング、非対話型コマンドの実行などは表示されません。また、親プロセスである sshd を無差別に強制終了（kill）することは、子セッションの切断を保証しない上に、管理者がサーバーから締め出されるリスクがあるため厳禁です。管理者はプロセーツリー、ネットワーク接続、認証ログを個別に調査し、疑わしいセッションを特定して強制終了する必要があります。ローカルで秘密鍵を削除したりパスフレーズ（passphrase）を変更したりしても、すでに外部へコピーされた鍵には何の影響もありません。

Tailscaleネットワークと企業向けVPN

Auth Keysに関するTailscaleのドキュメントによると、認証キー（auth key）はノードの登録専用に設計されています。

1. Tailscaleコンソールで Keys セクションに移動し、侵害されたauth keyを失効させます。これにより、新規デバイスの登録が阻止されます。
2. auth keyを失効させても、すでに登録済みのノードは切断されません。管理者は必ず Machines タブに移動し、デバイス一覧を確認して、不正なデバイスを手動で削除（Remove/Delete）する必要があります。

従来の企業向けVPN（IPsec、OpenVPN、WireGuard、および各種プロプライエタリなソリューション）では、CRL等を通じた単一共通の失効手順は存在しません。具体的な仕組みは、採用されている認証方式（x509証明書、静的preshared keys、RADIUS/IdPトークンなど）によって異なります。アカウントのパスワードを変更しても、すべてのゲートウェイでアクティブなトンネルが即座に切断されるわけではありません。そのため、ネットワーク管理者にエスカレーションし、対象となるVPNゲートウェイの管理コンソールから証明書やアカウントの失効手続きを行い、アクティブなセッションを強制終了させる必要があります。

影響の分析：ログ、時間枠、不可逆的なリスク

事象をシステムログと照合する際は、テレメトリの技術的な限界を考慮する必要があります。

• 曝露期間（Exposure window）：エージェントにシークレットが最初に渡された時点から、キーの失効およびアクティブセッションの終了が確認された時点までの正確な時間間隔を特定します。
• ログの制約：イベント収集の遅延（ingestion delay）、ログの保持期間（retention period）、そしてテレメトリの死角（一部のAPIにおける詳細パラメータの監査欠落や、TTYを伴わないセッションのログ記録の欠如など）に注意してください。
• 「証拠の不在」の原則：確認可能なログ期間内に異常な記録が見当たらないことやトークン消費量がゼロであることは、シークレットが傍受されていないことや、将来の悪用を目的として第三者に保管されていないことを証明するものではありません。

キーの失効は将来のリクエストをブロックしますが、外部サービスにすでに送信されてしまったデータ、ソースコード、環境変数を取り戻すことはできません。エージェントやプラットフォームのWebインターフェースで会話履歴を削除する機能は、画面上のやり取りを非表示にするだけであり、ダウンストリームのプロバイダー側のログやキャッシュからデータが完全に消去されたことの技術的な証明にはなりません。

安全な再起動：リスク低減と分離の検証

エージェントを運用に復帰させる際は、インシデントの再発リスクを低減させなければなりません。

1. 短命トークン（Short-lived tokens）：プラットフォームやインフラがサポートしている場合は、有効期間が制限されたセッション認証情報を活用します。
2. ワークスペース境界の制限：.env ファイル、秘密鍵、シークレットを含むディレクトリをエージェントのワークスペースから除外します。ただし、シークレットを作業ディレクトリ外へ移動させるだけでは完全な分離は保証されず、OSレベルのアクセス権限分離の代用にはなりません。
3. ネットワークカナリアを用いない境界テスト：権限設定をテストする際は、本物のシークレットが一切含まれない一時的な隔離ディレクトリを作成します。そこにダミーの文字列を入れたプレースホルダーファイルを配置し、エージェントによるファイルアクセス、シェルコマンドの実行、および env を介した環境変数の読み取りが適切にブロックされるか検証します。基本的な権限検証のために外部ネットワーク接続型のカナリアトークン（canary tokens）サービスを利用しないでください。
4. 多層防御（Defense in depth）：単一パスの読み取りを遮断できたとしても、エージェントがターミナルやネットワークへの無制限なアクセスを保持している場合、完全なプロセス分離が達成された証明にはなりません。

システムコールの制限と権限分離に関する詳細なアーキテクチャ設計のアプローチは、Claude Codeにおける権限とシークレットの管理ガイドで解説されています。アカウント権限を最小化し、永続的なシークレットの利用を避けることが、自律型AIツールにタスクを委任する際のリスク軽減につながります。