AI APIシークレットスキャンは、プロバイダーキーがインシデントチケット、想定外の請求、または本番環境の障害になる前に発見するためのものです。AIチームにとって、これはソースコード以上のものをスキャンすることを意味します。プロバイダーキーは、ノートブック、プロンプトテストのフィクスチャ、CI変数、ランブック、サポートのトランスクリプト、Dockerレイヤー、ブラウザの自動化、そして社内チャットからコピーされたサンプルなどに紛れ込む可能性があります。
予防計画はシンプルです。AI関連の作業が行われる場所をスキャンし、発見された各項目を所有者にマッピングし、キーが有効かどうかを証明し、適切なスコープでローテーションさせ、調達、財務、プラットフォームエンジニアリング、セキュリティの全部門が読める証拠を保管します。
Flatkeyはこのワークフローで役立ちます。なぜなら、現在の公式サイトflatkey.aiは、公式のGPT、Claude、Gemini、DeepSeek、画像、音声、動画モデルへのアクセスを1つのAPIキーで提供し、ダッシュボードで利用状況、コスト、ルーティング、エラーを可視化できるからです。これにより、プロバイダーから直接発行されるキーの乱立を減らすことができますが、AI APIシークレットスキャンの必要性がなくなるわけではありません。すべてのFlatkey、OpenAI、Anthropic、Gemini、その他のプロバイダーの認証情報を、スキャン、所有権、スコープ、ローテーションの証拠が必要なシークレットとして扱ってください。
ローテーションのパスについては、このガイドをAI APIキーローテーションゲートウェイのチェックリスト、AI APIアクセスレビューのワークフロー、AI APIリダクションポリシー、およびAI APIペイロードロギングのチェックリストと併せてお読みください。
AI APIシークレットスキャンのワークフロー
ほとんどのチームは、APIキーをコミットすべきではないことをすでに知っています。より難しい問題は、キーを早期に検出し、インシデントの所有者に次に行うべきことを伝えるワークフローを運用することです。
| ステージ | スキャン対象 | 下すべき決定 | 保管すべき証拠 |
|---|---|---|---|
| コミット前 | ローカルファイル、ノートブック、設定、フィクスチャ | コミットを続行できるか？ | スキャナー名、ルールセットのバージョン、ブロックされたパス、開発者の所有者 |
| プルリクエスト | 差分、追加されたファイル、生成されたアセット | PRをブロックすべきか、レビューすべきか？ | 検出ID、シークレットファミリー、パス、レビュー担当者、解決策 |
| CIパイプライン | リポジトリ全体とビルドコンテキスト | ローカルチェック後にブランチに何かが入ったか？ | CIジョブ、コミットSHA、スキャナーの出力、許可リストの変更 |
| レジストリとアーティファクトストア | コンテナ、パッケージ、ビルドログ | キーがソース管理から漏洩したか？ | アーティファクトのダイジェスト、レイヤー/ファイルパス、失効ステータス |
| ランタイムとサポートシステム | ログ、トレース、ランブック、チケット、トランスクリプト | キーがエンジニアリング部門外で観測可能になったか？ | ログインデックス、チケットID、保持ステータス、リダクションチケット |
| ローテーション後 | 利用状況ダッシュボード、プロバイダーの監査記録、ゲートウェイログ | 古いキーは機能しなくなり、新しいキーはスコープ内に留まっているか？ | 古いキーの無効化、新しいキーの所有者、スモークテスト、利用状況レビュー |
これがAI APIシークレットスキャンの核となるルールです。パターンが一致しただけでは、検出事項はクローズされません。認証情報が有効であったか、どこで公開されたか、誰が所有していたか、何がローテーションされたか、そして古いキーがもはや重要でないことを証明する記録は何かをチームが把握したときにクローズされます。
プロバイダーキーのカバレッジから始める
汎用的な「APIキー」の正規表現1つに頼らないでください。AIチームは通常、それぞれ異なるキーの形式と権限モデルを持つ複数のプロバイダー、ゲートウェイ、ツールに触れます。
ルールを調整する前に、プロバイダーのインベントリを作成します。
| 認証情報ファミリー | 通常出現する場所 | スキャン要件 |
|---|---|---|
| OpenAIキーとサービスアカウント認証情報 | バックエンドサービス、ノートブック、評価ハーネス、AI SDKのサンプル | 可能性の高いキー文字列、プロジェクト/サービスアカウントのコンテキスト、組織/プロジェクトの不一致、ローカルキャッシュ内の古い失効済みキーを検出する |
| Anthropicキー | エージェントツール、サーバーサイドのラッパー、ノートブックテスト、Claude固有のSDKサンプル | 直接的なキーを検出し、ワークスペースID、管理者トークン、無害なサンプルと区別する |
| GeminiまたはGoogle APIキー | クライアントのプロトタイプ、ノートブック、envファイル、モバイル/Webのサンプル | APIキーを検出し、制限、ローテーション、削除が文書化されているかを確認する |
| Flatkeyキーなどのゲートウェイキー | 共有モデルのルーターコード、ベースURL移行のサンプル、CIスモークテスト | 直接的なプロバイダーキーとまったく同じようにゲートウェイキーをスキャンし、ローテーションする |
| スキャナーの例外 | テストフィクスチャ、ドキュメント、サンプル、ハッシュ化された値 | 許可リストは範囲を狭く、レビュー済みで、有効期限があり、パス固有のものに保つ |
公式のスキャナードキュメントは、この階層的なアプローチをサポートしています。GitHubのシークレットスキャンは、サポートされているシークレットパターン、プッシュ保護、カスタムパターンをカバーしています。GitLabのシークレット検出はパイプラインで実行できます。GitleaksとTruffleHogは、一般的なリポジトリ/履歴スキャナーです。その後、プロバイダーのドキュメントで、検出後に影響を受けるキーファミリーをどのように扱うかが説明されています。
AIキーが移動するすべての場所にスキャンを配置する
AI APIキーは、mainにコミットされることなく漏洩する可能性があります。
この最小限の配置チェックリストを使用してください。
- ソース、
.envファイル、ノートブック、生成されたフィクスチャ、プロンプト例に対して、ローカルのpre-commitスキャナーを実行する。 - プラットフォームがサポートしている場合は、リポジトリでホストされるシークレットスキャンとプッシュ保護を有効にする。
- プルリクエストと保護されたブランチでCIシークレット検出を実行する。
- SDKの例、公開テンプレート、または内部スターターリポジトリを公開する前に、Gitの履歴をスキャンする。
- リリース前にコンテナイメージとパッケージアーティファクトをスキャンする。
- サポートのランブック、インシデントメモ、エクスポートされたトラブルシューティングバンドルをスキャンして、コピーされたシークレットがないか確認する。
- ログとトレースをレビューして、偶発的なプロンプト、ヘッダー、または環境のダンプがないか確認する。
AI APIシークレットスキャンの最初のパスは広範囲にわたるべきです。2回目のパスは正確であるべきです。つまり、許可リストを調整し、ゲートウェイキーや内部ラッパー用のカスタムパターンを追加し、誤検知によってチームがアラートを無視するようにならないようにします。
すべての検出結果を所有者にマッピングする
所有者がいないシークレットスキャンは、恐ろしい文字列のキューになってしまいます。ローテーションする前に、運用範囲を記録してください。
| フィールド | 重要である理由 |
|---|---|
| 非シークレットキーのラベル | チームがシークレットをコピーせずにキーについて議論できるようにする |
| プロバイダーまたはゲートウェイ | どこで失効、ローテーション、使用状況の検査を行うかを決定する |
| 所有者 | キーに責任を持つチームまたはサービスアカウントを指名する |
| 環境 | 開発、ステージング、本番、バッチ、評価、サポート自動化を分離する |
| 許可されたモデルとエンドポイント | キーがテキスト、画像、動画、バッチ、または管理画面にアクセスできるかどうかを示す |
| データクラス | プロンプトに顧客のテキスト、規制対象データ、シークレット、または内部専用データが含まれる可能性があるかどうかを明確にする |
| 最近の使用状況 | キーが悪用されたのか、単に漏洩しただけなのかを判断するのに役立つ |
| ローテーションの所有者 | 代替キーを作成し、デプロイを更新できる担当者を指名する |
| 財務担当者 | 漏洩、再試行、または高トークントラフィックによるコストの急増を説明するのに役立つ |
チームが承認されたモデルトラフィックを1つのOpenAI互換ゲートウェイ経由でルーティングし、製品ダッシュボードから現在の使用状況、コスト、ルーティング、エラーをレビューする場合、Flatkeyがこのレビューを支援します。その主張は限定的にしてください。インシデントの証拠としてそれらに依存する前に、アカウント内の正確な現在のダッシュボードフィールド、価格設定行、モデルルート、ログの可視性、キーラベルを確認してください。
ローテーション範囲の前に有効性をトリアージする
すべての一致がライブインシデントであるとは限りません。検出結果の中には、テスト値、切り捨てられたスニペット、例、またはすでに失効したキーなどがあります。トリアージは、それでも迅速かつ保守的に行う必要があります。
このトリアージ表を使用してください。
| シグナル | 意味 | アクション |
|---|---|---|
| ソース、ログ、またはチケット内の完全長の可能性が高いシークレット | そうでないことが証明されるまで漏洩を想定する | 直ちに失効またはローテーションし、その後使用状況を調査する |
| 部分的なキー、マスクされた値、またはスクリーンショットのぼかし | アカウントやプレフィックスのコンテキストを明らかにする可能性がある | 手動でレビューし、攻撃者にとって有用な場合は編集する |
| 公開リポジトリでの漏洩 | 外部からのアクセスの可能性 | ローテーション、証拠の保全、プロバイダーの使用状況の確認、所有者への通知 |
| 内部専用ブランチでの漏洩 | 外部リスクは低いが、依然として安全ではない | 環境と権限に基づいてローテーションする |
| スキャナーの許可リストにヒット | 誤検知または承認されたテストフィクスチャの可能性 | レビュー担当者、有効期限、正確なパスを要求する |
| 漏洩後の予期せぬ使用 | 悪用または自動化のドリフトの可能性 | キーを無効化し、ログを収集し、インシデントワークフローをエスカレーションする |
検出結果が本番環境のAIプロバイダーキーである場合は、まずローテーションしてから議論してください。AIワークロードは、数分で実際のコスト、データ、信頼性の漏洩を引き起こす可能性があります。
アカウント全体ではなく、小さなスコープでローテーションする
優れたAI APIシークレットスキャンは、キーが漏洩する前にスコープが設定されていると容易になります。1つの共有本番キーは、広範な対応を強いることになります。所有者、環境、ワークロード、ルートごとにキーを分けることで、1つの影響範囲でローテーションできます。
AI APIキーの場合、ローテーション計画には次のことを記載する必要があります。
| ローテーションに関する質問 | レビューの回答 |
|---|---|
| 正確に何が漏洩したか？ | プロバイダーまたはゲートウェイ、非シークレットキーのラベル、パス、コミット、アーティファクト、ログ、またはチケット |
| 何ができるか？ | モデル、エンドポイントファミリー、管理アクション、予算、プロジェクト、組織、ルート |
| 代替キーの所有者は誰か？ | チーム、サービスアカウント、プラットフォーム所有者、財務担当者 |
| デプロイはどのように更新されるか？ | シークレットマネージャーのパス、CI変数、ランタイム構成、フォールバック計画 |
| 古いキーの使用はどのように検出されるか？ | プロバイダーの使用状況、ゲートウェイログ、リクエストID、コストダッシュボード、アラート |
| インシデントをクローズするための証拠は何か？ | 失効記録、新しいキーのスモークテスト、失効後の使用がないこと、編集チケット |
OpenAIプラットフォームのドキュメントでは現在、プロジェクトAPIキーの権限、プロジェクト管理、サービスアカウント、使用状況ダッシュボード、モデルリクエストの権限が分離されています。AnthropicはAPIキー認証と管理者/API管理の概念を文書化しています。Google CloudのAPIキーガイダンスでは、制限、ローテーション、削除、クライアントサイドまたは公開コードでのキーの使用回避が強調されています。誰も実行できないプロバイダーに中立なローテーション手順を作成する代わりに、これらのプロバイダー固有のコントロールを使用してください。
ゲートウェイキーをスキャナーに追加する
チームがAIゲートウェイを採用すると、アプリケーションコード内で直接プロバイダーキーを使用することは少なくなります。これは良いことです。しかし、ゲートウェイキーが重要になります。
Flatkeyの場合、2026年7月11日に確認された現在の公開ページでは、1つのキー、OpenAI互換のゲートウェイベースURL、使用状況分析、コスト管理、リクエストログ、プロバイダー横断の単一請求書、モデルファミリー横断の単一残高を中心とした位置付けが示されています。これは日付の入った公開情報として利用するものであり、永続的なアカウント保証として利用するものではありません。
スキャナーは、ゲートウェイキーを引き続き本番環境のシークレットとして扱う必要があります。
- 文書化されている、またはアカウントで確認済みのゲートウェイキー形式に対して、カスタムパターンを追加します。
- 所有者、環境、ルート、予算所有者ごとにキーにラベルを付けます。
- ゲートウェイルートが承認されたら、直接のプロバイダーキーをアプリリポジトリから除外します。
- 移行ドキュメントやサンプルをスキャンして、コピーされた古いプロバイダーキーがないか確認します。
- 検出後、ゲートウェイの使用状況ダッシュボードを確認し、予期しないルート、モデル、または支出が発生していないかを確認します。
- ゲートウェイキーを、直接のプロバイダー認証情報と同じシークレットマネージャーとローテーションワークフローに保存します。
これにより、1つのゲートウェイ認証情報がレビューされていない共有スーパーキーになることを防ぎ、統合のメリットを維持できます。
リスクを隠さずに誤検知を制御する
誤検知は避けられません。許可リストは、がらくた入れではなく、セキュリティコントロールとして扱ってください。
| 許可リストのルール | 必要なコントロール |
|---|---|
| テストフィクスチャ | 明らかに偽の値を使い、テスト専用のパスに保持する |
| ドキュメントの例 | プロバイダーが承認したプレースホルダースタイルを使用し、実際のプレフィックスと現実的なエントロピーを組み合わせたものは決して使用しない |
| 過去の検出結果 | ローテーションチケットと削除決定へのリンク |
| 生成されたファイル | シークレットのような文字列なしで再生成するか、レビュー付きで生成パスを除外する |
| ベンダーのサンプル | ソースリンクを保持し、認証できないことを証明する |
| 一時的な例外 | 所有者、有効期限、更新レビューを追加する |
開発者が本物に見えるサンプルを繰り返し許可リストに追加している場合は、テンプレートを修正してください。より良いサンプルは、アラート疲れを軽減し、実際のLLM APIキーの漏洩が普通に見えてしまう可能性を低くします。
証拠パケットの構築
AI APIシークレットスキャンの出力は、エンジニアリング、セキュリティ、調達、財務の間の引き継ぎに耐えうる小さな証拠パケットであるべきです。
AI APIシークレットスキャン証拠レコード
検出ID:
スキャナーとルールバージョン:
プロバイダーまたはゲートウェイ:
非シークレットキーラベル:
リポジトリ、アーティファクト、ログ、またはチケット:
コミットSHAまたはアーティファクトダイジェスト:
所有者:
環境:
許可されたルートとエンドポイントファミリー:
データクラス:
キーは有効でしたか:
漏洩後の使用はありましたか:
ローテーションアクション:
古いキーの無効化日時:
代替キーのデプロイ日時:
スモークテストリクエストID:
コストまたは使用状況のレビュー:
墨消し/削除チケット:
レビュー担当者:
更新トリガー:このレコードに生のキーを貼り付けないでください。非シークレットのラベル、キーID、プロバイダーのダッシュボード参照、またはセキュリティによって承認されたハッシュ化された識別子を使用してください。
調達時に尋ねるべき質問
意思決定段階の購入者にとって、AI APIシークレットスキャンはベンダーおよび運用レビューに含まれます。次の質問をしてください。
| 質問 | 重要である理由 |
|---|---|
| 現在、アプリケーションリポジトリに直接のプロバイダーキーはいくつありますか？ | ゲートウェイ統合前のキースプロールを測定する |
| プッシュ前およびCIでシークレットをブロックするツールはどれですか？ | インシデント対応の前に予防策が存在するかどうかを示す |
| プロバイダーとゲートウェイのキー形式はカバーされていますか？ | スキャナーの死角を防ぐ |
| 各本番AI APIキーの所有者は誰ですか？ | ローテーションを実行可能にする |
| キーは環境とワークロードによって分離されていますか？ | 影響範囲を縮小する |
| 使用状況はキー、ルート、モデル、コスト別にレビューできますか？ | 不正使用と財務のレビューをサポートする |
| 緊急ローテーションのランブックは何ですか？ | チームが事後分析を待たずに行動できることを証明する |
| スキャナーの例外はどのようにレビューされますか？ | 許可リストの乖離を防ぐ |
Flatkeyを評価している場合は、Flatkey固有の証明ステップを1つ追加してください。テストキーを作成し、意図したモデルルートを介して低リスクのリクエストを実行し、チームが依存することになる現在の使用状況、コスト、ルーティング、およびキーレビューの証拠を確認します。その後、直接のプロバイダーキーをアプリレベルの設定から削除できるかどうかを決定します。
FAQ
AI APIシークレットスキャンとは何ですか？
AI APIシークレットスキャンとは、漏洩した認証情報がコスト、データ、または信頼性に影響を与える前に、ソースコード、Git履歴、CI変数、アーティファクト、ログ、ランブック、サポートチケット、その他のワークフローの表面でAIプロバイダーおよびゲートウェイのAPIキーを見つけるプラクティスです。
AI APIシークレットスキャンは通常のシークレットスキャンと異なりますか？
スキャンの仕組みは重複しますが、AIキーにはモデルアクセス、エンドポイントファミリー、プロンプトと出力の漏洩、トークンコスト、フォールバックルート、プロバイダー固有のローテーション証拠について追加のレビューが必要です。漏洩したAIキーは、セキュリティリスクと急激な使用料の両方を生み出す可能性があります。
ゲートウェイキーと直接のプロバイダーキーの両方をスキャンすべきですか？
はい。ゲートウェイは直接のプロバイダーキーのスプロールを減らすことができますが、ゲートウェイキーは依然としてモデルアクセスを承認します。それをスキャンし、シークレットマネージャーに保存し、所有者を割り当て、環境を分離し、漏洩した場合はローテーションしてください。
AI APIキー漏洩の検出結果は、どのような状態になったらクローズすべきですか？
検出結果は、生のシークレットが削除または墨消しされ、キーが失効またはローテーションされ、漏洩後の使用状況がレビューされ、所有者に通知され、代替キーのスモークテストが行われ、証拠がインシデントまたはアクセスレビューの記録に添付された後にのみクローズすべきです。
FlatkeyはAI APIシークレットスキャンを提供していますか？
公開ページからそれを想定しないでください。Flatkeyの公開ページは、ワンキーモデルアクセス、OpenAI互換のルーティング、使用状況分析、コスト管理、リクエストログ、請求の可視性をサポートしています。リポジトリ、CI、アーティファクト、ログスキャナーを使用してシークレットを検出し、関連する箇所でFlatkeyアカウントの証跡を使用してゲートウェイキーの使用状況とローテーションを確認してください。
まとめ
AI APIシークレットスキャンは、漏洩後のgrepではなく、予防的なワークフローであるべきです。コード、履歴、CI、アーティファクト、ログ、チケット、ランブックをスキャンします。直接のプロバイダーキーとゲートウェイキーを対象とします。すべての検出結果を所有者とスコープにマッピングします。安全な最小の影響範囲でローテーションします。古いキーが削除され、新しいルートが制御されていることを証明する証拠を保存します。
モデルアクセス、ルーティング、使用状況、コストレビューを1か所にまとめながら、直接のプロバイダーキーの拡散を減らしたい場合は、キーを取得し、すべてのプロバイダー資格情報に使用するのと同じAI APIシークレットスキャンおよびローテーションワークフローにFlatkeyキーを追加してください。
