--- title: "LLMjacking 把 AI API 金鑰變成現金：台灣企業設好支出上限、權限範圍與異常告警的五個步驟" description: "企業要先設支出上限、限縮金鑰範圍、盯異常用量，帳單才不會先於資安事件爆發。LLMjacking 指盜用的雲端與 AI API 金鑰被轉賣來跑模型；Google GTIG 2026-11-02 指出，個別事件單日費用可超過 10 萬美元。本文整理五個步驟與驗收標準，供沒有資安團隊的台灣中小企業照做。" canonical: "https://yotron-ai.com/blog/google-gtig-llmjacking-enterprise-ai-api-key-spend-cap-guide" published: "2026-11-11" last-updated: "2026-11-11" --- # LLMjacking 把 AI API 金鑰變成現金：台灣企業設好支出上限、權限範圍與異常告警的五個步驟 企業要先設支出上限、限縮金鑰範圍、盯異常用量，帳單才不會先於資安事件爆發。LLMjacking 指盜用的雲端與 AI API 金鑰被轉賣來跑模型；Google GTIG 2026-11-02 指出，個別事件單日費用可超過 10 萬美元。本文整理五個步驟與驗收標準，供沒有資安團隊的台灣中小企業照做。 > 文／Laban（優創智能 AI 導入工程師） LLMjacking 是攻擊者盜用企業的雲端憑證或 AI API 金鑰，拿去跑模型並轉賣算力的手法。結論先講：**企業要先把「支出上限」與「金鑰範圍」當成資安控制來做，而不是財務報表的事。** 等帳單出現異常，通常已經晚了一個月的額度。 本文是新聞解析與執行清單，不是資安或法律意見。文中的數字全部來自 Google 原始報告，我們另外標出哪些是研判、哪些是示例門檻。 --- ## 一、已知事實：Google GTIG 報告說了什麼？ ### 1. 消息來源與時間 Google Threat Intelligence Group（GTIG）於 2026-11-02 在 [Google Cloud 威脅情報部落格](https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models) 發表 LLMjacking 報告，描述攻擊者如何盜用雲端與模型資源並變現。CSO Online 同日報導，標題是 [〈Enterprises pay $100,000 a day for AI they never ordered〉](https://www.csoonline.com/article/4243863/enterprises-pay-100000-a-day-for-ai-they-never-ordered.html)。 ### 2. 原文數字與它的範圍 | 說法 | GTIG 原文的口徑 | | --- | --- | | 單日超過 10 萬美元 | 「個別事件」中，因資源消耗產生的詐欺性費用「單日超過 10 萬美元」 | | 累計 100 萬美元 | 部分組織累計費用達到 100 萬美元，才撤銷存取 | | UNC6993 累計超過 10 萬美元 | 取得 LLM API 金鑰後，嘗試產生更多金鑰並啟用受害專案中的相關服務，「短時間內累積超過 10 萬美元」帳單 | | 不到 8 小時超過 50 萬次呼叫 | 一名行為者利用偷來的第三方 API 金鑰，透過 `jet-night.com` 這個 token 路由服務，執行超過 50 萬次 LLM API 呼叫；GTIG 稱受害組織承擔近 100 萬美元的 token 成本 | **注意：** CSO Online 的標題寫成「每天付 10 萬美元」，比 GTIG 的說法更強。GTIG 寫的是「個別事件」與「可能」的量級，不是每家企業每天的平均費用。本文以 GTIG 原文為準。 ### 3. 攻擊怎麼開始，怎麼被用 - **入口**：GTIG 指出，最主要的初始入口是外洩或被盜的雲端身分憑證，包括 IAM 憑證、服務帳戶金鑰、GitHub 個人存取權杖（PAT），以及有效的 session token。 - **驗證**：攻擊者會用 `max_tokens=1` 這類極小請求，批次確認偷來的金鑰能不能用。GTIG 把這類做法描述為規避偵測的手法。 - **轉賣**：GTIG 把 LLM Mixer 定義為「非法路由閘道，代理、彙整並轉賣未授權的 LLM 存取給地下訂閱者」。 ### 4. GTIG 的防禦建議（原文摘要） - **限制金鑰壽命**：用集中式的密鑰管理工具控管輪替，自動化輪替可以縮短外洩金鑰的有效期。 - **最小權限**：拒絕所有未明確需要的權限，包括雲端 LLM 服務的存取。 - **配額與支出上限**：對 LLM 服務設定細緻的 API 配額，並使用支出上限（spending caps）避免超支。 - **監控低量異常請求**：留意 `max_tokens=1` 或零 temperature 的探測式呼叫。 - **閘道及時修補**：LiteLLM 這類模型閘道要快速套用特權提升與認證繞過的修補。 ### 5. 還不知道的部分 - GTIG 沒有公布受害組織的數量與產業分布，也沒有說明金鑰外洩的比例。 - GTIG 對 Jet Night 的營運方式是「研判」：它認為這項服務「依賴被盜金鑰才能獲利」，因為每 token 的售價遠低於市場行情。這不是已證實的事實。 - CSO Online 把 Jet Night 寫成「合法的 token 路由服務」，GTIG 則把它歸為 LLM Mixer。本文採 GTIG 的定性。 - GTIG 文中提到的 LiteLLM 漏洞編號，我們本次無法從 NVD 取得對應紀錄，因此本文不寫編號，也不寫修補版本。 --- ## 二、編輯分析：這對台灣企業代表什麼？ ### 1. 帳單是最早響的警報 資安事件可能要幾週才被發現，但帳單的異常通常在一天之內就會出現。對沒有 SOC 的中小企業，**支出告警其實是最便宜的入侵偵測**，前提是它的通知有人收、有人看、能在當天停用金鑰。 ### 2. 預算告警不等於支出上限 這是最常見的誤解。以 Google Cloud 為例，官方 Budget API 文件寫明： - **僅發告警的預算（alerts-only）**：支出超過門檻時發出通知，不會停止用量。 - **支出上限預算（spend-cap）**：可以強制暫停指定專案中該服務的新用量，但只適用於部分服務。 - **時間差**：實際支出的計算通常需時最多約 24 小時，告警會落後於實際用量。 所以，「我們設了每月 1 萬美元的預算」不等於「帳單不會超過 1 萬美元」。上限要靠可以停用的機制，而不是靠通知。 ### 3. 其他雲端也有類似的自動動作 AWS Budgets 的 budget actions 可以在門檻達到時，自動或經人工核准後，套用 IAM 政策或 SCP，或停止指定的 EC2、RDS 執行個體。這種做法比單純的告警更接近上限，但需要事先設計角色、政策與核准流程。我們建議先用示例政策在測試帳號演練，再套用到正式帳號。 --- ## 三、五個步驟：這週就能開始做的事 ### 步驟 1：盤點所有會計費的 AI 金鑰與雲端入口 列出所有會產生費用的 AI 金鑰與服務帳號，每一把都寫下：供應商、擁有者、用途、放在哪裡（`.env`、CI 變數、n8n 或 Make 的憑證、客服後台）、月預算、最後輪替日。**沒有擁有者的金鑰，先停用再說。** 員工個人帳號接公司資料的部分，也列進來。金鑰放在別人平台上的風險，可參考我們的 [Zeabur 事件整理](/blog/zeabur-shutdown-security-incident-enterprise-lessons)。 ### 步驟 2：設定支出上限，不要只設告警 依供應商分別處理： - 能設硬上限的服務，就設硬上限。以下數字是示例，請依自身用量調整：每把金鑰的月上限設為過去三個月平均用量的 1.5 倍。 - 只能設告警的服務，就把告警接到會自動停用金鑰的流程，並先在測試環境驗證這個流程真的會停。 - 每個供應商都要確認：超過上限時，是「停止新請求」還是「只通知」。 ### 步驟 3：限縮金鑰範圍 - 一個應用程式用一把金鑰，不共用。 - 區分開發與正式環境，開發用的金鑰不碰正式模型與正式資料。 - 只開需要的模型與服務；AI 代理的權限邊界可參考 [AI Agent 權限邊界](/blog/ai-agent-permission-boundary-sandbox)。GTIG 指出，攻擊者拿到金鑰後會嘗試啟用受害者原本沒有使用的服務，所以未使用的服務應該關閉，而不是保持開啟。 ### 步驟 4：設定異常用量告警，並指定誰收到 以下是示例規則，請依自身基準調整： - 單日用量超過過去 14 日中位數的 3 倍，立即通知負責人。 - 非上班時段（例如 00:00 至 06:00）出現大量呼叫，立即通知。 - 出現大量 `max_tokens=1` 或零 temperature 的小型請求，視為可能的金鑰驗證，直接停用該金鑰。 通知要送到會看的人手上，例如值班群組或負責人的手機，不要只寄到沒人讀的共用信箱。 ### 步驟 5：定期輪替金鑰，並修補模型閘道 - 以 90 天為示例，建立輪替日程，並用密鑰管理工具自動化輪替。 - 若公司使用 LiteLLM 等模型閘道，把它列入修補清單。我們 10 月的 [LiteLLM 投毒事件整理](/blog/october-2026-security-patch-week-emudhra-litellm-railway) 提到，金鑰外洩時要換掉該主機能讀到的所有憑證，不只是換一把。 - 金鑰外洩或異常用量出現後，除了停用，還要查雲端稽核紀錄，確認這段期間的呼叫來源。 ### 驗收標準 做完五步，你要能回答五個問題： 1. 公司有幾把會計費的 AI 金鑰，每把的負責人是誰？ 2. 每個供應商的上限是「停止新請求」還是「只通知」？ 3. 最近一次金鑰輪替是哪一天？ 4. 異常用量出現時，誰會在幾小時內收到通知？ 5. 模型閘道目前的版本，是否在修補清單上？ 任一題答不出來，代表那一段還只是「有設定」，還不是「能停下來」。 --- ## 四、結語：先讓帳單能停，再談怎麼用得更多 LLMjacking 的重點不是某一家平台的漏洞，而是金鑰一旦外洩，攻擊者就能用你的額度做別的生意。對台灣企業，最實際的第一步是三件事：知道有哪些金鑰、讓它們有上限、讓異常能被人看到。 如果你的團隊正在導入 AI 代理或自動化流程，想先把金鑰範圍、支出上限與告警流程一起設計，可以從一次導入前盤點開始。我們也可以協助你把這五個步驟放進既有的 IT 流程。 --- **免責說明**：本文依據 Google GTIG 2026-11-02 報告、CSO Online 2026-11-03 報導，以及 Google Cloud Budget API 與 AWS Budgets 官方文件整理。文中的 1.5 倍、14 日中位數、3 倍與 90 天等門檻為示例，請依自身用量與風險調整。文中關於 Jet Night 的營運判斷為 GTIG 研判，不是已證實的事實。本文不構成資安、法律或財務建議。 **參考來源** - Google Threat Intelligence Group，〈The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources〉，2026-11-02：https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models - CSO Online（Shweta Sharma），〈Enterprises pay $100,000 a day for AI they never ordered〉，2026-11-03：https://www.csoonline.com/article/4243863/enterprises-pay-100000-a-day-for-ai-they-never-ordered.html - Google Cloud，〈Budget API overview〉，2026-11-11 查閱：https://docs.cloud.google.com/billing/docs/how-to/budget-api-overview - AWS，〈Configuring budget actions〉，2026-11-11 查閱：https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-controls.html --- ## 相關推薦與延伸閱讀 - [Claude Enterprise 推出推論掛鉤與安全中心：企業把 AI 助理接進既有 DLP 前，該先定的五項設定](/blog/claude-enterprise-inference-hooks-security-center-ai-governance)：Claude Enterprise 的推論掛鉤可把提示詞與工具呼叫先送公司資安伺服器審核，但預設逾時放行，圖片內容也不檢查，企業要先定好失敗處理與檢查範圍。An - [2027 資安趨勢：修補寬限期結束、AI 代理權限要像管理員帳號一樣管，中小企業該先做的五件事](/blog/patching-grace-period-over-2027-security-ai-agent-checklist)：2027 資安趨勢的重點是：漏洞公開到被利用只剩幾天，AI 代理權限要像管理員帳號一樣管。Check Point 資安暨信任長 2026-10-30 在 For - [Claude 改頁碼卻刪掉一年講義：企業讓 AI 代理動雲端資料夾前的五個檢查](/blog/ai-agent-file-deletion-shared-folder-backup-checklist)：讓 AI 代理整理檔案前，先給它副本、限縮資料夾權限並確認還原期限，不要直接開放正本。芝加哥大學法學教授 William Baude 於 2026 年 11 月