OpenCode の情報漏洩：Synthorai の信頼済み IP で流出キーを止める

2026 年 10 月 17 日、OpenCode は、ホスト型サービスの OpenCode Console を支える旧システムに侵入があり、保存されていた外部プロバイダーのキーが「流出した可能性がある」とユーザーに通知しました。その後、ユーザーから OpenAI、Anthropic、Google のアカウントで数百ドルから $1,700 の請求が発生したとの報告がありました。プロバイダーキーとは、OpenAI や Anthropic から発行される API キーです。これをホスト型ツールに預け、ツールからプロバイダーを呼び出す方式を BYOK（bring your own key）と呼びます。キーが流出したときの被害額は、どこから使えるか、そして止まるまでにいくら使えるかの 2 点で決まります。

TL;DR

• OpenCode によると、Console への侵入で影響を受けたのは Console ユーザーの 1.4% です。ローカルの OpenCode CLI に保存されたキーは影響を受けていません。
• ゲートウェイの IP 制限と利用上限が適用されるのは、ゲートウェイを通る通信だけです。プロバイダーキーの流出に備えるには、プロバイダー側の強制上限が必要です。
• Synthorai で「新しい IP を承認制にする」を有効にすると、そのキーで承認されていないアドレスからの API 呼び出しは HTTP 403 と ip_not_trusted で拒否されます。
• Synthorai のキーには、利用額の上限、1 分あたりのリクエスト数と token 数の上限、有効期限をそれぞれ設定できます。

OpenCode Console への侵入で何が起きたのか

OpenCode が対象ユーザーに送ったメールによると、不正な第三者が「廃止作業中だった旧システム」に侵入しました。対象ユーザーの Console ワークスペースに保存されていたプロバイダーキーが読み取られた可能性があります。OpenCode は、流出が起きた可能性のある最も早い時刻を 10 月 17 日 00:30 UTC としています。OpenCode の投稿、プロバイダーの担当者の投稿、報道をもとにした時系列は次のとおりです。

蒸留攻撃とは、あるモデルの回答を大量に集め、別のモデルの学習に使う行為です。盗んだキーは、その呼び出し費用を他者に負担させる手段の 1 つです。OpenCode は、今回の侵入と蒸留の関係を説明していません。共同創業者の Dax Raad は、対象は「OpenCode 自体ではなく OpenCode Console」であり、ローカル CLI に追加したキーが同社に送られることはないと述べています。10 月 21 日時点で、OpenCode は根本原因、保存キーの暗号化の有無、1.4% に相当するアカウント数、補償方針、事後分析を公表していません（The Hacker News、BleepingComputer）。

流出したのはどのキーか、どの対策が有効か

流出したのはプロバイダーキーです。盗まれたプロバイダーキーは、保存先のツールを経由せず、プロバイダーに直接リクエストを送るために使われます。このため、LLM ゲートウェイで対処できる範囲には限界があります。ゲートウェイは、アプリケーションのコードとモデルプロバイダーの間でリクエストを中継するサービスです。把握して制限できるのは、そこを通る通信だけです。キーを次の 2 種類に分けると整理できます。

次の 2 つのセクションで扱う信頼済み IP と利用額の上限は、表の 1 行目を保護する機能です。2 行目では、OpenAI、Anthropic、Google 側で設定する強制上限が最後の歯止めになります。その設定は、続くセクションで説明します。

Synthorai はプラットフォームキーと BYOK キーをどう保護するか

BYOK 保管庫に追加したプロバイダーキーは、標準的な認証付き暗号アルゴリズムである AES-256-GCM で暗号化して保存されます。保存後は、API、MCP ツール、コンソール画面のいずれからもキーを取得できません。コンソールに表示されるのは末尾の 4 文字だけです。ゲートウェイは、そのキーを使うリクエストの処理時に限り、メモリ上で復号します。追加、ローテーション、削除ができるのはワークスペースのオーナーだけです。Synthorai が自社の提供枠に使うプロバイダーキーも同じ方法で保存しており、管理者用コンソールを含め、どのコンソール画面や API にも表示されません。暗号化はデータベースのコピーを保護します。ただし、稼働中のサービスが侵害されると、使用中のキーにアクセスされる可能性は残ります。そのため、BYOK キーでは後述するプロバイダー側の上限が最後の歯止めになります。

Synthorai が発行する API キーは、ハッシュとしてのみ保存します。ハッシュは一方向の指紋のようなもので、元のキーを復元できません。キー全体が表示されるのは作成時の 1 回だけです。その後はコンソール、管理 API、MCP サーバーのどこから読み出しても、返るのはプレフィックスだけです。推論用キーでできるのはモデルの呼び出しだけです。管理 API は受け付けないため、推論用キーが盗まれても、ログ、利用状況、ほかのキーは読み取れません (API keys, admin keys)。

信頼済み IP は流出したキーをどう止めるか

信頼済み IP は、そのキーで承認されていないアドレスからの API 呼び出しを拒否します。CI ログやノート PC からコピーされたキーを別の場所で使っても、回答ではなくエラーが返ります。オーナーまたは管理者が、Settings › Security の「新しい IP を承認制にする」で有効にします。確認ダイアログには、過去 7 日間に各キーを使って呼び出したアドレスが、すべて承認対象としてチェックされた状態で表示されます。確定する前に一覧を確認し、心当たりのないアドレスはチェックを外してください。すでにキーが流出して使われていれば、攻撃者のアドレスもこの一覧に含まれます。

以後、新しいアドレスからの呼び出しには HTTP 403 が返ります（以下のアドレスはドキュメント用の例です）。

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

キーの作成者には、アドレス、所在地、クライアント、要求されたモデルを記載したメールが届きます。承認にはコンソールへのサインインが必要なため、メールを転送するだけでは承認されません。承認対象は単一のアドレスか、そのアドレスを含む /24 の範囲（隣接する 256 個の IPv4 アドレス）から選べます。後者はアドレスが変わるクライアント向けです。ゲートウェイは、自身のプロキシが受けた接続から呼び出し元アドレスを取得します。そのため、クライアントが独自の X-Forwarded-For ヘッダーを送っても、別のアドレスを名乗ることはできません。このヘッダーは、プロキシが元のクライアントのアドレスを伝えるために使うものです。実際に偽装ヘッダーで確認したところ、拒否応答には実際のアドレスが表示されました。

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

キーの作成時に、固定の ip_allowlist を設定することもできます。ただし、このリストはキー自体の設定です。オフィス、サーバー、VPN の出口が増えるたびにキーの設定を編集する必要があり、削除し忘れたエントリは許可されたまま残ります。信頼済み IP は、すでにそのキーを使っているアドレスから始め、新しいアドレスを信頼する前に承認を求めます。全キーのアドレスを 1 つの一覧で管理でき、心当たりのあるアドレスを 1 クリックで信頼できます。独自の許可リストがあるキーは、そのリストだけで判定されるため、キーごとにどちらか一方を使ってください。

信頼の設定はキー単位です。実行のたびに新しいアドレスから呼び出すサーバーレス関数や CI ランナーは、毎回保留されます。ホスト型 CI サービスが公開しているアドレス範囲を、そのまま信頼しないでください。そのアドレスはサービスの全顧客で共有されているため、そこでジョブを実行できる人なら誰でも通過できてしまいます。こうした呼び出し元は、セルフホスト型ランナーや NAT ゲートウェイなどの固定出口アドレスを経由させ、そのアドレスを信頼してください。あるいは、有効期限が短く、利用上限の低いキーを渡してください。

利用額の上限で、盗まれたキーの被害をどう抑えるか

Synthorai の API キーには、それぞれ利用額の上限を設定できます。キーが流出しても、指定した金額で止められます。コンソールでは、キーの作成時に上限、利用可能なモデル、有効期限を設定します。

キーごとのレート制限と、以下の各設定は管理 API から設定します。

次の例では、あるサービス専用のキーを、そのサービスに必要な範囲だけに制限して作成します。作成には管理者キーを使います。管理者キーは、キーの作成と制限の設定ができる一方、モデルは呼び出せない管理用キーです。

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

ワークスペースのオーナーは、メンバーごとに日次と月次の利用上限も設定できます。月次上限に達したメンバーには、翌月まで HTTP 402 が返ります。これらの制限が適用されるのは Synthorai を通る通信です。BYOK を上限に含めれば、ゲートウェイ経由の BYOK リクエストも対象になります。ただし、流出したプロバイダーキーが直接使われる場合は対象外です。

これらの対策で防げないこと

信頼済み IP は、新しい場所からのキーの利用を止めます。信頼済みのマシンから使われた場合には効果がありません。よくあるキーの盗難は、まさにその場所で起きます。開発者のノート PC に入ったマルウェア、侵害された CI ジョブ、攻撃者の代わりにリクエストを送るよう仕向けられたサーバーなどです。こうした場合に被害を抑えるのは、キーの利用上限、モデルの制限、短い有効期限です。

承認するかどうかは人が判断するため、攻撃者が保留されるリクエストを発生させ、利用者が習慣的に承認するのを狙う可能性があります。承認画面には、アドレス、所在地、クライアント、モデルが表示されます。自分が行った呼び出しと一致する場合だけ承認してください。

毎日リセットされる上限では、盗まれたキーが発覚するまで毎日その上限額を使えます。上限だけでなく検知も組み合わせてください。アドレスが保留されるたびに届くメール、コンソールのキー別利用額、キー変更の監査ログが役立ちます。流出の疑いがあるキーはコンソールで削除し、代わりのキーを作成してください。流出前に検出するには、コードのホスティング先で sk-syn- プレフィックスをシークレットスキャンの対象に追加します。たとえば GitHub では、プッシュ保護を有効にしたカスタムパターンを使えます。

BYOK キーではプロバイダー側に何を設定すべきか

ツールごとに専用のプロバイダーキーを発行し、プロジェクトまたはワークスペースも分けて、強制的な利用上限を設定してください。そうすれば、1 つのキーが流出しても、そのプロジェクトの予算までしか使えません。流出したキーは、プロバイダーのダッシュボードで失効させてください。保存先のツールから削除しても、キー自体は失効しません。3 社ともキー単体には上限を設定できず、最小単位はプロジェクトまたはワークスペースです。

メールを送るだけの利用額アラートや予算設定では、進行中の攻撃は止まりません。強制上限を設けたうえで、補助的な通知として残しておくと役立ちます。Synthorai コンソールの BYOK ページでは、キーの下に各プロバイダーの上限設定へのリンクがあります。

OpenCode を Synthorai と組み合わせて使えるか

使えます。ローカルの OpenCode CLI で使うキーは自分のマシンに保存され、今回の侵入の影響を受けなかった構成です。opencode auth login https://synthorai.io を実行すると、ワンタイムコードを使ってブラウザー経由で OpenCode にサインインし、OpenCode 専用の API キーが発行されます。有効期限は 7、30、90 日から選べます（設定手順）。「新しい IP を承認制にする」が有効で、同じネットワークからサインインを許可すると、そのキーではサインイン元のアドレスが自動的に信頼されます。それ以外の場所からの呼び出しは承認待ちになります。サインイン要求がブラウザーとは別のネットワークから届いた場合、確認画面に警告が表示され、そのアドレスは最初の呼び出しが承認されるまで信頼されません。自分でコマンドを実行していないなら、要求をキャンセルしてください。

キーは API キーのページに「OpenCode」という名前で表示され、そこで利用上限の追加や削除ができます。ノート PC に保存したキーも、その PC 上のマルウェアには盗まれる可能性があります。有効期限は 7 日または 30 日にし、「新しい IP を承認制にする」は有効のままにしてください。コピーされたキーは別のアドレスからは使えず、短期間で失効します。

よくある質問

OpenCode CLI に保存したキーも今回の侵入で流出しましたか？

いいえ。OpenCode によると、侵入の対象は OpenCode Console に限られます。ローカル CLI やデスクトップアプリに追加したキーはユーザーのマシンに保存され、OpenCode に送信されることはありません。

ホスト型ツールからプロバイダーキーを削除すれば失効しますか？

いいえ。ツールから削除されるのは、そのツールが持つコピーだけです。プロバイダーのダッシュボードで失効させ、新しいキーを作成するまでは、プロバイダー側で引き続き使えます。

ゲートウェイの利用上限で、流出したプロバイダーキーを保護できますか？

いいえ。ゲートウェイの上限が集計するのは、ゲートウェイを通ったリクエストだけです。流出したプロバイダーキーはプロバイダーに直接送るリクエストに使われるため、適用されるのはプロバイダー自身の利用上限です。

関連：信頼済み IP、BYOK 保管庫、管理者キーとキーの上限、OpenCode の設定。

出典の確認日：2026 年 10 月 21 日。報道で引用された OpenCode の投稿とメール、プロバイダーの担当者の投稿、本文中でリンクしたプロバイダーのドキュメントを参照しました。偽装ヘッダーの検証は、2026 年 10 月 21 日に Synthorai の本番ゲートウェイに対して実施しました。

← ブログに戻る