Agent 接入工具以后安全治理不能只停留在 Prompt 里。只要 Agent 能访问 CRM、工单、订单、知识库、审批或消息系统工具调用前就必须有独立的运行时风险分级。原因很直接模型生成的不是普通文本而是可能改变业务状态的工具调用。一条更稳的调用链路建议把 Agent 工具调用拆成下面的链路用户输入 - 输入风险识别 - 用户身份和角色解析 - 意图识别 - 候选工具选择 - 工具风险分级 - 参数敏感性检查 - 二次确认 / 改写 / 拦截 - 工具调用 - 工具返回内容审查 - 最终输出审查 - 审计日志工程上最容易漏的是工具风险分级和参数检查。很多系统会校验登录态但不会在 Agent 选择工具时重新判断“这个自然语言请求是否应该触发这个业务动作”。风险等级可以先按动作后果拆风险等级典型工具判定条件默认处理L1 公开查询查询公开 FAQ、产品说明数据不含客户信息不涉及内部策略allowL2 受限查询查询客户、订单、合同用户角色匹配数据属于授权范围allow 或 rewrite_paramsL3 可逆写入新增备注、修改标签动作可回滚不产生外部影响confirm 或 allowL4 不可逆动作关闭工单、删除记录、提交退款影响业务状态回滚成本高confirm 或 handoffL5 外部影响动作发短信、发邮件、同步第三方对客户或外部系统产生影响block 或 handoff这个表不是最终规则而是第一版策略骨架。团队可以先把所有工具映射到风险等级再逐步增加业务条件。调用前需要构造风险上下文不要只把用户原始输入交给模型判断。工具调用前建议生成一份结构化上下文request_id user_id user_role business_scene requested_intent candidate_tool tool_risk_level data_scope parameter_summary parameter_sensitive_fields action_reversibility external_side_effect previous_tool_calls这些字段的作用是把“这句话危不危险”变成“这次工具调用能不能执行”。例如external_side_effecttrue时即使当前工具只是发送模板消息也应该升级处理previous_tool_calls里已经出现客户资料查询时再触发外发动作也要按组合风险处理。处理状态不要只有 allow / deny生产环境里只做放行和拒绝会让业务流程很僵硬。更实用的状态是allow允许调用。confirm要求用户或人工二次确认。rewrite_params参数脱敏、缩小范围或改写。handoff转人工处理。block禁止调用。例如用户要求“查询这个客户所有合同”如果当前角色只能看本人客户应把参数范围改写成授权客户而不是直接查全部合同。用户要求“关闭这个投诉工单”应确认工单状态、责任人和关闭原因再决定是否执行。日志字段要支持复盘工具调用前的拦截如果不留日志后面很难调规则。建议至少记录request_id user_id user_role tool_name tool_risk_level parameter_summary sensitive_fields_detected decision decision_reason review_status created_at其中parameter_summary应该是脱敏摘要不要直接保存完整手机号、合同号、订单号或客户资料。日志的价值不只是追责也能用于每周复盘哪些工具误伤最多哪些高风险动作应该增加确认哪些提示词注入样本应该进入规则库。接入位置建议如果使用 Dify 或类似工作流平台可以把统一护栏放在两类位置接入点主要职责注意事项工具调用前判断工具、参数、角色、动作后果不要只依赖模型自我约束工具返回后判断返回内容是否能进入上下文敏感字段要脱敏或截断最终输出前判断回复能否对用户发出避免把内部信息带出去审计链路保存决策原因和处理动作日志要脱敏、可检索唯客护栏适合补的是这层统一运行时边界让工具调用从“模型决定”变成“模型建议系统裁决”。总结Agent 工具调用治理的关键不是把工具都禁掉而是让每一次调用都有条件、有证据、有回退。工程团队可以先从工具风险等级、参数敏感性、处理状态和审计日志四件事开始把 Agent 的业务动作纳入可控链路。参考来源https://jotoai.com/
