AI Agent 防護設計：輸入、工具與輸出的授權邊界

先列資料、工具與允許行動

為 Agent 定義使用者、可存取資源、允許操作及重要後果。預設拒絕未核准的存取與行動，再確認哪個元件負責執行及測試。讀取資料也可能造成嚴重揭露，不能因為「唯讀」就省略資源與身份限制。

輸入、工具、輸出三層是一種整理控制的方式，不是全部威脅或某個 SDK 的固定架構。提示詞可以協助約束，但權限、數值限制及批准不能只依模型判斷。

使用者訊息、檢索文件、工具結果與影像都可能帶入不可信指令。OWASP LLM01:2025說明直接與間接注入及不同表現形式。檢查特定句子或加另一個模型，可作為緩解措施，但無法保證攔住所有攻擊。

限制來源與任務範圍，測試編碼、跨來源和工具結果中的指令。只提供需要且已獲適當授權的資料；若採遮罩或 token 替換，也要檢查工具、日誌、快取、輸出及替換對照的保護。資料存在不等於允許再利用，個人資料保護法的目的與必要性邊界仍須確認。

工具服務應依當下身份、資源與行動檢查權限、參數、單位、限額及批准。模型選了一個工具名稱，不能代替使用者對特定資源的授權。重要操作的批准也要對應實際請求，避免批准之後參數又被更改。

以下欄位是政策偽設定，用來討論控制，不是任何 SDK 可直接執行的格式。實作時要定義執行元件及規則優先順序。

設定項目	規劃用途	概念範例
`allowed_tools`	最少功能與預設拒絕	`[search_kb, draft_reply]`，另核對使用者與資源
`require_confirmation`	已核准的重要操作需批准	`[issue_refund, send_email]`，不能因此啟用未允許工具
`value_limits`	任務特定的數量、單位與限額	依核准規則檢查實際請求
`rate_limit`	限制工作量與損害範圍	按任務及資源設定預算與停止條件
`dry_run_first`	支援時做無副作用的檢查	確認各依賴真的能模擬，再核對執行請求

範例中退款與寄信不在允許清單，列入確認欄位不會授予使用權。OWASP LLM06:2025強調最少功能、權限、使用者脈絡與下游授權；限流可減少損害，不會讓一次未授權或重複操作變安全。

Schema 可以檢查格式與欄位，引用檢查要再確認原文是否支持說法、版本與適用範圍。格式正確、語氣合適或來源存在，都不能單獨證明事實或合規。

生成失敗可以依已定義的次數及成本預算重試。付款、寄信、刪改等操作的重試則要依外部服務的去重及確認協議處理。逾時或未收到確認，不代表操作未發生；先停止、依權限核對狀態或轉交負責人，不盲目重送。輸出攔截也不能撤銷先前已執行的副作用。

至少依實際任務測試：

保留必要的身份、請求、批准、版本及拒絕理由，避免記錄原始秘密。約定接手、停止、狀態核對與恢復條件，並在控制或依賴改動後確認受影響行為。NIST AI RMF（2023-01-26）提供自願性的風險及監測框架，不是安全認證。

來源於 2026-10-04 查閱；OWASP 的 2025 是文件版本，確切發布或更新日期未建立。可搭配Agent 沙箱邊界，或從Agentic 工作流服務確認允許任務與介面。