盗まれたAI APIキーがハッキングスキャン費用に悪用される今、OpenAI・Anthropic・Geminiのキーを保護する方法

盗まれたAI APIキーが、今や他人のハッキングの支払い手段になっている。2026年10月、Bitsightの脅威インテリジェンスチームは、犯罪フォーラムで販売されているツールMONST3R-AIについて報告した。これは盗まれたOpenAI、Anthropic、Googleのキーを使って自律型のペネトレーションテストスキャンを実行するものだ。購入者がキーを持ち込み、エージェントがスキャンを行い、キーの所有者に請求が回ってくる。本ガイドでは、キーがどのように漏洩するか、悪用をどう見つけるか、そして各プロバイダーが現在提供している制御について解説する。

OpenAI、Anthropic、Geminiのキーを保護するには、1つのプロジェクトまたはワークスペースにスコープを限定し、月次の厳格な支出上限を設定し、呼び出し元を制限し、有効期限を設定するかローテーションし、クライアントコードやリポジトリに含めないようにし、プッシュ保護付きのシークレットスキャンを有効にする。キーが漏洩した場合は、代替キーを作成してデプロイし、その後で古いキーを無効化して使用状況を監査する。

LLMjackingとは？

LLMjackingとは、盗まれた大規模言語モデルの認証情報（通常はAPIキー）を悪用し、キーの所有者が費用を負担する形で推論を実行することだ。攻撃者はそのアクセス権を転売したり、自分のワークロードで使い潰したり、そしてBitsightによれば今では自律型攻撃エージェントを動かすために使ったりする。被害者から見ると、その活動は自分のアカウント上の課金対象の利用としてしか見えない。

BitsightがMONST3R-AIについて発見したこと

以下の事実は、2026年10月17日に公開されたHelp Net SecurityとAI WeeklyによるBitsightの研究の報道に基づく。本記事の執筆時点で、Bitsight自身によるこのツールに関する解説は公開されていなかった。

• 何であるか: 限定された犯罪フォーラムのある販売者が、MONST3R-AIを「自律型ペネトレーションテストプラットフォーム」として売り込んでいる。
• 誰のキーか: 盗まれたOpenAI、Anthropic、GoogleのAPIキーで動作する。
• 誰が支払うのか: 購入者は盗んだキーをツールのパネルに貼り付け、予算の上限を設定し、エージェントをターゲットリストに向ける。販売者はモデルをホストしていないため、推論の請求はキーの正当な所有者にのしかかる。
• 主張されている結果: 販売者のダッシュボードは、スキャンした199台のホストで1,072件の検出を主張している。Bitsightはこの数字を独自に検証できないとしているため、証拠ではなく宣伝文句として扱うべきだ。
• より広いトレンド: 2026年2月から8月にかけて16のアンダーグラウンドフォーラム全体で、AIエージェント、間接プロンプトインジェクション、Model Context Protocolへの言及が67パーセント増加した。

漏洩したキーはもはや、突然届く請求書というだけではない。それは他人の攻撃キャンペーンの資金源になり得るし、すべてのリクエストはあなたの通常のトラフィックのように見える。

AI APIキーが漏洩する仕組み

盗まれたキーのほとんどは「ハッキング」されたものではない。事故によって公開されたのだ。よくある経路は次のとおり:

GoogleのGemini APIキーガイドはクライアントサイドのルールを明快に述べている。Webアプリやモバイルアプリにコンパイルされたキーはユーザーに抽出され得るため、実際の呼び出しを行うバックエンドプロキシを運用すること。APIキーの保存に関する当社のガイドでは、保存の側面をより詳しく扱っている。

エージェントの設定には特に注意が必要だ。MCPやエージェントの設定ファイルは、ドットファイルのリポジトリ、画面共有、バグレポートに紛れ込む。

キーが悪用されていることに気付く方法

「犯罪者がこれを使っています」と教えてくれるアラートはない。利用状況と請求データで次を注視しよう:

1. デプロイを伴わない支出の急増。 毎日一定だったコストが一晩で倍になるのが最も明確な兆候だ。
2. 使っていないモデル。 自社製品が一度も呼び出さないモデルファミリーでの利用。
3. 時間外のトラフィック。 日中に使われるアプリのキーから、あなたのタイムゾーンで午前3時に安定してリクエストが来る。
4. 自分が原因ではないレート制限エラー。 誰かがあなたの1分あたりのクォータを消費している。
5. 使用状況ページにある身に覚えのないキーやプロジェクト。 Google AI Studioの使用状況ページでは、名前付きキーに紐付けられないリクエストが「(unknown keys)」の下にまとめられる。

急増が1つのキーを指し示すように、キーを十分細かく分割しよう。

OpenAI APIキーを保護する方法

2026年10月28日にOpenAIの開発者ドキュメントに基づいて確認。

• 厳格な支出上限: 支出上限ガイドによれば、組織または単一プロジェクトに対して月次上限を設定し、「Enforce a hard limit」をオンにできる。追跡された支出が上限に達すると、リクエストは429とコードorganization_spend_limit_exceededまたはproject_spend_limit_exceededで失敗する。適用は即時ではないため、支出が上限をわずかに超えることがある。
• 支出アラート: アラートは通知するだけでトラフィックを止めない。両方を使い、アラートは厳格な上限より十分低く設定しよう。
• IP許可リスト: IP許可リストは、有効なキーであっても他のIPからのリクエストを拒否する。最大50個のアドレスまたはCIDR範囲を登録でき、プロジェクト単位または組織全体に適用できる。ブロックされた呼び出しはHTTP 401とip_not_authorizedを返す。変更の反映には最大15分かかる。
• アプリと環境ごとに1つのプロジェクト: プロジェクト単位の上限と許可リストは、キーがプロジェクトごとに分割されている場合にのみ役立つ。
• 制限付きキー権限: OpenAIのプロジェクトガイドには、ユーザー所有キーの権限としてAll（デフォルト）、Restricted、Read Onlyが記載されている。各キーにはそのアプリが必要とする権限だけを与えよう。
• プロジェクトごとのモデルアクセス: プロジェクトのLimits内のModel usageで、そのプロジェクトが呼び出せるモデルを選ぶ。そうすれば、盗まれたキーが、あなたが決して使わない高価なモデルに飛びつくことはできない。

当社のOpenAI APIキーガイドも参照。

Anthropic APIキーを保護する方法

2026年10月28日にClaude Platformのドキュメントに基づいて確認。

• ワークスペースの支出上限: ワークスペースのドキュメントによれば、ワークスペースごとに月次支出の上限を設定し、しきい値でアラートを構成できる。Default Workspaceには支出上限を設定できないため、本番キーは専用のワークスペースに置こう。
• ワークスペースのレート制限: ワークスペースごとに1分あたりのリクエスト数、入力トークン数、出力トークン数に上限を設ける。
• キーの有効期限: 認証ドキュメントでは、作成時に有効期限を選べる。3時間、1日、7日、30日、カスタム期間、またはNever。後から変更することはできない。
• IDに紐づくキー: 個人キーとサービスアカウントキーは、所有者が削除されると機能しなくなる。Anthropicはワークスペースキーをレガシーと呼び、クラウドプラットフォームやCIでの本番利用にはWorkload Identity Federationを推奨している。
• 無効化と削除の違い: 無効化は可逆的で、キーはinactiveとして表示される。削除は永続的だ。判断に迷ったらまず無効化しよう。

当社のAnthropic APIキーガイドも参照。

Google Gemini APIキーを保護する方法

2026年10月28日にGoogleのGemini APIキーのドキュメントと請求のドキュメントに基づいて確認。

• 認証キー: 2026年5月28日以降、Google AI Studioで作成される新しいキーは、サービスアカウントに紐づく認可キーであり、デフォルトでGemini APIに制限される。Googleによれば、同社のシステムが検出した漏洩キーに対して迅速に効く強制措置が付随する。
• 無制限キーは不可: Gemini APIは、無制限の標準キーからのリクエストを拒否する。古いキーはAI StudioでGemini APIに制限するか、認証キーに移行しよう。
• アプリケーションの制限: Cloudコンソールの認証情報ページで、キーを特定のIPアドレスに制限できる。
• プロジェクトの支出上限: AI StudioのSpendページで、プロジェクトごとに月次上限を設定する。Googleはこれを実験的と位置づけており、約10分の課金遅延の間に超過が起きる可能性があると警告している。

全プロバイダー共通のロックダウンチェックリスト

所有するキーごとに一度、これを実行しよう:

1. 棚卸し。 すべてのキー、それを使うアプリ、保存場所をリストアップする。
2. 分割。 アプリと環境ごとに1つのプロジェクトまたはワークスペースにして、急増が発生源を指し示すようにする。
3. 上限設定。 月次の厳格な上限と、それより早い段階のアラートを設定する。
4. 制限。 送信元が固定されている場所では、IP許可リストまたはアプリケーション制限を適用する。
5. 失効またはローテーション。 プロバイダーが対応していれば短い有効期限を、対応していなければローテーションのスケジュールを。
6. スキャン。 GitHubのシークレットスキャンパターンにはOpenAI、Anthropic、Google GeminiのAPIキーが含まれており、OpenAIのキーはプッシュ保護に対応している。漏洩したAPIキーをチェックする方法に関する当社の記事では、ローカルで実行できるスキャナーを紹介している。
7. 短命な認証情報を優先する。 AnthropicとOpenAIはいずれも、本番向けのワークロードIDフェデレーションについて文書化している。

ポリシー面については、APIキー管理のベストプラクティスを参照。

漏洩後1時間以内にやるべきこと

根本原因より速さが優先だ。順番は次のとおり:

1. 代替キーを作成する 新しいプロジェクトまたはワークスペースで。
2. それをデプロイする 必要とするアプリに。
3. 漏洩したキーを無効化する。 Googleの漏洩チェックリストでは、ダウンタイムを避けるため、新しいキーを検証した後にのみ古いキーを無効化するよう述べている。支出が急速に増えている場合は、先に無効化し、一時的な停止を受け入れる。
4. 支出上限を引き下げる 調査中は、影響を受けたプロジェクトの。
5. 利用状況を監査する 漏洩以降の期間について、モデル、時間、キー別に。
6. 漏洩経路を特定する 上の表を使って、そしてgit履歴から消し去る。
7. プロバイダーに連絡する タイムラインが判明したら、不正利用について。

コーディングエージェントにApidog CLIでキー処理をテストさせる

OpenAI、Anthropic、Geminiへのバックエンドプロキシは、キー処理が破綻しやすい場所だ。認証なしの呼び出しを受け入れてしまったり、エラーレスポンス本文にプロバイダーのキーをそのまま返してしまったりする。コーディングエージェントにApidog CLIでそのテストを書かせて実行させよう。シークレットはテスト定義に含めないようにする。

一度セットアップする:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

次に、エージェントに1つのプロンプトを与える:

In Apidog project <id>, create a test case for POST /v1/ai/chat on our proxy.
Assert: no Authorization header returns 401, a bad token returns 401, a valid
token returns 200, and no response body contains "sk-" or "AIza". Read the
token from the {{PROXY_TOKEN}} environment variable, never hardcode it.
Then run it against the staging environment and summarize failures.

エージェントはペイロードスキーマを読み取り、検証し、テストケースを作成して実行する:

apidog cli-schema get test-case-create
apidog test-case category --project <id>
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> \
  --env-var "PROXY_TOKEN=$PROXY_TOKEN" -r cli,junit

--env-varは実行時にトークンを渡すので、トークンがスペックやリポジトリに残ることはない。同じapidog runの行はそのままCIにも組み込める。CI/CDパイプラインでのApidog CLIとClaude CodeでのApidog CLIを参照。

FAQ

LLMjackingとは何か？ 盗まれたLLMの認証情報（通常はAPIキー）を使い、所有者が費用を負担する推論を実行することだ。攻撃者はそのアクセス権を転売したり、MONST3R-AIの場合のように攻撃エージェントを動かすために使ったりする。

盗まれたAI APIキーが本当にハッキングツールの支払いに使われるのか？ はい。Bitsightは、MONST3R-AIの購入者が盗んだOpenAI、Anthropic、Googleのキーをそのパネルに貼り付け、販売者はモデルをホストしていないため、被害者が支払うことになると報告した。販売者が主張する結果は検証されていない。

支出上限は盗まれたキーを止められるか？ 厳格な上限は上限額で支出を止めるが、即時ではない。OpenAIもGoogleも、上限が反映されるまでの間にわずかな超過が生じると注記している。支出アラートだけではトラフィックを止められない。

OpenAI APIキーをフロントエンドコードに置いてもよいか？ いいえ。ブラウザやモバイルアプリに配信されるものはすべて抽出され得る。モデルはバックエンドから呼び出すこと。

GitHubは漏洩したAIキーを検出できるか？ GitHubのシークレットスキャンは、OpenAI、Anthropic、Google GeminiのAPIキーのパターンを検出する。プッシュ保護を有効にすれば、キーを含むコミットが公開される前にブロックされる。