别把密钥交到 AI 手上：vibe 项目的凭据管理实战

先说一个 vibe coder 几乎人人都经历过的剧本：深夜，你让 AI"把支付接通、上线"，它吭哧吭哧写完代码、跑通测试，你顺手 git push，睡觉。第二天早上，Stripe 给你发来一封"检测到你的 secret key 被公开"的邮件——AI 为了图省事，把 STRIPE_SECRET_KEY 直接写进了前端能访问到的配置文件里，而那个文件被打进了浏览器 bundle，也躺在了 GitHub 公开仓库里。从那一刻起，这把 key 就不再是你的了：扫描机器人全天 24 小时在 GitHub 上爬新 push 的密钥，平均几分钟内就会有人试着用它刷一笔。

这不是"人不小心"，这是 AI coding 时代的新常态。以前泄露密钥靠人手滑，现在 AI 会主动把密钥写进代码、写进注释、写进 commit message，甚至写进它生成的文档里——而你 review 时眼睛一扫，"能跑就行"，就放行了。所以这篇指南不讲大道理，只给一套凭据五态管理框架：一把密钥的生命周期只有五个状态——生成 → 存储 → 使用 → 轮换 → 泄露应急，每个状态回答一个问题，五个问题全答对，密钥才算管住了。下面所有清单、配置、AGENTS.md 红线原文，都可以直接抄走。

开始之前先对齐一个判断，这也是全文最重要的结论：一人团队别自建 Vault，直接用平台环境变量起步，项目超过两个或环境超过三套再上 Doppler 免费档。HashiCorp Vault 是给有 SRE 团队的公司准备的，一个人运维 Vault 等于给自己埋了个需要 24 小时值守的雷。凭据管理的目标是"别泄露"，不是"架构好看"。

一、vibe 项目最常见的 5 种密钥泄露姿势

先认识敌人。下面五种，每一种我都见过真实翻车，且每一种在 AI coding 工作流里都会被放大：

姿势 1：.env 进了 git。最经典，也最持久。git init 时忘了写 .gitignore，或者 ignore 里写了 .env 却没写 .env.local，AI 新建了个 .env.production 直接 push。更隐蔽的是：你后来补了 .gitignore，但 key 早就在 git 历史里了——git 历史里的密钥，删文件是删不掉的，公开仓库里的一旦 push 就视为已泄露。中招信号：GitHub 给你发 secret scanning 告警邮件，而你"改天再看"。

姿势 2：AI 把 key 写进前端代码。AI 时代的新王。你说"把支付接通"，AI 把 sk_live_xxx 写进了一个前端 import 的文件，或者塞进 NEXT_PUBLIC_ 开头的环境变量——Next.js 里所有 NEXT_PUBLIC_ 变量都会被打进浏览器 bundle，打开 devtools 就能看见。AI 不理解"前后端边界"，它只理解"这样能跑通"。中招信号：view-source 里能搜到 sk_live。

姿势 3：截图和录屏里露出密钥。终端里 cat .env 查个变量，顺手截屏发群里问问题；录演示视频时，VS Code 侧边栏的 .env.local 展开着；浏览器 devtools 的 Network 面板里，请求头带着 Authorization: Bearer sk-xxx，录屏一帧不落全录进去。AI 时代的放大器：你把报错截图喂给 AI debug，截图里就有 key，而这张截图又进了聊天记录、issue、文档。

姿势 4：日志把密钥打印出来。console.log(process.env) 调试完忘了删；AI 生成的错误处理中间件把整个请求头打进日志；更狠的是把整份 env 发到 Sentry 这类错误上报平台——等于把密钥存到了第三方。中招信号：日志平台里能搜到 sk- 开头的东西。

姿势 5：平台环境变量配错了可见性。Vercel、Cloudflare 这类平台的环境变量是分环境的（Production / Preview / Development），还有的会问"要不要暴露给浏览器"。手一抖把 secret 标成可公开，或者 Preview 环境用了 Production 的 key，而 Preview 的部署 URL 是公开可访问的，fork 来的 PR 触发的 CI 还可能把环境变量打进构建日志。AI 不会替你检查控制台配置，这是纯人肉失误位。

预防这五种姿势不需要五个方案，后面三节的本地三层防线 + AGENTS.md 红线 + 每月巡检，基本能一网打尽。先记住一句话：密钥泄露从来不是"会不会"，而是"第几种姿势先来"。

如果你想看看"AI 主动偷密钥"能有多离谱，可以读读我们之前报道过的反面教材：《一条加密网页，28 秒掏空 .env.prod：Copilot CLI 被"加密指令注入"攻破》——攻击者用加密网页注入指令，让 AI 编程工具自己把本地密钥读出来发走。防泄露和防注入是同一枚硬币的两面，注入防御的完整方法可以看《Prompt 注入防御指南》。

二、本地开发：三层防线，先把自己家门锁好

本地是密钥待得最久的地方，也是 AI 读写最频繁的地方。三层防线按顺序建：

第一层：.env 分层，让"该提交"和"不该提交"物理隔离。规则只有三条：.env.example 提交仓库，里面全是假值加注释，告诉后来者（包括三个月后的你和 AI）每个变量去哪申请；.env.local 放真实值，永不提交；有多少套环境就加多少个 .env.*.local，但真实值文件一律进 .gitignore。直接抄：

# .env.example —— 提交到 git，值全是占位
# 复制为 .env.local 后填入真实值

# Stripe：在 dashboard.stripe.com/apikeys 申请 Restricted Key（见第五节）
STRIPE_SECRET_KEY=sk_test_xxx
STRIPE_WEBHOOK_SECRET=whsec_xxx

# Supabase：项目设置 → API
# anon key 可进前端；service_role 绝不进前端、绝不提交
SUPABASE_URL=https://xxx.supabase.co
SUPABASE_ANON_KEY=eyJxxx
SUPABASE_SERVICE_ROLE_KEY=eyJxxx

# OpenAI：platform.openai.com/api-keys，建议按项目建独立 key
OPENAI_API_KEY=sk-xxx

# .gitignore —— 凭据相关，一律不提交
.env
.env.local
.env.*.local
*.pem
*.key
id_rsa*

注意一个 AI 时代特有的坑：你要明确告诉 AI"真实值只写 .env.local，示例值只写 .env.example"，否则它会在 .env.example 里填上它"猜"出来的真 key——别笑，这事发生过。把这条写进第四节的 AGENTS.md 红线。

第二层：预提交钩子，最后一道机械门。人会忘，AI 会犯浑，但钩子不会。装 gitleaks（或 git-secrets，二选一，别两个都装），commit 前自动扫描暂存区里的密钥指纹，扫到就拦下：

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.0
    hooks:
      - id: gitleaks
# 安装：pip install pre-commit && pre-commit install
# 此后每次 git commit 前自动扫描，命中密钥直接拦截

丑话说在前面：钩子拦的是"已写进暂存区"的密钥，拦不住"已经 push"的。所以钩子必须和第一层配合——分层做对了，钩子一年也响不了一次；分层没做对，钩子就是你最后的救命绳。顺带一提，GitHub 现在已经换上专用小模型做密钥检测（不再只靠正则），我们在《密钥不再靠正则了：GitHub 换上专用小模型》里报道过——平台侧的网越织越密，但平台告警是事后诸葛亮，钩子才是事前拦截，两个都要。

第三层：密码管理器，一人版工作流。真实值只活在两个地方：密码管理器（1Password / Bitwarden）和各环境的 .env.local。换电脑时 10 分钟恢复，不用翻聊天记录找 key。1Password 用户可以用 CLI 直接注入，连 .env.local 都不落真实值：

# .env.tpl 里写 op:// 引用而非真实值，git 可提交
# STRIPE_SECRET_KEY=op://vibe-project/stripe/secret
op run --env-file=".env.tpl" -- npm run dev

另外，生成密钥别让 AI"随便编一个"。AI 给你的"随机字符串"熵不够，还可能跟它训练数据里的某个真 key 撞车（概率极低但恶心）。用密码管理器或系统工具生成：openssl rand -hex 32，一步到位。

三、生产环境：先用平台环境变量，别急着上 Vault

本地防线建好，密钥还得有个"生产住的地方"。一人团队在这里最容易犯的错不是"太松"，而是"太重"——项目刚上线就去折腾 HashiCorp Vault 自托管，结果 Vault 本身的备份、高可用、解封密钥成了新的运维负担。记住开头的判断：一个项目、两三套环境，直接用部署平台的环境变量；项目超过两个或环境超过三套，上 Doppler 免费档；只有合规明确要求，才考虑 Vault。

平台环境变量（Vercel / Cloudflare / Render / Fly.io）的正确姿势是"按环境隔离 + 最小可见"：Production、Preview、Development 三套各配各的 key，secret 类变量一律关掉"暴露给浏览器"的开关。Vercel 里尤其注意两点：一是 Preview 环境默认对所有人可访问，别把 Production 的 key 填进 Preview；二是 fork 来的外部 PR 触发的构建，默认不注入环境变量——别为了"让 CI 跑通"手动打开这个开关，那等于把密钥发给全世界。

什么时候平台变量不够用了？信号很明确：你在三个项目的控制台之间来回复制粘贴 key，或者改一个 Stripe webhook secret 要登五个后台。这时候上 Doppler（或 Infisical，开源可自托管）：一个地方管所有项目、所有环境，改一次全同步，还带版本历史和访问审计。云厂商的 Secrets Manager（AWS / GCP）功能最全，但按调用次数计费，一个人用属于"大炮打蚊子"，除非你的后端已经重度长在某家云上。

一句话决策表：1 个项目 → 平台环境变量；2–5 个项目 → Doppler 免费档；5 个以上或有合规审计要求 → 再谈 Vault / 云厂商 Secrets Manager。凭据管理的 KPI 只有"没泄露"，架构评审没人给你打分。

四、给 AI 立规矩：AGENTS.md 里写死三条红线

技术防线只能防"人犯错"，防不住"AI 主动犯错"。AI 不理解"这串字符很值钱"，它只看到"把这段配置填上就能跑通"。所以必须在 AGENTS.md 里用 AI 能理解的死命令，把红线钉死。下面三条直接抄：

## 密钥红线（违反直接停手并上报）
1. 只读 .env.example，绝不读取、输出、复述任何真实密钥。
   真实值只存在于 .env.local 和部署平台，AI 无权查看。
2. 密钥只进服务端环境变量。绝不写入前端代码、注释、文档、
   commit message；绝不使用 NEXT_PUBLIC_ 前缀存放任何 secret。
3. 需要示例值时只写占位符（如 sk_test_xxx），绝不"编造"
   看似真实的密钥，也绝不把用户粘贴的真实 key 回写进仓库。

再配一张"双不进"清单，贴在仓库 README 或 onboarding 文档里，三个月后的你和新来的 AI 都看得见：

永远不进仓库：.env.local、.env.*.local、*.pem、*.key、SSH 私钥、云厂商的 service account JSON、Supabase service_role key、任何带 live 的生产密钥。永远不进 prompt：真实 key、用户的 access token、webhook 签名 secret、数据库连接串（含密码的那版）。需要 AI 帮你 debug 鉴权问题时，把 key 替换成 sk_live_xxx（已打码） 再贴——AI 不需要真值也能看懂 401 的逻辑。

最后，code review 时加一道机械检查：让 CI 跑 gitleaks 扫描整个 diff（不只是暂存区），AI 写的每一行都在网里。红线写进文档不算数，红线进 CI 才算数。

五、第三方 key 的最小权限：泄露了也不致命

防泄露是减少"泄露概率"，最小权限是降低"泄露伤害"。假设 key 已经泄露，最小权限决定你是"换一把 key"还是"连夜跑路"。三个最常见的第三方，按伤害排序处理：

Stripe：永远用 Restricted Key。Stripe 后台可以创建"受限密钥"，精确到"只能创建 PaymentIntent、不能退款、不能看客户列表"。给 vibe 项目的规则：生产 key 只勾选当前功能真正需要的权限，多一个都不给；测试和生产用两套 key；每个项目独立一把 key，别一把 key 跑三个 side project——吊销时你会感谢自己。

Supabase：anon 和 service_role 是两种生物。anon key 设计上就是可以进前端的（配合 Row Level Security）；service_role key 绕过所有 RLS，等于数据库 root，绝不进前端、绝不提交、只活在服务端环境变量里。AI 最爱干的事就是"为了省事"在前端直接用 service_role 调数据——看到这种代码，review 直接打回，不管它跑得多顺。

通用规则：按项目、按环境独立发 key，能设过期就设过期。OpenAI / Anthropic 的 key 都支持按项目创建；能设 IP 白名单的设上（服务器固定 IP 的话）。每季度做一次 revoke 演练：挑一把非核心的 key 吊销掉，看有没有东西挂——演练时发现的断裂，比真泄露时发现的便宜一百倍。

六、泄露应急 SOP：30 分钟止血清单

真泄露的那天，你不会有时间思考，所以清单现在就要写好。顺序不能乱——先止血（revoke），再换血（轮换），最后验尸（审计）。删文件、改 .gitignore 这些"体面动作"排在最后，因为它们不止血。

0–5 分钟：revoke。登录对应平台，把泄露的 key 吊销/删除。Stripe、OpenAI、Supabase 都支持一键 revoke，先让旧 key 变成废铁，攻击者手里的就是一串乱码。这一步不需要"确认"，怀疑即行动。

5–15 分钟：轮换。生成新 key，更新所有用到的地方：本地 .env.local、各平台环境变量、Doppler。注意 webhook secret 这类"双向"的：Stripe 的 webhook secret 换了，要去 Stripe 后台重新生成并同步，别只换一边导致回调全挂。

15–30 分钟：审计。三件事：① 查 git 历史——如果 key 进过公开仓库，用 BFG Repo-Cleaner 清历史或干脆删库重建（删文件不够，历史里还在）；② 查调用日志——Stripe / OpenAI 后台都有 API 调用记录，看泄露窗口期内有没有异常调用、异常 IP；③ 查下游——key 是不是还躺在 Sentry 日志、CI 构建日志、AI 聊天记录里，躺一处清一处。

30 分钟后：复盘。写清楚三件事：怎么漏的（五种姿势里的哪一种）、哪道防线没起作用、下次怎么拦。涉及用户数据的，按你所在地区的法规决定是否发公告——瞒报的代价永远大于早报。这份 SOP 打印出来（电子版也行）存在你找得到的地方，真出事时你会手抖，清单不会。

七、每月 5 分钟巡检：别让防线慢慢烂掉

所有防线都会随时间腐烂：新加的环境变量忘了进 gitignore、新项目没配钩子、离职（划掉，你是一个人）——主要是"你三个月前随手配的东西"。定个每月 1 号的 5 分钟 ritual：

① 打开 GitHub → Settings → Code security，看 secret scanning 有没有新告警，有就按第六节 SOP 处理；② git log --all -p -- .env* 扫一眼历史里有没有新增的真实值；③ 检查各平台环境变量：有没有"本该过期"的测试 key 还活着、有没有 Preview 环境误用了 Production 的 key；④ 看一眼依赖和日志平台：Sentry / 日志服务里搜 sk-、eyJ 这类前缀，确认没有密钥躺在里面；⑤ 翻一下最近一个月的 AI 对话记录，确认没人（包括你自己）把真 key 贴给 AI debug。

五分钟，换的是"泄露了能第一时间知道"。密钥管理这件事，做到极致就是三句话：生成时用真随机，平时让 AI 碰不到，出事时 30 分钟止血。剩下的，都是这三句话的注脚。现在就去做第一件事：检查你的 .gitignore 里有没有 .env*.local，没有的话，关掉这篇文章先去补上。