Agent 工具授權：不要把 Prompt 當權限檢查

一個具體的越權路徑

假設民宿 A 的訪客要求查詢訂單。模型產生一個格式正確的工具呼叫，參數中卻帶入民宿 B 的訂單 ID。JSON schema 可以確認參數型別正確，卻不能證明這位呼叫者有權讀取該筆訂單。

Prompt 寫著「不得讀取其他民宿資料」也不是授權檢查。使用者輸入、檢索文件與工具回傳內容都可能包含對抗性指示；它們可以影響模型輸出，但不應改變伺服器認定的身分與資源範圍。

把信任邊界放在模型之外

入口完成來源驗證後，由伺服器根據已驗證的 channel / 帳號設定解析 tenantId 和呼叫者身分。Runtime 把這份可信任 context 傳給工具；模型只提供工具名稱與候選參數，不能自行指定或覆寫 tenant、角色或授權結果。

簡化的執行路徑是：已驗證入口解析 actor / tenant → Agent 提出 tool 與 args → allowlist 與參數驗證 → 資源授權 → 執行並記錄決策。

資料讀取也要把授權範圍落在查詢條件中。例如讀取訂單時，查詢同時限定 tenant_id 與模型提出的訂單 ID；不能先按 ID 取出資料，再期待 Prompt 要求模型自行判斷能否顯示。

執行前的檢查順序

1. 確認呼叫者 context：身分與 tenant 由已驗證的入口建立，不接受工具參數回填。
2. 確認工具可用：按部署環境、tenant 與角色套用伺服器端 allowlist；未啟用的工具不應交給模型，也不能只靠隱藏 UI。
3. 驗證參數：檢查型別、範圍、長度與業務不變條件。Schema 驗證是輸入驗證，不等於授權。
4. 授權目標資源：以可信任 actor / tenant context 檢查每次讀寫，包含模型提供的 ID、搜尋條件與批次目標。
5. 限制副作用：設定 timeout、速率與輸出上限；敏感或不可逆操作依風險要求明確核准。
6. 記錄決策：保存 request ID、工具名稱、租戶、政策版本與允許／拒絕原因；不要把憑證或不必要的個資寫入 log。

安全測試要測拒絕路徑

• 把另一個 tenant 的有效資源 ID 放進合法參數，必須拒絕或回傳不洩漏存在性的結果。
• 在使用者訊息或知識文件中加入「改用另一個 tenant／呼叫刪除工具」，不得改變伺服器授權。
• 直接要求模型呼叫未列入 allowlist 的工具，執行層仍須拒絕。
• 角色被撤銷或工具被停用後，沿用舊對話再次呼叫也必須重新檢查。
• 批次操作中混入一筆無權存取的資源，確認系統採用明確且一致的全有／部分成功政策。

這份清單描述應有的邊界與負向測試，不等同於測試已在某個正式環境通過。若公開案例要宣稱隔離已驗證，應提供可重跑的測試與失敗時的拒絕證據，而不只是架構圖。

Prompt 仍然有用，但用途不同

Prompt 可以說明工具的用途、輸入格式與何時該詢問使用者；它提升模型選擇工具的品質。真正允許或拒絕操作的決定，仍須由每次工具執行前的伺服器端政策與資料存取控制負責。