AIの能力評価で知られる非営利組織METRが、2026年に起きた2件のセキュリティインシデントを公表しました。1件目は研究者の個人環境から流出したAPIキーが3週間にわたって悪用されたもので、消費されたクレジットは商用価値にして約60万ドル（約9,300万円）に達します。もう1件は、外部の攻撃者が公開インフラを執拗に探った事案です。いずれも機密情報へのアクセスは確認されていないとしています。

※1ドル155円換算（2026年9月4日時点）

発端は研究者が個人で立てた「作らせただけ」のアプリ

きっかけは2026年3月にさかのぼります。機密級のアクセス権を持たない研究者が、自分の個人アカウントで用意したAmazon EC2インスタンス上でエージェントを動かしていました。社外の人にも見せる前提で、Google認証をかけたうえで意図的に公開していた環境です。このインスタンスには、公開モデル向けのAPIキーが置かれていました。

問題は、そのアプリがAIに書かせたコード、いわゆるバイブコーディングで組まれていた点にあります。認証処理に、失敗したときに拒否ではなく通過させてしまうフェイルオープンの欠陥が潜んでいました。しかも認証が黙って無効になるため、誰も異常に気づきません。結果として、この環境は数日間インターネットに対して素通し状態になりました。

METRは、攻撃者が証明書の透明性ログをたどって最近登録されたドメインを洗い出し、その中から言語モデルやエージェントに関係しそうな語を含むサイトを探していたと見ています。狙いは、そうしたサイトに置かれたモデルプロバイダーのAPIキーです。個人が試しに立てた開発環境が、キーの在庫置き場として狙われているという構図です。

侵入後の手口も現代的でした。攻撃者は稼働中のエージェントに直接プロンプトを与え、自分が保持しているAPIキーを喋らせています。さらにSSH鍵を追加して居座り、その資格情報で3週間にわたり大量のトークンを消費しました。

3週間も気づけなかった理由

評価を専門にする組織が、なぜこれほど長く見逃したのか。METRは3つの事情を挙げています。

1つ目は、大量のトークンを使うこと自体が日常だったことです。公開前のモデルを対象に大規模な評価を回していれば、レート制限やAPIエラーは頻繁に飛んできます。その多くは実際の使用量を反映しない見せかけのエラーで、チームはそれに慣れきっていました。

2つ目は、当時の内部ダッシュボードが、レート制限を受けたリクエストを全ユーザー分は表示していなかったことです。異常の兆候が可視化される場所になかったわけです。

3つ目が、もっとも効きました。このクレジットはモデル開発元がMETRに無償で提供したもので、支払いが発生しません。請求額という分かりやすい歯止めがないうえに、当時はこの種のキーに支出上限を設定する手段もありませんでした。約60万ドルという数字は、あくまで商用価値に換算した場合の規模であって、METRが実際に失った金額ではありません。ただ、無償枠だからこそ誰も金額を見ていなかったという事実は残ります。

5月には外部からの本格的な攻撃キャンペーン

2件目は同じ年の5月です。METRは、金銭目的とみられる攻撃者に狙われているという情報提供を受けました。攻撃者の関心は、フロンティアモデルへのアクセス権にあったとみられています。

その手口は、公開インフラへの網羅的な探索でした。認証プロバイダーへのクレデンシャルスタッフィング、OAuthトークンの取得試行、新しく立ち上がったサービスのスキャン、職員へのフィッシングまで、脆弱性の発見作業の大部分をエージェントに自動化させていた点が特徴です。

厄介なことに、同じ時期にMETR側も穴を開けていました。公開しているトランスクリプト閲覧機能に、読み取り専用のSQL問い合わせ機構が意図せず露出していたのです。既定では公開データだけを対象にする設計でしたが、バグを突けば未公開の評価データにも手が届きました。しかもこのデータベースには、本来入れるはずのない機微なモデルのデータが手違いで混ざっていました。

この欠陥は、外部のセキュリティ研究者が発見して責任ある開示を行っています。METRはAPIを停止して報奨金を支払いました。攻撃者はこのエンドポイントを通りすがりに探ってはいたものの、バグの存在に気づいた形跡も、非公開データに触れた形跡もないとしています。

公開環境と内部を切り離し、専任のセキュリティ人員を置く

2件を受けて、METRは体制を組み直しています。まず、METRの資格情報やデータを社外のインフラや端末に置くことについて、全従業員と契約者に適用される規程を明確化しました。研究者がアプリケーションを公開する際には、正式なセキュリティレビューを通す手順も新設しています。監視範囲を広げる一方で、無視されがちなノイズ警報を減らす作業も進めました。キーには可能な範囲で利用額のアラートを追加しています。

構成面では、公開向けアプリケーションを内部インフラから構造的に切り離した専用の本番環境で動かす方式に変えました。公開サービス側の設定ミスが内部データの露出につながらないようにするためです。

人の面では、セキュリティリードを採用し、専任のセキュリティエンジニアを含めた増員を計画しています。攻撃対象領域を無駄に広げていたレガシー基盤は停止しました。データベースへの問い合わせやAPI利用のログ取得を強化し、APIキーの異常な使われ方を検知する監視も設けています。資格情報の有効期間を短くし、権限の範囲を絞る作業も並行して進めました。なお、公開された内容は2026年7月30日時点のものだと明記されています。

まとめ

METRの公表で目を引くのは、被害の大きさよりも、見逃しが起きた条件のほうです。大量のAPI利用が常態化した組織では、異常なトークン消費が背景に溶け込みます。支払いが発生しない無償クレジットには、金額という分かりやすい警報も鳴りません。そして最初の入り口は、AIに書かせた個人用の小さなアプリでした。エージェントに与えた鍵は、エージェントに聞けば出てくる。その前提でキーの置き場所と有効期間を見直しておくことが、遠回りに見えて確実な対策になりそうです。