模型生成的函式呼叫只是以結構化形式提出的建議。是否有效、是否獲得授權、執行是否安全，必須由應用決定，而不是模型。
理解控制邊界
函式呼叫允許模型選擇預先宣告的操作並生成引數。Google 的文件明確指出執行邊界：函式程式碼由應用執行。這種職責分離是安全設計的基礎。
絕不能把語法有效的引數視為授權。模型可能誤解使用者、重複被注入的指令，或選擇許可權過大的操作。身份驗證確認使用者是誰；授權檢查仍須核實請求的資源與操作。
設計許可權範圍明確的工具
優先使用 draft_refund 和 submit_refund，而不是能呼叫任意內部 API 的通用端點。為每個工具限定完成任務所需的最小資料範圍和副作用級別。對識別符號、目標地址和操作型別使用允許列表。
工具描述應說明前提條件和不承擔的任務。不要在工具結構描述中放入金鑰，也不要回傳不必要的個人資料。模型需要的是足以正確選擇的資訊，而不是不受限制的後端訪問權。
用普通程式碼執行驗證
按照嚴格結構描述解析引數，規範化取值，再執行業務規則。在服務端重新計算價格並檢查許可權。拒絕檢索內容中試圖擴大許可權的嵌入式指令。將操作繫結到當前使用者、會話和已批准的資源。
對可能重複提交的寫入操作使用冪等鍵，將試執行與正式提交分開。遇到超時或含糊的回應，應回讀核對狀態，而不是盲目重試並可能造成重複操作。
根據後果設定確認環節
低風險且可撤銷的查詢可以自動執行。對外傳送訊息、購買、刪除、更改許可權和公開發布都值得提供預覽或要求明確確認。向使用者展示有意義的引數——收件人、金額、物件及操作影響——而不是原始 JSON。
確認必須繫結到當時凍結的準確請求內容。如果模型隨後更改引數，應重新徵求確認。批准還應設定有效期，不能讓一次確認授權使用者未見過的一連串操作。
審計決策與結果
紀錄使用者請求、選定工具、驗證後的引數、策略判斷、確認過程和執行結果。對金鑰進行脫敏，同時保留足夠的事故覆盤證據。監控遭拒的呼叫、反覆重試和異常工具呼叫序列。
測試直接提示詞注入和工具回傳的惡意內容。目標不是讓模型永遠不提出錯誤呼叫，而是讓錯誤建議無法越過執行邊界。
如何付諸實踐
先選取一個與「函式呼叫不等於授權：AI 工具的安全模型」相關、邊界清晰的工作流程。改動系統之前，用一頁文件紀錄基線：目前的完成時間、品質檢查項、常見失敗類別、升級處理路徑和結果負責人。選取有代表性的樣本，而不是隻挑最乾淨的案例。納入普通案例、困難的邊緣案例，以及至少一個正確做法是停止或請求更多資訊的案例。
在允許候選方案取代現有流程前，先讓兩者並行執行。成功和失敗的輸出都要檢查，因為錯誤率下降仍可能掩蓋新的高影響失敗。紀錄每次測試使用的準確設定，並保留足以讓其他稽核人員復現結果的材料。試點結束時，依據事先商定的閾值決定擴大應用、修改方案還是停止，而不是事後憑一次最出色的演示作判斷。
向供應商或內部團隊提出的問題
詢問核心主張有哪些證據支撐、證據基於哪個系統版本和資料版本，以及排除了哪些條件。要求提供與你的部署場景相符的語言、輸入型別和風險類別的測試結果。詢問變更如何通知、迴歸問題如何發現，以及客戶如何匯出事故覆盤所需的紀錄。
還要問清：當置信度低、依賴項故障或請求超出支援範圍時，系統會如何處理。可靠的產品應有明確的失敗狀態，而不是僅僅給出更像樣的回答。責任歸屬同樣重要：明確誰能暫停流程、誰批准例外，以及重大錯誤流入正式環境後由誰通知受影響的使用者。
實用檢查清單
- 選擇模型或工具前，先明確使用者任務以及真正需要防範的失敗。
- 維護一個來自真實工作的、小規模且有版本紀錄的測試集，納入棘手案例和對抗性案例。
- 每次執行都紀錄模型、提示詞、工具、檢索設定、資料版本、延遲和成本。
- 不可逆、高影響或對外可見的操作必須經過人員確認。
- 按類別覆盤失敗，不要只看單一平均分，並將迴歸案例加入測試集。
Meydo Journal 延伸閱讀
原始資料
- 透過 Gemini API 使用函式呼叫 — Google AI for Developers
