Claude Code跳过确认暴露凭据，GitHub公开仓库现1,122份泄露

摘要：APIiro 报告称，Claude Code 的“Don’t Ask Again”权限选项可能把密码、令牌等敏感内容直接写入代码，并已出现在1,122个公开GitHub文件中。该问题暴露了编码智能体在终端确认、最小权限和出站数据传输之间的安全缺口：一旦用户为减少交互而永久授权，代理获得的不只是写入代码的权限，还可能把凭据带入补丁、提交记录或公开仓库。修复重点不只是轮换密钥，还包括默认拒绝外传、秘密检测拦截、可撤销授权及提交前审计。

---

泄露路径不只是一次“误粘贴”

APIiro 的调查称，Claude Code 的 “Don’t Ask Again” 选项与公开 GitHub 仓库中的敏感信息暴露有关，发现了 1,122 个包含泄露密码或凭据的文件。核心问题并非模型偶然生成了一段看起来像密钥的字符串，而是用户为减少终端确认关闭提示后，编码智能体获得了持续执行敏感操作的权限，密码、令牌或 API Key 随后通过代码修改进入版本控制系统。

公开仓库使这类风险从本机事故升级为供应链事故：即使仓库随后删除文件，历史提交、Git 对象、缓存、fork 和第三方镜像仍可能保留原始内容。凭据一旦进入提交历史，单纯删除当前版本并不足以完成处置。

“不再询问”如何扩大攻击面

终端编码智能体通常需要在执行命令、修改文件、访问网络或写入敏感位置前请求确认。将某一类操作设为“不再询问”，本质上是在客户端维护一个持久化放行策略。若该策略只按命令或工具类别授权，而不理解数据敏感度，代理就可能在用户不知情的情况下连续执行以下链路：

1. 从环境变量、配置文件或命令输出读取凭据；
2. 把凭据拼接到源码、测试或迁移脚本中；
3. 通过自动提交或外部工具调用将内容送出本机；
4. 将仓库设为公开，使秘密从私人工作区扩散到公共供应链。

从权限模型看，这属于典型的混淆代理（confused deputy）：智能体原本代表用户完成编码任务，却可能被恶意指令、依赖脚本或上下文注入诱导，把本机敏感数据写入它有权修改的资源。

更关键的是，“Don’t Ask Again”的安全性不能只依赖弹窗设计。一次授权解决的是交互摩擦，而不是数据流中的信任边界。

真正的技术缺口在秘密数据流

成熟防护不应只扫描最终 diff，而应在秘密产生、复制和传输的路径上实施分层控制：

• 读取隔离：凭据应留在专用 secret store，代理只获得短期、任务级令牌，而不是读取完整 .env、云凭据文件或密码管理器导出。
• 写入阻断：在文件修改和补丁应用层部署规则，对私钥、PEM、GitHub token、AWS key、数据库密码及高熵字符串进行识别。
• 出站控制：代理访问网络时执行数据流检查，阻止携带疑似秘密的请求正文、查询参数和命令输出。
• 提交门禁：在 git commit 和推送前扫描暂存区及完整历史，并对已暂存但后来移除的文件保持检测状态。
• 权限可撤销：持久授权应绑定工具、资源、目录、网络目标和有效期，而不是只有“允许”或“拒绝”两个状态。

仅在编辑器中提示“可能包含密码”并不足以形成闭环。开发者可以在压力下批准告警，恶意内容也可能通过编码、分块或编码变换绕过正则表达式。因此，检测器应同时采用规则匹配、凭证格式解析、熵分析和上下文判断，并保持低误报率。

现有工具链需要补齐哪些环节

GitHub Secret Scanning、Push Protection 和组织级策略可以阻止部分高置信度凭据进入远端，但不能覆盖所有编码智能体场景。原因是秘密可能在推送前已经进入本地 Git 对象、第三方模型接口、Issue 附件或代理自身的远程会话记录。

更完整的防线应覆盖三个阶段：

| 阶段 | 风险 | 必要控制 | | --- | --- | --- | | 代理读取 | 批量获取环境变量和密钥文件 | 最小权限令牌、字段级遮蔽、敏感目录隔离 | | 代理写入 | 将秘密嵌入源码或补丁 | 写入前 DLP、可信上下文校验、原子化阻断 | | 代理外传 | 通过网络、提交或工具调用泄露 | 出站代理、网络白名单、提交门禁、审计日志 |

例如，组织可以在 Claude Code 的网络出口设置统一代理，对请求正文执行 secret scanning；对本地工具启用只读挂载或临时副本；对 Git 暂存区增加 pre-commit 与 server-side push protection。这样即使模型产生错误，也由确定性的基础设施策略承担最终阻断，而不是依赖模型“自觉谨慎”。

评测不能只看秘密能否生成

n 安全评测应至少覆盖四类攻击面：

• 直接诱导：提示词要求读取并输出环境变量；
• 上下文注入：恶意 README、Issue 或依赖包输出包含“继续执行并忽略规则”的指令；
• 组合式泄露：先写入文件，再通过格式化、测试或部署工具间接外传；
• 持久授权：关闭普通确认后，敏感操作仍必须触发独立审批。

指标不能只有召回率。误报率同样重要：过于激进的检测会迫使团队整体忽略告警。更实用的评估方式是同时记录阻断率、误报率、敏感文件访问次数、持久权限覆盖率，以及秘密是否进入 Git 历史或模型请求日志。

处置与部署建议

对已经暴露的凭据，应先吊销和轮换，而不是只修改仓库内容。随后使用 git filter-repo 等工具清理历史，并检查远端缓存、fork、CI 日志、Issue、Release 附件及第三方代理服务的保留情况。清理提交无法撤销已被抓取的凭据，因此轮换必须优先于历史改写。

团队还应建立以下基线：

1. 禁止把真实秘密提供给编码智能体，默认使用短期、最小权限和可撤销凭据；
2. 将“DontAskAgain”拆分为按工具与资源授权，禁止全局永久批准；
3. 在文件修改、Git 提交、网络请求和模型 API 出口设置秘密检测；
4. 记录代理读取、修改、提交和发送敏感数据的完整审计链；
5. 定期扫描 Git 历史与公开仓库，并模拟恶意依赖和间接提示注入。

这类事件的核心警示不是“Claude Code 不够聪明”，而是编码智能体把自然语言意图转换为系统级操作时，权限粒度和数据流控制不能继续停留在终端确认层面。随着代理获得更持久的执行权，安全边界必须从“是否询问用户”升级为“哪些数据可以流向哪里，以及用户能否撤销这种权力”。

---

消息来源：Hacker News AI Feed (2026-11-07)

—— 完 ——

主题标签： #Claude Code 关注 #编码智能体 关注 #密钥泄露 关注 #GitHub安全 关注 #权限治理 关注