2025年6月、LiteLLMサプライチェーン内の侵害されたPyPIパッケージが、月間9,500万回のパッケージインストールからAPIキーを窃取しました。2026年3月、ある企業が支出上限のないAPIキーで1か月に$500Mを燃やしました。その間にも、数十件の小規模インシデント——公開リポジトリにコミットされたキー、クライアントサイドコードに露出したキー、Slackメッセージで共有されたキー——がチームに数千ドルと数週間の修正作業を費やさせました。私たちの23のLLM APIミスガイドの最初の6つのうち5つはセキュリティ失敗です——漏洩したキー、欠落した予算上限、フラットなキーアーキテクチャ。
2026年のLLM APIセキュリティは理論ではありません。攻撃面は現実です。単一の漏洩キーの財務爆発半径は、1分あたりのドルで測られます。LLMアプリケーションのOWASP Top 10は最も重大なリスクをカタログ化しています——この記事は最も実行可能な10のセキュリティ基盤をそれらのリスクにマッピングします。これはTokSpanブログ全体のAPI認証とキー管理の権威あるリファレンスです——他の記事は詳細な実装のためにここにリンクしています。
基盤1：集中型シークレットボールト
.envファイルにAPIキーを置かない。ソースコードにキーを置かない。Slack、Notion、チャットログにキーを置かない。すべてのプロバイダーキーは暗号化シークレットボールト——AWS Secrets Manager、HashiCorp Vault、Azure Key Vault、またはDoppler——に保存されます。
キーはランタイムに注入されます——ビルド時にコンテナイメージに焼き込まれません。埋め込まれた認証情報を持つコンテナイメージは、そのイメージがプライベートレジストリを離れた瞬間に漏洩した認証情報です。Kubernetes Secrets Store CSI Driverは、キーがKubernetes Secretオブジェクトに触れることなく、ボールトからポッドへシークレットを同期します——素のK8s Secretsは、get secrets RBACを持つ誰にでも簡単に露呈します。
最小実行可能実装： 1つのボールト——セルフホスト用HashiCorp Vault、マネージド用Doppler。すべてのプロバイダーキーを暗号化して保存。アプリケーションは起動時にボールトのSDK経由でキーを取得。キーは設定ファイル、ディスク上の環境変数、バージョン管理に決して現れません。時間投資は漏洩キーのコストに比例します——そして予算上限のない漏洩したGPT-5.5キーは1か月で$500Mになる可能性があります。
基盤2：スコープ付きキーアーキテクチャ
「フラットキー」アンチパターン——各プロバイダーに1つのAPIキーをすべての環境・すべてのアプリケーション・すべての開発者で共有——は監査準備、コスト制御、インシデント封じ込めと両立しません。
スコープ付き階層を実装：
| スコープ | 目的 | 予算上限 | モデル許可リスト |
|---|---|---|---|
| Production（顧客向け） | 実ユーザートラフィック | $5,000/month | 固定・バージョン化モデルIDのみ |
| Production（内部ツール） | 内部ダッシュボード、分析 | $1,000/month | より広いが、実験的モデルなし |
| Staging | リリース前テスト | $200/month | 本番モデル + 評価候補 |
| Development | 実験 | $50/month | 最も広く、開発者ごとの上限付き |
各スコープは独自のAPIキー、モデル許可リスト、予算を持ちます。利点：帰属——すべてのリクエストが特定のアプリケーションと環境に追跡可能。爆発半径の封じ込め——侵害された開発キーは本番モデルや予算にアクセスできません。安全なローテーション——キーはスコープごとに独立したスケジュールでローテーションされ、組織全体の調整デプロイは不要。
スコープ付きキーへの最も単純な道は、仮想APIキーをサポートするプラットフォームです——各環境用に別々のキーを、キーごとの予算とモデル制限付きで作成。プロバイダーアカウントの変更なし。プロバイダーキーはプラットフォームのボールトに残ります。アプリケーションは特定のニーズにスコープされた短期仮想キーを使用。TokSpan認証ドキュメントで、仮想APIキー、スコープ付き権限、キーごとの予算が実際にどう機能するかを確認してください。
基盤3：プロキシ/ゲートウェイ層
アプリケーションはプロバイダーAPIキーを直接保持すべきではありません。短期・スコープ付き仮想キーでゲートウェイに認証します。ゲートウェイが実際のプロバイダーキーを保持し、モデル許可リストを強制し、予算チェックを適用し、すべてのリクエストをログし、プロバイダーに転送します。
アーキテクチャ： アプリケーション——仮想キー——ゲートウェイ——プロバイダーキー——LLMプロバイダー。
これでプロバイダーキーがブラウザ、モバイルアプリ、クライアントサイドコードに出荷されることはありません。アプリケーションログにも現れません。アプリケーションの仮想キーが侵害されたら、ゲートウェイで失効——プロバイダーキーは決して露出していません。伝播はリクエストごと、ほぼ即時の効果。
ゲートウェイはセルフホスト（LiteLLM）またはマネージド（集約プラットフォーム）にできます。セキュリティ特性は類似しています。運用オーバーヘッドが異なります——セルフホストはゲートウェイインフラの維持が必要、マネージドプラットフォームはそれを処理。TokSpanのセキュリティアーキテクチャは、ゲートウェイ層が実際にどう実装されるか——キー分離、リクエストレベル監査ログ、キーごとの予算強制——を文書化しています。
基盤4：自動キーローテーション
スケジュール： すべてのプロバイダーキーで90日ごと——広いスコープのキーはより頻繁に。緊急ローテーション： 開発者が退職したとき、ラップトップを紛失したとき、露出が検出されたとき——疑わしい場合でも——即座に。
ブルー/グリーンローテーション手順： プロバイダーで新しいキーを生成。古いキーの横にボールトへ追加。デプロイ——アプリケーションは両方のキーを取得。15〜30分モニタリング——すべてのリクエストが新しいキーで成功。プロバイダーで古いキーを失効。ゲートウェイがキー選択を処理するため、遷移はシームレス。アプリケーションはキーが変わったことを知りません。
ゲートウェイ層がないと、ローテーションはキーを使うすべてのアプリケーションでの調整デプロイが必要——ダウンタイムリスクのある数時間の作業。ゲートウェイがあれば、30分・ゼロダウンタイムの作業です。
基盤5：ハード予算上限
3レベルで支出制限を設定。プロバイダーダッシュボード： 最終防衛線——プラットフォームが侵害されても超えられないソースでの上限。プラットフォーム/ゲートウェイレベル： 運用制御——環境別・アプリケーション別の上限で、プロバイダーに到達する前に暴走支出を防ぐ。キーごと： 帰属——開発者別・機能別の上限で、暴走ループや侵害キーの爆発半径を封じ込める。
各上限の80%でアラート。100%でハード拒否。$500Mの月間請求は、ある組織がどのレベルにも上限がなかったから起きました。1つの設定変更で防げたはずです。
基盤6：最小権限モデル許可リスト
各キーは必要なモデルだけにアクセスすべきです。本番顧客向けキー：固定・バージョン化モデルID——gpt-5.5-2025-06-15、決してエイリアスのgpt-5.5ではない。エイリアスは黙って新しいスナップショットにアップグレードし、動作を変える可能性があります。開発キー：実験用に広いアクセス、ただし使用ケースで承認されていないモデルには決してアクセス不可。
操作制限：推論専用キーはファインチューニング、管理、請求エンドポイントを呼び出せない。デフォルト拒否姿勢：新しいキーはゼロアクセスから開始。モデルと操作は明示的に付与されます。
基盤7：CI/CDシークレット検出
マージ前にLLM APIキーを捕捉する決定的スキャン。Python、JavaScript、Java、C#、Go、.envファイル、YAML設定、JSON設定、CIパイプラインログを横断してsk-proj-*（OpenAI）、sk-ant-*（Anthropic）、その他のプロバイダーキーパターンを検出。重大または高信頼シークレットが検出されたらマージをブロック。LLMキーを層ゼロ資格情報として扱う——クラウドIAM資格情報と同じ重大度。
基盤8：完全な監査証跡
すべてのAPI呼び出しがこれらの次元で追跡可能でなければならない：ユーザーID、アプリケーションID、環境、モデル、プロバイダー、消費トークン、コスト、タイムスタンプ、リクエストID、ガードレール結果。集中システムへログを出力——最低90日のホット保持、規制対象ワークロードは1年のコールド。永続ストレージに書き込む前に、機密パターン（APIキー、PII）をログから削除。
監査ログが実際に捕捉するもの：2026年1月、あるSeries A SaaS企業の開発者がCI障害のデバッグ中に、開発スコープのAPIキーを誤って公開GitHub Gistにコミットしました。キーはUTC午前2:14に漏洩。午前6:30までに、SOCはゲートウェイから自動アラートを受信——そのキーのリクエスト量が40倍にスパイク。すべてのリクエストがユーザーID、アプリケーションID、モデル、トークン数でログされていたため、チームは11分で完全な露出を追跡：4時間にわたる37リクエスト、すべて固定されたGPT-4.0モデルに対するもので、本番データやファインチューニングエンドポイントには無関係。スコープ付きキーとキーごとの予算上限が損失を$18に抑えました。これらのログがなければ、チームは爆発半径の再構築に数日費やしていたでしょう——あるいは最悪を想定し、すべての顧客に不要な侵害開示をトリガーしていたかもしれません。監査証跡は資格情報漏洩を確認済みの非イベントに変えました。
HIPAAの下では、監査証跡は答えなければなりません：「この日付にどのシステムがPHIにアクセスしたか？どのモデルが処理したか？どのBAAの下で？」ユーザー別帰属のないフラットキーアーキテクチャはこれらの質問に答えられません。ゲートウェイレベルのログを持つスコープ付きキーアーキテクチャは答えられます。
基盤9：PII削除とデータプライバシー
インフラを離れる前に、プロンプトから個人識別情報を削除します。ゲートウェイレベルのPII検出を使用——Portkeyのガードレール、カスタムミドルウェア、専用ツール。各プロバイダーのデータ利用ポリシーを理解：あなたの階層はAPIデータでのトレーニングを許可していますか？オプトアウトはありますか？機密ワークロードには、契約上のデータ処理契約を持つプロバイダーを使用——またはそれを提供するプラットフォーム経由でルーティング。
基盤10：文書化されたインシデントレスポンス
キーが漏洩したとき、対応は時間に敏感です——予算上限のない侵害キーは1時間あたり数千ドルの不正利用を生む可能性があります。手順： ゲートウェイでキーを即時失効——伝播はリクエストごと、ほぼ即時。露出した可能性のあるプロバイダーキーをローテーション。緊急バックストップとしてプロバイダーダッシュボードで支出を上限。露出期間のスコープのリクエストログを監査：プロンプトに何のデータがあったか？異常なアクティビティは？ギャップをパッチ——通常は欠落したガードレール、広すぎるCORSオリジン、明示的な同意ゲートのないツール。PIIまたはPHIが関与した場合、影響を受けた当事者に開示。
LLM APIセキュリティ成熟度モデル
初日に10の基盤すべては不要です。以下の成熟度モデルは基盤を組織の段階にマッピングします——今、侵害がいくらかかるかに基づいて優先順位を付けましょう。
基本（スタートアップ/個人開発者）：基盤1、5、7。 集中シークレットボールトが.envファイルとバージョン管理からキーを締め出します。プロバイダーダッシュボードのハード予算上限が単一の漏洩から壊滅的な支出を防ぎます。CI/CDシークレット検出が公開リポジトリにマージされる前にキーを捕捉。この3つの基盤が最も一般的な2つの障害モード——コミットされたキーと上限のない支出——を防ぎます。実装時間：Doppler＋プロバイダーダッシュボード上限＋pre-commitフックで午後ひとつ。
標準（成長チーム/マルチ環境）：基本＋基盤2、3、4、6。 環境別のスコープ付きキーが爆発半径を封じ込めます。ゲートウェイ層がアプリケーションがプロバイダーキーを直接保持しないことを保証——漏洩した仮想キーは何も露呈しません。自動ローテーションがキー露出ウィンドウを数か月から90日に短縮。モデル許可リストが最小権限アクセスを強制し、ステージングキーが本番専用モデルを呼べないようにブロック。これらの基盤は環境が1つを超えた瞬間に必要になります——プロバイダーあたりの単一フラットキーはAPIセキュリティの「MFAなしルートユーザー」です。実装時間：マネージドゲートウェイで1週間。
エンタープライズ（規制対象/コンプライアンス必須）：標準＋基盤8、9、10。 ユーザー別帰属付きの完全監査証跡がHIPAA、SOC 2、ISO 27001要件を満たす——任意の監査ウィンドウで「誰がどのデータにいつ、どのモデルを通じてアクセスしたか」に答えられます。ゲートウェイレベルのPII削除がプロンプトがインフラを離れる前に機密データを拭き取ります。文書化・テスト済みのインシデントレスポンスプレイブックで、SOCは失効-ローテーション-監査ワークフローを5分未満で実行——5時間未満ではなく。この層では、セキュリティはもはや機能ではなく、LLMインフラ全体のコントロールプレーンです。
FAQ
LLM APIで第1のセキュリティミスは？
ソースコードまたは.envファイルのハードコードキーがバージョン管理にコミットされること。LiteLLMサプライチェーン攻撃は月間9,500万インストールからキーを窃取——しかしより一般的なベクトルは公開リポジトリへの単純なgit pushです。シークレットボールトを使用。ハードコードしない。
環境別のAPIキーは本当に必要ですか？
はい。侵害された開発キーが本番モデルや予算へのアクセスを付与してはなりません。スコープ付きキーが爆発半径を封じ込めます。プロバイダーあたりの単一フラットキーはLLM APIセキュリティの「MFAなしルートユーザー」です。
集約プラットフォームは直接APIより安全ですか、安全でないですか？
よく実装されたプラットフォームはより安全：仮想キーがプロバイダー資格情報を決して露呈せず、キーごとの予算と許可リストが組み込み、監査証跡が統合、キーローテーションが集中。悪く実装されたプラットフォームはより安全でない。コミット前にプラットフォームのセキュリティドキュメントを評価。セルフホスト要件には、LiteLLMがインフラの完全制御で同じセキュリティ特性を提供。
LLM API使用時にHIPAAに準拠するには？
BAAサポート、すべてのリクエストをユーザーと目的に帰属させる監査ログ、PHIを準拠インフラ内に保つデータレジデンシーオプション、プロバイダーがデータでトレーニングしないという契約保証を持つゲートウェイを使用。直接APIはプロバイダーごとのBAAが必要——それぞれ別々に交渉。集約プラットフォームはこれを1つの契約に統合できます。
APIキーが漏洩したらどうすれば？
即時：ゲートウェイで失効。プロバイダーキーをローテーション。支出を上限。次に：何にアクセスされたか監査ログを確認。ギャップをパッチ。データが露出したら開示。最初の3ステップは5分未満であるべき。最後の3つは数日かかるかもしれません。必要になる前に手順を文書化しておくことが、「インシデント」と「大惨事」の違いです。
ここで扱った10の基盤は、LLM APIセキュリティの具体的なチェックリストを形成します。ズームアウトすると、業界全体に広がるより大きなパターンが見えます：セキュリティは後付けの機能であることをやめ、他のすべてが走る基盤になりつつあります。同じシフトが10年前のクラウドIAMで起きました——コンプライアンスチェックボックスとして始まったものが、インフラ全体のコントロールプレーンになりました。LLM APIセキュリティは同じ軌道にあります。これらの基盤をローンチ後の監査項目ではなく基盤となるアーキテクチャとして扱うチームが、物——や予算——を壊さずに速く動けるチームです。
APIキーを保護する——仮想キー、スコープ付き権限、キーごとの予算、統合監査ログ。10の基盤のうち7つがデフォルトで強制されます。