别让 API Key 跟着 Agent 到处跑：用 Weir 验证凭据是否泄漏
AI Agent 的凭据风险并不只发生在代码仓库里。模型调用、工具执行、遥测日志和错误输出都可能把密钥带到不该去的地方。传统 secret scanner 擅长识别“看起来像密钥”的字符串，却很难回答另一个更具体的问题：某个真实凭据值是否真的进入了模型上下文、日志或外部请求？Weir 是一个 Apache-2.0 许可的 Python 工具，采用两种不同方式处理这个问题：对自建 Agent 用假凭据做 canary 测试；对 Claude Code 会话则统计已登记真实凭据的流转情况。
与其猜测，不如放置不会生效的假凭据
Weir 的测试路径不需要把真实密钥交给测试框架。weir-run 会在预先指定的位置放置唯一的假值，执行 Agent 自己的流程，再由 weir canary judge 在采集到的输出中查找这些精确值。命中就说明值确实到达了相应位置，而不是仅仅因为字符串长得像 API Key 就触发规则。
快速体验可安装扫描器并运行内置样例：
pip install weir-scan weir canary judge --sample
项目 README 说明，样例会展示泄漏判定；检测到 leak 时命令以退出码 1 结束。因此在 CI 中不能把所有非零退出码都当成“测试基础设施坏了”，应读取工具给出的 verdict。完整的 Agent 流程还需安装 weir-run，并编写配置描述凭据放置点和要执行的 flow：
pip install weir-scan weir-run weir-run run --config canary.toml
配置中的 placement 可以声明环境变量位置、密钥形状以及该凭据允许到达的 provider。flow 则指定具体命令，让测试运行应用自己的路径，而非只测试一个脱离真实工作流的玩具函数。项目还提供 GitHub Action 示例，可将检查接入 Pull Request；配置细节和 Action 输入应以各自 README 为准。
判定并非简单的“没搜到就算安全”。如果配置标记为 required 的路径没有被实际执行，结果会是 incomplete，而不是 clean。退出码分别区分 clean、leak、输入不可用和 incomplete，CI 应保留这种差异：缺少覆盖不是通过，泄漏也不等同于运行错误。
面向 Claude Code：看凭据是否进入上下文
另一条路径面向使用 Claude Code 的开发者。Weir 的 status line 展示已登记凭据有多少进入会话上下文、多少随工具调用发出；/weir 可进一步说明来源和流转。它不会显示密钥原文。可选的 redaction hook 会在模型读取工具结果前，将匹配到的已登记完整值替换为标记文本。
安装方式之一是：
uv tool install weir-scan weir statusline setup
设置过程会先展示改动，只有用户明确确认才应用；weir statusline undo 用于撤销。当前 README 标明适用于 Linux 和 macOS。不要把这个功能误解成能撤回已经执行的命令：钩子只改变模型随后读到的工具结果，不能逆转先前发生的外部副作用，也不能捕获用户直接粘贴到聊天里的密钥。
适用边界：精确值测试，不是万能防泄漏
Weir 的强项是验证已知凭据的精确值是否流出，不是发现所有可能的敏感信息。它不能识别被哈希、拆分或截断的值；status line 只认识本地 inventory 中的完整值。redaction hook 也有明确失效边界：钩子无法完成时，原始输出可能继续传递，状态会提示可能未脱敏，而不是给出绿色安全信号。测试运行只覆盖实际执行过的路径，因此应把关键工具调用、错误分支和日志路径都纳入 flow。
项目描述在 Linux、允许非特权 user namespace 时可隔离 Agent 网络；其他环境不能默认拥有同样的网络隔离能力，报告也会指出隔离未启用。测试所用 fake model 支持 OpenAI-compatible 与 Anthropic Messages API。Weir 自身的扫描器不需要向外发送数据，测试环境也使用本地假模型；但团队仍应按自己的依赖与部署环境审核工具链。
这类工具适合补足而不是替代 gitleaks、TruffleHog 等静态扫描器。静态扫描回答“代码或文件中有没有疑似秘密”，canary 测试回答“运行时某个已知值有没有走到预期边界之外”。可以先把假密钥测试接入 CI，再用 status line 观察本地会话；若团队需要强保证，必须覆盖更多真实工作流，并将 incomplete 视为需要补测的信号。