總結：LLM 應用安全檢查清單與心法

查核資訊： 本文於 2026-08-25 查核 NIST AI Risk Management Framework、NIST AI 600-1、NIST SP 800-218A、OWASP GenAI LLM Top 10 2026 與 OWASP Artificial Intelligence Security Verification Standard 1.0。NIST AI RMF 1.0 正在修訂；標準、威脅分類與建議控制仍會變動，正式採用前請重新確認最新版本與適用要求。

LLM 應用安全檢查清單如果只列「有使用 guardrail（護欄）」、「有做權限控管」與「有保存紀錄」，每一項都可能勾選完成，但團隊仍然無法回答三個問題：guardrail 漏判後由哪個元件阻擋、權限判定依據是什麼，以及紀錄是否足以追查一次未授權動作。

前 29 篇從模型行為的不確定性出發，依序測試提示注入、RAG、Agent、工具、供應鏈、輸入與輸出防禦、敏感資料、稽核、成本控制與自動化紅隊。這些測試最後形成一個明確判斷：模型可以參與判斷與提案，但資料存取、授權、執行與外部副作用必須由可驗證的系統控制決定。

因此，這份清單不只問「控制是否存在」。每個完成項目都要回答五件事：

缺少其中一欄時，項目只能標成「待確認」，不能標成完成。

先決定驗證深度

OWASP Artificial Intelligence Security Verification Standard（AISVS）1.0把可測試的 AI 安全要求分成三種驗證層級。Level 1 是所有 AI 應用的基本控制；Level 2 適合正式環境、面向客戶、處理個資或做出重要決定的系統；Level 3 用於關鍵基礎設施、安全關鍵與高保證環境。OWASP 建議多數正式系統至少以 Level 2 為目標。

本篇清單不是 AISVS 的翻譯，也不是通過 AISVS 的證明。團隊應先依使用情境決定驗證深度，再把本篇當成架構與工程交接用的起點。正式稽核仍要回到 AISVS 的完整要求、組織政策、契約與所在地法規。

先回答下列四個問題：

1. 系統會接觸哪些個資、機密、租戶資料或受管制內容？
2. 模型輸出可以到達哪些功能、資源與外部系統？
3. 錯誤動作能否撤銷？最大影響範圍是多少？
4. 系統是內部輔助工具、對外服務，還是能自主執行高風險動作的 Agent？

這四個答案會決定後續控制的嚴格程度。唯讀公開資料的摘要器與能寄信、付款或修改正式資料的 Agent，不應使用同一份最低要求。

一、範圍、資產與信任邊界

• [ ] 已列出使用者、管理者、模型供應商、資料來源、RAG、工具、記憶、輸出目的地與外部服務。
• [ ] 已標出每個不可信輸入入口，包括使用者 prompt、網頁、文件、圖片、語音、檢索內容、工具回傳與上游模型輸出。
• [ ] 已畫出資料流與信任邊界，並把 request、模型 response、log、trace、debug evidence 與公開報告視為不同資料路徑。
• [ ] 已為每項資產指定機密性、完整性與可用性需求，以及事故負責人。
• [ ] 已定義模型允許影響的欄位；應用程式一律忽略模型輸出的身分、權限、政策與核准結果。
• [ ] 已記錄部署環境、租戶邊界、外部依賴、合法測試範圍與停止條件。

NIST AI RMF要求組織把風險管理放進 AI 系統的設計、開發、使用與評估，而不是只在上線前做一次掃描。威脅建模的作用是把抽象風險放回實際系統：同一段模型輸出在終端機只是文字；HTML 渲染器、shell、SQL、郵件或付款工具會把文字轉成顯示內容、命令、查詢或外部動作，所以每個目的地（sink）都需要不同的安全控制。

二、輸入與模型可見內容

• [ ] 已限制輸入類型、長度、來源數、總內容量與可接受的檔案格式。
• [ ] 解析器（parser）與擷取器（extractor）採允許清單，只把必要欄位送進後續流程；HTML 註解、文件中繼資料（metadata）、檔名與隱藏內容都有明確處理政策。
• [ ] 每份外部內容都保留來源紀錄（provenance），包含控制者、租戶、擷取時間、內容雜湊與可信用途；格式轉換後仍保留這些資料。
• [ ] System prompt、developer 訊息、RAG 區塊與 tool schema 不被當成保密或授權邊界。
• [ ] 模型可見內容只包含完成當前任務所需的資料，不把憑證、完整資料集或不相關機密交給模型。
• [ ] 輸入分類器與 guardrail 的誤判、漏判、支援語言、版本與判定門檻都有測試；分類器失敗時仍有後續確定性控制。

隔離、標記與 prompt 強化可以降低模型失守機率，但自然語言標籤不會因此成為解析器強制執行的安全邊界。應用程式仍要決定哪些資料能進入模型請求（request），以及模型輸出能影響哪些欄位。

三、RAG、資料與記憶

• [ ] 資料進入知識庫前會驗證來源、擁有者、授權、內容類型、審核狀態與完整性。
• [ ] 檢索前先依可信身分與租戶縮小允許檢索的資料集合（eligible corpus），再做相似度排名；向量相似度不參與授權。
• [ ] 切塊（chunk）、embedding、索引與原始文件都能追溯版本，並能找出哪個片段進入哪次 request。
• [ ] 文件撤銷、權限變更或內容刪除後，索引重建與快取失效有明確時限及驗證方式。
• [ ] 使用者與 Agent 的記憶有寫入條件、來源標記、租戶隔離、保存期限、刪除與重建流程。
• [ ] 已用惡意文件、跨租戶資料、同租戶污染、過期索引與正常對照案例測試檢索路徑。

先做權限過濾，再做相似度排名。Day 17 的固定實驗沒有啟用租戶過濾時，其他租戶的文件會進入 Top-1；加入只允許測試租戶 Alpha 的條件後，該文件連候選集合都進不去。同屬 Alpha 的污染文件仍能通過租戶過濾並壓過乾淨政策，所以來源治理與檢索授權不能互相取代。

四、模型與供應鏈

• [ ] 模型使用不可變更的版本或完整 digest（內容雜湊識別值），不只寫 latest 或模型家族名稱。
• [ ] 推論服務、system prompt、工具 schema、推論參數與重要範本都有版本，能對應到每次測試與正式部署。
• [ ] 套件鎖檔記錄套件檔案的雜湊值；模型、資料、容器、MCP Server 與外掛都有來源、授權、完整性與更新政策。
• [ ] 外部元件接入前會檢查可執行格式、安裝行為、所需權限、網路目的地、資料處理方式與停止方法。
• [ ] 更新會先在隔離環境比較舊版與新版；模型變更與測試工具變更分開驗證。
• [ ] 已準備回復上一個模型、prompt、索引、工具與應用程式版本的程序。

NIST SP 800-218A補充既有 Secure Software Development Framework，涵蓋 AI 模型生產者、使用模型的 AI 系統生產者與採購者，並要求與 SP 800-218 一起使用。模型不是唯一供應鏈元件；載入模型的程式、資料集、套件、容器、外掛與自動化測試工具都可能改變執行邊界。

五、模型輸出與下游處理

• [ ] 模型輸出先通過封閉 schema（結構規格）、型別、長度、列舉值與額外欄位檢查，解析失敗時停止。
• [ ] 內容政策、事實檢查與業務規則各自留下判定，不用單一安全分數代替所有問題。
• [ ] 應用程式會依每個輸出目的地套用轉義、編碼、允許清單或安全 API；HTML、SQL、shell、URL 與 Markdown 不共用一套處理。
• [ ] 模型產生的命令、程式碼、路徑、URL 與查詢不會直接執行；應用程式若要執行必要操作，會把具名動作對應到已納入版本控制的安全實作。
• [ ] 模型拒絕、分類器命中或比對字串（marker）出現不會直接等同攻擊成功；判定會檢查資料是否跨界、動作是否執行與 sink 是否產生影響。
• [ ] 正常輸出、邊界輸出、惡意輸出、解析錯誤與下游失敗都有測試。

Day 23 的配對實驗把模型產生的同一份待處理輸出，分別送進未轉義與防禦路徑。攻擊組共產生 5 份輸出，其中 4 份符合 JSON 格式，並在未轉義路徑被解析成 HTML 元素（active HTML）；防禦路徑處理 5 份輸出後，都沒有形成 active HTML。這個結果只證明固定輸出在兩條渲染路徑的差異，但已足以說明輸出目的地的安全控制不能交給模型自行保證。

六、Agent、工具、權限與確認

• [ ] 模型只能提出動作（action）與必要參數；應用程式不會把模型輸出的 user ID、tenant、role、policy、approved 或 allow 欄位當成授權依據。
• [ ] 後端從已驗證的 session、token 或服務身分取得可信主體（subject），並針對系統認定的正式資源（canonical resource）逐次重新授權。
• [ ] 工具使用封閉 schema，拒絕額外欄位；參數通過型別檢查後仍要接受目的地、資源與業務政策驗證。
• [ ] Agent 只取得任務需要的工具、資料與時間範圍，讀寫權限分開，權限可以到期與撤銷。
• [ ] 高風險動作需要特定動作確認；確認綁定完整動作內容（action envelope），內容變更、逾時或撤銷後不得沿用。
• [ ] 批次動作會逐項顯示差異與影響；不可逆或高價值動作不使用一次籠統確認全部放行。
• [ ] 應用程式會在受限制的環境中執行工作，並限制執行身分、Linux capabilities（權限能力）、檔案系統、網路、程序、CPU、記憶體與逾時。
• [ ] 工具回傳保留為不可信資料，不能改寫 system policy、授權結果或下一個工具動作。

Day 25 的固定矩陣顯示，功能範圍、資源權限、特定動作確認與執行期沙箱各自處理不同失敗點。Day 25 另用模型產生 20 份提案，全部都符合 JSON 格式；其中 9 項提案涉及私密讀取或報告寫入，並在容器建立前被資源與確認政策擋下。有效格式只代表資料能解析，不代表動作已獲授權。

七、敏感資料與隱私

• [ ] 每條資料流都套用資料最小化，只收集、傳送與保存完成任務所需的欄位。
• [ ] Prompt、response、embedding、快取、記憶、log、trace、除錯檔與紅隊證據分別定義敏感資料政策。
• [ ] 個人可識別資訊（PII）與機密偵測使用符合資料類型、語言與產品格式的規則；通用工具之外另有產品專用辨識規則。
• [ ] 遮罩後會驗證必要資訊仍可使用，也會測試誤判、漏判、同義改寫、分段與結構化欄位。
• [ ] 租戶隔離在資料庫、檢索、快取、物件儲存、記憶與備份層都能獨立驗證。
• [ ] 保存期限、存取權限、加密、刪除、匯出與事件通知符合組織政策與適用法規。

Day 26 使用 24 個英文虛構案例。固定規則與分層路徑都在 16 個已標記的敏感資料片段中辨識出 12 個，召回率（recall）是 0.75；四個漏判都是虛構人名。四條測試路徑都沒有改動 12 個正常對照案例，但這份小型資料集不能證明正式流量也不會被誤判。團隊必須用自己的語言、資料格式與誤判成本重新評估 PII 控制。

八、可用性、成本與濫用

• [ ] 已限制每個可信主體、租戶、來源與整體服務的請求速率，並定義可接受的短時間突增量。
• [ ] 已限制單次輸入 token、單次輸出 token、期間總 token、對話輪數與 Agent 最大步數。
• [ ] 已限制並行工作、佇列深度、工具重試、遞迴與總逾時。
• [ ] 已設定每日或每期預算、告警門檻、硬上限與降級模式。
• [ ] 模型、檢索、工具與外部服務失敗時有預設阻擋（fail-closed）、備援、斷路器（circuit breaker）或人工接手策略。
• [ ] 壓力測試會驗證限制實際生效，不只檢查設定檔存在。

請求速率、token、並行數與預算是四種不同限制。Day 28 的固定事件中，完整控制路徑拒絕 7 筆請求；拒絕原因分布在請求速率、輸入 token、輸出 token、總 token、並行數與預算。只加一個 API 速率限制無法處理其他資源耗用。

九、觀測、稽核與事件處理

• [ ] 每次互動都有可追蹤的 ID，能串起輸入、檢索、模型、政策、工具、確認與最終 sink。
• [ ] 稽核事件記錄可信主體參照、動作、正式資源、政策版本、判定與原因代碼，不保存不必要的原文與憑證。
• [ ] 紀錄（log）與追蹤資料（trace）使用欄位允許清單；完整 prompt、response、PII、secret 與 session token 預設不進入遙測。
• [ ] 稽核紀錄有完整性、順序與外部檢查點；保存系統本身有最小權限、加密、留存與刪除政策。
• [ ] 告警對應可執行的處理程序，包含停用工具、撤銷權限、切換模型、隔離租戶與保存證據。
• [ ] 事件結束後會建立最小重現案例、修正控制、回歸測試與追蹤期限。

Day 27 的固定測試登記了 5 種稽核事件竄改；加入終點檢查點後，5 種竄改全部被偵測。測試如果不提供檢查點，刪除尾端事件後，剩餘紀錄仍能形成內部一致且驗證有效的事件鏈。雜湊串接只能證明已保存資料的內部關係，外部檢查點才能協助發現尾端截斷。

十、測試、發布與持續重驗

• [ ] 上線前測試包含正常對照、已知攻擊、邊界輸入、失敗路徑與人工語意複核。
• [ ] 測試固定應用程式、模型、資料、prompt、工具、參數、案例、判定方法與請求上限。
• [ ] 原始證據與可公開摘要分開保存；摘要包含版本、案例 ID、分母、結果、雜湊與限制。
• [ ] 自動判定器（detector 或 scorer）的命中會由人員判斷實際影響，不直接建立「已被入侵」結論。
• [ ] 模型、資料、索引、system prompt、parser、renderer、工具、權限、guardrail 或測試工具變更後會重跑相關案例。
• [ ] 已修正的弱點會加入持續迴歸測試，並保留修正前後的結果。
• [ ] 正式紅隊測試使用專用租戶、虛構資料、受限帳號與停止條件，高風險工具不會觸發真實副作用。
• [ ] 發布決策有具名核准者、未解風險、到期日、回復計畫與上線後觀測項目。

Day 29 的 garak 與 PyRIT 實驗顯示，兩套固定工具能在 9 個只於本機內部傳送的 loopback 請求上限內完成既定流程。這次實驗沒有測試真實模型，也沒有證明工具具備完整涵蓋率。自動化紅隊的主要價值是持續重跑已知案例與保存一致證據，不是替產品簽發安全證明。

把勾選結果變成證據紀錄

團隊可以為每項控制建立一筆最小紀錄：

狀態欄不能只寫「通過」。團隊還要保存測試分母、判定方式與未涵蓋範圍，否則下一次模型或程式變更後無法比較。

六項上線阻擋條件

下列任一條成立時，系統不應直接進入正式環境：

1. 團隊無法畫出資料流，或無法說明模型輸出最後會到達哪些功能與系統。
2. 模型輸出可以決定身分、權限、核准或直接執行高風險動作。
3. System prompt 或隱藏內容（hidden context）保存憑證，或被當成唯一授權邊界。
4. RAG 只依相似度取資料，沒有先做可信身分、租戶與資源授權。
5. 模型輸出直接進入 HTML、shell、SQL、URL 或工具 sink，沒有目的地專用驗證。
6. 團隊無法辨認正式環境使用的模型、資料、prompt、工具與政策版本，也沒有回復與事件處理程序。

風險接受不是把勾選框改成完成。風險接受要寫明負責人、理由、補償控制、有效期限與重新評估條件。

最後留下三個工程原則

第一，模型不擁有授權。模型可以提出讀取、寫入或工具動作，應用程式必須使用可信身分、canonical resource 與後端政策重新決定。

第二，每個邊界只回答一個問題。Schema 驗證格式，PII 偵測器尋找敏感資料，guardrail 判斷內容，後端授權元件決定權限，渲染器保護輸出目的地。任何一項通過都不會讓資料變成全面可信。

第三，安全是持續保存證據的流程。模型、資料、prompt、工具與攻擊手法都會改變；團隊必須知道哪個控制在何處生效、哪份測試證明有效，以及什麼變更會使證據失效。

OWASP GenAI LLM Top 10 2026提供威脅地圖，AISVS 提供可驗證要求，NIST AI 600-1則透過治理、盤點、衡量與處置（Govern、Map、Measure、Manage）四項功能，把生成式 AI 風險管理放進整個生命週期。團隊可以從威脅建模開始，選定適用要求，實作確定性控制，再用正常對照、攻擊案例、人工複核與持續觀測驗證。

檢查清單真正要留下的不是一排勾選，而是一組能重現、能交接、能在變更後重新判定的安全證據。

參考資料

• NIST AI Risk Management Framework
• NIST AI 600-1：Artificial Intelligence Risk Management Framework — Generative Artificial Intelligence Profile
• NIST SP 800-218A：Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• OWASP GenAI LLM Top 10 2026
• OWASP Artificial Intelligence Security Verification Standard 1.0
• LLM Application Security Lab

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

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

上一篇：AI Red Teaming 實戰：自動化攻擊測試 · 下一篇：LLM 應用資安怎麼學：從威脅地圖、攻擊靶場到紅隊工具