エージェントに預けた鍵が、他人のAI学習に流用されていた──OpenCodeのコンソールから、Anthropic・OpenAI・Googleの鍵が漏れた
ターミナル型コーディングエージェント OpenCode が、クラウド版 Console で不正アクセスを公表。外部連携した約1.4%の利用者の OpenAI・Anthropic・Google の API キーが漏れた可能性があり、一部は数百ドルの不正請求も。鍵の再発行・上限設定・保管設計を事故前の運用習慣に。
ターミナル常駐型のコーディングエージェント「OpenCode」(開発元 Anomaly Innovations)が、10月17日、クラウド版「Console」で不正アクセスが起き、利用者が預けていた外部プロバイダーの API キーが漏れた可能性があると公表しました。対象は Console 利用者のうち外部キーを連携していた約1.4%で、漏れた可能性があるのは OpenAI・Anthropic・Google のキーです。すでに一部の利用者が、身に覚えのない数百ドル規模の請求を報告しています。OpenCode は先日「2.0」で背景実行やコードモードを打ち出したばかりで、勢いのある側で起きた足元の事故という位置づけになります。
廃止予定だった「旧システム」が入口になった
OpenCode の説明によると、侵入が起きたのはすでに停止準備中だったレガシーなシステムで、そこに保管されていた利用者ワークスペースの API キーが引き出されたとされます。重要なのは、今回漏れたのが Console(ホスト型のダッシュボード)側に預けられていたキーであり、手元で動くエージェント本体とは切り分けられている点です。裏返せば、便利さのために鍵を一か所に集めて預ける仕組みそのものが、攻撃面を太らせていたことになります。
OpenCode は通知メールを10月17日に送付し、公式には「メールが届かなければ対象外」としています。対応は Anthropic・OpenAI・Google と連携して進めているものの、記事公開時点で事案は継続中とされ、初期侵入の詳しい手口は明らかになっていません。断定を避けるべき段階です。
狙いは「安い模倣モデルの教材」だったとみられる
OpenCode はこの件を大規模な「蒸留(distillation)」攻撃に関連づけています。蒸留とは、高性能なモデルの応答を大量に集め、その出力を教材にして安価な競合モデルを育てる手法です。盗んだキーがあれば、高価なフロンティアモデルへの問い合わせを被害者の財布で回せるため、攻撃者は計算コストを負わずに学習用データを収穫できます。利用者側で請求が急増したのは、この「他人名義の大量クエリ」が原因とみられます。ただし、漏れたキーが実際にその用途に使われたかまでは確認されておらず、攻撃の帰属も現時点では推定の域を出ないと報じられています。
鍵を回し、上限を設け、「開けっ放しの請求」を閉じる
影響の有無にかかわらず、キーの再発行は無料で、やっておいて損はありません。各報道が挙げる対処を手順として整理します。
- プロバイダーの管理画面から直接、鍵を失効・再発行する。メール内のリンクは踏まない(フィッシングの恐れ)。OpenAI・Anthropic・Google それぞれのダッシュボードで操作します。
- 10月16〜17日以降の利用ログと請求を確認し、不審なクエリがないか点検する。
- キー単位の上限(スペンディングキャップ)を設定する。各社とも予算上限に対応しており、「盗まれても青天井にはならない」状態を先に作っておく。
- 古い鍵を参照している箇所を更新する。CI/CD、
.env、チーム設定、他ツールまで洗い出す。 - 不正請求があれば、時刻付きで課金異議を申し立てる。
ある解説記事は「キー単位・クレジット単位の上限は、盗まれた鍵を青天井の請求から上限つきの請求へ変える」と述べ、多くの開発者がこの設定を事故が起きるまで後回しにしがちだと指摘しています。
「預けた鍵は、最も手入れの悪いシステムの分だけ安全」
OpenCode のようなエージェントは、ファイルを読み、外部 API を呼び、コマンドを実行するために、利用者の認証情報そのものを握って動きます。キーは便利のための付属品ではなく、動作に不可欠な中核です。OpenCode 自身のドキュメントも「エージェントをサンドボックス化しない」「許可プロンプトは UX であって安全境界ではない」と断っていました。だからこそ、どこに・どう鍵を預けるかの設計が効いてきます。チーム運用で踏める手当ては次のとおりです。
- 鍵を絞る: 共有キーをやめ、開発者・プロジェクト単位で分ける。
- 保管場所を移す: ホスト型ダッシュボードより、管理されたシークレットボールトに寄せる。
- 実行時に注入する: 中央に貯めるより、必要な瞬間に差し込む方が、漏れたときの被害範囲(ブラストラジウス)を小さくできる。
コーディングエージェントに仕事を任せるほど、鍵という「最も価値の高い資産」を預ける相手は増えていきます。今回の件は、その預け先が「最も手入れの悪いシステムの分だけ安全」でしかない、という古くて新しい教訓を、改めて突きつけた形です。利便性を手放す必要はありませんが、鍵の棚卸しと上限設定は、事故の前に済ませておく運用習慣として組み込んでおきたいところです。
参照: Cybersecurity News: OpenCode Security Breach / Crypto Briefing: OpenCode distillation attack / Startup Fortune: urgent key rotation / ExplainX: What to do


