先数清钥匙再谈防护：Show HN 上的 Heldkeys 盘点你的 agent 手里攥着多少凭证

先问一个能让你后背发凉的问题：如果现在这台电脑上跑着的 coding agent 被一句注入提示词哄着执行了一条 shell 命令，它能用你的身份拿到多少东西？不是它会不会写坏代码，而是它能以你的名义花多少钱、删多少资源、推多少代码。

10 月 16 日登上 Show HN 的 Heldkeys，就是冲着这个问题来的。它是一个 Rust 写的只读命令行工具，回答的不是“你的代码里有没有泄露密钥”，而是“此刻、以你这个用户的身份运行的 agent，手边到底攥着多少凭证”。仓库创建于 10 月 15 日，MIT 开源。据作者自述，灵感来自他自己的经历：每天在笔记本上跑 coding agent，有一天突然想问一句——如果提示词注入让 agent 失控，它能动用些什么？市面上的 secret scanner 回答不了这个问题，因为它们扫的是“提交进仓库的秘密”，而他想知道的是“此刻一个以我身份运行的进程能立刻用上的秘密”。

它扫的不是仓库，是“agent 的视野”

这个区分是 Heldkeys 全部设计的起点，也是它最值得被讨论的地方。传统的密钥扫描关心的是静态产物：有没有把 key 提交进 git、有没有写进配置文件并推送出去。Heldkeys 关心的是运行态的继承关系：agent 从你这里继承了什么环境、读到了哪些登录态、踩进了哪些挂载点。换句话说，前者查的是“你有没有把钥匙弄丢”，后者查的是“你把多少钥匙顺手放在了 agent 伸手就能够到的桌子上”。

据仓库 README，本地扫描覆盖的面相当广：环境变量里的 token 和 API key；AWS、gcloud、Azure 的 CLI 登录态和 kubeconfig；Codex、Claude Code、Gemini CLI、Copilot、Hugging Face 等 AI 工具的登录信息；Vault、Terraform、Vercel、Netlify、Fly.io、Supabase、Wrangler、Stripe、Doppler、Railway、Kaggle 等开发者平台 CLI 留在磁盘上的登录态；.npmrc、.pypirc、Cargo credentials、Docker registry 登录；.netrc、git credential helper、GitHub CLI 登录；项目里的 .env 文件——包括被 gitignore 排除的那些，因为 agent 照样能读到它们；甚至 VS Code Local History 扩展在 .history/ 里留下的 .env 旧副本；还有 MCP 服务器配置里以环境变量、参数、URL 或请求头形式塞进去的 token。README 还特别提到，macOS 上 Claude Code 的登录存在钥匙串里，而 Heldkeys 从不读取钥匙串——这是一个诚实的能力边界，后面还会说到。

输出设计也值得单独说一句。它默认只给一份“几秒钟能读完”的摘要：多少凭证可达、其中多少是长期有效且有写权限的，按“先修这些”排序，附带“同一个秘密出现在几个地方”和“下一步先改什么”。README 里给出的演示扫描结果是 13 个凭证可达、7 个长期有效且有写权限。需要强调的是，那是作者用假 fixture 搭出来的演示，不是任何真实用户的扫描结果；但它恰好说明了这个工具想让你看到的画面：一台“正常开发机”上，agent 的权限清单可能比你想象的长得多。

最有价值的一半在 CI 里

如果 Heldkeys 只有本地扫描，它也就是一个做得比较全的清单工具。真正让它在 10 月这个时间点显得应景的，是 heldkeys ci 对 GitHub Actions 工作流的分析。

README 把 CI 场景说得很直白：一个在 issue_comment 触发器上跑 agent、又给了 contents: write 权限的工作流，等于让任何能评论的人都能指挥一个可以 push 的 agent；一个先 checkout 了 PR head、再启动 agent 的工作流，等于让 fork 的作者决定 agent 会加载哪些 MCP 服务器和指令文件——README 称这正是 CVE-2026-47751 背后的模式。这个 CVE 编号是 README 的说法，本文没有独立核实其细节，读者应当把它当作作者给出的线索而非定论。

据 README，heldkeys ci 做两件事。第一，在 CI 作业内部做运行时盘点：环境里的秘密、GITHUB_TOKEN、OIDC 相关变量、Actions 运行时 token、checkout 留在 .git/config 里的 token、远程 URL 里的 token、GitLab 的 CI_JOB_TOKEN，以及 runner 是不是自托管的——也就是“这个作业本身能看见什么”。第二，静态分析 .github/workflows/*.yml，找出其中的 agent 步骤（覆盖 Claude Code Action、Codex Action、Gemini CLI、Copilot coding agent 等官方动作，以及 run 步骤里直接调用的 claude、codex、gemini、copilot、aider、opencode、cursor-agent 等 CLI），再套用一套确定性规则：agent 是不是挂在外人能触发的触发器上、是不是在 PR head 的 checkout 之后运行、作业权限是不是 write-all 或者干脆没写 permissions、是不是把超出模型 key 的秘密塞给了 agent、动作有没有钉死到 commit SHA、是不是允许 agent 在持有写 token 的情况下跑任意 shell。规则还会跟进本地可复用工作流的调用链，因为被调工作流实际运行时继承的是调用方的触发器、权限和秘密——只看单个文件会漏掉这一层。

这个设计里有一个值得肯定的克制：它明确说自己只看“agent 能拿到什么”，工作流里其他问题（比如模板注入、缓存投毒、未钉死的第三方动作）请交给 zizmor 这类工具。工具知道自己不是什么，比工具宣称自己是什么更能建立信任。

“绝不打印秘密”不是口号，是测试

一个盘点凭证的工具，自身首先不能成为新的泄露源。Heldkeys 在这件事上的做法比口头承诺硬得多：它从不打印秘密原文，只对格式前缀公开的 token 显示指纹（比如首尾几个字符），未知形状的密码和 token 连指纹都不给；README 称有一项测试会把所有 fixture 秘密的每一段 10 字符切片拿去比对全部输出格式，一旦出现在 stdout、stderr 或输出文件里就失败。它不发遥测、不检查更新、不写崩溃报告；除了你用 --output 或 --write-baseline 明确指定的文件，它不在你的机器上写任何东西；扫描沙箱或 CI 作业时，它只做最小必要的外部接触——比如对 Docker socket 只连接不发送数据，对云元数据地址只做一次 300 毫秒超时的 TCP 连接且不发 payload，并且可以用环境变量关掉联网探测。

这些细节之所以重要，是因为这类工具的采用门槛从来不是功能多不多，而是“我敢不敢让它在装满钥匙的机器上跑”。一个会把秘密原样打到日志里的盘点工具，比没有工具更糟。Heldkeys 把“只读、无遥测、不打印”做成可验证的工程约束，而不是 README 里的一句保证，这是它设计上最成熟的部分。

作者自己的使用故事也给出了一个可参照的基线：他在自己机器上第一次跑 Heldkeys，找出了多年积累下来的老问题——明文的 git 凭证文件、shell profile 里 export 的 token、没有口令的 SSH 密钥——清理花了大约二十分钟。这个数字是作者自报的、未经独立验证的，但它传递的判断是对的：第一次盘点往往不是发现什么高深攻击面，而是清理掉你早已忘记的陈年登录态。

它不能保证什么，同样值得说清楚

先说三个局限，免得把它用错地方。第一，它是一份“可达性清单”，不是“入侵证据”：它告诉你 agent 理论上能拿到什么，不证明任何 agent 真的拿过、也不证明你的机器已经被入侵。把它当成体检报告，不要当成报警记录。

第二，它的视野等于“当前进程能看见的视野”。macOS 钥匙串里的登录态它明确不读；agent 通过其他渠道（比如浏览器会话、别的用户身份、云端托管的 agent 沙箱）拿到的凭证，也不在一次本地扫描的射程内。跑扫描的姿势有讲究：README 建议就在 agent 用的那个终端里跑，因为那才是 agent 实际继承的环境。换个干净环境跑出来的“0 发现”，除了自我安慰没有任何意义。

第三，一份干净的报告不等于安全。Heldkeys 能帮你发现“钥匙放错了地方”，但它管不了“你主动把钥匙交给了不该交的 agent”、也管不了模型本身被诱导去做坏事。把清单清干净之后，真正的安全工作才开始：给 agent 最小权限的 token、把写操作拆到不读不可信文本的独立作业里、把动作钉死到 commit SHA——这些恰恰是它 CI 规则里“下一步”建议的方向。

另外一个现实提醒：截至本文核实日，仓库 README 中的现版本还包括一个 heldkeys incident black-october 命令，用于对照 2026 年 10 月几起公开安全事件的指标并提示轮换。10 月确实是凭证安全的多事之月：本轮之前本站已经报道过 OpenCode Console 的 API key 泄露事件（10 月 17 日官方声明），而 Heldkeys 的 README 也提到了 LiteLLM、OVHcloud CLI 等事件的指标。这些事件各自的细节不在本文核实范围内，读者如果要用到 incident 命令，应当把它当作“对照公开指标的辅助检查”，而不是事件本身的权威信源。

给 vibe 开发者的三条实操建议

第一，把它放进“开工第一天”的清单里，而不是等出事再想起来。装好之后先在 agent 常用的终端跑一次，再用 --fail-on long-lived-write 把它变成一道门：只要还有长期有效且能写的凭证可达，就让检查失败。门槛要先定在“长期 + 可写”这个组合上，别一上来就追求零发现——后者会让你在第一天就把工具关掉。

第二，CI 里先扫工作流，再谈别的加固。把 heldkeys ci 加到 agent 工作流所在的仓库，重点看三类问题：触发器是不是外人能点火的、agent 是不是跑在 PR head 的 checkout 上、作业是不是给了超出需要的秘密。README 里给出的修复方向很具体：只给 agent 模型 key、把需要其他秘密的步骤拆到独立作业、用 OIDC 代替长期云密钥、把 agent 作业的权限收成只读、把动作钉死到 commit SHA。

第三，定期复扫，而不是一扫了之。凭证是会重新长出来的：新装一个 CLI 就多一个登录态，新接一个 MCP 服务器就多一处 token，新开一个项目就多一个 .env。把本地扫描和 CI 检查都变成例行动作，清单才有意义；否则你清理掉的二十年老问题，会在三个月后以新工具的名字重新出现。

把它放进工具箱的正确位置

要避免对 Heldkeys 的误读，最好的办法是把它和身边几类工具并排放在一起看。第一类是传统的 secret scanner：它们回答“仓库里有没有不该出现的东西”，强项是发现已经泄露的秘密、阻止新的秘密被提交，盲区是运行态——一个从来没进过仓库、却躺在环境变量和 CLI 登录态里的凭证，它们看不见。第二类是 zizmor 这类工作流静态分析工具：它们回答“工作流文件本身有没有危险写法”，覆盖面比 Heldkeys 的 CI 规则更广（模板注入、缓存投毒、未钉死的第三方动作都在射程内），但它们不盘点运行时的凭证——一个写得再干净的工作流，跑在装满长期密钥的 runner 上，照样危险。第三类是此前本站报道过的 quiz hook：它回答“人是否理解 agent 产出的代码”，管的是人的理解力。Heldkeys 的位置在它们之间偏下的一层：它不判断代码对不对、不判断工作流写法全不全，它只回答“此刻、这个环境里，失控的 agent 能摸到什么”。四类工具没有谁能替代谁，拼在一起才是一条比较完整的防线；单独把任何一类吹成“agent 安全解决方案”，都是在偷换概念。

CI 的六条规则也值得逐条拆开看，因为它们其实是一份“agent 工作流最容易踩的坑”的清单。第一条是触发器：外人能点火的触发器（pull_request_target、issue_comment、issues、discussion 等）上挂 agent 步骤，且步骤持有秘密或写 token，这是最危险的组合——触发门槛低、权限又高。第二条是 checkout 顺序：先 checkout PR head 再启动 agent，等于把 fork 里自带的指令文件和 MCP 配置直接喂给 agent，这条在 README 里被标为 High，没有商量余地。第三条是权限声明：作业写了 write-all，或者干脆没写 permissions 块——后者的问题在于，默认权限是什么取决于平台配置，等于把安全边界交给了“默认设置”这个最不可靠的东西。第四条是秘密范围：把模型 key 之外的秘密塞给 agent，特别是一句 secrets: inherit 把整包秘密倒进可复用工作流，等于是把“最小权限”四个字反着写。第五条是钉死版本：动作只钉到 tag 或分支而不是 commit SHA，意味着你今天审计过的代码，明天可能就不是同一份。第六条是 shell 自由度：允许 agent 跑任意 shell（比如 Bash(*) 或 --dangerously-skip-permissions 这类放行标志），同时手里还握着写 token——这是把“能执行”和“能破坏”同时交出去。把这六条当成检查单来读，比把 Heldkeys 当成“又一个扫描器”要有用得多：即使你不用这个工具，照着这六条去审一遍自己的工作流，也已经值回时间。

还有一个细节值得团队负责人注意：Heldkeys 对“忽略规则”的设计相当较真。接受已知风险要写进 .heldkeys.toml，必须带 rule id 和非空的 reason，还可以设过期时间；基线机制只放过“没有变糟”的发现，严重程度、权限范围、有效期三者任何一项变糟都会重新上报；更关键的是，在 PR 场景下，如果忽略文件本身是 PR 可以改的，报告里会到处标注这一点——因为 PR 作者完全可以给自己引入的风险写一张豁免条。README 甚至建议用 CODEOWNERS 保护这两个文件，或者让 CI 读默认分支上的副本。这个设计说明作者对“安全工具被绕过”的方式有过真实的想象：最常见的绕过不是黑客攻破工具，而是开发人员为了让流水线变绿，顺手把规则关掉。一个把“被绕过”本身也当成风险来设计的工具，比一个只会报 High/Medium 的工具更值得信任。

最后补充一个适用边界：README 明确说这是一个面向 Linux 和 macOS 的单二进制工具，没有提到 Windows 原生支持——Windows 用户大概率要走 WSL 路线，但这句话是本文的推断，不是 README 的原话，实际采用前请以仓库最新说明为准。另外，它是一个 10 月中旬才公开的新工具：规则库覆盖的 agent 动作和 CLI 清单会随着生态变化而过期，今天扫得全，不代表半年后还全。把它当作“持续盘点”而不是“一次性体检”，定期跟进上游更新，才是正确的用法。

第一次跑完之后，数字应该怎么读，也值得说一句。不要盯着总数焦虑：一个数字本身说明不了风险等级，真正要先看的是“长期有效 + 有写权限”这个组合——短期只读的凭证即使多几个，失控时的破坏力也有限；反过来，只要有一个长期可写的云密钥或代码托管 token 摆在 agent 伸手可及的地方，总数再小也不安全。README 的默认摘要正是按这个逻辑排序的：先列“先修这些”，再按来源分组计数，最后给出下一步。这也是本文建议把 --fail-on 门槛先定在 long-lived-write 上的原因：先把最危险的组合清零，再逐步收紧，而不是第一天就追求一张漂亮的零报告。

最后说一句判断。10 月的 agent 安全讨论里，有两种工具在同时出现：一种是帮你“看住 agent 产出的代码”，比如此前本站报道过的、要求开发者先证明自己读懂了 diff 才能 push 的 quiz hook；另一种是帮你“看住 agent 手里的钥匙”，Heldkeys 属于后者。前者管的是理解力，后者管的是 blast radius（失控时的影响半径）。在 agent 越来越能直接调用外部系统、而提示词注入至今没有银弹的现实下，先把影响半径数清楚，是一种成本最低、也最不容易被营销话术带偏的防御姿态。它不会让你的 agent 变安全，但它会让你在决定给 agent 什么权限之前，先看清自己到底给了什么。