给 AI 接工具的权限设计：账号、Key、参数三层
给 AI 接了工具之后，最常被问到的问题是"它会不会乱来"。答案不取决于模型，而取决于你把权限切成几层。本文给出一套可以直接落地的三层模型。
一、为什么"一把总开关"一定出事
如果所有场景共用一把万能 Key：出问题时你无法回答三个问题------谁在调、调了什么、花了多少。日志只能告诉你"有一把 Key 在调"，定位就此断链。
二、三层权限模型
第一层：账号层
谁能用这个客户端。这是团队准入，解决"人"的问题，不解决"工具"的问题。
第二层：Key 层
一把 Key 能调哪些工具、能花多少额度。这是最实在的一层：
| Key 用途 | 开放工具 | 额度策略 |
|---|---|---|
| 日常信息活 | 搜索、网页解析、结构化抽取 | 给足，高频 |
| 文档处理 | 文档解析、新闻检索 | 按项目，用完关 |
| 重能力 | 图像生成、云沙箱 | 单独审批，单独看用量 |
第三层：参数层
同一把 Key 内，哪些参数禁止传：密钥、完整请求头、身份证、手机号、客户名单、内网地址、未公开源码。参数会离开你的电脑，回包还会进客户端与模型。
三、一个容易搞错的概念
客户端界面上的"启用工具"勾选不是授权边界，它只决定模型看不看得见。真正的边界在 Key。把两者混为一谈，就会出现"我在界面上关掉沙箱了"这种自我安慰。
四、落地清单
- 按用途建 Key，命名能看出归属人/产品线。
- 重的、有副作用的能力单独 Key，单独配额。
- 说明书里写一份"禁止入参"清单。
- 控制台按 Key 看用量，异常时第一动作是停而不是充值。
- 离职/换项目时，Key 的回收写进流程。
五、边界为什么要分层
因为故障定位要靠层。有了三层，你能立刻回答是"谁在用""哪把 Key""传了什么"。没有分层，一句"AI 乱调了"就是结论，也就没有改进空间。
小结
权限设计的目标不是让 AI 什么都不能做，而是让每一次调用都能被追溯到人。最小权限从来不是省钱技巧，它是可维护性的前提。
六、常见反问
问：小团队也要分三层吗？
答：层数可以少，但不能没有。一个人也建议至少两把 Key：一把日常轻工具，一把重能力。
问：Key 放哪里？
答：放进密钥管理或环境变量，不要进仓库、群聊、截图。泄了立刻轮换，轮换成本远低于事后追查。
问：客户端能不能帮我兜住？
答：客户端过滤只能减少误调，不能当授权边界。真边界在服务端按 Key 的权限控制。