METRがAPIキー窃取とインフラ探索の2件を公表 — 個人EC2の認証無効化で約60万ドル相当のクレジットを消費

AIモデルの能力を科学的に測定する非営利団体METR（Model Evaluation and Threat Research、発音は「Meter」）は2026年8月31日、2026年3月と5月に発生した2件のセキュリティインシデントの詳細を公表した。METRは外部のセキュリティコンサルタントと共同で調査した結果、いずれのインシデントでも機微なモデルへのアクセスや、高度に機微な業務情報（アーキテクチャやリリース時期など）へのアクセスは確認されていないと説明している。一方で、公開モデル向けのAPIキーが窃取されて大量の推論クレジットが消費されたほか、公開インフラが体系的に探索される事態が重なり、METRはこれらを「ニアミス」と位置づけて対策を強化した。

3月のインシデント：個人EC2の認証無効化とAPIキーの窃取

METRによると、1件目は2026年3月に発生した。機微な情報へのアクセス権を持たない研究者が、個人のAmazon EC2インスタンス上でエージェントを動作させていた。このEC2は本来Google認証の背後で公開される想定だったが、研究者がvibe coding（自然言語の指示でAIにコードを生成させる手法）で作成したアプリにfail-openの脆弱性が含まれていた。認証処理が静かに無効化される不具合により、システムは数日間にわたり認証なしでインターネットに露出した。

METRの分析では、攻撃者は最近登録されたウェブサイトを証明書透明性ログ（Certificate Transparency）などから探索し、LLMやエージェントに関連するキーワードを含むvibe-codedサイトを狙ってAPIキーを収集しようとしていたとみられる。攻撃者は公開されたシステムを発見すると、エージェントに直接プロンプトを送ってモデルプロバイダーのAPIキーを引き出し、SSH鍵を追加して永続的なアクセスを確保した。その後3週間にわたり、盗んだ認証情報を使って公開モデルで大量の推論を実行し、消費したクレジットは約60万ドル相当に上った。METRは、このクレジットはモデル開発元から無償で提供されたものだったと説明している。

なぜ大量の不正利用に気づくのが遅れたのか。METRは、大規模な評価実験で日常的に大量のトークンを消費し、レート制限やAPIエラーが頻発することに慣れていたためだと説明している。当時の内部利用ダッシュボードは、レート制限されたリクエストを全利用者分で可視化できておらず、無償提供のキーには利用上限を設定する手段もなかった。

METRが不正利用の急増を評価実験ではないと判断した後、同団体は研究者のアクセスを直ちに停止し、EC2インスタンスを停止してフォレンジック用のイメージを取得し、存在した全ての認証情報をローテーションした。研究者のノートPCもイメージ取得後に初期化した。METRは関係するパートナーAI企業へ通知を続け、セキュリティコンサルタントのCalifが調査結果を検証し、独自の侵害評価を実施した。手動とエージェント支援のフォレンジックにより、単一のAPIキー窃取を超える侵害はないと確認したという。

このインシデントを受けてMETRが実施した対策は次のとおりだと同団体は公表している。

• 全従業員と契約者に適用されるセキュリティポリシーを明確化・拡張し、METRの認証情報やデータを非METRのインフラや端末に置かないルールを徹底した。
• 研究者がアプリケーションを公開する際のセキュリティレビュープロセスを正式に整備した。
• 監視範囲を拡大し、誤検知のノイズを削減した。
• 可能なキーには利用量のアラートと上限を設定した。

5月のインシデント：公開インフラへの体系的な探索

2件目は2026年5月上旬に発生した。METRは、経済的動機を持つとみられるハッカー集団から標的にされているとの情報提供を受けた。攻撃者は公開されたインフラを体系的に探索し、認証プロバイダーへの認証情報詰め込み（クレデンシャルスタッフィング）、OAuthトークン発行の試行、新規デプロイされたサービスのスキャン、職員へのフィッシングなどをエージェントで自動化して実行した。

同じ時期に、METRは別の問題を抱えていた。公開トランスクリプト閲覧機能を通じて、読み取り専用のSQLクエリ機構を誤って露出していたのだ。この機構は既定では公開データのみを対象とする設計だったが、バグを悪用すると未公開の評価データへアクセスできる状態になっていた。本来このデータベースは機微でないモデル（公開モデル）のデータのみを含む想定だったが、実際には一部の機微なモデルデータ（非公開モデルや隠された思考過程を含む評価結果）も誤って含まれていた。

METRは、この脆弱性を独立したセキュリティ研究者が責任ある開示で報告したことで把握し、APIを直ちにオフライン化して報奨金を支払った。攻撃者はこのエンドポイントも探索の一環で軽く触れていたが、脆弱性を発見して悪用したり、非公開データにアクセスしたりした痕跡はないとMETRは判断している。

機微なトランスクリプトへアクセスするには、攻撃者がバグを発見して悪用し、エラーメッセージを出さずに機微なデータを特定してダウンロードする必要があり、極めて可能性は低いとMETRは説明している。

情報提供を受けた後、METRはほぼ全ての公開サービスと、機微なデータへの内部アクセスを一時的に停止し、攻撃の範囲を特定した。その後、公開アプリケーション用の本番環境を内部インフラからアーキテクチャ上分離し、公開サービスの構成ミスが内部データを露出させない設計に切り替えた。追加のレッドチーミングもCalifに依頼した。

METRが示す今後のセキュリティ強化

METRは、上記2件の教訓に加え、全体的なセキュリティ態勢を次のように強化したと説明している（2026年7月30日時点の内容）。

• セキュリティ責任者を新たに採用し、専任のセキュリティエンジニアの採用も計画する。Califからの支援も拡充した。
• 攻撃面を広げていたレガシーインフラを停止した。
• インフラ全体で定期的な脅威モデリングレビューを実施する。
• データベースクエリやAPI利用などでのログ取得範囲を拡大し、APIキーの異常利用などを監視する仕組みを整備した。
• エンドポイントとサーバーの保護ソフトの追加導入、認証情報の有効期間短縮、権限範囲の縮小なども進めた。

METRは、公開モデル向けの一般的なアクセス（評価結果や公開モデルの出力、公開モデル用APIキー）、機微なモデルアクセス（非公開モデルや隠された思考過程を含む評価結果とそのAPIキー）、高度に機微な業務情報という4段階でデータを分類し、機微なデータほど情報隔離（information barriers）で厳格に管理する方針を改めて示した。今回の2件では、最も機微な2つのカテゴリー（機微なモデルアクセスと高度に機微な業務情報）へのアクセスは確認されていないとしている。

日本の組織が学ぶべき点

METRの事例は、日本企業でも広がる「vibe coding」やエージェントの個人環境での利用が、組織の境界を越えて認証情報を露出させるリスクを示している。証明書透明性ログを悪用してAI関連サイトを自動探索する手口は、公開した検証用アプリやデモサイトにも当てはまる。METRが実施したように、公開デプロイ前のレビュー、認証のfail-closed設計、APIキーの利用量監視と上限設定、公開環境と内部環境の分離は、規模を問わず有効な対策だと同団体は示している。

出典：METR「Update on Security at METR」（2026年8月31日）