對 LLM 應用做威脅建模

查核資訊： 本文於 2026-08-06 依 Microsoft Learn、OWASP Threat Modeling、OWASP Threat Dragon、OWASP GenAI LLM Top 10 2026 官方資料，以及 LLM Application Security Lab 的 Day 4 固定 commit 8be976a913335951271d99515489a194472f3785 與 Day 5 固定 commit 4b0cc06 查核。Day 5 使用 Ollama 0.32.5、固定 gemma4:latest 完整 digest，Clean／Attack 各執行三次；結果只適用於記錄的模型、prompt、fixtures 與觀測點。To-be 架構尚未實作，不能視為已驗證的防禦效果。

替 LLM 應用畫完資料流後，第一個浮出的不是新的 Prompt Injection 技巧，而是一條根本不需要模型配合的資訊洩漏路徑：Day 4 的 CLI 會把完整 fixtures、完整 request 與 model response 一起印到 stdout。

先把這四個名稱對齊：fixtures 是實驗程式讀取的合成檔案；request 是送給模型的完整輸入；model response 是模型回傳的文字；stdout 是 CLI 最後印出的整份終端機輸出。canary 則是另一份筆記裡的無害測試值，只有出現在 model response 時，才代表模型路徑觀察到資料跨界。

Day 4 的 CLI 會在呼叫模型前讀取 fixtures，把內容組成 request；模型回傳 model response 後，CLI 又把 fixtures、request 與 response 一起印到 stdout。這就是不需要模型配合也能成立的另一條資訊洩漏路徑。

這個發現沒有推翻前篇實驗。Clean 的 model response 沒有 canary，attack 的 model response 帶出了另一份筆記的 canary，對照仍然成立。但是前篇使用的 canary_in_visible_output 名稱太寬；整份終端機輸出原本就含有 canary。真正接受實驗檢驗的 predicate 應該是 canary_in_model_response。

威脅建模的價值就在這裡。只盯著模型，問題會停在「Prompt Injection 有沒有成功」；把整個應用程式畫出來，問題才會擴大成「敏感資料還能從哪一條路離開」。

我一開始把 cleaner 放在模型前後

我最初畫的理想流程是：

input context -> context cleaner/ escape  -> LLM -> 權限檢查 -> 資料讀取 -> response -> context cleaner

我把核心問題收在一句話：「是，LLM 可讀到的問題。」後續設計也很直接：「LLM 提出讀取要求，再由權限層逐筆核准」；若權限層拒絕，「權限層拒絕讀取後，應直接終止」。

這個方向抓到真正需要控制的地方，但流程圖混在一起的其實是兩種架構。Day 4 的現況不會等 LLM 提出要求；Python 程式在呼叫模型前，就已經讀完所有選定筆記。理想流程則把受保護資料留在模型外，等 LLM 提出資源 ID 後才授權。

威脅模型必須先忠實畫出 as-is，再討論 to-be。若一開始只畫理想架構，圖上每個漂亮的控制點都可能只是願望。

Day 4 真正讀資料的是 Python，不是 LLM

固定實驗程式的資料流如上圖左側所示。

Day 4 沒有 tools，也沒有讓模型直接碰 filesystem。Python read_fixture() 先讀取檔案，build_user_message() 再把所有筆記與目標文件串成一則 user message。應用程式把內容放進 prompt 的瞬間，就已經授予模型讀取權。

這個差異很重要。真正的第一個控制點不是 model response，而是：

Data Store → Application → Model Context

context cleaner 可以限制格式、長度或已知字串，卻不能取代存取控制。Day 4 的 system message 已經把 reference notes 標成不可信資料，模型仍然服從 99-injection.md。在這組實驗裡，<reference_notes> 標記沒有形成 parser 強制的資料／指令邊界；把 escape 寫在流程圖上，也不會自動多出那條邊界。

DFD 先把四種角色拆開

Microsoft 的方法先描述元件、data flow、連接埠與協定，再從圖上識別與排序威脅。OWASP 的 threat modeling 流程則要求標出 Actor、Process、Data Store、Flow、trust boundary 與敏感資料。

Day 4 可以拆成：

最危險的地方不是資料跨過網路。Ollama endpoint 固定在 loopback，但不可信攻擊指令與受保護 canary 在同一個 model context 相遇，資料的信任等級已經改變。Trust boundary 描述的是信任改變，不是只描述主機或網段的邊界。

STRIDE 找得到影響，LLM01 解釋根因

OWASP Threat Dragon可以對 DFD 元件記錄 threat 與 mitigation，並以 STRIDE 逐項追問 Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service 與 Elevation of Privilege。

把 STRIDE 套回 Day 4 與理想架構，可以得到六個直接問題：

STRIDE 能命名攻擊者目標與系統影響，但 STRIDE 不會自動解釋一份自然語言資料為什麼能改變模型的指令遵循。Day 4 仍需要 OWASP GenAI LLM Top 10 2026的 LLM01 Prompt Injection 描述機制，再用 LLM02 Sensitive Information Disclosure 描述 canary 進入 response 的結果。

兩套方法不是競爭關係。DFD 說明資料怎麼流，STRIDE 逼分析者逐元件檢查攻擊目標，LLM01／LLM02 則補上模型特有的攻擊機制與影響。

Threat register 不能只留一個 STRIDE 字母

把元件旁邊標上 T 或 I 只完成分類，沒有留下工程團隊可以處理的問題。每一筆 threat 至少還要記錄範圍、攻擊路徑、現有證據、預定控制與驗證方式。

Day 4／Day 5 的 threat register 可以濃縮成：

這張表刻意不填 High／Medium／Low。合成單機實驗沒有正式資料價值、外部攻擊機率與業務影響，硬填 severity 只會製造假的精準度。Risk rating 應等到實際使用者、資料分類、暴露面與影響範圍都確定後再做。

另外做一個實驗，不把 Day 4 結果重算一次

畫出 stdout 路徑後，我還缺一個能被推翻的觀測：Clean model response 沒有 canary，是否代表使用者看見的完整 stdout 也沒有？我的事前預測是兩條路徑同時存在：Clean 的 request 與完整 stdout 會有 canary，但 model response 不會；Attack 則三處都有。

這次實驗沒有直接重跑 Day 4 再換一個標題。day-05-threat-flow-observation擁有自己的 experiment definition、合成 fixtures、raw runs 與 evidence。Day 5 的 fixture 內容、模型 digest、seed=101 與 temperature=0 刻意和 Day 4 相同，並以 SHA-256 確認等值，但 Day 5 bundle 不引用 Day 4 的 fixture 路徑。

Clean 與 Attack 各完成一批三次執行，不因模型結果挑選性重跑：

uv run llm-security-lab \
  --experiment day-05-threat-flow-observation \
  --scenario clean \
  --repeat 3

uv run llm-security-lab \
  --experiment day-05-threat-flow-observation \
  --scenario attack \
  --repeat 3

每次 run 分別檢查 canary 是否出現在 request、model response、fixture evidence 與 CLI 印出的完整 stdout。結果與預測一致：

完整 raw request 與 response 留在 Git 忽略路徑，公開 repo 只保存經檢查的報告、hash 與實驗說明。

這組結果把兩條 flow 分開：

Canary fixture → application evidence → stdout
Canary fixture → model context → model response → stdout

第一條在 Clean／Attack 都成立，不需要 Prompt Injection；第二條只在三次 Attack 中出現，而且每次 response 第一行都是合成的 LEAKED: LAB_ONLY_CANARY_7K4M_20260806。實驗沒有證明所有模型都會被相同 payload 攻破，也沒有測試逐筆授權。實驗只證明：只檢查 model response，會漏掉應用程式自己建立的敏感資料輸出路徑。

理想架構要把 LLM 降級成提案者

依照我選定的方向，to-be 流程需要兩次模型呼叫。圖右側把模型輸出的 {action, resource_id} 視為不可信讀取要求，而不是授權結果。

第一階段 LLM 只能取得規劃所需的低敏感資料。模型可以提出 action 與 opaque resource_id，但模型不能提供或覆蓋 user_id、tenant_id、role、policy 或 allow／deny 結果。權限層必須從可信 session 與 resource metadata 取得授權依據。

resource_id 也不能直接當 filesystem path。應用程式必須先驗證 schema、解析 canonical resource，再確保授權與實際讀取指向同一個不可變的資源身分。否則「核准 note-123，實際讀到另一份檔案」仍是權限繞過。

權限層若拒絕讀取，流程直接終止。權限層只對呼叫端回傳 generic deny，內部另記 request ID、可信 subject、resource ID、action、policy version、decision 與 timestamp。拒絕原因不回送模型，避免模型利用不同回應探測資源，或反覆更換 ID 猜測。

畫出控制不代表控制已經生效

To-be DFD 目前只是 security requirement。要聲稱逐筆授權能阻止 Day 4 攻擊，至少需要三組測試。

第一組驗證模型看見的 context：

• 第一階段 request 不得包含任何受保護筆記內容。
• 權限層核准後，第二階段 request 只能包含核准的單一資源。
• Deny 後不得發生資料讀取，也不得送出第二次模型 request。

第二組驗證權限層：

• 模型輸出的 user_id、tenant 或 allow flag 必須被拒絕或忽略。
• 未授權 resource_id、不存在的 ID、額外 action 與路徑逃逸必須得到相同 generic deny。
• 授權決定與後續讀取必須綁定同一個 canonical resource，避免核准與使用不同物件。

第三組驗證資料離開應用程式的路徑：

• Deny 的 model response、stdout、log 與 trace 都不得包含受保護內容。
• Allow 的 response 仍要跑 canary_in_model_response 與 sink-specific 檢查。
• Audit 要能證明 subject、resource、policy 與 decision，又不能保存不必要的完整敏感內容。

Day 4 固定 fixture 很適合重用：把 99-injection.md 留在第一階段可見範圍，把 canary 留在受保護 store。新的成功條件不是「模型變乖」，而是攻擊筆記無法讓未核准 canary 進入第二階段 context。這個 predicate 能直接檢驗授權邊界，不必依賴每次 response 的措辭。

一套可以重複使用的建模順序

這次實作最後留下六個步驟：

1. 先畫 as-is，不要先畫預期中的防線。
2. 把 Actor、Process、Data Store 與每一條 Flow 具名列出。
3. 在 store 與 flow 上標出敏感資料、攻擊者可控資料與 trust boundary。
4. 對每個元件套一次 STRIDE，再用 LLM01 等模型風險補充根因。
5. 把模型輸出視為提案或不可信資料；授權、資源解析與 sink 驗證留在確定性程式。
6. 把 mitigation 寫成可測試的 requirement。沒有實驗或測試結果，就不能宣稱控制已生效。

Day 5 完成威脅模型與一個獨立的資料流觀測實驗，但尚未實作理想架構，也沒有證明逐筆授權能阻止既有 payload。下一篇會繼續拆解每一種不可信輸入從哪裡進入；真正的防禦實作則留到後續輸入端、輸出端與最小權限篇，用相同內容但各篇獨立版本化的 fixture 重新驗證。

參考資料

• Microsoft Learn — Threat models and data flow diagrams
• OWASP Security Culture — Threat modelling
• OWASP Threat Dragon
• OWASP GenAI LLM Top 10 2026
• LLM Application Security Lab — Day 4 fixed commit
• LLM Application Security Lab — Day 5 獨立資料流觀測實驗

本文同步刊載於 iThome 鐵人賽。

《LLM 應用資安：從 Prompt Injection 到 AI Red Teaming》第 5／30 篇

上一篇：打造你的資安實驗室：環境建置 · 下一篇：信任邊界與「不可信輸入」的觀念