AIコーディングツール OpenCode が運営する Console の古いシステムが破られ、利用者が預けていた OpenAI、Anthropic、Google の APIキーが盗まれたと、TechCrunch（10月19日）と SecureWorld（10月20日）が報じている。報道によれば、影響を受けたのは利用者の1.4%で、盗まれたキーは蒸留（他社モデルの出力を集めて自前のモデルを訓練すること）が目的とみられる大量の呼び出しに使われた。1,000ドルを超える請求が出た利用者もいるという。OpenCode 自身の一次の発表には、まだ当たれていない。以下の数字はどれも報道によるものである。
この件で問われているのは、侵入の手口よりも鍵の性質である。プロバイダーの APIキーは、持っている人なら誰でも使える。期限も持ち主もない。そうした鍵を1か所に集めておくと、その1か所が破られただけで、3社のアカウントに他人名義の請求がたまっていく。
何が漏れたと報じられているか
報道によれば、破られたのは OpenCode の本体ではなく、Console の古いシステムである。利用者はここに、自分の OpenAI、Anthropic、Google のキーを登録していた。OpenCode 共同創業者の Dax Raad は、本体の作りについて次のように説明したと伝えられている。
those keys never come to us
訳: （OpenCode 本体では）そのキーは私たちのところには来ない
つまり、ふだん利用者の手元で動くツールはキーを OpenCode 側に送らない。ところが、キーを預かる設計になっていた古い Console だけは例外だった。新しい作りが安全でも、古い経路に1か所でも保管場所が残っていれば、そこが全体の弱点になる。今回の件はそれを示している。
Raad は調査の途中の出来事にも触れている。攻撃に使われたコードを AI に解析させようとしたところ、安全フィルターに断られたという。
that was a bit frustrating
訳: あれは少しもどかしかった（調査のためにAIへ攻撃コードの解析を頼んだら、安全フィルターに断られたことについて）
防御側が調査のためにモデルを使おうとしても、攻撃コードの解析は拒否されうる。サイバー能力をどこまで開放するかについて、各ラボは審査制のプログラムを広げているが、事故が起きたその場で調査する小さな開発元にまでは届いていなかったことになる。
盗んだキーで侵入はしない。他人の名義で呼び出すだけでよい
セキュリティ企業の専門家は、この構造を次のように指摘している。Noma Security の Chris Hughes は、キーを集めて預かる仕組みそのものを問題にする。
The platform becomes a single point of failure, where one compromise exposes access to several frontier providers at once.
訳: プラットフォームが単一障害点になり、1か所破られるだけで複数のフロンティアモデル事業者へのアクセスがまとめて漏れる。
1つのツールが3社分のキーを預かっていれば、攻撃者は1回の侵入で3社のアカウントにまとめて手が届く。プロバイダーの側がいくら認証や監視を固めても、鍵がツール側で漏れてしまえば役に立たない。
Cequence Security の Shreyans Mehta は、盗まれたキーがどう使われるかを説明している。
A stolen model key isn't used to break in. Its value is running large volumes of valid requests on someone else's account.
訳: 盗まれたモデルのキーは侵入には使われない。価値は、他人のアカウントで正規のリクエストを大量に流せることにある。
キーは本人確認の代わりになっているので、盗まれたキーからのリクエストも、プロバイダーから見れば正規の利用者からのものに見える。蒸留のための大量の呼び出しは、攻撃者にとっては無料の訓練データになり、請求は利用者のアカウントに回る。1,000ドルを超えたという請求額は、この非対称を数字で示している。
蒸留への対策を強めているラボもある。Anthropic は10月12日の研究ページで、蒸留を狙うアカウントを分類器で止めていると書き、拒否した要求にも9月24日から課金していると明らかにした。対策としては筋が通っている。ただ、盗まれたキーで蒸留の要求が流された場合、止められた分の料金もキーの持ち主である被害者に請求されうる。今回の請求にそうした分が含まれていたかどうかは、報道からは分からない。
止める手段は、各社での失効しかなかった
報道によれば、被害を止める手段は、利用者が OpenAI、Anthropic、Google のそれぞれでキーを失効させることしかなかった。OpenCode の側では、すでに外に出たキーを取り消せない。期限がないので、放っておいても鍵は切れない。使える人も特定のツールや端末に結びついていないので、プロバイダーは攻撃者の呼び出しと利用者本人の呼び出しを区別できない。利用者が漏洩に気づいて3社の管理画面を回り終えるまで、請求は増え続ける。
エージェントに長時間の作業をさせる使い方が広がり、1つの開発環境が複数社のモデルを切り替えて使うのは当たり前になった。ハーネスや ADE に鍵をまとめて渡すのは便利だが、その便利さは、鍵が持参人型のまま中継点に集まることと引き換えになっている。SecureWorld は、こうしたキーが誰にも管理されていない状態を問題にしている。
この件から言える教訓は3つある。1つ目に、ツールにキーを預けるなら、使える範囲と期限を絞った専用のキーを発行すること。2つ目に、プロバイダーごとに利用の上限と異常な利用の通知を設定しておくこと。3つ目に、古い管理画面や移行前のシステムに鍵が残っていないかを確かめること。今回は、それらがないまま古いシステム1か所が破られ、3社の請求書に他人の利用が載ったと報じられている。OpenCode が影響を受けた利用者に請求をどう扱うか、プロバイダーの側が不正な請求を取り消すかは、まだ分かっていない。
