METR 的 Vibe-Coded 代理儀表板停用了自身的登入功能，攻擊者因此消耗了價值 60 萬美元的模型額度

在2026年3月，有人從一名研究員個人使用的 Amazon EC2 執行個體上取走 METR 公開模型帳戶的 API 金鑰，並將之用於三週。METR——模型評估與威脅研究（Model Evaluation and Threat Research），這家衡量 AI 代理在長時程任務上能推進到什麼程度的非營利組織——估計所消耗額度的商業價值約為60 萬美元。這把金鑰並非透過網路釣魚從人身上騙得：攻擊者誘導在研究員那個以 vibe coding 打造的儀表板上運行的代理，交出其模型供應商的 API 金鑰，接著新增一組 SSH 金鑰，以便日後再回來。METR 於2026年8月31日披露這起事件，而紀錄帶有該檔案庫的高嚴重性等級與 A 級信心評等。這份披露是AI 事件檔案庫中的一筆紀錄；該檔案庫收錄完整紀錄集、其來源，以及本系列中的鄰近條目。

紀錄實際上說的是什麼

檔案庫將此歸類為已實際發生的事件，而非理論弱點的揭露：嚴重性 高，信心 A，無爭議，並記錄到實際傷害且確認 AI 參與。類型標籤為 CRED，地區為 美國，且日期僅記錄到月份——檔案庫知道竊案發生於 2026 年 3 月，不主張具體日期，METR 亦然。

這項損害需要加一個限定說明，而 METR 正好提供了這項說明。這些額度是由模型開發商免費授予 METR 的，因此這 $600,000 是所消耗資源的價值，而不是從帳戶中流出的金錢。The Register 的導言更直白地提出同一點：模型供應商把額度給了 METR，而實際付費的客戶不會這麼幸運。Infosecurity Magazine 也以同樣方式報導這個數字，將其視為商業價值而非直接財務損失。

METR 的貼文涵蓋了兩起事件，而非一起。2026 年 5 月的行動在下方另有描述；金鑰遭竊以及為期三週的支出是三月的事件，而它們正是本文的主題。

問題出在登入，不在模型。

一位沒有敏感存取權限的 METR 研究員，在個人 EC2 執行個體上運行代理程式；該執行個體是刻意設定為可公開連線，並置於 Google 驗證之後。該執行個體帶有 METR 一般存取帳戶的 API 金鑰——這個帳戶用於公開模型，而 METR 將其列為敏感度倒數第二低的資料類別。圍繞這些代理程式的調度應用程式是以 vibe coding 方式寫成，其中含有 METR 所稱的失效開放漏洞，會悄悄停用驗證。

「故障開放」值得翻譯，因為這兩個詞就概括了整起事件。登入檢查有兩種出錯方式：它可能拒絕合法使用者，也可能在檢查本身故障時放行任何人。故障開放指的是第二種——當驗證步驟發生錯誤或被略過時，應用程式將請求視為允許而非拒絕。沒有任何告警。在 METR 的描述中，結果是一個系統暴露在公開網際網路上數天，前門敞開，卻沒有任何跡象顯示情況有變。

METR 並未指明所使用的編排工具或儀表板建置所依據的框架，也未公開程式碼，亦未說明驗證整合是以何種方式失敗。這篇文章確實指出的是該錯誤背後的架構性失誤：一個組織模型帳戶的憑證，存在於 METR 無法控制的基礎設施上，且位於一名研究人員自行部署的應用程式中。

鑰匙是如何離開這棟大樓的

METR 對攻擊者手法的重建明確屬於懷疑，而非已證實的結論，而這也是整份披露中最有意思的未經證實說法。該文章指出，METR 懷疑攻擊者是透過瀏覽近期註冊的網站——憑證透明度清單即為一例——來找到該執行個體，從中尋找帶有可辨識 LLM 或 agent 專案關鍵字的 vibe-coded 網站，以便蒐集遭到外洩的模型供應商 API 金鑰。

憑證透明度日誌在設計上就是公開的：為公開信任的網站簽發的每張憑證都會被記錄，因此新的主機名稱在上線後幾分鐘內就會出現在可搜尋的資訊流中。在該資訊流中篩選名稱含有 agent 或 model 術語的項目成本低廉，無須存取目標，還能產出一份可能尚未經任何人審查的新部署清單。若將此視為一種狩獵技術來解讀，它便會把發布示範這項日常行為轉化為訊號。

一旦進入內部，攻擊者無需從檔案系統竊取機密。他們直接提示該代理揭露其模型供應商的 API 金鑰，這句話值得停下來想一想：該代理的憑證就在其上下文之中，而它竟能被說服把它印出來。攻擊者隨後加入了一把 SSH 金鑰以取得持續存取權，如此一來，即使修補了驗證漏洞也無法將他們逐出，接著便安頓下來，進行了長達三週、針對公開可用模型的推論。

模型開發者並未被指名——無論是 METR，還是 The Register、Dark Reading、Infosecurity Magazine 或 The Hacker News 在報導這起披露時，都沒有點名。未發布 CVE，因為這不涉及任何產品漏洞。也沒有任何逮捕、起訴或歸因於具名團體的報導。

為什麼三週的異常使用量看起來卻很正常

METR 直接回答了那個顯而易見的問題，而答案正是其他組織應該反覆細讀的部分。這家非營利組織執行大規模評測，這意味著它對極龐大的 token 數量，以及源源不絕的古怪速率限制與 API 錯誤（其中許多是誤報）早已司空見慣。模型流量出現尖峰，本身並不構成訊號。

三個具體缺口，讓那份熟悉感變成三週的沉默。METR 的內部使用儀表板並未顯示所有使用者受速率限制請求的資料，即使那些請求正在發生也一樣。因為 token 是免費的，所以沒有帳單，也就沒有自然會觸發的支出上限。而且 METR 表示，當時根本無法對那種類型的金鑰設定支出上限。一個按牌價付費且有硬性上限的組織，幾小時內就會撞牆；一個獲得捐贈額度且沒有上限的組織，則沒有東西可撞。

未被取走的事物

METR 的資料分類體系從已發布資料，一路涵蓋到一般模型存取、敏感模型存取，以及高度敏感的商業資訊。涉入的研究人員無法存取最高兩類資料，而 METR 表示，據其所知，這兩起事件均未導致上述類別的資料遭到存取。

除了那把單一金鑰之外，METR 表示，人工與代理輔助的鑑識調查並未發現任何遭入侵的跡象，且其資安顧問Calif驗證了這些發現，並自行進行了入侵評估。這是一項有意義的管控措施——由外部公司來查核該帳戶，而非直接採信——但 Calif 是由 METR 委聘並付費的，因此並非獨立於 METR。目前尚無任何第三方公布其對這起事件的獨立鑑識審查。

METR 注意到時做了什麼

貼文中的應變流程很具體。METR 查明使用量激增並非評估的一部分，追查到遭入侵的個人執行個體，撤銷該研究員的所有存取權限，停止並對該執行個體建立映像，輪換其上所有憑證，並對該研究員的筆記型電腦建立映像後予以抹除。它通知了額度正被消耗的合作夥伴 AI 公司，並在整個應變過程中持續向該公司更新情況。

METR 並未說明抹除筆記型電腦背後的理由，而這是整個流程中唯一超出撤銷對該執行個體本身存取權的一步——合理的解讀是，同一位研究人員一直從攻擊者所能觸及的工作站處理該憑證，而先製作映像再重建，是確保某台機器狀態的低成本做法。

之後有什麼改變？

METR 列出了與此事件相關的四項變更：

• 已釐清並擴充適用於員工與承包商的安全政策，特別是在將 METR 憑證或資料放置於 METR 不擁有的基礎設施與裝置上的相關規範。

• 現在任何公開部署應用程式的研究人員，都須適用正式的安全審查流程。

• 監控涵蓋範圍已擴大，同時著手消除會讓應變人員養成忽略習慣的雜訊警示。

在供應商做得到的情況下，金鑰已加入消費警示——這層保留很重要，因為文章先前的論點是：當時這類金鑰有些無法設定上限。

這份披露也列出全組織層面的工作：聘請安全主管並規劃一名全職安全工程師、提高 Calif 的參與程度、關閉擴大攻擊面的舊有基礎設施、定期進行威脅建模審查、將日誌記錄擴展至資料庫查詢與 API 使用情形、監控異常的 API 金鑰使用、部署額外的端點與伺服器安全軟體、縮短憑證有效期並縮減權限範圍。METR 將這些措施標註為準確至2026年7月30日，並表示這些措施可能有所變動——這項但書值得保留，因為這意味著該篇文章描述的是竊盜發生約四個月後、發表約一個月前的狀態。

同一則貼文中的另一起事件

METR 的揭露將金鑰竊取與另一宗獨立事件並列，該事件發生於 2026 年 5 月初，而這兩者很容易被混為一談。在後者中，METR 接獲通報指出自己正被一批攻擊者鎖定，這些攻擊者看似出於財務動機，且可能意在取得前沿模型的存取權；METR 觀察到他們探測其公開基礎設施，大量運用代理程式自動化漏洞發掘，包括對身分驗證服務供應商進行憑證填充、嘗試取得 OAuth 權杖授權、掃描新部署的服務，以及對員工發動釣魚攻擊。

在同一段期間，METR 不慎透過其公開逐字稿檢視器暴露了一個唯讀 SQL 查詢機制。查詢預設範圍限於公開資料，但一個漏洞可能被轉向未公開的評估資料，而且部分敏感的模型輸出曾被誤載入該資料庫。一名獨立安全研究人員發現了這個缺陷並負責任地通報；METR 將該 API 下線並支付了賞金。根據 METR 的說法，攻擊者在更廣泛的行動中曾經過該端點，但沒有跡象顯示他們發現了該漏洞或觸及非公開資料——METR 在腳註中將此結論列為「高度不可能」，而非零。

何者為已確立，何者則否

已證實。METR 於 2026 年 8 月 31 日公布這份披露內容，其中描述了三月竊案、fail-open 身分驗證故障、由代理中介的金鑰外洩、SSH 金鑰、為期三週的空窗期，以及約 60 萬美元的估值。四家安全媒體——《The Register》、《Dark Reading》、《Infosecurity Magazine》與《The Hacker News》——在一天內報導了同一說法，且沒有任何一家提出反駁——儘管四家都取材自同一篇 METR 貼文，而非獨立查閱 METR 的日誌或供應商的帳務資料。

尚未證實。 這 60 萬美元是 METR 自行對捐贈額度所作的估算；沒有公布任何發票、供應商聲明或獨立估值，而且因為沒有支付任何款項，也就沒有交易可供核對。憑證透明度追查方法被 METR 標示為僅屬懷疑，且尚未獲得任何能掌握攻擊者活動情況的相關方佐證。攻擊者的身分、模型供應商的身分，以及三月的確切日期，全都未知或未公布。而「未觸及任何敏感資料」的說法，依據的是 METR 的鑑識結果及其顧問的審查，而非外部稽核。

也值得精確釐清「近乎失誤」這個詞。METR 將這兩起事件都如此形容，而 Dark Reading 則對三月事件的這種定調提出反駁，理由是那是一起成功的入侵：攻擊者建立了持久化，並利用一組遭竊憑證在內部潛伏了三週。這兩種描述各自準確說明了不同的事：結果受到了控制，而入侵確有其事。

Dark Reading 在其報導中也提出了最犀利的外部評估。Suzu Labs 安全 AI 解決方案與網路安全資深總監 Jacob Krell 告訴該媒體，METR 是 AI 領域中安全成熟度較高的組織之一，擁有 SOC 2 Type I 認證、專職安全顧問以及四層級資料分類系統，而這些事件仍是透過尋常途徑發生——個人雲端執行個體上的一個故障開放式身分驗證缺陷。Krell 主張，如果一個處於那種成熟度水準的組織，仍被基本的雲端與憑證衛生問題所困，這反映的是 AI 產業安全的下限，而非上限。Dark Reading 指出，METR 未回應其就該報導提出的置評請求。

為什麼評估者的關鍵不是小事

METR 的角色，正是這份紀錄被歸入安全檔案、而非雲端衛生彙整的原因。Dark Reading 報導，該組織與大多數主要西方模型供應商都有合作，包括 OpenAI、Anthropic、Google、Meta 和 Amazon；The Register 指出，METR 曾與 OpenAI 合作，調查 OpenAI 的代理程式在 2026 年稍早如何觸及 Hugging Face 伺服器。評估機構掌握未公開的結果、未發表的逐字稿，以及在模型發布前取得模型的權限；其憑證實際上屬於客戶安全邊界的一部分。

三月事件並沒有走到那一步。它涉及的是一把公開模型的金鑰，這把金鑰位於個人執行個體上，而該執行個體藏在一道早已悄悄失效的登入機制之後——這正是它之所以是有用紀錄的原因。這次失敗並不需要對模型發動新型攻擊。它只需要一個無人審查的示範部署、一個在故障時預設放行的身分驗證檢查，以及一個把巨量用量視為常態的用量核算系統。