把一个 MCP 服务接进 Codex，验证连接正常，然后把服务挂的全部工具交给 AI agent 随手用——这是接入时的默认路径，也是最危险的一条。一次接入动辄带进几十个工具，读的写的、查的删的混在一起，agent 在错误指令或注入攻击下能摸到哪一层，取决于你放开了多少。安全研究里对真实接入的测量给过一个扎眼的结论：默认配置下的能力供给，可以达到任务实际所需的十五倍上下——十五倍的能力过度供给，意味着绝大多数风险面是白送出去的。这篇按误区文的惯例，先摆三种常见说法再逐条纠正，然后给白名单的配法与上线前的验证流程。
说法一：连上了就能用，工具多说明能力强
第一种说法把工具数量当能力指标。对照看，agent 用不上不等于摸不到——模型在每轮决策时面对的是当前可用的全部工具，工具越多，误选的概率越高，被提示注入诱导去调用危险工具的面也越大。提示注入怎么让 agent「听别人的」，见提示注入一篇；放到 MCP 场景里，网页内容、文档批注、外部数据都可能夹带指令，而全量放开的工具清单给了这些指令施展的空间。能力由任务需要的那几个工具决定，与清单长度无关。
说法二：服务是可信的，不用再裁一刀
第二种说法把信任押在服务来源上。对照看，服务可信与配置保守是两回事：服务方不会了解你的项目里 agent 该碰什么——同一个数据库服务，开发环境该给写权限，生产库前只该给只读；同一个文件服务，这个项目只需要读两个目录。默认全量放开，等于把「agent 该做什么」的决策权完全交给了服务方的工具设计，而服务方设计工具时想的是通用场景的完整覆盖。十五倍过度供给的测量正是这么来的：服务供给的能力集合，远大于任何单一任务的真实需要，差的这部分不是功能，是敞开的风险面。
说法三：先全开跑通，安全以后再说
第三种说法把授权当成后续优化项。对照看，白名单是配置里的一行事，成本极低；而出事之后的补救——回滚误删的数据、追查泄露的凭据——成本高出一个量级。扩权的时机也比收权好把握：任务跑通了，确实需要写权限再加一条，代价是几分钟；反过来先全开再想收，往往想不起来收。插件与工具的权限边界怎么理解，插件权限一篇有通用框架，MCP 是同一套逻辑的工程化落地。
白名单怎么配：enabled_tools 与只读先行
具体配法分三步。第一步列清单：把服务提供的工具全列出来，标注每个是只读还是写操作、动的是哪类资源。第二步配 enabled_tools 白名单：在服务条目里显式声明本次放开的工具名，没列进名单的一律不注册——从「全开再关」改成「关着按需开」，这是两种配置思路的分水岭。第三步按读写分层推进：先只放开只读工具，让 agent 跑几天真实任务，确认它查得准、不乱来，再逐条加入写工具，每加一条观察一段。写操作里不可逆的那类——删除、覆盖、对外发送——能不放开就不放开，确要放开时配合沙箱与审批两层一起用，两层的分工见审批与沙箱两层一篇。
| 工具类型 | 默认怎么处理 | 放开的前提 | 文中给出的理由 |
|---|---|---|---|
| 只读查询工具 | 先放开 | 让 agent 跑几天真实任务，确认查得准、不乱来 | 只读是风险大幅下降的一档，不是免责的一档 |
| 写操作工具 | 逐条加入，每加一条观察一段 | 只读阶段跑稳之后再动 | 扩权几分钟，收权常常想不起来 |
| 删除、覆盖、对外发送 | 能不放开就不放开 | 确要放开时配合沙箱与审批两层 | 这类操作不可逆 |
| 白名单外的工具 | 不注册 | 任务卡在哪一步再补哪一条 | 多数任务真正依赖的工具只有三五个 |
上线前：用测试账号把白名单跑一遍
白名单配完不等于完事，上线前拿测试账号走一遍完整流程。测试账号指向测试资源：测试库、测试目录、测试的第三方账号，agent 在里面怎么调用都伤不到生产数据。要验证的清单不长：白名单外的工具确实调不到；白名单内的只读工具行为符合预期；第一个写工具放入后，观察 agent 什么时候主动调用、参数给得对不对。测试跑稳了再切到真实账号，同时把测试环境与生产环境的差异记录下来——凭据不同、资源路径不同，这些差异点正是日后排障的入口。接入与排查的完整链路见Codex 接 MCP与MCP 连不上两篇。
MCP 最小授权速查
- 连接成功不等于可以全量放开，默认全开是风险面白送
- 测量实锤：默认配置的能力供给可达任务所需的十五倍上下
- enabled_tools 白名单：关着按需开，不搞全开再关
- 推进节奏：先只读后写，不可逆操作尽量不放开
- 上线前用测试账号跑通白名单，再切真实账号
关于 MCP 授权的常见疑问
- 白名单关掉的太多，agent 任务完不成怎么办？：先看任务卡在哪一步，缺哪个工具补哪一条，而不是整批放开。多数任务真正依赖的工具只有三五个，十五倍的过度供给说明放开清单里大部分本来就用不上。
- 只读真的安全吗？：只读不代表零风险——读到的数据可能被带进回答发给外部，敏感库的只读同样要斟酌。只读是风险大幅下降的一档，不是免责的一档，敏感资源按需再收紧。
- 多个项目共用一个 MCP 服务，白名单怎么管？：按项目层配置各自声明 enabled_tools，全局层只放公共的只读工具；每个项目的 agent 面对各自的最小集合，互不放大权限面。
想把自己的放开清单审一遍，可以让 DeepSeek 按读写属性把你所有 MCP 工具列成一张分级表，再用豆包对照你最近的 agent 任务清单，标出哪些工具从来没人调用——那张表就是可以关掉的部分。
