先以實際交易定義威脅模型
不要從「我們要做一個 AI 助手」開始，而要從具體交易開始：誰提出要求、助手會讀取哪些資料、可能呼叫哪些工具、以誰的身分執行，以及結果會寫回哪個系統。例如，查詢庫存、讀取客戶資料、建立報價單與修改付款條件，雖然都能放在同一個對話介面中，風險等級卻完全不同。
接著畫出信任邊界，包括使用者裝置、身分驗證服務、模型供應商、RAG 文件庫、工具閘道、企業 API、日誌與外部網路。每跨越一道邊界，就要回答資料是否加密、身分是否重新驗證、授權是否重新判斷，以及輸入能否被另一個系統或使用者控制。特別要盤點 API 金鑰、個資、合約、價格、原始碼與可執行動作；真正需要保護的不只資料，也包括企業以合法身分完成交易的能力。
優先分析模型特有的濫用路徑
傳統 Web 威脅仍然存在，但 AI 助手多了一個不穩定的決策層。模型可能把文件、郵件、網頁或客服訊息中的文字誤當成指令，因此不能只檢查使用者輸入。建議至少逐一演練以下路徑：
- 直接與間接提示注入：攻擊文字要求模型忽略規則、洩漏上下文，或呼叫原本不相關的工具。RAG 取回的內容必須視為資料，而不是可信指令。
- 權限放大：所有人共用高權限服務帳號時，一般使用者可能透過助手取得自己原本看不到的資料或操作能力。
- 代理人混淆：助手知道某項操作合法，卻沒有確認目前使用者、資料範圍與業務情境是否相符，因而成為替攻擊者執行工作的代理人。
- 危險寫入與重播：重複送出、逾時重試或對話歧義，可能造成重複建立訂單、修改錯誤紀錄或大量發送訊息。
- 資料外洩：敏感內容可能經模型請求、外部連結、工具參數、除錯紀錄或過度完整的對話日誌離開原有邊界。
排序時不要只看攻擊是否常見，也要看影響範圍、可偵測性與可逆性。一次錯誤查詢通常比不可撤銷的付款或大量通知容易處理；難以察覺的跨部門資料洩漏，則可能比明顯的服務中斷更需要優先控制。
讓權限跟著使用者與動作，而不是跟著模型
安全的預設做法是使用短效、範圍受限且可追溯的憑證，並盡可能以目前使用者的身分存取內部系統。若必須使用服務帳號，也應依工具或工作流程拆分權限，避免一組管理者金鑰同時存取 CRM、ERP 與文件庫。每次工具呼叫都要由後端重新執行授權檢查；模型聲稱使用者已獲批准，不能當成授權證據。
可以把能力分成只讀、可逆寫入、高影響寫入與管理操作。只讀仍需套用欄位、資料列與租戶範圍限制；可逆寫入可先建立草稿；高影響操作應顯示確切目標、欄位差異與後果，再要求使用者確認。確認必須綁定當下的參數與有效期限，不能用一句籠統的「是否繼續」授權後續任何動作。若無法可靠描述操作內容、限制影響範圍或復原結果，就不應開放自動執行。
把控制點放在模型之外，並以失敗情境驗收
模型適合理解意圖與提出操作建議，但不適合擔任最終政策引擎。工具閘道應只暴露允許的操作，使用嚴格參數結構、型別與值域驗證，拒絕任意 SQL、任意 URL 或通用命令。後端還應加入資料範圍檢查、輸出過濾、速率限制、冪等鍵、網路出口限制與完整的動作稽核。日誌要保留誰在何時要求什麼、政策如何判斷、工具回傳何種狀態，但敏感提示詞、權杖與完整文件內容應遮罩或縮減。
上線前的測試資料應刻意包含惡意文件、跨權限問題、撤銷帳號、過期憑證、格式錯誤參數、工具逾時、部分成功、重複請求與同時寫入。測試重點不是模型是否永遠回答正確，而是即使模型判斷錯誤，閘道與企業系統仍會拒絕越權操作。也要確認告警能對應到明確負責人，並實際演練停用工具、撤銷憑證與追查單次操作。
是否可以上線，可用三個問題判斷：最壞結果是否被限制在可接受範圍、異常是否能及時發現，以及動作是否能停止或復原。若答案仍不明確，先以只讀、有限資料集或人工核准模式推出，通常比一次開放完整自動化更務實。整合團隊的價值，也正在於把這些邊界落實為可測試、可稽核的系統控制。