METRのセキュリティインシデントが露呈させた60万ドルのAI認証情報障害

METRは、攻撃者がAPIキーを盗み、約60万ドル相当のモデルクレジットを消費したことを受け、2件のセキュリティインシデントを公表した。最初の攻撃は、異常なトラフィックや繰り返されるレート制限エラーを発生させながらも、3週間にわたって継続していた。

モデル開発元がMETRにクレジットを無償提供していたため、この損失は直接的な請求には至らなかった。この事情は金銭的な影響を抑えた一方で、不正利用を早期に露見させ得た支出上限も取り除いていた。

METRのセキュリティインシデントが重要なのは、単一の研究組織にとどまる話ではない。実験的なエージェントダッシュボードは、クラウドアクセス、有効な認証情報、公開状態、不十分な監視を一つのシステムに組み合わせていた。この組み合わせにより、認証の失敗は、価値の高いコンピューティングリソースへの長期的なアクセスへと発展した。

METRは、調査の結果、攻撃者が最も機密性の高い情報にアクセスした証拠は見つからなかったとしている。しかし、2件目のインシデントは、公開研究ツールが非公開の評価データにどれほど近づいていたかを示した。これらの事例は、低リスクと見なされるプロトタイプには緩いセキュリティ統制でよいという前提に疑問を投げかける。

METRのセキュリティインシデントは公開されたエージェントダッシュボードから始まった

最初のインシデントは一般的な認証障害として始まったが、AIエージェントが公開アクセスから認証情報窃取へ至る経路を提供した。

2026年3月、METRの研究者は個人のAmazon EC2インスタンス上にエージェントを展開した。EC2は、仮想サーバーを借りるためのAmazon Web Servicesのプラットフォームである。研究者は意図的にインスタンスをインターネットからアクセス可能にし、Google認証の背後に配置した。

このアプリケーションには、METRがフェイルオープンの脆弱性と呼ぶ問題が含まれていた。フェイルオープンのシステムは、認証制御に失敗した際、アクセスを拒否するのではなく動作を継続する。このケースでは、障害によって認証が静かに無効化され、ダッシュボードが数日間公開された。

EC2インスタンスには、公開モデル向けのMETRの一般アクセスアカウントに接続されたAPIキーも保存されていた。APIキーとは、ソフトウェアがオンラインサービスへのリクエストを認証するために使用する認証情報である。

METRのセキュリティ開示によると、攻撃者はエージェントにプロンプトを与え、そのモデルプロバイダーのキーを明かさせた。その後、攻撃者はSSHキーをインストールし、侵害されたサーバーへリモートアクセスを継続する手段を作り出した。

この一連の流れは重要だ。攻撃者は最先端モデルの安全対策を突破したり、新しいAIエクスプロイトを開発したりする必要はなかった。最初の侵入口は、安全でない状態で失敗した通常のWebアプリケーション制御だった。

それでも、エージェントは結果に影響を与えた。外部者がインターフェースに到達すると、エージェントはアプリケーションそのものの外部で価値を持つ認証情報にアクセス、あるいはそれを再現できた。侵害されたダッシュボードは、別のモデルプロバイダーアカウントへの橋渡しとなった。

METRは、攻撃者が最近登録されたWebサイトを監視してインスタンスを発見した可能性があると見ている。証明書透明性の記録は、発行されたWeb証明書を公開記録するため、新しいドメインやサブドメインの特定に役立つ。

同組織は、攻撃者が大規模言語モデルやエージェントに関連する語句をこれらの記録から検索したと考えている。こうした語句は、価値のあるプロバイダー認証情報を含む可能性のある実験的サービスを特定できる。

この説明は、公開検証された帰属ではなく、あくまでMETRの評価にとどまる。METRは攻撃者、モデルプロバイダー、正確な発見インフラを特定していない。

認証情報を取得した後、侵入者は3週間にわたりそれを利用した。METRは、消費されたクレジットの価値を約60万ドルと算定しているが、その金額を支払ったわけではない。

インシデントで印象に残る数字は、より広範な失敗の連鎖から注意をそらしかねない。公開状態、エージェントが利用可能な認証情報、永続的なホストアクセス、不完全な利用状況の可視化は、いずれも解消されないまま残っていた。

これらの制御のどれか一つでも、被害を抑えられた可能性がある。認証はアクセスを拒否できた。認証情報の隔離は開示を防げた。ホスト監視は新しいSSHキーを検知できた。プロバイダー側の制限は消費を抑制できた。

この攻撃が成功したのは、これらの防御策が同じ一連の流れを止められなかったためだ。

なぜ3週間にわたるモデルの不正利用が通常の研究活動に見えたのか

METRの通常業務は、攻撃者の活動を隠すのに十分な運用上のノイズを生み出していた。

METRは、大量のトークンを消費し得る実験を通じて高度なAIシステムを評価している。トークンは、モデルが処理または生成するテキストを測定する単位である。大規模な評価実行は、異常なレート制限やプロバイダーエラーを引き起こすこともある。

こうした運用パターンは、一般的なセキュリティシグナルを弱めた。正当なMETRの研究でも似たような挙動が発生し得るため、高い利用量は自動的に悪意あるものとは見なされなかった。

METRによると、インシデント発生時、内部ダッシュボードにはレート制限された各ユーザーのリクエストがすべて表示されていなかった。そのため調査担当者は、侵害されたアカウントに関連する活動を完全には把握できなかった。

組織には、影響を受けたキーに対する自然な支出上限もなかった。モデルプロバイダーがMETRに課金せずクレジットを提供していたため、請求額の増加が即時調査を促すことはなかった。

請求がないからといって、リソースに価値がないわけではない。モデル推論はコンピューティング能力を消費し、その能力へのアクセスは再販されたり、無関係なワークロードに利用されたりする可能性がある。METRが現金支払いを免れたとしても、攻撃者は譲渡可能な経済的利益を得ていた。

報告された時系列を扱った独立系報道も、同じ監視上の欠落を強調している。不正な消費は、高いトークン量と一貫しないレート制限メッセージにすでに慣れた環境に紛れ込んでいた。

これがMETRのセキュリティインシデントにおける中心的な逆説だ。規模は通常、研究グループが高性能モデルを試験する助けとなるが、同じ規模が異常な消費を見分けにくくした。

従来の支出アラートは、盗まれたクラウド認証情報を素早く発見できる場合がある。しかし、無償提供のクレジット、研究用割り当て、前払い済みのキャパシティは、その防御を弱める可能性がある。組織には依然として、利用パターン、リクエスト元、キーの識別情報、想定ワークロードに基づく制限が必要だ。

しきい値では、失敗したリクエストやレート制限されたリクエストも考慮すべきである。これらのリクエストは、標準的な請求合計に現れない場合でも、偵察行為や消費の試行を示す可能性がある。

このインシデントは、生の利用量が不完全な指標である理由を示している。より良い検知システムは、その活動がキーに設定された目的と一致するかを問う。

一つの実験に割り当てられた認証情報が、無関係なトラフィックを何週間も密かに支えるべきではない。アプリケーションごとにキーを分ければ、一つの識別情報に結び付く正当な挙動の数を減らせるため、この比較は容易になる。

短命な認証情報は、攻撃の時間枠をさらに縮小する。期限切れになる、または更新を必要とするキーは、コピーされた値が有用であり続ける期間を制限する。長期間有効なシークレットは、攻撃者に永続化を確立し、アクセスを収益化する時間をより多く与える。

METRは対応として、プロバイダーが対応している場合に支出アラートを追加した。また、監視範囲を拡大し、ノイズの多いアラートの削減にも取り組んだ。

これらの変更は目に見える症状に対処するものだが、より深い教訓はシステム境界に関するものだ。異常な利用が定期的に発生するからといって、研究ワークロードが説明不能な活動を許容可能なものにしてはならない。

通常業務には、測定可能な範囲、責任者の明確化、定義された例外が必要である。そうでなければ、「研究トラフィック」は、正当な実験と不正な消費の両方を隠す広すぎる分類になってしまう。

本当の対立は迅速な実験とアクセスの封じ込めにある

エージェント開発は迅速な展開を促す一方、セキュリティはプロトタイプに欠けがちな厳格な境界に依存する。

METRは、公開されたダッシュボードをvibe-codedと表現しており、主にAI支援のプロンプトと反復的な生成を通じて開発されたことを意味する。この表現は、AIコーディングツールが認証上の欠陥を引き起こしたことを立証するものではない。

重要なのは、完成したアプリケーションがどのようにレビューされ、展開されたかだ。このソフトウェアは公開トラフィックを受け入れ、エージェントと連携し、有効なプロバイダー認証情報の近くで動作していた。こうした条件により、これは使い捨てのローカルプロトタイプ以上のものとなっていた。

迅速な実験は、モデル評価において価値がある。研究者はしばしば、カスタムインターフェース、一時的なオーケストレーションツール、新たなモデルの組み合わせを必要とする。長い承認プロセスは探索的な作業を妨げかねない。

しかし、セキュリティ上の分類は、システムの想定寿命ではなく、そのアクセス権と公開範囲に基づくべきだ。一時的なアプリケーションでも、インターネットから到達可能で再利用可能な認証情報を保持した時点で、本番環境に近いものとなる。

また、エージェントは生のキーを開示できるべきではなかった。アプリケーションが外部サービスを呼び出すには認可が必要なことが多いが、それは再利用可能なシークレットをモデルが読み取れるコンテキストに置くことを意味しない。

認証情報ブローカーであれば、基盤となるキーを公開せずに、エージェントの代理として認可済みリクエストを実行できる。狭く限定された権限により、アプリケーションがアクセスできるモデル、操作、利用量の水準も制限できる。

この分離が重要なのは、言語モデルが信頼できない指示を処理するためだ。エージェントのインターフェースに到達した攻撃者は、モデルに隠されたデータを公開させたり、接続されたツールを悪用させたり、アプリケーションの想定ワークフローを超える行為を実行させたりできる。

OWASPのエージェントセキュリティガイダンスは、機密データの露出、過剰な権限、ツールの悪用、プロンプトインジェクションを関連するリスクとして挙げている。また、権限を制限し、認証情報をエージェントがアクセス可能なコンテキストの外に置くことを推奨している。

METRの開示によれば、攻撃者はエージェントに直接プロンプトを与え、プロバイダーキーを明かさせた。これはプロンプトに基づく認証情報抽出に似ているが、公開情報は正式な分類を行うにはモデルの挙動を十分に詳しく示していない。

ただし、認証上の欠陥が最初の決定的な統制の失敗だった。公開アクセスがなければ、外部者はリクエストを発行するためのインターフェースを持てなかったはずだ。

したがって、この事案を単にプロンプトインジェクション攻撃と呼ぶのは単純化しすぎである。損失に至る経路は、安全でない展開、シークレットの露出、許容的なエージェントアクセス、永続化、不十分な消費監視を組み合わせたものだった。

同様に、vibe codingだけを非難すれば、コードの生成方法にかかわらず適用される既存のセキュリティ慣行を見落とすことになる。人間が書いたプロトタイプでも、フェイルオープン、シークレットの露出、テレメトリーの欠落は起こり得る。

METRにはすでに、本番評価プラットフォーム向けの文書化されたセキュリティ統制があった。同組織が公開したSOC 2レポートには、定義されたそのシステムについて、2025年8月時点で設計された統制が記載されている。

SOC 2 Type Iレポートは、ある時点における統制設計を評価するものだ。個人による実験、一時的なサービス、その後の展開のすべてが同じ統制に従うことを保証するものではない。

この区別こそが、インシデントの中心にある。組織は主要プラットフォームを保護できても、研究者が正式な境界の外側で並行インフラを作成する可能性がある。

個人用クラウドアカウントは、この分断を把握しにくくする。中央のセキュリティチームは、管理対象外の環境で作成されたインスタンスに関するログ、インベントリ、ネットワーク制御、自動化されたポリシー適用を持たない可能性がある。

METRによると、研究者は最も機密性の高い2つのカテゴリにはアクセスできなかった。このため、見かけ上の影響範囲は限定された。しかし、そのインスタンスには攻撃対象となり得るプロバイダーの認証情報が依然として含まれていた。

教訓は、実験を中止すべきだということではない。短期間の研究ツールであっても、インターネットへの公開と実運用の認証情報が存在する場合は、標準的なレビューを自動的に実施すべきだということだ。

2度目の攻撃で評価データも危険にさらされた

5月のキャンペーンは、攻撃者が安価なコンピューティング資源だけでなく、非公開のモデルアクセスや評価データにつながる経路も探っていたことを示した。

2026年5月初旬、METRはハッカーが同組織の公開インフラを標的にしていることを把握した。組織は彼らを金銭的動機を持つ者と評価し、最先端モデルへのアクセスを狙っていた可能性があると述べた。

METRは、認証情報の詰め込み、OAuth権限付与の試行、新たに導入されたサービスのスキャン、職員を狙ったフィッシング試行を含む体系的な探索を確認した。認証情報の詰め込みとは、過去に盗まれたログイン情報の組み合わせを別のサービスで試す手法である。

組織によると、攻撃者は脆弱性の発見を自動化するためにエージェントを多用していた。この主張は、AIによって複数のサービスや認証経路をスキャンする労力が軽減されたことを示唆するが、METRは性能測定値を公表していない。

同じ時期に、METRは公開トランスクリプトビューアを通じて読み取り専用のSQLクエリ機構を意図せず公開していた。SQLは、アプリケーションが構造化データベースから情報を取得するために使う言語である。

クエリは、デフォルトでは公開レコードを返す設計だった。だが、バグによりその範囲が変更され、未公開の評価データが公開される可能性があった。

METRは、基盤となるデータベースには公開モデルに関する結果のみが含まれると想定していた。しかし、一部の機密性の高いモデル出力が誤って含まれていた。

独立したセキュリティ研究者がこの欠陥を発見し、責任ある開示を行った。METRは影響を受けたAPIを停止し、報奨金を支払った。

攻撃者はMETRのインフラをスキャンする過程でこのエンドポイントに接触していた。組織によると、証拠からは、攻撃者が脆弱性を発見した、あるいは非公開情報にアクセスしたことを示す兆候は確認されていない。

この結論には慎重な表現が必要だ。証拠がないことは、アクセスが一度も起きなかったことの数学的な証明にはならない。これは、METRとそのセキュリティコンサルタントが利用可能なログとフォレンジック資料から確認した内容を反映している。

METRは、悪用には複数の具体的な手順が必要だったと説明した。攻撃者はスコープ設定のバグを見つけ、正しく利用し、機密性の高いトランスクリプトを識別し、エラーを発生させずにダウンロードする必要があった。

組織は、この一連の流れが起きる可能性は極めて低いと判断した。また、一時的にエンドポイントを削除した後、バグに気づかないまま復元していたこと、そしてその後の攻撃者アクセスは確認されなかったことも認めた。

この2度目の事案は、盗まれたクレジットとは異なる重大性を持つ。未公開の評価結果は、モデルの弱点、行動パターン、隠された出力、または秘密保持契約の下で提供された情報を明らかにする可能性がある。

METRは情報を大きく4つのカテゴリに分けている。公開済みの資料は最も低いレベルに位置する。公開モデルの認証情報と、未公開の公開モデル結果が次のカテゴリを占める。

上位2つのカテゴリは、機密性の高いモデルアクセスと、極めて機密性の高い組織情報を対象とする。METRによると、調査ではいずれの事案でも、それらのカテゴリの情報へのアクセスは確認されなかった。

それでも、本来含まれるべきではなかった上位カテゴリの資料が、トランスクリプトデータベースには含まれていた。つまり、意図された分類境界は、誰かがクエリ機構を悪用しようとする以前にすでに破綻していた。

ポリシーによるデータ分離だけでは、レコードが誤ったデータベースに入り得る場合には不十分である。実効的な分離には、自動分類チェック、クエリ時のアクセス制御、そして後の調査に備えて証拠を残すログも必要となる。

最初の事案は認証情報の境界を露呈した。2度目の事案はデータの境界を露呈した。いずれも、公開向け研究システムが、想定された役割で正当化される以上に価値あるリソースへ近づいていたことに関係している。

METRの対応はリスクを低減するが、検証上の疑問は残る

METRはアーキテクチャとセキュリティプロセスを変更したが、外部からは、これらの管理策が将来の実験をどこまで一貫してカバーするかをまだ測定できない。

3月の不正利用を検知した後、METRは研究者のアクセスを取り消し、侵害されたインスタンスを停止した。フォレンジックイメージを作成し、認証情報をローテーションし、研究者のノートPCをイメージ化して消去し、関連するモデル企業に通知した。

セキュリティコンサルティング会社CalifはMETRの調査結果をレビューし、別途侵害評価を実施した。METRはこの事案の調査に、手作業とエージェント支援によるフォレンジックも利用した。

組織によると、これらの取り組みでは、単一の公開モデルAPIキー以外の侵害は確認されなかった。コンサルタントによる完全な評価、詳細な侵害指標、またはプロバイダーの身元は公表していない。

METRは、個人所有インフラ上の認証情報とデータを対象とするポリシーを拡充した。また、公開アプリケーションを展開する研究者向けに正式なセキュリティレビューを設けた。

5月のキャンペーン後、METRはほぼすべての公開サービスと、機密データへの内部アクセスを一時的に無効化した。その後、内部インフラからアーキテクチャ上分離された、独立した公開本番環境を構築した。

この分離は、トランスクリプトビューアのリスクに直接対応するものだ。一貫して実施されれば、公開アプリケーションの欠陥が内部データシステムへの経路を提供することはなくなるはずだ。

METRはまた、レガシーインフラを停止し、ログ記録を拡充し、認証情報の有効期間を短縮し、権限スコープを縮小し、エンドポイントとサーバー向けのセキュリティソフトウェアを追加導入した。

組織はセキュリティ責任者を採用し、チームをさらに拡大する計画だと述べた。また、認可されたテスターが攻撃者の行動を模倣して弱点を探す追加のレッドチーム作業も委託した。

これらの措置は、開示された障害モードと整合している。資産管理、封じ込め、認証情報の取り扱い、テレメトリ、説明責任を改善するものだ。

懐疑的に問うべきなのは適用範囲である。研究者が個人のクラウドアカウント、管理されていないサービス、または実験ツールにコピーした認証情報を通じて回避できるなら、ポリシーや集中管理された環境は機能しない。

METRは、この適用範囲に関する測定可能な目標を公表していない。読者には、公開展開の何パーセントが現在レビューを受けているのか、異常なキー使用がどれほど迅速に調査につながるのかは分からない。

どの管理策がモデルプロバイダー層で機能しているのかも明確ではない。支出アラートは役立つが、厳格な利用上限、短命のトークン、より狭いスコープ、自動失効のほうが強力な制限を提供する。

すべてのモデルプロバイダーが同じ管理機能を提供しているわけではない。METRは、3月の事案発生時には、影響を受けたキーに支出上限を設定できなかったと指摘した。

したがって、公開されたアプリケーションをMETRが管理していたとしても、プロバイダーも広範な設計上の問題の一部を担っている。価値の高いモデルアクセスを扱う組織には、キーはいずれ漏洩することを前提としたアカウント機能が必要だ。

開示そのものは評価に値する。METRは詳細な時系列を公表し、複数の内部的な失敗を認め、可能性のある露出と実際のアクセスの証拠を区別した。

ただし、透明性を独立した検証と混同すべきではない。中心的な調査結果は依然としてMETRの調査と、同組織が起用したコンサルタントに基づくものだ。

公開された証拠からは、攻撃者の正体や動機は特定されていない。60万ドルという評価額も、支払済み請求額や独立監査済みの損失ではなく、付与されたクレジットのおおよその価値を示すものだ。

こうした留保は事案を否定するものではない。利用可能な証拠が裏付ける範囲を定め、見出しの数字が事実以上に精密な印象を与えることを防ぐ。

METRの開示後にセキュリティチームが注視すべきこと

次の試金石は、METRの新しい管理策が、目に見える制限、より迅速な検知、そしてより安全な公開研究システムにつながるかどうかである。

最初の指標は、公開展開に関する強制力だ。METRはセキュリティレビューを正式化したが、このポリシーの価値は、インターネットに公開されるすべての実験が管理対象のインベントリに登録されるかどうかにかかっている。

有用な成果には、組織に関連する新しいドメイン、クラウドインスタンス、公開エンドポイントの自動検出が含まれるだろう。セキュリティチームは、そのインベントリを承認済みアプリケーションおよび指定された所有者と照合すべきだ。

将来の研究ツールが一貫して分離された公開環境内で稼働するなら、METRの対応はアーキテクチャ上の境界が改善されたという主張を裏付けるだろう。実運用の認証情報を含む別の個人展開が見つかれば、その結論は弱まる。

2つ目の指標は、測定可能な認証情報の封じ込めだ。METRは可能な範囲で利用状況の監視と支出アラートを追加したが、アラートには依然として解釈と対応が必要となる。

組織は、より短い認証情報の有効期間、アプリケーション固有のキー、限定的なプロバイダー権限、異常な活動後の自動停止を求めるべきだ。生の認証情報は、エージェントのプロンプトコンテキストおよび出力チャネルからアクセスできない状態に保つ必要がある。

OWASPによるprompt injection risksの解説は、モデルへの指示だけでは秘密を守れない理由を示している。攻撃者は、公開されたモデルを操作して意図された制限を無視させたり、そのコンテキスト内で利用可能な情報を明かさせたりできる。

METRまたはそのプロバイダーが仲介型アクセスと厳格な消費上限を導入すれば、同様のインターフェース侵害による損失はより小さくなるはずだ。管理策が主にアラートベースのままであれば、攻撃者は人間がパターンを認識するまで活動を続けられる可能性がある。

3つ目の指標は、データ分離に関する証拠だ。METRは新しい公開環境がアーキテクチャ上分離されていると述べているが、5月の問題には、機密レコードが誤ったデータベースに置かれていたことも含まれていた。

ネットワーク分離だけでは、誤分類された情報を是正できない。METRには、制限対象の評価データが公開向けストレージに入る前に検出する保護策が必要だ。

今後の開示、監査、技術更新では、これらの管理策が直接アクセスと偶発的なデータ配置の両方を防ぐかどうかが示されるべきである。外部によるクリーンな評価があれば、改訂された境界に対する信頼は高まる。

METRのセキュリティ事案は、AI企業に対して、評価アクセスの提供方法を見直す理由も与える。外部評価者には現実的なモデル能力が必要だが、広範で長期間有効な認証情報は魅力的な標的を生む。

プロバイダーは、スコープを限定したトークン、プロジェクトごとの上限、オリジン制限、迅速な失効、拒否されたリクエストの可視化によって、このリスクを減らせる。こうした機能は、プロバイダーと評価者の双方を保護する。

開発者は、より小規模なエージェントプロジェクトにも同じ考え方を適用すべきだ。メール、ソースコード、クラウドサービス、または社内文書に到達できるプロトタイプには、すでに意味のあるセキュリティ境界が存在する。

こうした実験を記録するチームは、制御されたknowledge baseを利用して、脅威モデル、展開の所有者、レビュー判断、インシデントから得た教訓を保存できる。文書化は技術的な管理策の代わりにはならないが、管理されていない例外を見つけやすくすることはできる。

最も有用な問いは、アプリケーションがvibe-codedかどうかではない。信頼できないユーザーが到達できるか、どの認証情報にアクセスできるか、そしてすべての指示を敵対的なものとして扱ったときに何が起きるかである。

METRの開示は、まれに見る具体的な答えを示している。公開認証の失敗がエージェントに到達し、エージェントが認証情報を露出させ、不完全な監視によって3週間にわたる不正利用が許された。

セキュリティリーダーは今、自組織のシステム内で同じ連鎖をテストすべきだ。外部者はインターフェースを発見できるか。モデルは秘密を明かせるか。ホストは永続的なアクセスを受け入れられるか。異常な消費は想定されるトラフィックに紛れ込めるか。

いずれかの答えが「はい」であれば、現時点でインシデントが発生していないのは封じ込めの成果ではなく、単にタイミングの問題を反映しているにすぎない。次回のMETR更新では、新しいアーキテクチャが苦労して得た教訓を強制可能な制限へと転換できたかどうかが示されるはずだ。