自动关联目录：工具权限：Tool Schema 不是执行授权

核心判断：Tool Schema 只约束参数形状；能否执行必须由宿主根据会话、目标资源、影响类型、预算和用户许可重新裁决。

一、业务冲突

同一个 write_file 既可能修改临时草稿，也可能覆盖构建配置；同一个 Shell 既可能运行只读查询，也可能启动外部副作用。若权限只按工具名判断，“本会话允许”会把一次低风险操作扩张成对任意参数和任意目标的授权。

二、实际实现

实际权限引擎把工具分为只读、文件写入、副作用和独占四类，并从安全级别推导审批策略。allow_once 按工具名与规范化参数摘要缓存，allow_session 按工具名缓存；没有权限解析器时失败关闭。Plan 模式既过滤模型可见 Schema，又在执行前硬拦截。

每次权限请求和裁决进入事件流，PreToolUse Hook 还能在授权后、执行前阻止调用。外部工具默认按副作用处理，未知安全级别也不会自动降为只读。

三、值得保留

Schema 可见性、执行期权限、Hook 和审计事件四层分离是正确设计。尤其是“没有 UI Resolver 就拒绝”和“未知工具按副作用处理”，避免了集成缺失时静默放权。

四、结构性缺陷

allow_session 只绑定工具名，不绑定工程、目录、操作类型或参数范围；批准一次 Shell 后，本会话的其他 Shell 参数也可能直接通过。allow_once 虽绑定参数摘要，却没有规范化成业务目标，例如等价路径、重定向和工具内部二次访问。开发/CI 的 bypass 模式若进入普通会话会绕过全部审批，工具名安全表也无法描述一个 MCP 工具内部的多种 Effect。

五、目标设计

审批产物应是一张最小权限 Capability Grant：

struct CapabilityGrant {
    SessionId session;
    Principal user;
    ToolId tool;
    EffectSet effects;          // Read, Write, Execute, Network, Publish
    ResourcePattern targets;    // 规范化工程内路径或对象集合
    Budget maxCost;
    uint32 maxCalls;
    TimePoint expiresAt;
    Hash policyRevision;
};

Authorize(call) = SchemaValid(call)
               && GrantCovers(call.effect, Canonicalize(call.target))
               && PreconditionsHold(call)
               && BudgetAdmits(call);

工具注册时声明可能的 Effect 和目标提取器，宿主根据真实参数计算本次权限，模型不能自行声明“这是只读操作”。

六、取舍与验证

资源级授权会增加提示次数，因此需要受限的目录级或对象集 Grant，而不是退回整会话全放行。截至 2026-10-14，官方 Agent 安全指南仍建议为工具保留审批，并强调结构化输出和隔离不能彻底消除 Prompt Injection；MCP 规范的无状态化也更强调由应用显式携带身份与能力，而非依赖隐藏会话状态。Agent safety、MCP 2026-07-28

测试要覆盖路径别名与逃逸、同工具换参数、Grant 过期、策略升级、嵌套工具、批量调用、bypass 误配置和授权后前置条件变化。最终必须能回答：谁在何时允许哪个会话，以什么预算，对哪些资源产生哪类副作用。