AI Agent 能读到哪些密钥？用 Heldkeys 盘点本机与 CI 的凭据暴露面
把 API key 放进环境变量，并不代表它只会被你预期的程序使用。AI 编码 Agent 通常以当前用户身份执行命令；如果提示注入诱导它运行恶意操作，当前进程可访问的云 CLI 登录、Git 凭据、SSH key、MCP 配置等，都可能成为攻击面。传统 secret scanner 擅长找仓库里的密钥，却未必回答一个更直接的问题：此刻运行的 Agent 实际能接触什么？
Heldkeys 是一个 MIT 许可的 Rust 命令行工具，尝试回答这个问题。它盘点当前执行环境可触达的凭据，并提供针对 GitHub Actions/GitLab CI 中 Agent 工作流的检查。项目 README 强调它不把凭据值写入报告或发送到网络；但扫描器需要读取相应文件来分类，因此敏感数据仍会短暂进入本机进程内存。安全工具也应按自己的威胁模型审查，而不是只凭一句“不会泄露”就盲目信任。
先在 Agent 所处的身份下扫描
安装方式包括 Homebrew、安装脚本、预编译二进制和 Cargo。Linux/macOS 可按项目文档选择适合的渠道；使用远程脚本前应先检查脚本内容，并核对发布包校验和。安装后，在与 Agent 相同的 shell、用户和工作目录下运行：
heldkeys heldkeys --details
默认摘要用于快速判断暴露面；--details 展示具体发现的位置与类别。项目示例会报告凭据类型、生命周期和可能的访问能力，而不是打印完整密钥。可选的 --path 用于检查另一个项目目录，--home 可指定另一用户目录；但要注意，扫描结果只有在权限与运行身份接近真实 Agent 时才有意义。用 root 扫描普通用户环境，可能把 Agent 根本读不到的文件也算进去。
想把问题变成可执行门槛，可以让长效且可写的凭据触发非零退出码：
heldkeys --fail-on long-lived-write
也可以在沙箱入口运行 heldkeys preflight，在启动 Agent 前做检查。先阅读工具的规则说明及实际输出，再决定是否将它接入启动脚本；门槛过严会阻断开发，门槛过松又可能漏掉风险。项目还提供 .heldkeys.toml 和 baseline 机制，用于记录经人工审查接受的既有发现，让后续 CI 重点关注新增或恶化项。忽略规则应窄化到具体路径或位置，并在变更时复核，避免把“基线”变成永久免检名单。
CI 工作流也要看，而不只是本机文件
在 CI 中，风险不止是仓库里有没有泄漏的字符串：工作流触发条件、Agent 步骤能否获得写权限、是否继承额外 secrets、第三方 Action 是否固定版本，都会影响提示注入后的影响范围。Heldkeys 提供 ci 子命令分析 Agent 工作流，并能生成 Markdown、JSON 或 SARIF 报告；项目的 GitHub Action 可以把结果呈现在作业摘要或安全扫描界面。
基本思路是在 Agent 执行之前检查工作流，并让权限遵循最小化原则：不需要写仓库就不要授予 contents: write；对不可信的 PR 内容谨慎使用 secrets；第三方 Action 尽量固定到完整 commit SHA。Heldkeys 聚焦 AI Agent 相关的工作流风险，并非通用 GitHub Actions 安全审计器，README 也建议把通用工作流分析交给专门工具。可以将它与常规静态检查并用，而不是替代现有 CI 安全措施。
适用边界：盘点不是凭据治理的全部
发现可达凭据后，真正的修复通常是缩小权限和作用域：清理不再使用的登录，避免把长期令牌放在 Agent 默认继承的 shell 环境中，为自动化创建短期、只读或资源受限的凭据，并把高风险操作放在隔离环境中。Heldkeys 的价值是把“可能能读到”具体化，不能替你撤销令牌，也不能证明某个凭据是否已被滥用。
项目文档还列出边界：它只覆盖已实现的检查项，无法证明未知位置没有凭据；多数情况下也不会向凭据提供方查询真实权限。对于容器或 Kubernetes 目标的扫描涉及复制并运行检查程序，使用前应阅读相关文档，并确认目标平台、二进制架构及清理行为满足自身要求。若要检查 Git 历史、验证泄漏密钥是否有效，或分析更广泛的工作流问题，应另配专用工具。
一个稳妥的落地顺序是：先在开发机以 Agent 身份运行一次摘要扫描；逐项处理高风险长期凭据；再在沙箱入口启用 preflight；最后把 CI 工作流检查加入 Agent 作业。不要把“扫描通过”理解为“绝无秘密”，而是把它当成一次可重复的暴露面盘点。
相关链接