权限策略、命令白名单与安全审计

代理能力越强，越需要清晰的授权边界。权限治理的目标是在效率与安全之间取得平衡：常规工作顺畅执行，高风险动作可控、可审计、可回收。本节梳理权限模式、允许/拒绝规则与治理实践。

一、常见权限模式定位

模式	行为特征	典型场景
计划模式 plan	只读分析、产出方案，不落改动	动手前调研、影响评估、方案设计
自动模式 auto	由安全分类预审常规动作，拦截高风险（越权、未知基础设施、可疑内容驱动）动作	交互式常规开发，减少频繁确认
手动模式 Manual	写文件、命令、外部工具等动作逐项确认	高风险仓库、不熟悉的任务、严格审计要求
无人值守 dontAsk	非交互运行中拒绝一切待批准动作，只执行已授权项	脚本/CI 批量运行，避免卡住等待确认

模式可在交互中切换，也可在非交互调用时通过参数指定；选择应匹配任务风险，而不是固定追求"全自动"。

二、允许列表与拒绝规则

• 会话中可用 /permissions（其别名为 /allowed-tools）查看与管理允许规则，把明确安全、高频的工具/命令加入白名单，减少重复确认。
• 白名单宜具体到命令范围，例如限定版本检查、格式化、提交等确定动作；避免宽泛放开整条命令族。
• 外部 MCP 工具的授权写法为 mcp__<服务器名>（批准整台服务器）或 mcp__<服务器名>__<工具名>（单工具）；不支持通配符写法，应按需最小授权（与第 7 章一致）。
• 可用拒绝规则兜底：例如 Agent(子代理名) 禁用特定子代理，或对特定工具整体拒绝；拒绝规则优先级高，用于明确"绝不允许"的动作。

三、分层授权实践

1. 只读层：探索、审查、文档分析默认只读，不给写入与发布能力。
2. 受限写层：实现阶段限定编辑范围与必要命令，先在工作副本内验证。
3. 受控执行层：测试、构建、格式化等命令经白名单放行；提交、推送、合并、外部系统变更保持人工确认或严格限定。
4. 兜底拒绝层：对敏感目录、破坏性命令、凭证操作与未登记外部调用设置拒绝规则。

四、安全卫生与审计

• 密钥、令牌、个人路径不写入提示词、命令文件与记忆文档；凭据通过受保护的环境或授权机制提供。
• 定期复核允许清单：删除不再使用的授权，收紧过宽规则；对共享项目的规则文件做版本评审。
• 保留可追溯痕迹：改动 diff、运行日志、被拒绝动作记录，便于事后复盘"做了什么、为何放行"。
• 优先使用官方 CLI 与受控工具访问外部服务；新增外部服务器前评估其可执行动作与数据范围（呼应第 7 章 MCP 安全清单）。
• 沙箱类隔离能力可用于限制文件系统与网络访问，具体可用选项以当前版本官方文档为准；高风险环境优先在隔离副本中运行。

五、按任务风险选择授权策略（决策表）

任务场景	推荐模式/授权姿态	关键控制点
只读调研、影响评估、方案设计	计划模式 plan，只读不写	只产出方案与文件清单，不落改动
熟悉仓库的常规实现	常规自动模式，仅白名单放行高频安全命令	写操作限定工作副本，高风险动作仍拦截
不熟悉仓库 / 高风险改动	手动模式，动作逐项确认	提交、推送、外部变更必须人工确认
脚本 / CI 无人值守运行	dontAsk 模式 + --allowedTools 最小白名单	拒绝一切待批准动作，只跑预授权步骤；失败项记录不越界补做
接入外部 MCP 服务	单工具最小授权，拒绝规则兜底	不整台服务器泛放开，按需逐个批准并复核数据范围

六、FAQ

问题	处理建议
白名单到底该放到多细	只对确定安全、高频的具体命令放行（如格式化、定向测试、只读检索）；写、推送、删除、外部网络调用保持确认或拒绝；宁可略紧、逐步按需放宽。
dontAsk 是否等于"什么都不让做"	不是：它执行已在白名单内的预授权动作，只拒绝需要待批准的项；无人值守脚本必须先把必要工具写进授权列表，否则任务会在第一步停下。
共享项目如何让权限规则一致	团队级规则集中维护并纳入版本评审，个人本地规则不覆盖团队安全基线；新增授权经评审后统一沉淀，不长期依赖临时确认。
如何确认没有敏感信息被带进命令或记忆	提交前做只读扫描，检查提示词、规则文件、自动记忆与示例数据中是否含密钥、内部路径；凭据改用受保护环境提供，不写入库文件。
发现规则过宽想收紧怎么办	先删冗余授权、收紧泛化条目，再在小样任务上验证常规工作不受阻；收紧后观察被拒绝动作日志，把确需的安全动作补回白名单。

七、动手练习

• 练习 1：为一个真实项目列出"只读 / 常规实现 / 高风险 / 无人值守"四类任务各自应放行与应拒绝的命令清单，区分具体动作与命令族，形成最小授权方案。
• 练习 2：在无人值守方式下对一个只读分析任务配置最小工具白名单并运行，记录哪些动作被拒绝、是否需要补授权，体会"先授权后自动"的顺序。