Learning Objectives
- 說明模型輸出為什麼要當成不可信任的輸入處理，並修補一個輸出處理的漏洞
- 依最小權限設計工具權限，分開讀取與寫入
- 說明資料外洩的組合條件：私有資料、不可信內容與對外通道
- 判斷人工確認的時機，說明確認疲乏與稽核紀錄的作用
模型輸出的可信度
上一課的結論是模型可能被說服。即使沒有攻擊，模型也可能誤解要求或回答錯誤。使用者說「把那封廣告信刪掉」，模型可能把整個收件匣當成對象。因此設計 AI 系統時要先採取一個假設：模型的輸出不可信任，它的權限要限定在出錯時也可以接受的範圍內。
OWASP LLM Top 10 稱這類問題為「過多的代理權」（Excessive Agency；2025 版編號 LLM06，2026 版升到第 3 項 LLM03），並指出不論原因是幻覺、注入或其他錯誤，系統都可能因此執行造成損害的動作。它的根源有三項：
| 根源 | 意思 | 範例 |
|---|---|---|
| 過多功能 | 工具的功能超過需要 | 只需要讀信的摘要助理，也能寄信與刪信 |
| 過多權限 | 工具對下游系統的權限超過需要 | 查自己成績的工具，使用可以讀取全校成績的帳號 |
| 過多自主 | 高影響的動作沒有經過獨立確認 | 自動刪除信件，沒有人工確認 |
本課的模擬環境。 輸出處理的練習是真的 Flask，在瀏覽器內執行，模型回應由固定函式模擬。權限練習是決定論模擬，沒有呼叫模型。信箱、網域與資料都是虛構的（第 1 課）。
模型輸出的處理
模型的輸出如果直接交給瀏覽器、資料庫或命令列，就等於讓不可信任的文字進入這些系統，第 7、8 課的漏洞會以新的形式出現。OWASP 對輸出處理不當（Improper Output Handling；2025 版編號 LLM05，2026 版列第 10 項）的建議是把模型當成其他使用者一樣對待：
| 輸出的去處 | 風險 | 處理方式 |
|---|---|---|
| 網頁 | 跨站腳本、外部連結與圖片 | 依情境轉義，需要 Markdown 時以允許清單清理（本平台用 DOMPurify） |
| 資料庫 | SQL 注入 | 參數化查詢，只讓模型提供值，不讓它組出 SQL |
| 命令列 | 命令注入 | 不把輸出交給殼層，改用固定的工具與參數 |
| 另一個工具 | 參數被竄改 | 由程式驗證型別、範圍與權限 |
下方的網站把模型的回應標記為 |safe 後輸出。開發者通常是為了顯示粗體或連結才這樣寫，但回應的內容受到文件影響。
工具權限與最小授權
第 14 課的最小權限原則同樣適用於模型的工具。OWASP 列出的作法包括：
- 只提供需要的工具：摘要信件的助理應該只能讀信，不能寄信或刪信
- 工具的功能要具體：提供「寫入指定檔案」而不是通用的殼層存取
- 限制下游權限：工具使用的資料庫帳號只有必要的操作權限
- 以使用者身分執行：工具呼叫要帶上目前使用者的授權範圍，查詢成績只回傳本人資料
- 完全仲裁：是否允許由下游系統判斷，不交給模型決定
- 分開讀取與寫入：寫入、刪除與對外傳送的風險遠高於讀取，要分別設定
資料外洩的組合條件。 Simon Willison 在 2025 年提出，當代理同時具備三項能力時，攻擊者就可能竊取資料，他稱之為 lethal trifecta：
- 能存取私有資料
- 會接觸不可信的內容
- 有對外通訊的管道
這三項單獨來看都很常見，也都有用途，問題在於同時存在。設計時可以嘗試移除其中一項，或讓它們不出現在同一次工作階段。NCSC 也建議以來源決定權限：模型處理不可信的外部信件時，其權限應該降到與該來源相同。設計模式的研究也探討讀過不可信內容後如何限制後續動作。這些作法都會犧牲部分功能，所以要依任務的風險取捨。
人工確認與確認疲乏
OWASP 建議高影響的動作由人確認。確認能否發揮作用取決於設計：
確認的時機。 不可逆的動作（刪除、付款）、對外傳送的動作，以及影響他人的動作，應該要確認。只讀取本人資料的動作通常不需要。
確認的內容。 畫面要顯示實際要執行的內容，例如完整的收件人與信件本文，而不是模型自己撰寫的摘要，否則使用者看到的可能也是受影響的文字。OWASP 2026 版同樣要求呈現實際動作，不以摘要代替。
確認疲乏。 確認過於頻繁時，使用者會傾向不閱讀就同意，OWASP 2026 版也指出確認次數過多會削弱判斷。上方練習的開關模擬了這種情況。常見的改善方式是減少不必要的確認，把確認留給真正有風險的動作；能由程式判斷的事情，例如收件網域，就由程式處理。
人工確認無法取代權限設計。它是最後一層防線，不應該是唯一的一層。
記錄、稽核與縱深防禦
AI 系統的紀錄要能回答「誰要求的、模型提出了什麼、實際執行了什麼、由誰確認」。上方練習下方的稽核紀錄列出實際執行的呼叫。OWASP 指出，記錄與速率限制不能防止過多代理權，但能縮短發現問題的時間並限制損害。NCSC 也建議記錄輸入、輸出與工具呼叫，並留意失敗的呼叫。
紀錄本身可能含有對話內容與個人資料，所以要依第 16 課的原則處理：限制存取、設定保存期限、遮罩不必要的資料。
把本課與前幾課合起來，一個能呼叫工具的 AI 系統可以這樣檢視：
| 層次 | 問題 |
|---|---|
| 設計 | 如果模型完全照著攻擊者的文字做，最壞會發生什麼事？ |
| 權限 | 每個工具是否都有需要？權限是否限定在目前使用者與任務的範圍？ |
| 資料流 | 私有資料、不可信內容與對外通道是否同時存在？ |
| 輸出 | 模型的輸出進入瀏覽器、資料庫、命令列之前是否經過處理？ |
| 確認 | 高風險動作是否由人確認？顯示的是實際內容嗎？ |
| 監控 | 工具呼叫是否有紀錄？異常時有沒有告警與應變計畫（第 16、17 課）？ |
每一層都可能失效，縱深防禦的目的是讓單一層的失效不至於造成嚴重後果。
重點整理
- 模型的輸出不可信任，進入瀏覽器、資料庫或命令列之前要依情境處理
- 過多功能、過多權限與過多自主是過多代理權的三項根源，都由程式與設定處理，不交給模型判斷
- 寫入、刪除與對外傳送要與讀取分開設定；工具以目前使用者的授權範圍執行
- 私有資料、不可信內容與對外通道同時存在時，資料就可能被送出去；移除其中一項或把它們分開，都會犧牲部分功能
- 人工確認適用於高風險動作，要顯示實際內容，並注意確認疲乏
- 紀錄與監控不能防止問題，但能縮短發現的時間；紀錄本身也要保護
- 提示注入目前沒有完全的解法，所以設計要以模型可能出錯為前提
本軌道到此結束。安全不是一次完成的工作，新的系統與新的攻擊方式會持續出現。請只在自己擁有或獲得明確授權的系統上練習（第 1 課）。
小測驗
網站把模型的回答以 |safe 輸出到頁面。即使模型來自可靠的廠商，這樣做仍有什麼問題？
一個只需要摘要信件的助理，使用的信箱權限也能寄信與刪信。這屬於哪一種問題？
一個助理能讀取使用者的信件，也能呼叫外部網址。若要降低資料外洩的風險，下列作法何者最直接？
助理每一個工具呼叫都跳出確認視窗。這樣的設計有什麼問題？
確認視窗顯示模型撰寫的摘要「寄送本週提醒給教學助理」，而不是實際的收件人與內容。問題在哪裡？
稽核紀錄能解決什麼、不能解決什麼？