上一篇讲了「Runtime over Prompt为什么 System Prompt 不是安全边界」——安全边界要落在 Tool 真正执行之前。这一篇往深一层边界既然落在执行路径上Runtime 凭什么判断一个 Tool 该不该放行AI 真正让企业犹豫的往往不是「读」而是「写」——查客户可以改客户呢发邮件呢删数据呢一、读和写风险不对称AI 读数据出错了是「看错了」——改回来即可损失有限。AI 写数据出错了是「改坏了」——订单金额改错、客户资料覆盖、邮件发给了不该发的人很多是不可逆或代价高昂的。所以企业对 AI 的态度通常从「让它查」到「让它做」之间有一道坎。这道坎的本质是对不同风险的操作企业要不要用同一套策略对待显然不要。查客户可以自动改合同必须人批删数据根本不该允许。这就是「工具风险分级」要解决的问题先给每个 AI 操作定一个风险等级再按等级决定执行策略而不是一刀切「全部自动」或「全部人审」。二、R0-R5一套可落地的分级把 AI 工具按风险从低到高分成六级每级对应一种执行策略等级含义例子执行策略R0信息性说明、统计概览自动R1只读查询客户列表自动R2低风险写更新备注策略决定治理可配置R3业务敏感写创建跟进任务、改订单人工确认R4高影响动作双人审批类操作双人审批R5不可逆 / 外部动作删除数据、发邮件阻断关键设计点读自动写确认高风险阻断——低风险自动化提升效率高风险人工把关不可逆直接拦死。显式声明优先未声明按语义派生——工具声明了风险级就按声明没声明时写操作默认 R3需确认、读操作默认 R1自动。漏声明不意味着「放行」而是「保守确认」。策略可覆盖——治理层可以在运行时覆盖单个工具的启用与确认要求实时生效。这套分级的好处是它把「敢不敢让 AI 做事」从感觉变成规则。业务方不用逐个判断只需要按风险级定策略。三、分级怎么在运行时落地分级本身只是纸面规则真正让企业放心的是它在运行时的强制力。一条完整的执行链工具声明风险级R0-R5→ 权限检查行级数据范围本人 / 组织→ 策略门控R5 阻断 / R3-R4 确认 / R0-R2 自动→ 人工确认确认了才执行拒绝则不执行→ 执行写操作 → 副作用登记可撤销 审计入链以开源项目 KeelBase 的实现为例这套链是可验证的。仓库境内访问建议用 Gitee 镜像Giteehttps://gitee.com/rain6fish/KeelBase工具声明每个 AI 工具带riskLevelMCP 出口把风险级透出到工具声明_meta.keelbase——外部客户端调用前即可见。门控R5 直接阻断响应明确告知「该操作已被安全策略阻断」R3/R4 返回确认标记人工批准后才执行。审计每次执行都落审计哈希链被拒绝的调用同样留痕授权拒绝写isErrortrue 拒绝理由清单可追溯、防篡改。撤销AI 创建的副作用登记后可撤销含跨系统补偿。协议合规认证套件锁定这套语义。实跑Server-NestJS/scripts/verify-protocol-conformance.mjs的输出─ 工具风险分级协议 §4─✓ RISK_STRATEGY 表与语料一致✓ R1读→ auto / 无需确认✓ R3业务敏感写→ confirmation / 需确认✓ R4高影响→ human_approval / 需确认✓ R5不可逆/外部→ block / 阻断✓ 派生规则未声明写工具 → R3 confirmation✓ 派生规则未声明读工具 → R1 auto═══ Conformance 结果34/34 通过0s═══篡改、越级、确认绕过都会在这里被拒。结语AI 写数据不是不能做而是要分级、要确认、要可追。把「敢不敢让 AI 做事」变成一套可执行的规则企业才敢把 AI 从「助手」升级成「干活的」。如果你也在做 Agent可以拿自己的系统对三个问题工具清单里有没有「写操作」是没有任何执行策略的——能调就执行没声明风险的工具默认是放行还是保守确认高风险操作被拦住时是模型自己回了一句「我不能」还是执行层真的拒了第三个问题最关键。如果答案是「模型自己拒绝的」那这道边界还停在 Prompt 层没落到执行路径上。如果你发现某种工具分级或门控方式可以绕过欢迎直接提 IssueGitHub 或 Gitee 都行——我更想看到失败案例而不是只有成功案例。