Dify Agent 工具权限：让智能体能办事，也能被审计

Agent 能调用工具之后，风险不再停留在回答是否准确，而会进入真实系统。一次参数误判可能查询到不该看的记录，一次重复调用可能创建多份工单，一段被文档诱导的指令可能尝试外发信息。因此工具权限必须按真实执行链设计：模型负责提出动作，平台验证身份和范围，人在关键节点确认，业务系统执行并留下可追溯结果。

判断这个场景是否适合

先把工具按影响分级。公开信息查询、受权限约束的内部查询、创建草稿、提交业务变更、删除或外发，风险逐级上升。适合交给 Agent 自主选择的通常是可逆、只读、结果可核验的动作。涉及资金、合同、账号、生产配置、个人信息或对外沟通时，模型最多准备参数和说明，最终动作应由确定流程及有权人员批准。

其次判断调用者身份能否贯穿全链路。如果所有请求都使用一个超级服务账号，Dify 界面里的角色控制无法阻止工具读取过量数据。理想方式是让网关获得经验证的用户或服务身份，并在业务系统侧再次校验资源范围。无法传递用户身份时，要为具体场景建立最小权限服务账号，限制可访问对象、方法、时段和调用量，不能把通用管理员密钥交给工具。

还要评估动作是否可幂等和补偿。查询失败可以重试，创建记录则需要幂等键，发送消息和删除数据可能无法撤回。没有可靠幂等、状态查询与人工对账的写接口，不适合让 Agent 自动重试。工具返回必须区分成功、处理中、可重试失败和永久失败，否则模型可能把超时误认为未执行并再次调用。

实施时怎么拆

首先建立工具登记表，记录所有者、用途、数据分类、输入字段、输出字段、认证方式、权限范围、超时、重试和停用方法。工具描述应说明何时可以用、何时禁止用，但真正限制由网关和后端实现。参数使用枚举、格式和长度校验，资源标识从授权上下文获得，避免让模型自由填写租户或用户范围。

第二步把读与写分开。Agent 可以先调用预览工具获取将要变更的对象、差异和风险，再生成审批请求。审批页面展示实际参数、依据、影响对象和有效期；审批通过后由固定执行节点带一次性授权调用写工具。批准人修改任何关键参数都应生成新请求，旧批准不能套用。特别敏感动作可要求双人复核或仅开放人工后台执行。

第三步形成审计链。每次运行关联使用者、应用版本、模型、工具版本、调用原因、脱敏参数、返回状态、审批记录和外部业务编号。审计日志与普通调试日志分开保护，正文和密钥不得直接落盘。运维人员应能按业务编号反查一次动作，也能从 Agent 运行定位外部结果；仅保存一段自然语言对话不足以证明实际发生了什么。

测试要主动制造越权和失败：要求查询其他部门、在文档中嵌入诱导指令、提供超长参数、让接口超时、重复提交、批准后篡改内容。验证拦截发生在模型之外，并确认告警能到达责任人。上线使用工具级开关和限流，小范围开放后观察拒绝、重复、超时和人工驳回。出现异常时先停用写工具，保留只读或人工通道，再核对已执行动作。

不要忽略的限制

审计记录不能替代事前控制，提示词也不能替代授权。模型可能被用户输入、知识文档或工具返回中的内容影响，所以所有外部文本都应视为不可信数据。工具返回中不要夹带可被继续执行的指令，敏感字段按需最小化。密钥应存于专用配置或密钥服务，定期轮换，应用导出和日志中不应出现明文。

回滚应用版本不会撤销已经发送的邮件、创建的账号或修改的数据。每个写工具都要定义业务补偿、对账负责人和证据保留方式；无法自动补偿时明确人工步骤。组织和人员变化也会让旧权限失效，应定期复核工具所有者、服务账号和审批组。只有能够回答谁在何时基于什么证据批准并执行了什么，Agent 才算真正可审计。