Wiki Notes

Appearance

03. 工具权限、审批与执行安全 ​

版本：v1.1

最后更新：2026-07-08

适用对象：已经让模型可以调工具、连接器、浏览器、文件系统或业务动作，希望把“模型能做什么”和“模型被允许做什么”明确分开的团队

很多 LLM 系统一旦走到 Agent 或 workflow 阶段，真正的安全边界就不再是：

  • 说什么

而是：

  • 能执行什么

这篇专题重点讲的就是执行安全。

1. 为什么工具安全是 Agent 时代的核心风险 ​

普通问答系统即使出错，很多时候影响还停留在文本层。

但一旦接入工具，错误就会变成真实副作用：

  • 发错消息
  • 改错配置
  • 删错对象
  • 导出敏感数据
  • 误触审批链

OpenAI 当前 Safety in building agents 明确提醒：

  • 工具审批要保持开启
  • 守住高风险动作的人类确认

这意味着工具安全不是“可选增强”，而是执行层基础。

2. 先分清四类工具 ​

2.1 只读工具 ​

例如：

  • 查知识
  • 查状态
  • 查公开文档

风险相对低，但仍然可能造成：

  • 越权读取
  • 敏感数据暴露

2.2 受限读工具 ​

例如：

  • 查内部客户信息
  • 查租户业务对象
  • 查运维状态

这类工具必须带：

  • 身份
  • 租户
  • 范围

2.3 可逆写工具 ​

例如：

  • 创建草稿
  • 创建待审批工单
  • 生成建议配置

更适合：

  • 自动执行 + 审计
  • 或弱审批

2.4 高风险 / 不可逆工具 ​

例如：

  • 删除
  • 转账
  • 对外发送
  • 修改生产配置
  • 导出敏感批量数据

这类动作更应该默认：

  • 人工审批
  • 强约束
  • 明确回滚策略

3. 工具权限不应该只靠 prompt 描述 ​

系统提示词可以说：

  • “不要调用高风险工具”

但真正可靠的边界必须在运行时：

  • 工具是否暴露
  • 工具是否可用
  • 参数范围是否允许
  • 调用后是否需要审批

否则一旦 prompt 被绕过，执行边界也会一起失守。

3.1 更稳的工具设计，不是“给模型一把万能钥匙” ​

OpenAI 当前 Safety in building agents 官方资料明确强调：

  • 不要把不可信变量直接放进 developer messages
  • 用 structured outputs 压缩自由文本通道
  • 对高风险动作保持 tool approvals

这三点放到执行层里，真正的含义是：

  • 工具不应该只是“暴露一个函数名”
  • 工具应该是一组经过约束的能力片段

更成熟的做法通常不是：

  • send_email
  • run_sql
  • write_file

这种能力过大的工具直接裸露给模型，而是拆成：

  • draft_email
  • submit_email_for_review
  • lookup_customer_invoice
  • append_safe_report_section

也就是说，工具安全最核心的事情之一，是：

  • 把“可执行能力”拆小，而不是把“风险控制”全压给审批

3.2 工具名本身也应该表达边界 ​

如果一个工具叫：

  • admin_action

那后续做审计、审批和回放时，几乎所有人都会痛苦。

更稳的命名通常至少让人一眼看出：

  • 操作对象
  • 操作方向
  • 风险级别
  • 是否只是草稿 / 建议 / 真实提交

例如：

  • customer_note_create_draft
  • tenant_report_export_request
  • prod_config_patch_submit_for_review

这样做的价值不只是可读性，而是：

  • 执行前更容易做策略匹配
  • 审批时更容易让人快速判断
  • 审计时更容易按动作族分桶

4. 最小权限原则应该怎么落 ​

更实用的做法不是“统一给一套工具再靠模型自律”，而是：

4.1 按角色暴露工具 ​

  • 客服助手只看知识和工单草稿
  • 运维助手能查状态但不能直接改生产
  • 财务助手不能天然访问跨租户明细

4.2 按任务阶段暴露工具 ​

  • 先分析
  • 再建议
  • 最后执行

每一步用到的工具集不一定一样。

4.3 按风险级别暴露工具 ​

  • 低风险默认可用
  • 中风险需额外校验
  • 高风险必须审批

4.4 按会话、步骤和上下文动态收缩权限 ​

很多团队会做角色级权限，但真实问题常常出在：

  • 同一个角色，在不同步骤不该看到同一组工具

更稳的做法通常是把权限再往下收一层：

  • 会话级
  • 任务阶段级
  • 单次 run 级

例如：

  • 分析阶段只能读，不能写
  • 生成草稿阶段可以创建 draft，但不能直接提交
  • 审批通过后才短时开放真正执行工具

这类“分阶段暴露”比单纯角色权限更适合 Agent / workflow，因为模型行为本来就有阶段差异。

5. 参数安全经常比工具名本身更关键 ​

很多事故不是因为：

  • 调错了工具

而是因为：

  • 参数越界了
  • 对象范围错了
  • 目标租户错了
  • 字段没校验

所以更稳的策略通常是：

  • 工具 schema 结构化
  • 值域校验
  • 业务规则校验
  • 幂等或补偿设计

5.1 参数校验最好拆成三层 ​

更实用的执行前校验通常至少分成：

  1. 结构校验
    • 字段是否齐全
    • 类型是否正确
  2. 语义校验
    • 时间范围是否合理
    • 数量级是否越界
    • 目标对象是否存在
  3. 策略校验
    • 这个 actor 是否能对这个 tenant 做这个动作
    • 这个动作是否超出审批覆盖范围
    • 当前 release / policy 是否允许这种写入

如果只有第一层，很多事故照样会穿过去，因为：

  • JSON 长得对
  • 不等于动作就安全

5.2 “审批通过的对象”和“最终执行的对象”必须可比对 ​

很多团队做了审批，但最后还是出事，常见原因不是审批缺失，而是：

  • 审批看的是草稿 A
  • 最终执行的是被二次改写后的 B

所以更稳的做法通常是：

  • 对审批前的关键参数做 canonicalization
  • 生成稳定摘要或签名
  • 执行前再次比对摘要

至少关键对象应能回答：

  • 审批时看的 tenant / object / action / amount / recipient
  • 和真正落地执行的是否一致

6. 审批的目标不是“让系统慢下来” ​

OpenAI 当前 Guardrails and human review 把 guardrails 和 human review 明确拆开：

  • guardrails：自动检查
  • human review：人工批准敏感动作

审批的真正意义是：

  • 把高风险最终裁决从模型移交给人或明确策略

它不是“对所有任务一刀切加人工”，而是：

  • 对高影响动作保留最后控制权

6.1 审批和 guardrail 解决的不是同一类问题 ​

OpenAI 当前 Guardrails and human review 官方资料把两者拆得很清楚：

  • guardrails 更像自动校验
  • human review 更像最终批准

这意味着一个更稳的顺序通常是：

  1. 先 guardrail 判断输入 / 输出 / tool behavior 是否异常
  2. 再决定是否进入 human review
  3. 审批通过后，执行前仍做最终参数比对

如果把审批当成“万能兜底”，常见问题会是：

  • 自动能挡住的低质量样本全都丢给人
  • 真正高风险动作反而没有准备好执行前一致性检查

6.2 更适合审批的不是“整段对话”，而是结构化动作卡片 ​

审批人最怕看到的是：

  • 一大段对话
  • 一个模糊总结
  • 然后让他判断是否允许执行

更稳的审批对象通常应该是结构化卡片，至少包括：

  • actor / tenant
  • action type
  • target object
  • 关键参数
  • 风险等级
  • 预计副作用
  • 回滚或补偿入口
  • 对应 trace / run id

这样审批人才是在审：

  • 一个可执行动作

而不是在猜：

  • 模型到底想干嘛

7. 哪些动作更适合默认审批 ​

建议默认进入审批的典型动作包括：

  • 对外发送消息
  • 生产环境写配置
  • 删除或批量修改对象
  • 导出敏感数据
  • 涉及金钱、合约、法律责任的提交

8. 哪些动作更适合双阶段执行 ​

很多业务动作更稳的方式是：

  1. 模型先生成建议稿。
  2. 人或策略决定是否提交。

这比让模型直接落库更稳，尤其适合：

  • 邮件回复
  • 工单处理
  • 配置建议
  • 审批意见

8.1 “draft -> review -> commit” 往往比“直接执行”稳很多 ​

这其实是执行安全里非常常见的一条主线：

  1. 先生成 draft
  2. 再审 draft
  3. 最后才 commit

这条路径的优势在于：

  • 模型仍然能高效工作
  • 但真正副作用被推迟到更可控的时刻

特别适合：

  • 邮件外发
  • 数据导出
  • 工单结案
  • 配置修改
  • 对外通知

如果一个系统暂时还做不到很强的执行前一致性控制，优先把直写改成 draft / commit 分离，通常就能先挡掉一大类事故。

9. Shell / 文件 / 浏览器 / MCP 工具要特别小心什么 ​

这类工具的共同点是：

  • 能力边界大
  • 行为不容易只靠自然语言约束

更值得优先检查的是：

  • 可访问路径范围
  • 可读写资源范围
  • 命令白名单
  • 网络访问边界
  • 人工确认点

9.1 第三方 MCP / connector 不能被当成“天然可信工具” ​

OpenAI 当前 Integrations and observability 与 Safety in building agents 连起来看，一个很关键的现实是：

  • 工具一旦跨到第三方系统，边界就不只属于你自己

这意味着除了工具 schema 之外，还要额外盘点：

  • 第三方保留哪些数据
  • 返回值会不会把不可信文本重新带回高权限上下文
  • 第三方是否还有自己的副作用链
  • 失败时谁提供审计和回放证据

也就是说，对 MCP / connector 来说，最危险的误判通常是：

  • “这只是另一个工具”

实际上它往往还是：

  • 另一个数据面
  • 另一个权限面
  • 另一个审计责任面

9.2 更稳的做法通常是给执行工具发短时、窄域凭证 ​

很多系统出问题并不是因为模型学会了黑客技巧，而是：

  • 执行工具背后拿着一把长期、高权限、宽作用域的服务账号

更稳的做法通常是：

  • run 级或审批后签发短时 token
  • token 只允许单租户、单对象或单动作族
  • 执行结束立即失效

这样就算模型或工具链被绕偏，爆炸半径也能被控制在更小范围。

9.3 浏览器和 shell 工具更需要“可见动作边界” ​

对浏览器、shell、文件系统这类能力边界特别大的工具，建议额外准备：

  • 高风险命令白名单或 denylist
  • 文件路径 allowlist
  • 出网域名边界
  • 用户确认或审批 checkpoint
  • 执行后产物摘要

否则后面排查时最常见的问题就是：

  • 知道它“做了很多事”
  • 但不知道哪些是计划内，哪些是越界行为

10. 高风险动作最好具备哪些运行时能力 ​

至少建议有：

10.1 幂等或去重 ​

避免重复执行。

10.2 补偿或回滚 ​

出错后能收回。

10.3 审计记录 ​

知道谁触发、为何触发、执行了什么。

10.4 熔断能力 ​

出事故时能快速停用某个工具或某类动作。

10.5 执行后验证 ​

真正稳的执行链路，通常不会在“API 返回 200”就结束。

还应该继续确认：

  • 最终对象状态是否符合预期
  • 是否写到了正确租户 / 正确环境
  • 是否只改了允许改的字段
  • 是否触发了不应有的连带副作用

这一步很重要，因为很多高风险动作的问题并不是：

  • 没调用成功

而是：

  • 调用成功了，但作用在了错误对象上

10.6 紧急冻结开关 ​

更成熟的系统通常还会有几类紧急开关：

  • 全局停某个工具
  • 停某个动作族
  • 停某个租户的写操作
  • 把某类高风险请求统一切成人工 review
  • 把某条 workflow 切到只读模式

这样出了事时不需要：

  • 全站停机

而是先把最危险的执行面收住。

11. 身份与租户边界为什么不能后补 ​

OWASP 当前 agentic 安全资料把 Identity and Privilege Abuse 视为高风险项之一。

工程上更现实的翻译是：

  • 工具调用如果不知道“是谁、在哪个租户、什么角色、什么范围”，就不算真正可控

所以工具执行上下文至少应带：

  • actor id
  • tenant id
  • role / group
  • action scope

11.1 身份上下文最好和执行凭证绑定，而不是只写进日志 ​

如果 actor / tenant / role 只存在于日志里，而不参与真正执行凭证的签发，实际效果通常还是：

  • 工具背后继续用大号权限跑

更稳的方式通常是让：

  • 谁触发
  • 属于哪个租户
  • 允许改哪些对象

直接进入执行令牌、策略匹配和审批决策，而不是只作为事后追责字段。

12. 执行前、执行中、执行后各该做什么 ​

12.1 执行前 ​

  • 参数校验
  • 权限校验
  • 风险分类
  • 是否需要审批

12.2 执行中 ​

  • 超时控制
  • 幂等控制
  • 结果收集

12.3 执行后 ​

  • 审计记录
  • 补偿或回滚入口
  • 回放字段保留

12.4 执行前后都要能冻结和人工接管 ​

尤其对长工作流来说，还应该明确：

  • 哪些节点允许暂停
  • 暂停后由谁接管
  • 接管后能不能跳过后续自动动作
  • 恢复时是否需要重新审批

否则系统很容易出现：

  • 自动阶段出问题了
  • 但流程还在继续往后跑

13. 典型故障到治理动作 ​

13.1 工具调用成功率下降 ​

优先查：

  • schema 是否变化
  • 参数是否越界
  • 下游服务是否异常

13.2 低权限角色偶发能做高权限动作 ​

优先查：

  • 工具暴露边界
  • 运行时身份上下文
  • 审批是否被绕过

13.3 写动作重复执行 ​

优先查：

  • 重试策略
  • 幂等键
  • 后台任务恢复逻辑

13.4 明明审批了，结果还是错 ​

优先查：

  • 审批看到的信息是否足够
  • 草稿与最终执行对象是否一致
  • 执行前是否又被二次改写

14. 常见反模式 ​

  • 所有工具对所有角色默认开放。
  • 只校验工具名，不校验参数范围。
  • 高风险动作没有审批或二次确认。
  • 工具成功就算完成，不记录执行上下文。
  • 失败重试没有幂等保护。
  • 审批看的是自然语言总结，执行落地的是另一组结构化参数。
  • 第三方 MCP / connector 用长期高权限凭证，不做短时窄域令牌。
  • 没有 draft / commit 分离，模型一生成就直接落库或对外发送。
  • 没有紧急冻结开关，出事只能全站停。

15. 推荐搭配阅读 ​

16. 重点官方资料 ​

以下资源已按 2026-07-08 复核可访问：