第十章：安全与隐私：密钥、脱敏、最小权限

10.1 先把一句话讲透：风险来自“能力”，不是“意图”

当工具能够：

• 读取代码与配置
• 修改文件并产出 diff
• 运行命令（测试、构建、脚本）

风险就天然存在。安全策略必须前置，而不是事后补救。

10.2 绝对禁止项（建议写进团队规范）

• 不粘贴密钥/Token/私钥到对话或仓库
• 不读取或修改 .env、证书、私钥文件
• 不运行破坏性命令（删除/清库/批量改写）
• 不在含真实用户数据的生产环境做探索式排障

你可以直接把这段写进任务约束：

安全约束（必须遵守）：
1) 不输出、打印、提交任何密钥或敏感数据
2) 不读取/修改 .env、证书、私钥
3) 不运行破坏性命令（删除/清库/批量改写）

10.3 脱敏：排障日志是最常见泄露源

最常见的敏感信息来自：

• Authorization header、Cookie/Session
• 手机号、身份证、地址、订单号
• 内网域名、IP、服务拓扑

建议你遵循“最小披露”原则：

• 只贴最小必要片段
• 去掉 header 与 payload 的敏感字段
• 能用伪造数据就不要用真实数据

10.4 最小权限：目录边界 + 命令白名单 + 质量门禁

把权限拆成三层，通常足够覆盖日常研发：

• 目录边界：只允许修改 src/ 与 tests/
• 命令白名单：只允许运行 tests/lint/typecheck/build
• 质量门禁：任何改动必须通过验收命令与诊断检查

示例：

边界：
- 只允许修改 src/ 与 tests/
- 只允许运行：<tests>、<lint/typecheck>、<build>
- 每轮修改先输出 diff，我确认后再继续

10.5 本章小结

安全不是“提醒一下”，而是“默认路径”：

• 禁止项写清楚（密钥、破坏性命令、生产数据）
• 日志先脱敏再粘贴
• 最小权限三层防护（目录/命令/门禁）

下一章进入团队落地：如何把规则与模板固化，让每个同学都能稳定交付。