```
Stolen AI Keys Are Running Up Million-Dollar Cloud Bills, Google Warns
Google has warned that attackers are quietly hijacking enterprises' access to large language models to burn through expensive AI compute — and in some cases running up cloud charges of up to $1 million, as reported by The Hacker News.
The technique has been dubbed LLMjacking: a modern twist on classic resource hijacking, in which a threat actor obtains a legitimate API key and then uses it to consume premium model inference and cloud capacity at the victim's expense.
How the keys are stolen
Google's warning identifies four routine ways enterprise LLM credentials end up in attacker hands:
- Phishing — credentials harvested directly from developers or ops staff
- Source code leaks — keys committed to repositories and scraped from public or compromised code
- Misconfigured environments — cloud workloads and secrets exposed by sloppy access controls
- Exposed client-side code — keys embedded in browsers, mobile apps, or other front-end artefacts
Because the abuse is authenticated, it presents as ordinary traffic to most monitoring stacks. There is no breach to spot, no firewall alert to triage, no unusual inbound connection. In practice, the anomaly only surfaces when the invoice does — which is why LLMjacking campaigns can run for extended periods before anyone notices.
Why the bills escalate
Once inside, attackers have little incentive to be restrained. Automated workloads can drive continuous inference against high-cost models around the clock, without any of the guardrails a legitimate team would apply. And because usage is metered by the account holder, the entire financial burden lands on the victim organisation.
The $1 million figure matters because it reframes the threat. Security teams tend to treat API keys as application configuration — a low-sensitivity item tucked into an environment variable. Finance teams tend to treat cloud bills as a monthly postmortem artefact rather than a live security signal. LLMjacking exploits precisely that gap: nobody owns the AI spend line item in real time.
A practical guardrail checklist
For enterprises adopting LLM APIs, this checklist is our editorial recommendation, going beyond what has been publicly attributed to Google. The measures are unglamorous but effective:
- Never ship keys client-side. Route all model calls through a backend gateway the enterprise controls itself.
- Rotate and scope keys aggressively. Issue per-service, per-environment credentials with tight quotas; revoke anything unused.
- Set hard spend ceilings — and name an owner. Configure billing alerts at multiple thresholds on every cloud and AI vendor account, ensure they reach a human on call rather than a shared inbox, and name the person accountable for AI cost anomalies. Unowned metrics go unread.
- Treat usage spikes as security events. Correlate token consumption and request volume with the SOC's alerting, not just the finance dashboard.
- Audit repositories and logs for leaked secrets. Scan continuously; assume committed keys are already public.
The durable lesson is that budgetary monitoring and security monitoring are converging. In the LLM era, an API key has quietly become equivalent to a privileged account — and, increasingly, to a corporate credit card. Treating cloud spend telemetry as a security control is no longer optional.
```
Google 警告：被盜 AI 金鑰令雲端帳單暴增至百萬美元
Google 警告稱，攻擊者正悄悄劫持企業存取大型語言模型的權限，以消耗昂貴的 AI 算力——在個別案例中，更令雲端帳單高達 100 萬美元，據 The Hacker News 報道。
此手法被命名為 LLMjacking：這是傳統資源劫持的現代變種，即威脅行為者先取得合法的 API key，再以受害者的名義消耗高價模型 inference 及雲端資源。
金鑰如何被盜
Google 的警告指出，企業 LLM 憑證落入攻擊者手中主要有四種常見途徑：
- 釣魚攻擊 — 直接從開發人員或維運（Ops）人員身上騙取憑證
- 原始碼洩露 — 已提交至 repository 的金鑰，從公開或已被入侵的程式碼中被搜刮
- 環境設定錯誤 — 因存取控制疏漏而暴露的雲端工作負載及 secrets
- 前端程式碼外洩 — 嵌入瀏覽器、流動應用程式或其他前端 artefacts 的金鑰
由於此類濫用屬經認證的存取，對多數監控系統而言與普通流量無異：沒有資料外洩可偵測，沒有防火牆警報需跟進，也沒有異常的入站連接。實際上，異常只有在帳單出爐時才會浮現——這正是 LLMjacking 攻擊行動往往在長時間內未被察覺的原因。
為何帳單不斷攀升
一旦入侵成功，攻擊者幾乎沒有收手的動機。自動化工作負載可全天候對高成本模型持續發動 inference，完全不受正當團隊會採取的任何 guardrail 約束。加上用量以帳戶持有人名義計費，全部財政負擔便落在受害機構身上。
100 萬美元這個數字之所以重要，在於它重新定義了威脅的性質。安全團隊傾向將 API key 視為應用程式配置——一項收納在環境變數中的低敏感度項目。財務團隊則傾向將雲端帳單當作每月事後檢討的文件，而非即時的安全訊號。LLMjacking 恰恰利用了這個缺口：沒有人即時為 AI 支出項目負責。
實用的防護清單
對於採用 LLM API 的企業，以下清單屬本刊編輯建議，超出 Google 已公開歸納的範圍。措施雖不花巧，卻行之有效：
- 切勿在前端交付金鑰。 將所有模型呼叫透過企業自行掌控的 backend gateway 處理。
- 積極輪換及限定金鑰範圍。 按服務、按環境簽發設有嚴格配額的憑證，撤銷一切閒置金鑰。
- 設定硬性支出上限——並指定負責人。 在每個雲端及 AI 供應商帳戶設定多個門檻的帳單警報，確保警報送達輪值人員而非共享收件箱，並指明負責跟進 AI 成本異常的人選。沒人認領的指標，最終乏人問津。
- 將用量急升視為安全事件。 將 token 消耗及請求量與 SOC 的警報系統關聯，而不只是財務儀表板。
- 審計 repository 及日誌中的洩露 secrets。 持續進行掃描；假設已提交的金鑰已經曝光。
最長遠的啟示是：預算監控與安全監控正在合流。在 LLM 時代，一把 API key 已悄然等同於一個特權帳戶——而且越來越多時候，等同於一張公司信用卡。將雲端支出遙測視為一項安全控制，已不再是可有可無的選項。