同一工具在不同场景应有不同权限，工具权限控制如何分层设计？

同一个工具在不同场景的风险完全不同——比如「执行 SQL」在只读分析场景安全，在生产库写场景就极危险。所以权限不能挂在工具上一刀切，要分层授权 + 最小权限 + 运行时拦截 + 审计。

分层维度

1. 按用户/角色：普通用户、运营、管理员能用的工具集不同（RBAC）。
2. 按渠道/会话：同一用户在公开群和内部后台的权限不同，公开渠道收紧。
3. 按 Agent：不同 Agent 被授予不同工具集，客服 Agent 不该有数据库写权限。
4. 按工具与具体动作：同一工具拆分读 / 写 / 危险操作三级，只读放开、写入受限、删除/转账等高危单独管控。

这四层逐级求交集，最终权限是各层的最小交集，天然贴合最小权限原则——默认拒绝，只显式开放必要项。

白/黑名单与配置化策略

用配置化的策略表描述「哪个主体（用户/角色/Agent）+ 在哪个渠道/会话 + 能调用哪个工具的哪些动作」，以白名单为主、黑名单兜底敏感项。策略与代码解耦，支持热更新、灰度和回滚，便于审计和合规。

危险操作二次确认与审计

对写入、删除、对外发送、支付等高危动作，即便有权限也要走二次确认（human-in-the-loop 或显式确认令牌），并把每次工具调用的主体、参数、结果、时间全程审计留痕，做到可追溯、可回放、可问责。

运行时鉴权拦截

所有工具调用前统一经过一个策略引擎/拦截器校验，模型只是「请求」调用工具，是否放行由系统决定，绝不把鉴权交给提示词去自觉遵守。校验失败直接拦截并返回安全提示，防止提示注入绕过权限。