模型生成的函数调用只是以结构化形式提出的建议。是否有效、是否获得授权、执行是否安全，必须由应用决定，而不是模型。
理解控制边界
函数调用允许模型选择预先声明的操作并生成参数。Google 的文档明确指出执行边界：函数代码由应用执行。这种职责分离是安全设计的基础。
绝不能把语法有效的参数视为授权。模型可能误解用户、重复被注入的指令，或选择权限过大的操作。身份验证确认用户是谁；授权检查仍须核实请求的资源与操作。
设计权限范围明确的工具
优先使用 draft_refund 和 submit_refund，而不是能调用任意内部 API 的通用端点。为每个工具限定完成任务所需的最小数据范围和副作用级别。对标识符、目标地址和操作类型使用允许列表。
工具描述应说明前提条件和不承担的任务。不要在工具模式中放入密钥，也不要返回不必要的个人数据。模型需要的是足以正确选择的信息，而不是不受限制的后端访问权。
用普通代码执行校验
按照严格模式解析参数，规范化取值，再执行业务规则。在服务端重新计算价格并检查权限。拒绝检索内容中试图扩大权限的嵌入式指令。将操作绑定到当前用户、会话和已批准的资源。
对可能重复提交的写入操作使用幂等键，将试运行与正式提交分开。遇到超时或含糊的响应，应回读核对状态，而不是盲目重试并可能造成重复操作。
根据后果设置确认环节
低风险且可撤销的查询可以自动执行。对外发送消息、购买、删除、更改权限和公开发布都值得提供预览或要求明确确认。向用户展示有意义的参数——收件人、金额、对象及操作影响——而不是原始 JSON。
确认必须绑定到当时冻结的准确请求内容。如果模型随后更改参数，应重新征求确认。批准还应设定有效期，不能让一次确认授权用户未见过的一连串操作。
审计决策与结果
记录用户请求、选定工具、校验后的参数、策略判断、确认过程和执行结果。对密钥进行脱敏，同时保留足够的事故复盘证据。监控遭拒的调用、反复重试和异常工具调用序列。
测试直接提示词注入和工具返回的恶意内容。目标不是让模型永远不提出错误调用，而是让错误建议无法越过执行边界。
如何付诸实践
先选取一个与“函数调用不等于授权：AI 工具的安全模型”相关、边界清晰的工作流程。改动系统之前，用一页文档记录基线：目前的完成时间、质量检查项、常见失败类别、升级处理路径和结果负责人。选取有代表性的样本，而不是只挑最干净的案例。纳入普通案例、困难的边缘案例，以及至少一个正确做法是停止或请求更多信息的案例。
在允许候选方案取代现有流程前，先让两者并行运行。成功和失败的输出都要检查，因为错误率下降仍可能掩盖新的高影响失败。记录每次测试使用的准确配置，并保留足以让其他审核人员复现结果的材料。试点结束时，依据事先商定的阈值决定扩大应用、修改方案还是停止，而不是事后凭一次最出色的演示作判断。
向供应商或内部团队提出的问题
询问核心主张有哪些证据支撑、证据基于哪个系统版本和数据版本，以及排除了哪些条件。要求提供与你的部署场景相符的语言、输入类型和风险类别的测试结果。询问变更如何通知、回归问题如何发现，以及客户如何导出事故复盘所需的日志。
还要问清：当置信度低、依赖项故障或请求超出支持范围时，系统会如何处理。可靠的产品应有明确的失败状态，而不是仅仅给出更像样的回答。责任归属同样重要：明确谁能暂停流程、谁批准例外，以及重大错误流入生产环境后由谁通知受影响的用户。
实用检查清单
- 选择模型或工具前，先明确用户任务以及真正需要防范的失败。
- 维护一个来自真实工作的、小规模且有版本记录的测试集，纳入棘手案例和对抗性案例。
- 每次运行都记录模型、提示词、工具、检索设置、数据版本、延迟和成本。
- 不可逆、高影响或对外可见的操作必须经过人工确认。
- 按类别复盘失败，不要只看单一平均分，并将回归案例加入测试集。
Meydo Journal 延伸阅读
原始资料
- 通过 Gemini API 使用函数调用 — Google AI for Developers
