简短结论：安全机构 Apiiro 在 1,994 个公开 GitHub 仓库中发现了 2,539 个由编程 Agent 配置文件泄露的真实密钥，多数保存在逐字记录已批准命令的本地配置中。工程团队的防范核心是把 6 道防线逐一落实到人：管控共享配置、双人审查永久放行规则、用环境变量引用传参、写入仓库级忽略规则、升级命令内联密码扫描，并提前指定密钥轮换责任人。
为什么编程 Agent 正在频繁泄露密钥
编程 Agent 泄露密钥看似是个人疏忽，实则是团队流程缺失：开发者顺手点了一次批准、配置文件被一并提交、密钥就此公开，关键环节无人把守。
2026 年 11 月，Apiiro 发布的公开 GitHub 仓库调查报告统计了 104,185 份 Claude Code 项目级永久放行配置文件 .claude/settings.local.json，发现其中 1,122 份含有有效密钥；连同 Git 历史、共享配置与 Agent 对话记录，共计在 1,994 个仓库中检出 2,539 个独立密钥，波及 63 家企业组织，Hacker News 相关讨论热度超过 590 分。
单个 Agent 的权限边界设计可结合《编程 Agent 的权限：它该碰什么，不该碰什么》一起阅读；本文聚焦工程团队层面的职责分工与可复现排查步骤。
一条批准执行的命令是如何变成公开密钥的
永久放行规则（Standing Approval）允许 Agent 下次运行同类命令时不再弹窗询问。据 Claude Code 官方设置文档，当你在 Bash 权限提示中选择“Yes, and don’t ask again”时，系统会把完整命令字符串作为 allow 规则写入仓库的 .claude/settings.local.json。一旦当时执行的是 PGPASSWORD=<真实密码> psql -h db.example.com，明文密码就会原样落盘。
官方文档指出，Claude Code 首次生成该文件时会把 **/.claude/settings.local.json 加入本机全局 Git 忽略列表；其负责人 Boris Cherny 也在 Hacker News 表示团队正开发含基础密钥扫描的修复原型。但 Apiiro 指出，全局忽略仅作用于单机，无法覆盖先运行 Agent 后执行 git init 的目录、其他机器的新克隆副本，或已被提交进版本库的文件。
报告中的三组数据直接决定了团队护栏的设计：
- Agent 会自己提交该文件：溯源成功的 1,105 个仓库中，539 个由 Claude 共同署名（co-authored）提交。
- 常规扫描器漏掉内联密码：gitleaks 与 TruffleHog 合计漏掉了 1,122 份含密钥文件中的 215 份。
- 仅删文件无法消除历史记录：734 个密钥已不在最新分支，仍保留在 Git 历史提交中。
同类风险也出现在 Agent 聊天记录、记忆文件与交接笔记中：只要工具持久化命令历史，敲进命令行的密钥就会留存。
面向工程团队的 6 项安全护栏清单
无人认领的护栏注定失效，以下 6 项防线均需指定唯一责任人兜底。
1. 由谁审批团队共享的 Agent 权限？
技术负责人（Tech Lead）负责管控提交到仓库的共享配置 .claude/settings.json。Apiiro 在这类主动共享的配置中也发现了 298 个真实密钥。编写权限规则时，应使用模式匹配（Pattern）而非完整字面量命令，避免把具体参数写进文件：
{
"permissions": {
"allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],
"deny": ["Read(./.env)", "Read(./.env.*)"]
}
}
仅对任何参数下均无风险的操作放行模式规则；涉及生产环境或敏感凭证的命令一律保留按次弹窗确认。
2. 像审查业务代码一样审查永久放行规则
将 Agent 配置目录纳入仓库 CODEOWNERS，使任何触及这些目录的 Pull Request 自动触发双人审查：
/.claude/ @your-org/platform
/.cursor/ @your-org/platform
/.gemini/ @your-org/platform
这能直接拦截 Agent 自动提交的放行配置。关于在研发流程关键节点设置人工拦截的做法，可以参考我们关于编程 Agent 审批门禁的专题文章《编程 Agent 的审批关卡：在合并前把自动执行停下来》。
3. 密钥一律通过环境变量引用传递
每位开发者需确保不在命令行直接输入明文密钥。改用环境变量引用后，放行规则只会记录变量名而非真实密码：
# 错误示范：密码明文会被直接写进放行规则文件
PGPASSWORD=hunter2-prod psql -h db.example.com -U app
# 正确示范：只记录变量引用，真实密码永远不会进入规则文件
psql "$DATABASE_URL" -c 'select 1'
运行前通过密钥管理器或禁止 Agent 读取的本地 .env 注入 DATABASE_URL；curl 的 Bearer 令牌与 sshpass -p 命令同理。
4. 在仓库级 .gitignore 中忽略本地配置，而非仅靠单机全局配置
仓库管理员（Repo Owner）应将本地 Agent 配置写入项目 .gitignore 及组织新建仓库模板，让忽略规则随克隆自动生效：
echo '.claude/settings.local.json' >> .gitignore
git rm --cached .claude/settings.local.json 2>/dev/null
git commit -m "Stop tracking local agent settings"
取消追踪只能阻断后续误提交，无法清除 Git 历史、Fork 与本地克隆副本中的旧记录，已暴露凭证仍需配合第 6 项轮换。
5. 升级扫描规则以捕获命令内联密码
平台工程团队（Platform Team）负责在 pre-commit 与 CI 中配置密钥扫描。默认规则擅长识别带固定前缀的高熵 API 密钥，却容易漏掉 PGPASSWORD= 后的普通密码，需补充自定义 gitleaks 规则：
[extend]
useDefault = true
[[rules]]
id = "password-in-command"
description = "Password passed inline to a database or SSH client"
regex = '''(?:PGPASSWORD=|MYSQL_PWD=|sshpass\s+-p\s*)['"]?([^\s'"]{6,})'''
secretGroup = 1
[[rules]]
id = "bearer-in-command"
description = "Bearer token inside a curl command"
regex = '''(?i)authorization:\s*bearer\s+([A-Za-z0-9._\-]{20,})'''
secretGroup = 1
先用 gitleaks git . 扫描全量提交历史，再接入每次推送检查，并开启 GitHub Secret Scanning 与推送保护（Push Protection）。排查时优先处置同时暴露了公网主机地址的凭证。
6. 在泄露发生前指定密钥轮换责任人
团队需提前指定值班责任人（On-call Owner），严格执行“先轮换吊销、后清理文件”。排查组织内待轮换凭证时，可同时检索远端仓库与提交历史：
gh search code --owner your-org --filename settings.local.json
git log --all --oneline -- .claude/settings.local.json .claude/settings.json
同时需清理开发机本地的放行文件：即便未推送至 GitHub，明文 JSON 仍可能被窃取凭证的恶意 npm 包从本地磁盘扫走。
HiFox 在这套安全体系中的定位
HiFox 是编程 Agent 外层的团队协作与管控层，不替代 Claude Code、Codex 等底层运行时，也不替代代码库密钥扫描器。它改变的是凭证配置方式与团队对执行过程的可见性。
在 HiFox 中，你可以在 Agent 设置里配置环境变量和启动参数（环境变量值默认隐藏），或通过连接器将第三方工具凭证授权给该 Agent，凭证只作用于授权它的 Agent 运行过程，不会出现在指令、任务描述或评论里。当任务派发到你自己的电脑（Computer）并由运行在电脑上的本地服务启动 Runtime 时，派单无需在命令行参数里填写明文密码。
同时，每次执行的运行记录都会保留状态、来源与进展，结果统一写回任务供团队验收。一旦某个 Agent 的提交触碰了 .claude/ 目录，变更会直接呈现在共享任务上，便于团队基于任务级证据链审查 AI 生成代码。
总结
Apiiro 的实测数据表明，编程 Agent 泄露密钥并非单次误操作所致，而是共享配置、永久放行规则、变量传参、仓库级忽略、内联密码扫描与应急轮换六个环节缺少明确责任人。建议本周内将这 6 项逐一指派到人，并优先完成全量 Git 历史排查。
如果团队正并行使用多个编程 Agent，现在就开始使用 HiFox，从接入第一台电脑和第一个 Agent 起步，让每次任务派发与代码变更都有迹可循。
常见问题
这是 Claude Code 的软件漏洞吗？
这是永久放行规则以完整命令落盘带来的设计隐患。尽管 Claude Code 会写入单机全局忽略列表，且官方正开发密钥扫描修复方案，但跨机克隆、历史提交与共享配置等团队协同盲区仍需工程护栏兜底。
团队应该把哪些 Agent 文件视作含敏感信息的受控文件？
不论在个人开发机还是代码库中，都应像管控 .env 一样管控 .claude/、.cursor/、.gemini/、.specstory/ 目录及各类 Agent 记忆文件与交接笔记。
我们应该彻底停用“不再询问”（don’t ask again）功能吗？
不必停用。只要改用 Bash(npm run test:*) 这类模式规则代替完整字面量命令，并通过环境变量引用传递密钥，规则文件里就不会出现真实凭证。
HiFox
