LLM安全治理中最危险的误区之一，是把Prompt过滤当成了工具执行授权。输入文本被识别为风险并被拦截，说明某个入口策略生效；但如果应用仍能接受模型输出的工具调用，或者工具执行器只检查技术账号，那么“模型说了什么”和“系统做了什么”之间仍然存在一条未治理的路径。Function Call需要独立的白名单、参数、身份、权限、确认、执行和审计控制。

适用场景：企业正在建设Agent、自动化运维、业务查询或数据处理应用，模型可以调用搜索、知识库、工单、数据库、消息或其他业务工具。

Prompt过滤和工具执行处在两条控制面

Prompt过滤主要观察输入和上下文文本，判断是否需要阻断、改写、标记或交给人工复核。Function Call则是一个候选动作：模型提出工具名称和参数，应用或编排器决定是否把它交给执行器。两者输入不同、责任不同、失败方式也不同。

一个请求即使顺利获得了Prompt策略，也可能因为工具白名单、参数范围、资源权限或人工确认被拒绝；反过来，一个看似普通的Prompt也可能诱导模型提出高影响工具调用。因此安全设计要把文本控制和动作控制拆开，每一道控制都允许独立拒绝，并保留统一事件ID。

Function Call需要独立于Prompt的执行闸门

下图把模型提议到受控执行拆成多道闸门：工具白名单、参数校验、权限决策、人工确认和执行审计。阅读时沿路径判断每道门的输入、拒绝条件和责任人。

模型提议只是候选动作，不是授权结果。白名单判断工具是否允许被当前应用使用；参数校验检查类型、范围、目标和关联资源；权限决策检查主体、动作和资源；高影响动作可能需要人工确认；执行器还要处理超时、重复、幂等、回滚和结果审计。

如果其中一扇门只在文档里存在，实际调用路径却绕过它，安全策略就会出现假闭环。POC应要求每次拒绝、暂停和执行都能关联到同一请求或父子事件链。

先给工具动作分级，再决定控制强度

工具风险不能只按工具名称判断。一个“查询”工具可能暴露敏感数据，一个“写入”工具可能只改测试环境，一个“发送”动作可能触达外部客户。建议按动作影响、资源范围、可逆性和数据敏感度分级，而不是把所有Function Call都用同一套规则处理。

可以先使用四类动作口径：

• 低影响只读：读取非敏感、范围明确的资源，仍需主体与资源授权；
• 敏感读取：访问个人、财务、内部或高价值数据，需要更细的资源范围和审计；
• 可回滚写入：创建、更新或提交可撤回对象，需要参数校验、幂等和必要确认；
• 高影响或不可逆：删除、外发、权限变更、资金或生产操作，应有更严格授权和人工确认。

等级只是起点。企业要结合业务流程、审批制度和工具实现确定控制。不能因为某个动作看似只读，就跳过权限，也不能因为某个动作风险高，就只要求人工点击而不做参数和资源校验。

参数由模型生成，必须重新验证

Function Call参数由模型或上游应用生成，具有不确定性。执行器不能把参数当成可信配置直接传给业务系统。需要验证类型、长度、允许值、目标资源、时间范围、租户、关联任务和重复请求。参数校验应在服务端执行，不能只依赖Prompt提示或前端展示。

参数校验失败时，要返回可理解的拒绝结果，但不要把内部敏感策略全部暴露给模型。高风险参数的错误应进入审计和人工复核，必要时停止整个任务或缩小权限范围。对于可重试动作，要设置幂等键和状态检查，避免模型重复调用造成重复写入。

尤其要区分用户要求、模型推断和系统默认值。模型补全了缺失目标或时间，不能自动等同于用户确认；应用需要在高风险场景要求明确输入或人工确认。工具结果也要校验状态，不能因为执行器返回“已提交”就把业务操作写成“已完成”。

权限决策要使用真实主体和资源范围

工具调用至少需要知道调用者、代理应用、动作、目标资源、环境和策略版本。共享服务账号可以承担机器间通信，但不能让它替代业务主体的授权判断。模型会话中的用户文本也不应直接作为权限凭据。

权限决策要能说明允许或拒绝的理由，并把结果写入审计。资源范围应尽量具体，避免给一个查询工具无限制的全局访问；写入和外发动作要绑定项目、租户或环境。权限变化后，长会话和异步任务必须重新判断，不能永久使用旧快照。

如果权限由IAM、业务系统或资源服务提供，工具治理层应明确调用顺序和真源。安全平台可以承接策略和证据，但不应在没有业务数据的情况下假装完成资源授权。

哪些动作需要人工确认

人工确认适合高影响、不可逆、敏感外发或责任难以自动判断的动作，但不应成为所有动作的默认按钮。确认页面或接口需要展示主体、工具、参数摘要、目标资源、影响范围、策略理由和过期时间，避免只显示“是否执行”。确认结果要与事件ID、审批人和策略版本关联。

人工确认也可能被误用。如果模型频繁提出低质量请求，审批人员可能形成机械点击；如果确认信息过于复杂，用户无法理解，实际控制效果会下降。应先用白名单、参数和权限减少不必要的请求，把人工确认留给真正需要业务判断的动作。

确认超时、撤回、重复提交和执行失败都要有明确处理。未确认的调用不能自动转成允许，已经确认的调用也不代表目标资源永远有效。需要根据资源状态和策略版本在执行前再次核验。

执行器要有幂等、超时和回滚边界

执行器是最后一道技术边界。它要知道动作是否可重复、是否可取消、失败后如何补偿、结果如何查询。对于创建或更新类动作，应使用幂等键或状态检查；对于删除、外发和生产变更，应有明确的回滚或人工处置路径；对于长任务，应区分已接受、执行中、成功、失败和未知状态。

不要把“函数返回成功”直接写成业务完成。执行器可能只表示请求已提交，下游系统还在处理；也可能返回部分成功、超时或不确定状态。审计应记录调用参数的最小必要摘要、授权结果、执行状态和最终业务结果，敏感原文按企业策略处理。

安全边界必须在执行器，而不是只在模型上下文里。即便模型被诱导或Prompt过滤漏掉，未授权动作也应在工具闸门处停止。

用受控POC验证每道闸门

白名单与未知工具

准备允许、未登记和已下线三类工具，观察路由、拒绝、告警和审计。未知工具不应因为名称相似或模型解释而自动放行。

参数边界

为同一工具准备合法、缺失、类型错误、越界、目标不匹配和重复参数，确认服务端校验生效，拒绝结果可追踪，敏感规则不会被过度暴露。

身份与权限

让不同主体在同一应用中访问不同资源，验证代理关系、资源范围、策略版本和工具结果。权限变化后重新发起调用，检查长会话是否重新授权。

人工确认与执行回滚

对高影响动作设置审批，对超时、拒绝、撤回、执行失败和重复提交进行演练。确认执行前后事件关联和业务结果，验证回滚是否真的改变目标状态。

测试样本必须在授权环境中使用，不需要在文章或报告中暴露可复用的危险Prompt、敏感参数或真实资源。

相关的AI基础设施内容可查看 AI基础设施分类。若需要把工具调用治理、模型服务和平台安全放进整体方案中评估，可查看 AI解决方案，发布前核验链接状态。

如何落到工具治理清单

先盘点工具名称、动作、参数、资源、主体、可逆性和审计要求，再按风险设置白名单、参数校验、权限决策、人工确认和执行回滚。选择一个低风险只读工具和一个高影响动作做端到端POC，确认每道闸门都能独立拒绝、解释和留证。

LLM安全治理的核心边界是：模型可以提出动作，但只有经过策略和执行器授权的动作才可以发生。Prompt过滤仍然有价值，但它不能替代Function Call的独立控制面。

常见问题

Function Call参数由模型生成，能否直接信任？

不能。模型生成的工具名称和参数是候选输入，可能受到上下文、历史消息、数据内容或模型不确定性的影响。即使用户意图正常，参数也可能缺失、类型错误、目标资源不匹配、范围过大或重复执行。执行器必须在服务端重新校验工具白名单、参数类型与范围、主体、资源、环境、策略版本和幂等条件，不能只依赖Prompt中的约束或前端提示。

对于写入、外发、删除和生产动作，还要根据风险增加人工确认、审批、超时和回滚。参数校验失败应可拒绝并留下事件证据；工具返回“已提交”时，应用还要区分下游是否真正完成。建议先选择一两个真实工具做边界测试，固定合法、缺失、越界和重复样本，再决定更广泛的自动执行范围。

哪些工具调用必须增加人工确认？

通常是高影响、不可逆、敏感外发、权限变更、生产操作或责任难以由规则自动判断的动作，但没有一份可以跨企业直接套用的固定清单。判断应结合动作影响、目标资源、数据敏感度、可回滚性、审批制度和异常后果。一个读取工具如果能返回高敏感数据，也可能需要比普通写入更严格的确认；一个测试环境写入动作若可完全回滚，控制方式可能不同。

人工确认不能代替白名单、参数和权限校验。确认信息应包括主体、代理应用、工具、参数摘要、目标资源、影响、策略理由和有效期限，并把审批与执行结果关联。还要验证确认超时、撤回、重复提交和策略变化。若审批人员只能机械点击，说明风险分级、工具设计或展示信息仍需调整。

只读工具是否可以不做权限控制？

不可以。只读不等于低风险：查询可能返回个人信息、商业秘密、内部配置或大范围数据，也可能成为后续越权和外发的输入。只读工具仍要校验主体、应用、资源范围、租户、数据敏感级别和调用目的，并记录结果状态。对于知识库、数据库和搜索工具，还要确认分段、缓存和导出不会让资源权限脱落。

可以根据风险降低执行复杂度，例如对非敏感、范围固定的只读资源采用自动放行，但不能取消身份和授权。高敏感查询应增加更细的字段过滤、审批或脱敏，结果回传模型前还要做数据保护。POC应测试有权、无权、跨租户、权限变更和结果导出场景，确认只读工具没有成为绕过业务授权的后门。