METR、外部による不正アクセス事案と評価におけるハッキングの事実なしを報告

本稿では、外部のアクターが METR のシステムへの不正アクセスを試みた事例に焦点を当てています。評価プロセス内で AI エージェントがハッキングを行ったという事案ではありません。現時点で、評価中に第三者に対するハッキング行為が行われた証拠は見つかっていません。詳細な更新情報は近日公開いたします。

今年前半、METR では 2 つの注目すべきセキュリティインシデントが発生しました。セキュリティコンサルタントと連携して徹底的に調査した結果、いずれの事案でも機密情報が流出したとは考えられません。それでもなお、実際の現場でどのような事態が起き得るか、そしてそれに対して私たちが采取了した対策について共有することは有益だと考えています。

2026 年 3 月には攻撃者が推論用の API キーを盗み出し、多額のクレジットを不正利用しました。同年 5 月には、攻撃者が公開インフラを体系的に探る動きが観測されました。その中には、誤って公開されたエンドポイントを通じて内部データへのアクセスを試みるも失敗したケースも含まれています。これらの事案は直接的な被害は限定的でしたが、我々は「ニアミス」と捉え、セキュリティ投資の強化に対応しました。

セキュリティへの取り組みについて

METR の中核業務には非公開モデルへのアクセスや機密情報の取り扱いが含まれるため、重要なデータを扱うにふさわしいセキュリティ体制を構築し、投資を行ってきました。これまでのセキュリティ対策の詳細は当社のブログで解説しており、SOC 2 Type I 認証取得にも貢献しています。

METR のセキュリティに関する基本的な組織原則は以下の通りです。

強力な認証要件を備えた集中型アイデンティティ管理、

厳格なネットワーク分離、

最小限の権限スコーピング（機密情報へのアクセス制限を含む）、

およびプラットフォーム全体にわたる攻撃や侵害の兆候の監視です。

当社は主に 4 つのカテゴリに分類される企業データを扱っています。これらは、最も低リスクから最も高リスクへと順に並べられています。

1. Published（公開データ）：外部に公開するデータ（例：公開された議事録や評価結果）
2. Generic model access（一般モデルアクセス用データ）：公開モデルのみを対象とした未公開の評価結果や情報（例：過去のモデルに基づいた時間予測の最新バージョン「TH1.1」）、または公開モデルからの出力（例：エージェントの会話記録）
3. Credentials（認証情報）：公開モデルへのアクセス権を与える API キー
4. Sensitive model access（機密モデルアクセス用データ）：非公開モデルからの評価結果や出力、あるいは内部思考連鎖（Chain-of-Thought: CoT）が含まれるデータ
5. Credentials（認証情報）：内部思考連鎖（CoT）、非公開モデル、または本番環境での安全対策が施されていないモデルへのアクセス権を与える API キー
6. Highly sensitive information（極めて機密性の高い情報）：アーキテクチャやトレーニングプロセス、リリース日、社内インシデントなどに関する知的財産や事業情報。

当社のセキュリティプロトコルは、機密データ（カテゴリ 3 と 4）を情報バリアの背後で厳重に管理しつつ、研究者が比較的リスクの低いデータ（カテゴリ 1 と 2）を取り扱う際の負担を最小限に抑えるよう設計されています。

当社の調査範囲内では、今回のインシデントによりカテゴリ 3 または 4 のデータがアクセスされた事実は確認されていません。ただし、機密性の高いモデル出力データ（3.a）については、原則としてアクセス可能な状態になっていた可能性がありましたが、攻撃者によって実際にアクセスされたとの確証はありません。

インシデント 1：エージェントオーケストレーションダッシュボードにおける公開用 API キーの盗難

概要

2026 年 3 月、機密データへのアクセス権限を持たない研究者（カテゴリ 3 および 4 のデータや認証情報のアクセス権なし）が、Google 認証を背後に置いた個人所有の EC2 インスタンス上でエージェントを実行していました。このインスタンスは意図的に公開設定されており、METR の一般利用（公開モデル用）アカウントの API キーが格納されていました。

この「Vibe-coded」アプリには、認証機能を無効化する脆弱性（fail-open 型）が存在し、結果としてシステムが数日間、公衆インターネットに対して露出する事態となりました。

当社の分析によると、攻撃者はおそらく、LLM やエージェントに関連する高シグナルキーワードを持つ Vibe-coded サイトを特定するために、最近登録されたウェブサイト（Certificate Transparency リストなど）を検索した上で、露出した可能性のあるモデルプロバイダーの API キーを収集しようとしたものと推測されます。

攻撃者が展開されたシステムに到達すると、エージェントに対して直接モデルプロバイダーの API キーの開示を要求し、永続的なアクセス用の SSH キーを追加しました。その後3週間にわたり、盗まれた認証情報を用いて公開利用可能なモデルに対して大量の API クレジットを消費しました。これらのクレジットは約60万ドル相当でしたが、モデル開発元がMETRに無償で提供していたものです。

なぜ私たちはこのような大規模な不正使用に気づかなかったのでしょうか？

私たちは、膨大な量のトークンを使用する評価や実験の実行には慣れています。特に、展開前のモデルを用いた大規模評価では、多くの奇妙なレート制限エラーやAPIエラーが発生することに非常に慣れており、その多くは誤報であり、実際の大量利用を反映しているわけではありません。

今回のインシデント当時、内部の使用状況ダッシュボードでは、すべてのユーザーに対するレート制限されたリクエストのデータが表示されていませんでした。発生していたとしてもです。

これらのトークンに対して私たちが支払っていたわけではないため、自然なトークン使用額の上限が存在せず、またインシデント時点では、このようなキーに対して支出制限を設ける方法もありませんでした。

モデル利用量の急増が評価の一環ではないことを確認した後、侵害された個人インスタンスがその発生源であると特定しました。直ちに当該研究者のアクセス権限をすべて無効化し、インスタンスの停止とイメージ取得を実施、現在有効なすべての認証情報をローテーション（更新）するとともに、使用していたラップトップのイメージ取得と完全消去を行いました。関連するパートナー企業である AI 企業へも速やかに通知し、インシデント対応の進捗を随時共有しています。

セキュリティコンサルタント（カリフォルニア州の専門機関）が当社の調査結果を検証し、独自の侵害範囲評価を実施しました。また、手動およびエージェント支援によるフォレンジック分析を行い、インシデントの全容を把握するとともに、盗まれた API キー以外に侵害は及んでいないことを確認しました。

今回のインシデントを受け、以下の対応を行いました：

• METR の従業員および契約者全員に適用されるセキュリティポリシーを明確化・拡充し、特に METR の認証情報やデータを METR 以外のインフラやデバイスへ持ち込むことに関する規定を強化しました。
• 研究者が公開アプリケーションを展開する際のセキュリティ審査プロセスを正式に確立しました。
• モニタリングの範囲を拡大するとともに、「ノイズ」となるアラートを排除する取り組みを進めました。
• 可能な限り、キーに対して支出制限アラートを追加設定しました。

インシデント2：攻撃者が内部データを探索

概要

2026 年 5 月初め、METR は持続的な外部攻撃キャンペーンの標的となりました。当社は、金銭目的で活動しているハッカーが、最先端モデルへのアクセス権を奪おうとしている可能性があると警告を受けました。攻撃者はエージェントを多用して脆弱性の発見を自動化し、認証プロバイダーに対するクレデンシャルスタッフィング（パスワードリスト攻撃）、OAuth トークンの付与試行、新規デプロイされたサービスのスキャン、そして社員のフィッシングなど、体系的に公開インフラをプローブしている様子が確認されました。

同じ時期、当社は誤ってパブリックなトランスクリプトビューアーを通じて、読み取り専用の SQL クエリメカニズムを露呈させてしまいました。デフォルトではクエリのスコープは公開データに限定されていましたが、バグを悪用することで未公開の評価データへのアクセスが可能となる脆弱性が存在しました。このデータベースには本来、非機密モデルからのデータのみ（上記の「カテゴリ 2」）が含まれるはずでした。しかし、実際には一部の機密モデルデータ（上記の「カテゴリ 3」）が誤って含まれていました。

この問題は、独立したセキュリティ研究者によって発見され、責任ある開示を受けたことで判明しました。当社は即座に API をオフラインにし、バウンティを支払いました。

攻撃者は広範なキャンペーンの一環としてこのエンドポイントをスキャンしていましたが、証拠からは彼らがこの脆弱性を悪用する手法を発見した形跡や、非公開データへのアクセスがあった形跡は確認されていません。2

対応

警告を受け取った後、攻撃の範囲を特定するまで、ほぼすべての対外サービスと機密データへの内部アクセスを停止しました。

現在、対外アプリケーション用の公開生産環境は、社内インフラからアーキテクチャ的に分離された孤立した環境として維持しています。これにより、公開サービスの設定ミスが内部データの漏洩につながることを防いでいます。

追加のレッドチーム演習をカリフォルニア州のセキュリティ企業に依頼しました。

今後のセキュリティプロセスの変更点

上記では、特定のインシデントから得た教訓に基づいて実施した変更をまとめました。

さらに、継続的な外部サイバーセキュリティパートナーとの連携を含め、セキュリティインフラ、プロトコル、レビュープロセスの改善を行いました。

• セキュリティ責任者を採用し、フルタイムのセキュリティエンジニアの雇用などを通じて、セキュリティスタッフの拡大を計画中です。カリフォルニア州の企業からのサポートも強化しました。
• 攻撃対象領域を不必要に拡大していたレガシーインフラを停止しました。
• インフラ全体における改善が必要な領域を特定するため、定期的な脅威モデリングレビューを実施しています。
• データベースクエリ、API 利用状況、その他のログソースなど、ロギングのカバレッジを大幅に増やしました。
• 異常な API キーの使用を検知するための監視体制を整備し、他のシステムでも不審な行動の検出に向けた仕組みを構築中です。

このほかにも、エンドポイントおよびサーバーセキュリティソフトウェアの追加導入、認証情報の有効期間の短縮、各種権限スコープの縮小など、多岐にわたる改善を行いました。

当社は、事業の進展とリスク環境の変化に応じて、セキュリティへの投資を継続してまいります。

上記の対策は 2026 年 7 月 30 日時点での正確な情報であり、今後変更される可能性があります。

本投稿は公開前に、当社が連携している複数の AI 企業へ共有され、フィードバックに基づき一部の表現を微調整しています。

この分類体系は簡略化されたものです。実際には、顧客確認（KYC）や利用ポリシーの制限があるモデル、あるいは METR 向けに特別な設定が有効になっているモデルなど、機密性の程度に応じた重要な段階区分が存在します。本ブログ記事では「ZDR が有効化されたそれ以外の公開モデル」をカテゴリ 2 と分類していますが、セキュリティ対策が無効な場合や政府によるアクセス制限がある場合はカテゴリ 3 に該当します。↩

機密トランスクリプトにアクセスするためには、攻撃者は脆弱性を発見・悪用した上で、エラーメッセージを引き起こすことなく機密トランスクリプトを特定しダウンロードする必要がありました。これは極めて unlikely（可能性が低い）と判断しています。↩

問題のアクセスは、当社が攻撃を検知する以前に発生しました。当社は初期段階で脆弱なエンドポイントを停止しましたが、数日後に脆弱性の存在に気づかずに再度稼働させました。しかし、攻撃者はその後再びアクセスを試みていません。↩