メインコンテンツへスキップ
キーが公開コミット、CI ログ、スクリーンショット、あるいはベンダーの侵害に現れました。時計が 動いています：その sk-orca-… 文字列を持つ者は誰でも、あなたが断ち切るまであなたの残高を費やし、 あなたのエージェントを駆動できます。このページはインシデントランブックです — まず資格情報を 断ち切り、それからそれが何をしたかを監査する — コンソールで自身のキーを管理する顧客向けです。 ライフサイクルの仕組み（無効化 vs 削除、キー状態、ロール）はキーを管理に あります；このページは攻撃下のシーケンスと、決定的に、出血が止まった後に監査証跡で 何をチェックするかです。
調査する前に支出を止めてください。 credit_limit_usd 上限と allow_ips リストを持つ スコープ付きキーは被害を境界づけますが、上限のない漏洩キーは、ライブのままである限り残高を 燃やせます。まず取り消し；フォレンジックは 2 番目。

​
1. 漏洩した API キーを取り消す（これを最初に行う）

2 つの断ち切り手段があり、どちらもコンソールの Keys 画面（/console/token）にあります。 どちらも Developer ロール以上が必要です — このアクションはあなたのセッション / アクセス トークン上で実行され、リレーキー上では決して実行されません。

無効化 — 可逆な一時停止

キーのステータスを Disabled に切り替えます。それが行うすべてのリクエストが即座に拒否 されますが、キー、その制限、そのポリシーアタッチメント、その使用履歴はすべて無傷のまま 残ります。掘り下げる間に設定とログを保持する必要があるときにこれを使ってください。

削除 — 恒久的な取り消し

キーに対して Delete を選びます。資格情報は二度とリクエストを認可できず、回復不能です。 漏洩が確認され、証跡から必要なものをキャプチャしたら、これを使ってください。
一般的なパターン：露出を疑った瞬間に即座に無効化（ゼロレイテンシの封じ込め、失うものなし）、 §3–§4 の監査を実行、被害範囲をスコープしたら削除。何をするにせよ、代替には新しいキーを 発行してください — 野に放たれたのを見られた資格情報を決して再有効化しないでください。 ゼロダウンタイムの引き継ぎはキーローテーションにあります。
無効化または削除は次のリクエストで反映されます — 再デプロイも伝播遅延もありません。

​
2. ついでに、代替キーを厳しくする

漏洩は、それが傷つけることを許したスコープを修正する瞬間です。代替キーは、ワークロードが実際に 必要とする最も狭いアイデンティティを運ぶべきで、次の漏洩が非イベントになるようにします：
IP 許可リストは、漏洩キーがあなた以外のどのアドレスからも 役に立たないことを意味します。リストにない IP からのリクエストは、何かにコストがかかる前に 認証層で拒否されます。
支出上限（0 = 無制限）は最悪ケースを境界づけます。 厳しい週次上限を持つ漏洩キーは、あなたのワークスペース残高を枯渇させられません。
モデル制限は、泥棒があなたの安価なキーを最も高価なモデルに 切り替えるのを止めます。
失効（-1 = 決して）は、あなたの注意を逃れたキーでも ひとりでに認可を停止することを意味します。
完全なエージェントごと 1 キーの姿勢については、 最小権限チェックリストを参照してください。

​
3. リクエストログを監査する — キーは何を呼んだか？

資格情報を断ち切ったら、被害をスコープします。そのキーが行ったすべてのリレー呼び出しは、あなたの ワークスペースリクエストログに記録され、各行はインシデントを再構築するのに必要なフィールドを 運びます：
フィールドそれが伝えること
token_name / token_idどのキーか — 漏洩したものを見ていることを確認。
ip各呼び出しのソースアドレス。認識しない IP からのバーストは決定的証拠です。
モデル + 使用量どのモデルが叩かれ、何のコストがかかったか — あなたの支出露出。
ログビューを漏洩キーにフィルタし、時間でソートします。「どれくらい悪いか」に最速で答える 2 つの問い：
  1. あなたのものではない IP からのトラフィックはあるか？ それは誤報ではなく、確認された 悪用です。
  2. 支出または呼び出しパターンが漏洩ウィンドウ前後でスパイクしたか？ 突然のジャンプは 攻撃者の足跡です。
キーが allow_ips リストを運んでいた場合、その外からの呼び出しはそもそも認可されなかった — なので外部 IP の行がないこと自体が健全性の証明書です。これがまさに、ソースを固定すること （§2）が漏洩を非イベントに変える理由です。

​
4. ポリシー証跡を読む — それは何をしようとしたか？

リクエストログはキーが何を呼んだかを伝えます；ポリシープレーンは、それがモデルに何を言わせ またはさせようとしたか、そしてあなたのガードレールとファイアウォールがそれを捕らえたかを 伝えます。どちらもワークスペーススコープです。ガードレールマッチは任意のワークスペース メンバーが読めます；ファイアウォールの Events / Runs ビューには Developer ロール以上が 必要です（ファイアウォールポリシーと設定はすべてのメンバーに開放されたままです）。

ガードレールマッチ

キーのトラフィックがガードレールルールに当たるたびに、マッチレコードが GET /api/guardrail/match に着地しました — ルールタイプ、action（block / mask / flag）、 stage、そして問題の詳細を運びます。漏洩キーのウィンドウにフィルタして、それが何の コンテンツ（PII、シークレット、jailbreak の試み）を押し通そうとしたかを確認します。

ファイアウォールイベント

キーが発行したすべてのツール呼び出しはファイアウォールイベントです — allow、audit、 deny、sanitize、あるいは保留。一連の deny イベントは、許可されていないことを試みた エージェントです。Events / Runs ビューで run ごとにロールアップします。
証跡を読む間に知っておく価値のあるいくつかの具体的事項：
  • ガードレールマッチがマッチした部分文字列をログするのは、そのガードレールで「Log raw content」がオンだった場合のみです（デフォルトはオフ） — なのでマッチ行は、生のテキスト なしにルールとアクションを示すことがあります。type / action / stage は常にそこにあります。
  • マッチ上の mark-fp（POST /api/guardrail/match/:id/mark-fp、Admin）は、ヒットを 誤検知としてフラグして、あなたのインシデントビューを歪めるのを止められるようにします — 実際の 悪用を埋めるために使わないでください。
  • ファイアウォールの deny はツール前です。 deny イベントは、攻撃者のツール呼び出しが ツールに到達する前にブロックされたことを意味します — ファイアウォールはすでにそのアクションを 封じ込めました。イベントは、それが試みたというあなたの証拠です。
3 つの証跡を同じ時間ウィンドウで相互参照してください： リクエストログ内の外部 IP、ガードレール マッチのスパイク、そしてファイアウォール deny イベントのクラスタが一緒になって全体像を描きます — 攻撃者が何を持っていたか、何を試みたか、そして何が止められたか。

​
5. インシデントの後

Keys リストを再チェック：漏洩キーは Disabled と読めるか、完全に消えているはずです。 無効化しただけの場合、監査を終えたら削除をスケジュールしてください — キーを管理を参照。
機能するキーがないギャップが決して生じないよう、古いものを退役させる前に、新しいより厳しく スコープされたキーにトラフィックを移します。完全な引き継ぎ： キーローテーション。
漏洩キーに allow_ips がなく、credit_limit_usd がなく、広い model_limits だった場合、 それが本当の発見です。すべてのエージェントに独自の狭くスコープされたキーを与えてください — 最小権限チェックリストと スコープとキーが姿勢全体を辿ります。

​
6. 関連

キーを管理

無効化 vs 削除、キー状態、そして各アクションの背後のロールゲート。

キーローテーション

侵害されたキーからクリーンなものへのゼロダウンタイムの引き継ぎ。

IP 許可リスト

キーをあなたのソースアドレスに固定して、漏洩が他の場所で使われないようにします。

データ持ち出し

漏洩キーが最も頻繁に養う脅威、そしてファイアウォールの egress サーフェスがそれをどう 境界づけるか。
シーケンス全体は意図的に短いです：取り消し、それから監査。各キーのスコープが最初から狭い ほど、実行しなければならない監査は小さくなり — そして漏洩した資格情報は、緊急事態から脚注へと 速く変わります。