安全评审把 MCP 工具清单摊开以后，通配路径、任意 shell、连写库都没人审的条目，往往比功能列表更抢眼。接 Coding Agent 时工具一多确实爽：读文件、跑命令、查库、开浏览器，对话里直接串起来。省事的另一面，是把过权当成默认配置。
OWASP AI Agent Security Cheat Sheet 把这类风险归在 Tool Abuse、Excessive Autonomy、High-Impact Action Abuse 下面。工具安全一节给的对比很明白：反例是一把梭的 MCP（例如 allowed_commands: "*"）。正例是 scoped allowlist——限定路径、只授 read、挡住 *.env / 密钥类模式。授权要落在执行组件里，而不是只信模型自己说的「用户已确认」。
一把梭和白名单差在哪
清单里「最小权限」几条可以压成日常检查：
- 只挂当前任务真正需要的工具，别为了「以后可能用到」先全开。
- 同一工具拆成只读 / 可写两套。用户可见 Agent 和内网运维 Agent 别共用一套过权配置。
- 敏感操作要显式授权。执行侧校验的是「这次调用的工具名、目标、参数」和未过期的批准对不对得上，改参数就要重新批。
- 未知工具默认拒绝，别静默放行。
Cheat Sheet 还提醒：user_confirmed 一类布尔标记不够。批准记录要绑到具体 actor 和这次 tool call，校验与消费要原子完成，避免并发或重放把同一批准用两次。高影响动作（删库、转账、改生产、对外发信）要把决策和执行拆开，由策略或执行组件再验一遍范围和权限。缺策略、缺审计或风险分类失败时默认拒绝执行，而不是「先跑了再说」。
间接提示注入也和工具权限缠在一起：网页、邮件、仓库里的说明一旦进上下文，过权工具会把「模型被带偏」放大成真实副作用。工具面收得越窄，单次注入能造成的损失上限越低。
只读可以松一点，写操作走人审
按文档里的风险分级思路，搜文档、读指定目录、只读查询，可以落在低风险、少打断。写文件、执行命令、发邮件、改库，默认走人审或独立的高权限通道。很多团队真正翻车的地方，是把「能查生产库的只读 MCP」和「能改配置、能跑迁移的写 MCP」挂在同一个会话里，模型一顺手就从 select 滑到 update。
和「办公网 Agent 调生产 CLI」「命令行把密码留在 ps 里」是同一类边界问题：工具入口一旦对 Agent 开放，身份、网络和审计要一起收。相关讨论可以和本批里 argv / 生产 CLI 那几篇对照着看，这里不展开打穿步骤，也不贴未发帖的站内链接。
落地时不必追求一次配完美：
- 先把 shell / 任意 HTTP / 写库类工具从默认会话拿掉，需要时再开独立 profile。
- 路径 allowlist 写成具体前缀，避免
*扫到家目录和密钥文件。 - 写操作要求预览或 diff，再点确认。确认票据短命、不可复用。
- 会话里记工具名、结果状态、有没有经人审，方便事后对账。高风险动作记下分类、授权结果和策略版本更有用。
- 提示词、工具策略、检索源有大改时，按 Cheat Sheet 的滥用用例矩阵回归一遍（越权工具、批准绕过、记忆投毒、多 Agent 传递提权等）。
- 给工具链、重试和费用加上限，避免文档里说的 Denial of Wallet：循环调用把账单打爆。
也不要去推销某一家第三方 MCP 商店或「万能工具包」。协议能接什么，和你该不该把写权限交给当前会话，是两件事。厂商演示里的「一键接入全部工具」往往按功能完整度排，不按你的威胁模型排。
你们现在给 Agent 挂的 MCP，写操作是默认开着，还是已经拆成只读会话加人工闸门了？