帖子说了什么
@twelvereasonss 分享了一个小实验：同一个 Agent，两天里对同一个问题做了两种安全决定。代码里硬编码着一个已经泄露的 sk-live 密钥，他让 Claude Code 修复。
- 第一天：Claude Code 把密钥移到环境变量，读取不到时直接报错（fail-closed），并提醒他去轮换这个 Key。
- 第二天：同样移到了环境变量，但把泄露的旧 Key 留在代码里当作兜底值。
他说另外两个编程工具两次都留了兜底值。
「兜底值」为什么等于没修
常见的写法类似 key = os.getenv("STRIPE_KEY") or "sk-live-..."。看上去密钥「已经改成从环境变量读」，代码审查时也容易一眼放过，但旧 Key 还是完整地躺在源码里，进了 Git 历史，跟着仓库被克隆、被推到远端、被别的工具读取。只要它没有被吊销，任何拿到代码的人都能用。
这件事也说明：同一句提示词，Agent 不会每次给出同样的安全判断。不能因为它上次做对了，就默认这次也对。
落地做法
- 修完搜一遍旧 Key。 用
git grep搜密钥的前几位，确认源码、测试、配置样例里都不再出现。 - 读取失败就报错。 环境变量缺失时让程序直接停下并提示，不要设任何「默认密钥」。可以把这条写进给 Agent 的指令里，作为验收条件。
- 泄露过的 Key 一律吊销。 移出代码不等于安全，已经进过仓库或聊天记录的 Key，要去对应平台吊销并换新。Claude API Key 在 Console 里处理。
- 清理历史前先吊销。 先让旧 Key 失效，再考虑重写 Git 历史，顺序反了中间就有空窗。
- 加一道推送前检查。 在 pre-commit 或 CI 里跑密钥扫描，Agent 和人提交的代码都要过。
小结
让 Agent 修安全问题很省事，但验收还得自己来：搜一遍、看有没有兜底值、把 Key 吊销掉，三步就能避免「看起来修好了」的假象。
