Case 1
文件內容注入
AI 在讀文件時，被文件內的惡意指令誘導忽略原本規則，轉而暴露更多內容。
AI 安全與防呆：Prompt Injection、資料外洩、權限邊界
先講結論：當 AI 開始能查資料、調工具、跑 workflow 時，風險就不再只是答錯話，而是可能真的讀到不該讀的資料、做了不該做的事，甚至把錯誤動作放大成系統風險。
這章要解決什麼問題？
前面幾章已經把 Skill、MCP、OpenClaw 與 workflow 串起來了。第 10 章要處理的是最後一個不能跳過的問題：當 AI 不只會回答，還開始能讀資料、調工具、接系統時，哪些地方最容易出事？系統又該怎麼設計防呆？
為什麼 AI 一接工具就要談安全？
純聊天模型最多是講錯話；一旦系統開始查資料、寫資料、呼叫外部能力，風險就從內容品質問題升級成資料、權限與動作控制問題。
面向
純聊天情境
工具 / Workflow 情境
主要風險
答錯、幻覺、格式不穩
越權、資料外洩、錯誤執行、連鎖動作
影響範圍
內容層
系統層、資料層、權限層
控制重點
Prompt 與回覆品質
授權、白名單、審計、流程邊界
Prompt Injection 是什麼？
它不是傳統 SQL Injection 那種字串攻擊，而是利用內容本身去影響模型判斷，讓模型偏離原本的規則、流程或邊界。
- 本質： 用惡意或誤導內容去改變模型行為。
- 目標： 讓模型忽略原本指示、洩漏資料、亂用工具或跳過檢查。
- 危險點： 如果模型後面接了工具與 workflow，注入就不只是讓回答變差，而是可能真的讓系統做錯事。
Prompt Injection 在實務上怎麼發生？
它不一定來自使用者直接發難，也可能藏在文件、網頁、知識庫內容，甚至工具回傳結果裡。
Case 2
工具結果注入
外部搜尋結果、網頁內容或第三方系統輸出裡混進誤導指令，影響後續決策。
Case 3
使用者角色偽裝
使用者用像管理員、開發者或內部流程的口吻要求系統越過原本邊界。
資料外洩通常發生在哪三層？
很多資料外洩不是模型自己憑空發明的，而是系統在流程中把不該進模型的資料先交進去了。
輸入層
敏感文件、token、內部規則、個資或查詢結果直接被塞進 prompt 或上下文。
處理層
工具回傳太多原始資料，沒有裁切、遮罩與欄位過濾，導致模型拿到超出任務所需的內容。
輸出層
模型把不該回給使用者的內容原樣吐出來，例如內部規則、其他使用者資料、完整查詢結果。
權限邊界：真正的安全防線不在 Prompt
Prompt 可以指引模型，但不能當成最終安全機制。真正的邊界必須放在工具層、runtime 層與後端授權層。
控制方式
能做到什麼
不能依賴什麼
Prompt / 指示
告訴模型偏好、流程與限制
不能當最終授權機制
工具白名單
限制可見與可調用能力範圍
不能取代參數驗證與後端檢查
後端授權
真正決定誰能讀、誰能寫、能做到哪裡
不能只靠模型自己判斷身份
常見防呆設計清單
安全不是把 system prompt 寫得很兇，而是讓系統就算遇到錯誤判斷，也不容易越權、不容易外洩、不容易做出高風險動作。
- 工具白名單： 不把所有內部能力都暴露給 AI。
- 參數驗證： 工具輸入要檢查格式、範圍、身份與上下文。
- 結果裁切與遮罩： 工具輸出先縮到任務所需最小範圍。
- 高風險操作二次確認： 刪除、發送、寫入、發布等動作不要直接放行。
- 敏感資訊隔離： token、密鑰、內部提示與管理資料不要直接進模型可回吐區。
- 日誌與審計： 記錄模型要求了什麼、工具做了什麼、哪些請求被拒絕。
把這章跟前面串起來
- Skill 會定義做事方法，但不應默默擴權。
- MCP 會把能力接進來，但不應把所有能力全都暴露出去。
- OpenClaw / runtime 會協調流程，但不應把模型判斷等同於最終授權。
- Workflow 會把能力串起來，但每一步都應有邊界、有檢查、有停止條件。
所以 AI 安全不是額外附加的一層，而是你前面每一層能力在真正落地時都必須重新檢查一次的事情。
這章真正想留下的觀念
不要把安全寄託在「模型應該不會這樣做」。好的 AI 系統設計，應該是就算模型判斷失誤，系統也不會輕易越權、不會輕易外洩、也不會輕易做出高風險動作。
1 分鐘小測驗
Q：哪個做法最接近穩健的 AI 安全設計？