Vibe Coding 时，为什么最容易泄露 API Key 和密码
TL;DR
从前端打包、环境变量、日志和终端 Agent 权限出发，解释 AI 编程中的秘密泄露风险与最小安全防线。
AI 编程最容易把秘密藏进前端、日志、配置和聊天上下文。本文解释浏览器端密钥、环境变量、日志暴露和 Agent 权限的风险，并给出适合个人项目的最小安全检查清单。
Vibe Coding 里最危险的时刻，往往不是模型生成了一段明显错误的代码，而是它顺手把一个秘密写进了“临时方案”：API Key 放在前端常量里，数据库密码出现在示例配置中，或者调试日志把完整的访问令牌打印了出来。页面能跑起来的那一刻，也可能意味着凭据已经进入浏览器、仓库和构建产物。
为什么新手特别容易泄露秘密
第一，前端代码天然会发给用户。只要密钥出现在浏览器加载的 JavaScript、HTML 或网络请求里，用户就能通过开发者工具看到它。环境变量名称以 PUBLIC 或 NEXT_PUBLIC 开头，也通常意味着它会被打包到客户端，不能存放真正的秘密。
第二，AI 喜欢让示例“马上可运行”。当接口需要密钥时，模型可能建议把值直接填进配置文件，或者让开发者把 .env 复制进仓库。对演示来说很方便，对真实服务来说却是长期暴露。
第三，日志和错误信息常被忽视。一个失败请求可能把 Authorization 头、完整 URL 查询参数或第三方响应写进日志，而日志往往比源码有更多访问者、保留更久。
先分清什么是配置，什么是秘密
API 地址、超时时间和公开的项目标识可以是配置；私钥、数据库密码、签名密钥、OAuth 刷新令牌和生产服务令牌属于秘密。配置可以进入版本控制，秘密应该由运行环境注入，并限制读取它的服务和人员。
一个安全的基本结构是：浏览器调用你自己的后端，后端在服务器侧读取密钥，再调用第三方服务。这样密钥不会出现在客户端。后端还需要校验用户身份、限制请求频率、记录必要的审计信息，并为第三方响应设置超时。
给 AI 的任务应该带上安全边界
不要只说“接入某某 API”，可以明确写成：
密钥只能从服务器环境变量读取，不得写入源码、返回给浏览器或出现在日志；先生成接口设计和错误处理，再实现；所有外部请求设置超时，并说明本地测试需要怎样注入假凭据。
这类约束能减少模型走捷径的机会。完成后还要搜索仓库和构建产物，检查常见关键词、配置文件和调试输出。不要把完整的真实密钥粘贴到聊天上下文里，必要时使用已失效的占位值。
已经泄露了怎么办
第一步不是删除文件，而是立即撤销或轮换凭据。因为 Git 历史、构建缓存、日志和聊天记录可能仍然留有副本。第二步确认访问范围和使用记录，判断是否有异常调用。第三步清理仓库历史、补充扫描和保护规则，再重新发布使用新凭据的版本。
GitHub 的安全实践建议配合密钥扫描、分支保护和最小权限；如果 AI Agent 需要执行命令或访问网络，也应只给完成任务所需的权限。能写文件、能安装依赖、能读取环境变量的 Agent，其能力边界必须被当成生产安全边界对待。
一份适合个人项目的检查清单
- 浏览器端没有服务端密钥。
.env等本地秘密文件没有提交到仓库。- 日志不会输出令牌、密码和完整认证头。
- 生产凭据可以轮换，服务只拥有最小权限。
- 提交前和 CI 中都有秘密扫描。
- 任何“全权限运行”的 AI 操作都在隔离环境中进行。
AI 编程能把接入服务的时间压缩到几分钟，但秘密管理不能被压缩成一句“先跑起来”。把安全要求写进任务描述、代码检查和发布门槛，才是真正适合长期使用的 Vibe Coding。
