比起天天讨论的 Prompt 注入，工具执行权限如果不把好关

真正实操下来发现，很多框架的校验逻辑太业余，很多回调函数是在工具跑完之后才触发的，这时候才发现出错了已经没意义了。一个靠谱的工具执行安全链路应该长这样：

一、前置策略拦截
校验必须发生在工具运行之前。如果你的验证逻辑在执行之后才跑，那不叫安全校验，那叫“事后验尸”。

二、工具权限分级
不能把所有工具混在一起，得按影响范围分类：

• 只读类： 风险最低，随便跑。
• 写入/修改类： 需要记录，严格限制范围。
• 删除/支付/外部发送类： 极高风险，必须触发人工审核。

三、不可逆操作的人工闸门
只要是涉及钱、删数据或者发对外 API 且无法回滚的操作，必须强制加一个 Human-in-the-loop 的确认环节，绝对不能全自动化。

四、不可篡改的执行日志
日志里不能只写“调用了工具 X”，得把具体的参数、目标对象、执行结果以及谁审核通过的全部记下来，方便出事后追溯。

五、默认关闭原则 (Fail Closed)
如果安全策略引擎挂了或者响应超时，系统应该直接拦截所有请求，而不是为了保证可用性而默认放行。

目前市面上很多 Agent 框架在这个细节上做得并不好，大部分只是在做简单的 Prompt 约束。最近看到 Custodyn 尝试在运行时做策略网关，这种在执行路径上强行截断的思路才比较硬核。

# 假设一个简单的策略检查伪代码逻辑
if (policy_engine.validate(tool_call) == ALLOWED) {
    execute_tool(tool_call);
} else {
    log_security_event(tool_call);
    throw SecurityException("Unauthorized tool execution");
}