hihi，我是歐娜😺
前幾天講的風險，大部分都在想：
但今天這一條，要看的東西非常現實。
就是：
你的 AI 到底可以花多少資源？🤣
今天來看 OWASP LLM Top 10 2026 第六名：
LLM06：Unbounded Consumption（無限制資源消耗）。
這一條可以先很簡單理解成：
如果 AI 系統沒有幫資源使用設定好上限，攻擊者就可能透過大量或特別昂貴的請求，把 Token、運算資源，甚至帳單一起吃掉。
乍看之下好像跟以前的：
DoS
Rate Limit
API Abuse
差不多。
但到了 LLM，事情會稍微麻煩一點。
因為：
不是每一個 Request 的成本都一樣。
這也是今天最重要的概念。
傳統 API 我們可能會先想到這種流程：
User
↓
API Request
↓
Server
↓
Response
如果有人短時間一直狂打：
100 Requests
1000 Requests
10000 Requests
Server 的資源可能被吃光，最後正常 User 就沒辦法使用。
所以我們很常做：
Rate Limit。
例如：
每個 User
每分鐘最多 100 Requests
超過就擋掉。
這個做法到了 AI 當然還是需要。
但問題是：
只算 Request 數量，可能已經不夠了。
因為到了 LLM Application，同樣都是一次 API Request，背後實際消耗的資源可能差非常多。
例如兩個 User 都只是呼叫一次：
POST /chat
第一個 User 問：
台灣的首都是哪裡？
可能只有很短的 Input，也只需要很短的 Output。
但第二個 User 可能一次丟進：
一整份 PDF
+
超長 Conversation History
+
大量 RAG Context
+
要求產生很長的分析結果
從 API Gateway 的角度來看：
Request A → 1 Request
Request B → 1 Request
完全一樣。
但真正送到 Model 後面：
Request A
Input: 20 Tokens
Output: 50 Tokens
Request B
Input: 50,000 Tokens
Output: 8,000 Tokens
兩個 Request 的資源消耗根本不是同一個等級。
所以如果今天只設定：
每分鐘最多 10 Requests
其實只是限制：
你可以問幾次。
卻沒有真的限制：
你每一次最多可以花我多少資源。
這就是 AI Application 在做 Resource Control 時，比傳統 API 多出來的一層。
前面一直提到 Token。
可以先很簡單理解成：
LLM 不是真的直接拿整段文字去處理，而是會先把內容拆成 Token，再進行運算。
概念大概像：
User Input
↓
Tokens
↓
Model Processing
↓
Output Tokens
所以通常：
Input 越長
Output 越長
需要處理的 Token 就會越多。
如果使用的是按照 Token 或使用量計費的 Model API，成本也可能跟著增加。
假設你的系統完全沒有控制：
Input Length
Output Length
Context Size
那攻擊者就可以想辦法讓每一個 Request 都盡可能變得很昂貴。
例如一直塞：
超長文章
大量文件
超長 Conversation
大量 Context
然後再要求：
幫我非常詳細地分析，越完整越好。
這時候很有趣的一件事是：
攻擊者發 Request 的成本可能非常低，但真正負責處理這些 Request、支付 Model API 費用的人，是服務提供者。
這就是 Unbounded Consumption 很重要的一個特性：
Cost Asymmetry（成本不對稱）。
概念大概是：
換句話說：
他只負責按送出，你負責付錢。
ummm...
這個商業模式對攻擊者來說滿不錯的🤣
講到這裡，就會出現一個非常好記的詞：
Denial of Wallet（DoW）。
我們比較熟悉的是：
Denial of Service（DoS）。
概念是：
大量 Request
↓
Server Resource 被耗盡
↓
正常 User 無法使用
也就是想辦法讓：
你的服務掛掉。
但現在很多 AI Application 背後使用的是 Cloud AI API。
而 Cloud Service 很常是：
用多少
↓
付多少
這時候攻擊者甚至不一定需要真的把服務打掛。
想像今天你做了一個公開的 AI Chatbot：
User
↓
你的 Website
↓
Backend
↓
Paid LLM API
對 User 來說，他可能只是一直按：
Send
但每按一次，
後面其實都是：
你的 API Key 在幫他付錢。
如果完全沒有 Consumption Limit，攻擊者只要一直讓你的系統處理高成本 Request：
大量 Requests
+
大量 Tokens
+
長 Output
+
昂貴 Model
可能就會變成：
Server：我還活著。
AI：我也還活著呦。
你的帳單：📈📈📈📈📈💸💸💸💸💸
🤣
這就是 Denial of Wallet 的概念。
目標不一定是：
把你的 Server 打掛。
也可能是：
讓你的服務持續幫我執行昂貴的運算，最後造成巨大的成本。
看到這裡可能會想：
沒關係啊，我有 Rate Limit。
例如：
每個 User
每分鐘最多 10 Requests
問題是：
這 10 個 Request 可以是：
10 個短問題
也可以是：
10 個超長 Context
+
超長 Output
+
高成本 Model
雖然數量都是：
10 Requests
但最後的 Consumption 完全不同。
所以 AI Application 的限制不能只看：
Requests / Minute
還可能需要一起看：
Tokens / Minute
Tokens / Day
Input Size
Output Size
Context Size
Cost / User
Cost / API Key
也就是：
不只限制「你可以問幾次」，還要限制「你最多可以用掉多少資源」。
這也是為什麼到了 AI，傳統 Rate Limit 還是需要，但已經不能是唯一一道防線。
現在很多 LLM 都支援很大的 Context Window。
也就是一次 Request 可以塞進非常多內容。
例如：
System Prompt
+
Conversation History
+
RAG Documents
+
Uploaded Files
+
User Input
這對 Application 當然非常方便。
以前一份很長的文件可能塞不進去，現在可以直接丟進 Model。
但從 Resource Consumption 的角度來看，
可以放很多，不代表一定要讓 User 無限制地放。
例如一個 Chat Application：
User 第一次問：
Message 1
下一次可能變：
Message 1
Message 2
再下一次：
Message 1
Message 2
Message 3
如果系統每一次都把整段 Conversation History 重新送給 Model：
Conversation 越來越長
↓
每次需要處理的 Context 越來越多
↓
每一輪成本也可能跟著增加
如果再加上：
Upload File
RAG Context
Tool Result
整個 Context 就可能變得更大。
所以問題不是：
Model 最大可以支援多少 Context？
而是：
我的 Use Case 到底需要多少 Context？
例如一個單純的客服 Bot，
可能根本不需要永遠保留前面 100 輪對話。
可以透過：
限制 History
摘要舊 Conversation
限制 Retrieved Documents
限制 Upload Size
控制每次真正送進 Model 的內容。
簡單來說：
Model 支援的最大值，不應該直接等於你的 Application 上限。
接下來是現在越來越常看到的：
Reasoning Model。
這類 Model 在回答之前，可能會使用更多運算去處理比較複雜的問題。
所以這時候又出現一件有趣的事情：
Prompt 很短，不代表 Request 一定很便宜。
例如 User 只送一句：
幫我完整解出這個複雜問題。
Input 本身可能只有幾個 Token。
但 Model 在背後可能需要進行比較多的推理運算。
所以：
Input Size 很小
不一定等於：
Resource Consumption 很小
如果 Reasoning Budget 或 Output Budget 完全沒有上限，
攻擊者也可能刻意設計一些問題，
讓 Model 花大量資源在：
長時間推理
反覆處理
大量輸出
這也再次說明：
不能只看 Input 大不大。
真正該看的其實是：
整個 Request 最後到底消耗了多少資源？
現在 AI 又不只會讀文字。
很多 Application 已經可以處理：
Image
Audio
Video
Document
這些就是 Multimodal（多模態）。
問題是：
一個：
「幫我看這張小圖片」
跟：
「幫我分析這支一小時的影片」
雖然從 API 層來看，都可能只是：
1 Request
但後面的處理成本差很多。
所以如果你的 Application 支援 Multimodal，
限制資源時也不能只看：
Request Count
還要思考：
最大 File Size
圖片數量
Image Resolution
Audio Duration
Video Duration
每次最多上傳幾個檔案
不然就會變成：
使用者一次只能送 5 個 Request。
結果每一個 Request 都丟超大的檔案🤣
那這個限制其實沒有真的解決問題。
還記得 Day 07 講 Excessive Agency 嗎？
Agent 不只會回答問題，
還可能自己去呼叫：
Search
Database
API
Email
MCP Tool
Other Agent
這時候 Resource Consumption 又多了一層。
假設 User 只下了一個很普通的指令：
幫我研究這間公司的資料，最後整理成一份完整報告。
對 User 來說：
我只送了 1 個 Request。
但 Agent 為了完成這個 Task，
可能實際跑：
User Request
↓
LLM 判斷下一步
↓
Search
↓
LLM 整理結果
↓
再 Search
↓
LLM
↓
Database
↓
LLM
↓
Another Tool
↓
LLM
所以：
1 User Request
背後可能已經變成：
多次 LLM Call
+
多次 Tool Call
+
多次 API Call
這就是 Agent 系統很容易遇到的問題：
User 看到的 Request 數量，已經不等於系統真正執行的操作數量。
如果 Agent 的 Workflow 沒有設定好上限，一個 Task 就有可能一直往下展開。
甚至 Workflow 寫得不好時：
Agent
↓
Call Tool
↓
Tool 回傳
↓
Agent 覺得還要再 Call
↓
Tool 回傳
↓
繼續 Call
↓
...
最後跑成 Loop。
這時候最可怕的不是 User 一直狂按按鈕。
而是：
你的 AI 自己開始幫你燒 Token。
🤣
Agent 還有另一種情況叫：
Tool Call Fan-out。
可以把它簡單理解成：
一個 Task 往下展開成很多個操作。
例如：
幫我分析 100 間公司
Agent 可能決定：
Company 1 → Search
Company 2 → Search
Company 3 → Search
...
Company 100 → Search
接著每一個 Search Result 又重新丟給 LLM 分析。
原本只是：
1 User Request
最後可能展開成：
100 Search Calls
+
100 LLM Calls
+
最後再一次 Summary
如果再有 Sub-agent：
1 Agent
↓
5 Sub-agents
↓
每個又呼叫 20 個 Tools
資源就可能很快被放大。
所以到了 Agentic AI，不能只問：
User 一分鐘可以送幾個 Request？
還要問：
一個 Task 最多可以跑幾步？最多可以 Call 幾次 Tool？最多可以花多少錢？
講了這麼久成本，
可能會覺得：
所以這條就是保護 AI 帳單？
其實不只。
如果今天是自己 Hosting Model，
或背後有固定的 GPU / CPU Resource，
大量 Consumption 一樣可能造成：
CPU / GPU 被占滿
Memory 被耗盡
Queue 塞滿
Response 越來越慢
正常 User 拿不到資源
最後結果就是：
Service Availability 出問題。
概念變成：
Attacker
↓
大量消耗 AI Resource
↓
系統忙著處理昂貴 Request
↓
正常 User 等不到
↓
Service Degradation / DoS
所以 LLM06 真正在保護的其實包含：
不是只有帳單。
OWASP 在 Unbounded Consumption 裡還有提到一種風險：
Model Extraction。
這個可以先不用想得太複雜。
概念就是：
攻擊者透過大量 Query Model API，蒐集很多 Input / Output，試著模仿這個 Model 的能力。
例如：
Attacker
↓
大量問問題
↓
收集 Model Response
↓
建立自己的 Dataset
↓
拿去訓練另一個 Model
這跟前面：
把 Server 打掛
把帳單打爆
看起來不太一樣。
但它們共同需要的一個條件是：
系統允許大量、沒有被妥善控制的 Model Usage。
所以 Unbounded Consumption 關心的不只是：
「User 有沒有用太多資源？」
也包含：
如果使用方式完全沒有限制，這些大量 Query 還可能被拿去做什麼？
講了這麼多，核心其實就是一句：
每一個會消耗資源的地方，都要有合理的邊界。
我自己會整理成幾個方向。
最基本的一層還是：
User
API Key
Organization
IP
限制：
Requests / Minute
Requests / Hour
Requests / Day
至少不要讓同一個來源可以完全無限制地打 API。
但要記得：
Rate Limit 是第一層，不是全部。
除了 Request Count，
還可以限制：
Max Input Tokens
Max Output Tokens
Tokens / Minute
Tokens / Day
例如：
User A
每天最多：
100 Requests
同時限制：
100,000 Tokens
這樣才不會出現：
Request 數量正常
↓
但每一個都超級昂貴
的情況。
如果支援：
Document
Image
Audio
Video
就可以根據 Use Case 設：
最大 File Size
最多 File Count
最大 Image Resolution
最大 Audio Duration
最大 Video Duration
原則很簡單：
不要因為 Model 做得到，就把最大能力全部直接開給 User。
如果背後使用付費 AI API，
那 Cost 就不能只當成財務問題。
它也應該變成：
Security Control。
例如：
Per User Budget
Per API Key Budget
Per Team Budget
Daily Budget
Monthly Budget
可以設定：
快接近上限
→ Alert
超過 Hard Limit
→ Stop / Restrict
重點是：
Alert 跟 Limit 是不一樣的。
如果只是：
帳單到 1000 美金
↓
寄 Email
但系統還是可以繼續花，
那攻擊發生得夠快時，你看到 Email 的時候可能已經：
😇...💸💸💸
所以真正重要的是：
到達某個上限後，系統本身有能力停下來。
如果是 Agent，
就要另外限制：
Max Steps
Max Tool Calls
Max Execution Time
Max Recursion Depth
Max Cost Per Run
例如：
一個 Task
最多跑 20 Steps
超過
↓
Stop
或者：
同一個 Tool
連續失敗 5 次
↓
Stop
這種概念很像：
Circuit Breaker（斷路器）。
當系統開始出現：
Recursive Loop
Tool Call 爆量
Execution Time 過長
Cost 異常
就直接把流程停掉。
而不是：
Agent 應該等一下就自己停了吧？
以前做 Application Monitoring，
可能很常看：
Error Rate
Latency
CPU
Memory
到了 AI Application，
還可以再多看：
Token Usage
Cost
Context Size
Model Usage
Tool Calls
Execution Steps
例如某個 User 平常一天使用：
5,000 Tokens
結果今天突然變成：
5,000,000 Tokens
即使：
沒有 Error
沒有 500
Service 也還活著
這本身就已經是一個值得調查的異常。
所以在 AI Application 裡：
Cost 和 Consumption 本身，也可以是一種 Security Signal。
以前做 API Security，
我們很容易問：
一個 User 可以打幾次 API？
但到了 AI Application，
現在還要多問一句：
一個 User 最多可以讓我的系統消耗多少資源？
因為：
1 Request
已經不代表：
固定的 1 份成本
它可能背後包含：
大量 Context
+
大量 Output
+
Reasoning
+
Multimodal Input
+
Tool Calls
+
Agent Loop
最後從：
一個看起來很普通的 Request
一路變成：
一張完全不普通的帳單
🤣
所以今天我會記：
不要只限制 User 可以「用幾次 AI」，而是要限制一次 Request、一個 User，甚至一個 Agent Task，最多可以消耗多少資源。
Rate Limit 只是開始。
真正需要設定邊界的可能是：
Request
Token
Context
File
Time
Cost
Tool Call
Agent Step
簡單來說：
只要是會消耗資源的地方，就不應該是 Unbounded。
iThome鐵人賽
看影片追技術