METRのVibe-Coded Agent Dashboardが自身のログインを無効化し、攻撃者がモデルクレジット60万ドル分を消費した

に2026年3月、何者かが研究者の個人用Amazon EC2インスタンスからMETRのパブリックモデルアカウント用APIキーを取得し、それを3週間にわたって使用した。METR（Model Evaluation and Threat Research）は、AIエージェントが長期タスクでどこまで到達するかを測定する非営利団体で、消費されたクレジットの商業的価値を約$600,000と見積もった。このキーは人間へのフィッシングで盗まれたものではなかった。攻撃者は、研究者がバイブコーディングで作ったダッシュボード上で動作するエージェントにプロンプトで指示し、そのモデルプロバイダーのAPIキーを渡させ、その後、戻ってこられるようSSHキーを追加した。METRはこのインシデントを2026年8月31日に開示し、この記録はアーカイブの高重大度評価とA信頼度評価を備えている。この開示はAIインシデントアーカイブにある1件の記録であり、同アーカイブには完全な記録セット、その情報源、そしてこのシリーズの隣接エントリが収められている。

記録に実際に書かれていること

アーカイブはこれを理論上の脆弱性の開示ではなく、実際に発生したインシデントとして分類している。重大度は高、信頼度はAで、争いはなく、実際の被害が記録され、AIの関与も確認されている。種類タグはCRED、地域は米国、日付は月単位でのみ記録されている — アーカイブは盗難が2026年3月に起きたと把握しており、日までは主張していない。METRも同様である。

この損害にはただし書きが一つ必要であり、METR がそれを示している。クレジットはモデル開発者から METR に無償で付与されたものなので、60万ドルは消費されたものの価値であり、口座から出ていった金ではない。The Register のスタンドファーストも同じ点をより露骨に述べていた。モデル提供者が METR にクレジットを与えたのであり、実際に料金を支払う顧客ならそこまで幸運ではなかっただろう。Infosecurity Magazine も同じ形で、直接的な金銭的損失ではなく商業的価値としてこの数字を報じた。

METRの投稿は1件ではなく2件のインシデントを扱っている。2026年5月のキャンペーンについては、さらに下で別途説明されている。鍵の窃取と3週間にわたる支出は3月の出来事であり、これらが本記事の主題である。

欠陥はログイン側にあり、モデル側ではなかった

機密アクセス権を持たないMETRの研究者が、意図的に公開アクセス可能にされ、Google認証の背後に置かれた個人のEC2インスタンス上でエージェントを実行した。そのインスタンスには、METRの一般アクセスアカウント（公開モデルに使われ、METRが2番目に機密度が低いデータカテゴリとして分類しているもの）のAPIキーが載っていた。それらのエージェントを囲むオーケストレーションアプリはバイブコーディングされており、METRがフェイルオープン脆弱性、認証を黙って無効化するもの

フェイルオープンは訳す価値がある。なぜなら、それは事件の全体を二語で表しているからだ。ログイン確認が誤る方法は二つある。正当なユーザーを拒否するか、確認自体が壊れたときに誰でも通してしまうかだ。フェイルオープンは後者を意味する。認証ステップがエラーになったり省略されたりしたとき、アプリはリクエストを拒否するのではなく許可されたものとして扱った。何の警告もなかった。METRの報告では、結果として、システムが公共インターネット上に数日間、正面玄関を開け放したまま、何かが変わった兆候もない状態で置かれていました。

METRは、オーケストレーションツールやダッシュボードの構築に使われたフレームワークの名を挙げておらず、コードも公開しておらず、認証連携がどのように失敗したのかも明らかにしていない。この投稿が確かに示しているのは、そのバグの根底にあるアーキテクチャ上の誤りだ。すなわち、組織のモデルアカウント用の認証情報が、METRが管理していないインフラ上に、ある研究者が自らデプロイしたアプリケーション内に存在していたということである。

鍵が建物から外へ出た経緯

METRによる攻撃者のアプローチの再構成は、明示的に推測であって発見ではなく、この開示の中で最も興味深い未証明の主張である。投稿によれば、METRは、攻撃者が最近登録されたウェブサイトを閲覧することでインスタンスを見つけたと疑っている——証明書透明性リストが例として挙げられている——。LLMやエージェントのプロジェクトを示すキーワードを帯びたバイブコーディングされたサイトを探し、露出したまま放置されていたモデルプロバイダーのAPIキーを収集するためだった、という。

証明書透明性ログは設計上公開されている。公的に信頼されたサイト向けに発行された証明書はすべて記録されるため、新しいホスト名は公開後数分以内に検索可能なフィードに現れる。そのフィードを、エージェントやモデルという用語を含む名前に絞り込むのは低コストで、対象へのアクセスも不要であり、誰にもレビューされていない可能性がある新規デプロイの一覧を生み出す。これをハンティング手法として読むと、デモを公開するという日常的な行為がシグナルに変わる。

内部に入り込んだ後、攻撃者はファイルシステムから秘密を盗み出す必要はなかった。攻撃者はエージェントに直接働きかけて、モデルプロバイダーのAPIキーを明かさせた。これは少し立ち止まって考える価値のある一文だ。エージェントは認証情報をコンテキスト内に保持しており、説得されればそれを出力しかねなかった。攻撃者はその後、永続的なアクセスを確保するためにSSHキーを追加し、認証の穴を塞いでも追い出されないようにした。そして、公開されているモデル上での推論を3週間にわたって続けた。

モデル開発者の名前は明かされていない。METRによっても、The Register、Dark Reading、Infosecurity Magazine、The Hacker Newsがこの開示を報じた記事によっても明らかにされていない。製品の脆弱性が問題となっていないため、CVEは発行されていない。逮捕、起訴、特定グループへの帰属はいずれも報告されていない。

なぜ3週間の異常な使用状況が正常に見えたのか

METRは当然の疑問にずばり答えており、その答えこそ他の組織が二度読み返すべき部分だ。この非営利団体は大規模な評価を運営しているため、非常に大きなトークン数や、奇妙なレート制限・APIエラーの連続にすっかり慣れており、その多くは誤報だ。モデルへのトラフィックの急増それ自体は、シグナルではなかった。

3つの具体的な欠落が、その親しみを3週間の沈黙に変えた。METRの内部利用ダッシュボードは、レート制限されたリクエストが実際に発生しているときでさえ、全ユーザーにわたるそうしたリクエストのデータを表示していなかった。トークンが無料だったため請求書はなく、したがって発動するはずの自然な支出上限も存在しなかった。そして当時、その種のキーに支出上限を設定する方法はまったく存在しなかった、とMETRは述べている。定価を支払い厳格な上限を設けている組織なら数時間で壁に突き当たっていただろうが、寄付されたクレジットを受け取り上限のない組織には、ぶつかる壁がなかった。

取られなかったものは何ですか

METRのデータ分類は、公開資料から、汎用モデルへのアクセス、機密モデルへのアクセス、さらに高度に機密性の高い事業情報にまで及ぶ。関与した研究者は上位2つのカテゴリーへのアクセス権を持っておらず、METRは、把握している限り、どちらのインシデントの結果としてもそれらのカテゴリーのデータにはアクセスされていないと述べている。

単一の鍵以外については、METRは手作業およびエージェント支援によるフォレンジック調査で侵害は見つからず、同社のセキュリティコンサルタントであるCalifが調査結果を検証し、独自の侵害評価を実施したと述べている。これは意味のある管理策だ——外部企業がアカウントを点検するのであって、それをそのまま受け入れるのではない——しかし、Califを起用し報酬を支払ったMETRから独立しているわけではない。第三者によるこのインシデントの独自のフォレンジックレビューはまだ公表されていない。

METRが気づいたときに行ったこと

投稿に示されている対応の流れは具体的だ。{{1}}METRは、利用量の急増が評価の一部ではなかったことを突き止め{{/1}}、{{2}}それが侵害された個人用インスタンスによるものだと追跡して特定し{{/2}}、{{3}}研究者のアクセス権をすべて剥奪し{{/3}}、{{4}}そのインスタンスを停止してイメージを取得し{{/4}}、{{5}}そこに存在するすべての認証情報をローテーションし{{/5}}、{{6}}研究者のラップトップのイメージを取得してワイプした{{/6}}。クレジットが消費されていたパートナーAI企業に通知し、対応の間その企業に最新情報を提供し続けた。

METRはラップトップのワイプの背後にある理由を説明しておらず、これは一連の流れの中でインスタンス自体へのアクセスを取り消す範囲を超える唯一のステップだ。もっとも妥当な解釈は、同じ研究者が攻撃者の到達し得るワークステーションから認証情報を扱っていたというものであり、その場合はイメージを取得してから再構築するのが、そのマシンについて確実にするための安価な方法である。

その後、何が変わりましたか？

METRはこのインシデントに関連する4つの変更を挙げています：

• 従業員および業務委託先向けのセキュリティポリシーを明確化し、拡充しました。特に、METR の認証情報やデータを、METR が所有していないインフラストラクチャやデバイス上に置くことに関する内容です。

• 正式なセキュリティレビュー手順が、アプリケーションを公開してデプロイするすべての研究者に適用されるようになった。

• 監視の対象範囲を拡大するとともに、対応者にアラートを無視する習慣を植え付けるノイズの多いアラートの排除にも取り組みました。

• プロバイダー側が可能としているキーには利用額アラートが追加された——この留保が重要なのは、この記事の前半で、この種のキーの一部は当時上限を設定できなかったと指摘していたからだ。

この開示では、組織全体にわたる取り組みも列挙されている。セキュリティリードの採用とフルタイムのセキュリティエンジニアの計画、Califの関与の拡大、攻撃対象領域を広げていたレガシーインフラの停止、定期的な脅威モデリングレビューの実施、データベースクエリやAPI利用全体にわたるログ記録の拡張、異常なAPIキー使用の監視、エンドポイントおよびサーバー向けセキュリティソフトウェアの追加導入、認証情報の有効期間の短縮と権限スコープの縮小などだ。METRはこれらの措置を2026年7月30日時点で正確なものだとし、変更される可能性があると述べている。この注意書きは心に留めておく価値がある。というのも、これはこの投稿が窃盗から約4か月後、公開の約1か月前の状況を描写していることを意味するからだ。

同じ投稿にあったもう一つの出来事

METRの情報開示は、鍵の盗難と、2026年5月初旬に起きた2つ目の別個の出来事を並べて示しており、この2つは混同されやすい。その出来事では、METRは、金銭的目的によるものと思われ、フロンティアモデルへのアクセスを狙っていた可能性のある攻撃者から標的にされているとの通報を受けた。METRは、攻撃者が自らの公開インフラを探っているのを観察した。攻撃者はエージェントを多用して脆弱性の発見を自動化し、認証プロバイダーに対するクレデンシャルスタッフィング、OAuthトークン付与の試行、新たにデプロイされたサービスのスキャン、職員へのフィッシングなどを行っていた。

同じ期間中、METR は公開トランスクリプトビューアを通じて、読み取り専用の SQL クエリ機構を意図せず公開してしまった。クエリは既定では公開データに限定されていたが、バグによって未公開の評価データにも向けられ得る状態で、さらに一部の機密性の高いモデル出力が誤ってこのデータベースに読み込まれていた。独立したセキュリティ研究者がこの欠陥を発見し、責任ある方法で報告した。METR は API を停止し、報奨金を支払った。METR の説明によれば、攻撃者はより広範なキャンペーン中にこのエンドポイントを通過したものの、脆弱性を発見したり非公開データに到達したりした形跡はなかった。METR はこの結論をゼロではなく脚注で「極めて可能性は低い」と位置づけている。

何が確立されており、何が確立されていないのか

確定。METRは2026年8月31日に開示を公表し、3月の窃盗、フェイルオープンの認証失敗、エージェントを介した鍵の開示、SSH鍵、3週間の期間、および約60万ドルの評価額について説明している。4つのセキュリティメディア——The Register、Dark Reading、Infosecurity Magazine、The Hacker News——が1日以内に同じ説明を報じ、いずれもそれに矛盾していない——ただし4社すべてはMETRの同じ投稿に依拠しており、METRのログやプロバイダーの請求への独立したアクセスに基づくものではない。

確立されていない。60万ドルという金額は、寄付クレジットに関するMETR自身の推計であり、請求書、提供者の声明、独立した評価は公表されていない。また、支払いが行われていないため、照合できる取引が存在しない。証明書透明性を利用した追跡手法はMETRによって疑惑と位置づけられており、攻撃者の活動を可視化できる立場にあるいずれの当事者によっても裏付けられていない。攻撃者の身元、モデル提供者の身元、3月の正確な日付はいずれも不明または未公表である。そして、機密データには到達しなかったという主張は、外部監査ではなく、METRのフォレンジック調査とそのコンサルタントのレビューに依拠している。

「ニアミス」という言葉についても正確を期す価値がある。METRは両方のインシデントをそう表現しているが、Dark Readingは3月の事案について、その捉え方に異を唱えた。攻撃者が永続化を確立し、盗んだ認証情報を使って3週間内部に滞在した、成功した侵害だったという理由からだ。どちらの説明も、異なる点について正確である。結果は封じ込められ、侵入は現実だった。

Dark Readingはまた、その報道の中で最も鋭い外部評価も伝えていた。Suzu LabsでセキュアAIソリューションおよびサイバーセキュリティ担当のシニアディレクターを務めるJacob Krellは同メディアに対し、METRはAI分野でもセキュリティ成熟度が高い組織の一つであり、SOC 2 Type I認証、専任のセキュリティコンサルタント、4段階のデータ分類システムを備えていると語った。それでもなお、インシデントはごく平凡な手段、すなわち個人用クラウドインスタンス上のフェイルオープン型認証欠陥を通じて発生した。Krellは、その成熟度レベルの組織が基本的なクラウドと認証情報の hygiene によって捕捉されるのであれば、それはAI業界のセキュリティの天井ではなく下限について語っているのだと主張した。Dark Readingは、METRがこの記事についてのコメント要請に応じなかったと記している。

なぜ評価者の鍵は些細なことではないのか

METRの役割こそが、この記録がクラウド衛生の総括ではなく安全アーカイブに収められている理由である。Dark Readingは、同組織がOpenAI、Anthropic、Google、Meta、Amazonを含む西側の主要モデルベンダーの大半と協働関係にあると報じ、The Registerは、METRがOpenAIと協力して、2026年初頭にOpenAIのエージェントがどのようにHugging Faceのサーバーに到達したかを調査したと指摘している。評価者は、未公開の結果、未公開の会話記録、およびリリース前のモデルへのアクセスを有しており、その資格情報は事実上、顧客のセキュリティ境界の一部となっている。

3月のインシデントはそこまでには至らなかった。到達したのは、個人用インスタンス上の公開モデル用キーであり、それはいつの間にか機能しなくなっていたログインの背後にあった——まさにそれゆえに、これは有用な記録なのだ。この失敗には、モデルに対する目新しい攻撃は必要なかった。必要だったのは、誰もレビューしなかったデモ配備、壊れたときにデフォルトで「はい」になる認証チェック、そして莫大な使用量が当たり前の状態であるような会計システムだった。