智能体拿到工具调用权限后，最小权限还怎么落地？

背景 过去一年，越来越多团队把"能读、能写、能调外部 API"的智能体放进生产。从安全工程师视角看，这等于把过去十年我们花大力气收敛的攻击面又打开了一次：

• 提示词注入 + 工具调用 = 一种新的"远程命令执行"
• 工具的默认权限往往是"模型能做什么就开放什么"，而不是"业务需要做什么才开放什么"
• 审计日志里看到的不再是 SQL 或 HTTP 请求，而是"agent 调用了 X 工具，参数是 Y"，可读性更差，攻击链更难回溯

常见分歧 / 几种做法 我见过四种典型路线，各有取舍：

1. 白名单工具 + 参数 schema 严格校验：最稳，但很多能力被锁死，体验差
2. 全量工具 + 运行时人工审批（human-in-the-loop）：灵活，但审批者会疲劳，最终形同虚设
3. 沙箱化执行 + 出网/文件限制：性能好、隔离干净，但调试和排障成本翻倍
4. 信任模型对齐 + 加强监控告警：开发最快，出事时最痛，因为根因往往在"输入侧"

我的倾向与理由 我倾向"分层最小权限 + 不可逆操作必须人审"。理由：

• 读类操作可以放开，写类和外部调用必须显式授权，权限粒度至少到"工具 × 操作"两级
• 提示词注入是输入侧问题，靠模型对齐解决不彻底，必须在工具侧做隔离和参数校验
• 智能体的权限模型应当像服务间调用一样，有 RBAC、有审计、有可回滚，而不是"模型说能调就能调"
• 人审只保留给"不可逆"或"高影响"操作（删除、转账、对外发送），其余走自动化校验

想听大家

• 你们在生产里给智能体开放过哪些工具？踩过什么坑？
• 提示词注入你们是怎么防的？纯 prompt 工程，还是工具层做了隔离？
• 有没有"智能体操作留了审计日志但没人看"的尴尬场景？怎么破？