AI APIキーのセキュリティ
プロバイダーキーをアプリケーションに含めないでください。代わりに、すべてのアプリ、エージェント、ツールにINFROゲートウェイキーを渡します。オフスイッチ、IP許可リスト、モデルの制限、支出上限があり、いずれもプロバイダーを呼び出す前に確認されます。
4件のチェック
すべてのリクエストで、プロバイダーが呼び出される前に。
32個のネットワーク
キーごとのIP許可リストで、IPv4またはIPv6。全プランで利用可能。
デプロイ不要
漏えいしたキーを無効にします。そのキーによるリクエストはすべて拒否されます。
AES-256-GCM
接続するすべてのプロバイダーキーに適用。二度と表示されません。
プロバイダーキーの置き場所
同じプロバイダーキーはたいてい5か所に置かれ、どのコピーからでもアカウント全体の支出ができます。INFROでは、プロバイダーキーは1か所に封印され、各アプリ、エージェント、ツールはそれぞれ専用のゲートウェイキーを持ちます。漏えいが起きる場所を選んでください。
sk-proj-••••7Hc25か所にコピー済みsk-proj-••••7Hc2ここで漏えいsk-proj-••••7Hc2同じキーsk-proj-••••7Hc2同じキーsk-proj-••••7Hc2同じキーsk-proj-••••7Hc2同じキーsk-proj-••••7Hc2INFROに封印sk_infro_••••a91f1日$50203.0.113.0/24漏えい、封じ込め済みsk_infro_••••3c7e1日$10203.0.113.64/27影響なしsk_infro_••••5d201日$530日後に失効影響なしsk_infro_••••8b141日$20Anthropicのみ影響なしsk_infro_••••e602月$151モデル影響なし4つのチェック
各チェックはそれぞれ文書化されたコードで拒否するため、ログに理由が正確に残ります。いずれもデプロイなしでコンソールまたはAPIから変更できます。4つともすべてのプランに含まれます。
このキーはオンか？
コンソールまたはAPIからキーをオフにすると、そのキーを使うすべてのリクエストが拒否されます。シークレット、上限、履歴は保持され、再びオンにすると同じキーが復活します。
403 key_disabledドキュメント
お客様のサーバーから呼び出されているか？
キーごとに最大32のIPv4またはIPv6アドレス、またはCIDR範囲。Cloudflareのエッジが報告するクライアントアドレスと照合し、X-Forwarded-Forは使いません。信頼できるアドレスがない場合、リクエストは拒否されます。
403 ip_not_allowedドキュメント
このモデルは許可されているか？
組織、プロジェクト、キーが呼び出せるモデルと、キーが到達できるプロバイダーを承認します。各キーは1つの環境に属し、その外の接続には到達しません。
403 model_not_allowedドキュメント
その上限は、このリクエストをカバーできるか？
組織、プロジェクト、メンバー単位の予算に加えて、キーごとの日次、週次、月次、または生涯の上限。上限がカバーできないリクエストは、プロバイダーを呼び出す前に拒否されます。
402 key_budgetドキュメント
支出上限
漏えいしたキー、ループにはまったエージェント、無料枠をスクリプトで使い倒す1人の顧客。いずれも予算全体に達する前に、それぞれの規模の上限で止まります。適用されるすべての上限は、処理中のリクエストの最悪のケースも含めて、プロバイダーを呼び出す前に確認されます。
上限は重なって適用されます
リクエストは、適用されるすべての上限に収まる必要があります。最も厳しい上限が判定を決めるため、適切な場所に小さな上限を置けば、組織全体の上限に達するずっと前に問題を止められます。
そのキーは、その日$50で止まります。他のすべてのキーは引き続きサービスを提供します。
| 上限 | 期間 | 動作 | 拒否コード | プラン |
|---|---|---|---|---|
| 組織 | 月間の目標とハード上限 | 目標はアラートを出し、ハード上限はアラートまたはブロックします。設定できるのはオーナーだけです。 | 402 organization_budget | すべてのプラン |
| プロジェクト | 月払い | お客様が設定したしきい値でのアラートに加えて、アラートまたはブロック。 | 402 project_budget | すべてのプラン |
| メンバー | 月払い | 1人の利用に対するアラートまたはブロック。 | 402 member_budget | すべてのプラン |
| ゲートウェイキー | 日次、週次、月次、または生涯 | 常にブロックします。生涯の上限はリセットされません。 | 402 key_budget | すべてのプラン |
| エンドカスタマー | 日次、週次、または月次 | 組織またはプロジェクトごとの、全顧客に共通する1つのルールと、バックエンドから設定する個別の上書き。 | 402 end_user_budget | Team以上 |
負荷をかけてテスト済みサンドボックスでのテストでは、$1のブロック型上限が、最大500件の同時リクエストで12回中12回とも維持されました（テストとその方法）。上限がカウントするのはプロバイダーの請求書ではなくINFROによるプロバイダー費用の推定値で、価格が不明なモデルはブロック型上限の下では許可しない限り拒否されます。プロバイダー側でも支出上限を設定しておいてください。 支出制御のドキュメント
キーが漏えいした
INFROゲートウェイキー向けです。プロバイダーキーが漏えいした場合は、まずプロバイダー側で削除してください。それを止められるのはそれだけです。
curl -X PATCH https://api.infro.io/manage/v1/gateway_keys/$KEY_ID \
-H "Authorization: Bearer $INFRO_MANAGEMENT_TOKEN" \
-H 'If-Match: "7"' \
-H "Content-Type: application/json" \
-d '{"disabled": true}'
# Every request with the key: 403 key_disabled
# Its secret, limits and history are kept.同じ3つの変更は、コンソールのキーのページにもあります。管理APIでは、変更に最後に読み取ったバージョン（If-Match）が必要なため、1つのインシデントに2人で対応しても互いに上書きすることはありません。
プロンプト内のシークレット
人は.envファイルをチャットに貼り付け、エージェントはシェルからそれを読み出します。Businessプランでは、ガードレールがプロンプト、ツール呼び出し、レスポンスにシークレットの形式がないかを確認し、プロバイダーを呼び出す前に、リクエストをブロックするか、一致部分を[SECRET]に置き換えるか、フラグを付けます。
検出はパターンベースです。これらの形式に一致するものだけを検出するため、AWSのシークレットアクセスキー、パスワード、未知の形式は見逃します。一致はすべてリクエスト記録にカウントされます。 ガードレールのドキュメント
エージェント、ツール、人
Claude Code、Codex、エージェントSDKは、AnthropicやOpenAIのキーではなくゲートウェイキーで、INFROの/v1/messagesと/v1/responsesを呼び出します。開発者やエージェントごとに、支出上限、有効期限、ネットワーク許可リスト付きのキーを1つずつ渡してください。失効させても他の誰にも影響しません。
各MCPサーバーをそのトークンとともに一度登録します。INFROがすべての呼び出しにトークンを付けるため、エージェント、プロンプト、設定ファイルがそれを保持することはなく、各ゲートウェイキーには許可されたツールだけが与えられます。
認証アプリによる二要素認証、パスキーとハードウェアキー、終了できるセッションの一覧、そしてすべてのメンバーに二要素認証を必須にする組織設定。 Businessプランから、SAMLまたはOIDCのシングルサインオンとSCIM。
当社が保持するキー
プロバイダーキーを保存するプラットフォームこそ、10月の攻撃が狙ったものです。同じ問いは当社にも当てはまります。以下の制御は、Trust Centerの記載をそのまま引用したものです。
INFROにできないこと
INFROから、あるいは他の場所から持ち出されたプロバイダーキーは、INFROのすべての上限の外で、プロバイダーに対して直接使えます。プロジェクトやワークスペースに範囲を限定し、プロバイダー側で支出上限を設定したキーを接続してください。それは当社が失敗しても機能する制御です。まだ整っていないものはTrust Centerに記載しています。
2026年10月
どちらの場合も、助言は同じでした。キーを置き換え、古いキーをプロバイダー側で削除し、何をしたかを確認することです。プロバイダーキーの置き場所が少ないほど、侵害時のローテーションは少なく済みます。配布するキーには、デプロイなしで変更できる制限を付けておくべきです。
Railwayの発表
An unauthorized party may have accessed encrypted customer environment variables and, for some of them, obtained the decrypted contents, in a series of attacks aimed at compromising AI inference providers.
対処法
Railwayが保持していたすべての変数をローテーションしてください。AIプロバイダーのキーを最優先に：置き換え、プロバイダー側で旧キーを削除し、デプロイし、旧キーの使用状況を確認します。
Railway breach: what happened and what to do2026年10月22日見直し
OpenCodeの発表
A breach related to a large-scale distillation attack affected 1.4% of OpenCode Console users, those with external AI providers linked, and provider keys saved in a workspace may have been exposed.
対処法
スコープを限定した置き換えのキーを作成し、プロバイダー側で旧キーを失効させ、10月16日以降のプロバイダーの使用状況を確認してください。
OpenCode Console breach: what happened and what to do2026年10月21日見直し
各概要は、当社の分析が引用している各社自身の公表に基づきます。執筆時点で両インシデントとも継続中でした。分析は毎週見直され、すべての変更を改訂履歴に記載しています。
フィールドガイド
よくある質問
プロバイダー側で置き換えのキーを作成し、漏えいしたキーをそこで削除し、置き換えをデプロイし、その後、旧キーが使われ得た全期間について、プロバイダー側で使用状況を確認してください。キーを止めるのは、プロバイダー側での削除です。アプリケーションやゲートウェイが、盗まれたキーを呼び戻すことはできません。その後、置き換えのキーにはプロバイダー側で支出上限を設定し、コード、クライアントアプリ、共有環境に置かないでください。
アプリケーションが持つのは、プロバイダーキーではなくINFROのゲートウェイキーです。各ゲートウェイキーは、オフにでき（403 key_disabled）、最大32のネットワークに限定でき（403 ip_not_allowed）、承認済みのモデルとプロバイダーに絞り込め、日次、週次、月次、または生涯の支出上限を設定できます（402 key_budget）。すべてのチェックは、プロバイダーを呼び出す前に、すべてのプランで実行され、デプロイは不要です。漏えいしたゲートウェイキーは、オフにできる限定的な問題ですが、漏えいしたプロバイダーキーはプロバイダーアカウント全体に及びます。
はい。予算は、組織ごと（アラートを出す月間の目標と、アラートまたはブロックするハード上限）、プロジェクトごととメンバーごと（月間）、ゲートウェイキーごと（日次、週次、月次、またはリセットされない生涯の上限）に設定できます。 Teamプラン以降では、エンドカスタマー向けの上限により、お客様自身の各顧客を日次、週次、月次で制限でき、特定の顧客に対する上書きも可能です。 該当するすべての上限は、プロバイダーを呼び出す前にチェックされ、処理中のリクエストの最悪ケースも含めてカウントされます。拒否されたリクエストは、その上限を示す402になります。上限がカウントするのは、プロバイダーの請求書ではなく、INFROによる推定プロバイダー費用です。プロバイダー側にも支出上限を設定しておいてください。
はい。プロバイダーキーを一度接続すると、INFROはそれを使ってリクエストを処理します。各キーは、データベースの外にあるWorkerシークレットとして保持される鍵のもとで、組織と接続を紐づけてAES-256-GCMで暗号化されるため、データベースのコピーだけでは何も開けません。保存された認証情報を返すコンソール画面、エンドポイント、エクスポートはなく、コンソールには末尾4文字だけが表示されます。ゲートウェイキーは、SHA-256ダイジェストとしてのみ保存されます。
はい。INFROが統制するのは、INFROを通るトラフィックだけです。どこから入手したものであれ、INFROから得たものも含め、プロバイダーキーは、INFROのあらゆる制限の外で、プロバイダーに直接使われる可能性があります。キーは、専用のプロジェクトまたはワークスペースにスコープを限定したものを接続し、プロバイダー側に支出上限を設定してください。その上限は、当社が障害を起こしても有効です。 Businessプラン以降では、使用状況へのアクセスを有効にした照合により、INFROを通っていない接続済みキーの使用状況を報告します。
OpenCodeは2026年10月17日、大規模な蒸留攻撃に関連する侵害により、外部AIプロバイダーを連携していたConsoleユーザーの1.4%が影響を受け、ワークスペースに保存されたプロバイダーキーが露出した可能性があると発表しました。Railwayは2026年10月21日、AI推論プロバイダーを侵害する攻撃において、権限のない第三者が暗号化された顧客の環境変数にアクセスし、その一部を復号した可能性があると発表しました。どちらの場合も助言は同じです。キーを置き換え、プロバイダー側で旧キーを削除し、その使用状況を確認してください。INFROは、各社自身の声明のみに基づいた分析を公開しています。
Businessプラン以降では、ガードレールが、プロンプトとレスポンスをOpenAI、Anthropic、Google APIキー、AWSアクセスキーID、GitHubトークン、Slackトークン、Stripe本番キー、INFROキー形式、JWT、PEM秘密鍵についてチェックし、プロバイダーに届く前に、リクエストをブロックするか、一致箇所を[SECRET]に置き換えるか、フラグ付けします。検出はパターンベースです。AWSシークレットアクセスキーやパスワードなど、知らない形式は検出できません。
INFRO経由ではありません。ゲートウェイキーを使ってINFROの/v1/messagesと/v1/responsesを呼び出すため、開発者やエージェントごとに、支出上限、有効期限、任意のネットワーク許可リスト付きの専用キーを持たせられ、失効させても他の人のアクセスには影響しません。エージェントは同じシェルに残っているキーを読めるため、開発者の環境から生のプロバイダーキーは取り除いてください。
LLMjackingとは、盗んだクラウドまたはAIのAPI認証情報を使って、被害者の費用でホスト型の言語モデルを呼び出すことです。攻撃者自身の利用のためか、アクセスを売るために行われます。対策は、お金を使える認証情報すべてに共通のものです。プロバイダーキーをコードやクライアントアプリに置かない、すべてのキーに支出上限を設ける、キーごとの使用状況を監視する、デプロイなしでキーをオフにできるようにしておく、ということです。
すべてのプランに、キーをオフにすること、許可するネットワーク、モデルとプロバイダーの制限、支出上限、ローテーションと有効期限、二要素サインインとパスキー、監査ログが含まれます。 支出アラートは、すべてのプランでメールに届き、Startupプラン以降ではSlackと署名付きWebhookにも届きます。 ガードレール、SSOとSCIM、迂回検出付きのコスト照合、MCPゲートウェイはBusinessプランに含まれます。
コンプライアンス、制御の全一覧、まだ整っていないものはTrust Centerにあります。脆弱性を見つけましたか？security@infro.ioまでご連絡ください。
始める
プロバイダーも、契約も、キーもお客様のもの。キーは1か所に封印。配布するすべてのキーに制限とオンオフを。モデル支出への上乗せは0%です。