以評估 AI 能力聞名的非營利組織 METR 公布了 2026 年發生的兩起資安事件。第一起是研究人員個人環境外流的 API 金鑰遭濫用三週，被消耗掉的額度以商業價值計算約為 60 萬美元（約 9,300 萬日圓）。第二起則是外部攻擊者對其公開基礎架構進行系統性探測。METR 表示，兩起事件都沒有發現敏感資訊遭存取的證據。

※1 美元 = 155 日圓（截至 2026 年 9 月 4 日）

起點是研究人員請 AI 寫出來的一個小程式

第一起事件要回到 2026 年 3 月。一位沒有敏感存取權限的研究人員，在自己個人帳號下的 Amazon EC2 執行個體上跑智慧代理。這台執行個體是刻意對外開放的，前面擋著 Google 認證。裡面同時放著 METR 公開模型帳戶的一組 API 金鑰。

問題出在這個程式是請 AI 產生的程式碼，也就是所謂的 vibe coding。它的認證邏輯有一個失敗即放行的瑕疵：驗證出錯時不是拒絕，而是直接放過。由於失效過程沒有任何提示，沒有人察覺。結果這套環境在網路上敞開了好幾天。

METR 推測，攻擊者是翻查憑證透明度紀錄找出近期註冊的網域，再從中挑出名稱帶有語言模型或代理等高訊號字詞的網站。目標正是那裡可能存放的模型供應商 API 金鑰。個人隨手架設的開發環境，如今已成了金鑰獵人的貨架。

入侵手法也很有時代感。攻擊者直接對執行中的代理下提示，讓它把手上的 API 金鑰說出來，接著加上 SSH 金鑰維持存取，並用這組被竊的憑證在三週內消耗了大量 token。

為什麼三週都沒發現

一個以評估為本業的組織，為何這麼久才察覺。METR 提出三個原因。

第一，大量消耗 token 本來就是日常。針對未發布模型執行大規模評估時，速率限制與 API 錯誤會不斷出現，其中許多並不反映真實用量，團隊早已習慣。

第二，當時的內部用量儀表板並不會向所有使用者顯示被限速的請求，異常的跡象沒有出現在有人盯著的地方。

第三，也是最關鍵的一點：這批額度是模型開發商免費提供給 METR 的，不會產生帳單。既沒有金額這道天然的煞車，當時也無法對這類金鑰設定消費上限。60 萬美元只是被消耗額度的商業價值，並非 METR 實際損失的金額。但正因為不用付錢，才沒有人去看這個數字。

5 月遭遇來自外部的大規模攻擊

第二起發生在同年 5 月。METR 接獲通報，得知自己正被一批看似以金錢為動機的攻擊者鎖定，對方很可能是衝著前沿模型的存取權而來。

他們的手法是對公開基礎架構進行地毯式偵察：對認證服務發動填充式登入、嘗試取得 OAuth 權杖、掃描新上線的服務，以及對員工發動釣魚。值得注意的是，漏洞探索的工作大多交給代理自動執行。

麻煩的是，同一時期 METR 自己也留了破口。對外提供的紀錄檢視功能意外暴露了一個唯讀的 SQL 查詢機制。預設情況下查詢範圍僅限公開資料，但利用一個瑕疵就能觸及未公開的評估資料。更糟的是，這個資料庫還誤載入了原本不該存放的敏感模型資料。

該瑕疵由一位獨立資安研究人員發現並負責任地揭露。METR 隨即將該 API 下線並支付獎金。攻擊者雖然在大範圍行動中順帶探測過這個端點，但沒有證據顯示他們發現了瑕疵，或接觸到任何非公開資料。

把對外服務與內部系統切開，並配置專職資安人力

因應這兩起事件，METR 重整了體制。首先明確並擴充適用於全體員工與約聘人員的規範，重點在於不得將 METR 的憑證或資料放到非 METR 的基礎架構與裝置上。研究人員要對外部署應用程式時，也必須通過正式的資安審查流程。監控範圍隨之擴大，同時清理容易被忽略的雜訊警報，並在條件允許的金鑰上加上用量警示。

架構面上，對外的應用程式現在跑在一個與內部基礎架構在結構上完全分離的專用正式環境中，避免公開端的設定失誤導致內部資料外洩。

人力方面，METR 聘用了資安主管，並計畫繼續擴編，包含一名全職資安工程師。那些無謂擴大攻擊面的舊有基礎架構已經關閉。資料庫查詢與 API 使用的日誌記錄獲得強化，也建立了針對 API 金鑰異常使用的監控。憑證的有效期限被縮短，權限範圍也進一步收斂。METR 特別註明，上述措施的描述以 2026 年 7 月 30 日為準。

總結

METR 這次揭露中最值得注意的，不是損失的規模，而是讓問題長期隱形的那些條件。在一個大量呼叫 API 已成常態的組織裡，異常的 token 消耗會融入背景之中。免費額度也不會有帳單這種簡單明瞭的警報。而最初的入口，只是一個由 AI 寫出來的個人小程式。交給代理的金鑰，問一句它就會交出來。重新檢視金鑰放在哪裡、能用多久，看似繞遠路，卻是最紮實的對策。