Agent 的密钥到底去了哪里？用 Weir 验证 AI 工作流中的凭据泄漏
AI Agent 的密钥风险不只在“有没有把 .env 提交到 Git”。密钥可能被工具读取后进入模型上下文，也可能出现在 trace、日志、控制台输出或发往其他服务的请求里。静态扫描能找出看起来像密钥的字符串，却很难回答一个更具体的问题：某个凭据是否真的沿着 Agent 的执行路径流出？
Weir 是一个 Apache-2.0 许可的 Python 工具，针对这个问题采用“植入可识别假凭据，再检查它流向何处”的办法。它的 GitHub README 将用途分成两条：在本地或 CI 中测试自己构建的 Agent；以及观察 Claude Code 会话中已登记凭据是否进入上下文或工具调用。它不是通用防泄漏保证，而是帮助团队验证特定流程的安全测试层。
用 canary 测试 Agent 自己的流程
测试模式由 weir-run 配合 weir-scan 使用。前者把唯一的假密钥放到模拟真实凭据的位置，运行 Agent 的流程；后者检查采集到的输出中是否出现这些精确值。README 给出的最小体验命令是：
pip install weir-scan weir canary judge --sample
要测试项目自身流程，README 展示了安装两个包并运行配置文件的方式：
pip install weir-scan weir-run weir-run run --config canary.toml
配置通过 [[placement]] 描述凭据放置点，通过 [[flow]] 描述要执行的流程。例如，将假值放在 env.OPENAI_API_KEY，并标注它允许流向 model。执行后，工具检查 span、日志、指标、控制台、模型输入和其他服务等出口；具体是否捕获到，取决于运行时采集和环境条件。
重要的是结果不只有“干净”或“泄漏”。如果配置要求覆盖的流程没有实际运行，测试会返回 incomplete，避免把没有测到误报成安全。README 列出的退出码是：0 表示 clean，1 表示 leak，2 表示输入不可用，3 表示 incomplete。CI 可以据此让泄漏或覆盖不足阻断合并；仓库还展示了 GitHub Action 的引用形式 IdoGol24/weir@，集成细节应以其 action README 为准。
观察真实密钥，但不展示密钥值
另一条能力面向 Claude Code：状态栏统计已登记凭据进入会话上下文或离开到工具调用的情况；/weir 提供来源和流转说明，但不会显示密钥原文。可选的 redaction hook 会在特定工具结果交给模型前，移除与清单中密钥完全匹配的值。README 明确指出它有边界：只覆盖指定工具、已登记完整值及其匹配形式；钩子失败时原始输出可能继续传递，并会标记为可能未脱敏。安装状态栏可使用：
uv tool install weir-scan weir statusline setup
设置流程会展示改动，并要求用户确认后才应用；weir statusline undo 可移除配置。文档称该状态栏支持 Linux 与 macOS，不应据此推断其他平台也受支持。
把结果当证据，而不是安全证明
Weir 的优势是验证“已知值是否经过已观测路径”，而不是根据模式猜测。它也有明确盲区：测试只覆盖实际运行的流程；对哈希、拆分或截断后的密钥无能为力；状态栏只知道清单里的凭据；附件、密钥变量名以及未触发的代码路径也不在其保证范围内。Linux 网络隔离还依赖非特权用户命名空间可用，其他环境可能无法隔离网络。
建议把它放进分层防护：先用假凭据跑关键 Agent 工作流，再将 incomplete 当作覆盖缺口处理；对状态栏和脱敏钩子做演练，确认失败时的提示会被团队看见；同时保留最小权限、密钥轮换、日志访问控制和人工审批。不要把 canary 测试的 clean 结果解释成“凭据绝不会泄漏”。
对于已经使用 Agent trace 的团队，README 还列出 weir scan 用于追踪敏感数据在 trace 中的传播，weir inventory 用于按名称列出 Agent 可访问凭据，weir audit 则可离线检查保存的会话。是否适配现有框架和遥测管线，最好先用小型测试项目验证，再纳入 CI。