GitGuardian 报告：AI 编码 Agent 凭据泄露怎么查？2026
这篇文章面向使用 AI 编码工具、负责 AppSec 或维护共享 CI 的团队，说明为什么仓库扫描不能代替开发者端点检查。内容按本地文件、Shell 历史、MCP 和 Runner 场景列出检查证据、处置顺序与复测条件。
本周建议：先选一台近期运行过 AI 编码 Agent 的开发设备，检查本地配置、会话日志、缓存、Shell 历史和 MCP 配置；若发现凭据，先按权限撤销或轮换，再追查残留副本。GitGuardian 报告称，其研究在公开 MCP 配置文件中发现了 24,008 个独特凭据；这是厂商对公开样本的分析，不代表所有 MCP 部署，也不能证明 AI 工具单独导致了泄露。报告原文
谁该看这篇：使用 Claude Code、Cursor 或 GitHub Copilot 的开发者，可据此排查会话和本地文件留下的线索。
AppSec 与安全负责人，可补上仓库扫描之外的端点检查和凭据回收流程。
平台工程师，可用这些场景核对 MCP 接入及共享 CI 执行环境。
最后更新于 2026 年 9 月 27 日；日期与研究范围核对自 GitGuardian 2026 年 9 月 25 日分析及其年度报告。
GitGuardian AI 编码 Agent 凭据泄露排查：先补上端点盲区
只检查代码仓库和 CI，无法确认开发者端点上没有凭据。仓库扫描通常只会发现进入其扫描范围的文件或提交；本地 Agent 配置、编辑器缓存、会话日志、Shell 历史和临时调试产物，可能一直留在设备上，根本没有提交。
GitGuardian 在 2026 年 9 月 25 日的文章中讨论了 AI 编码工具与端点凭据风险，并引用该公司年度研究数据。研究观察与风险分析来自厂商，不是独立审计，也不足以判定 Agent 是某次泄露的唯一原因。其报告中 Claude Code 辅助提交的凭据泄露率为 3.2%，全体公开提交基线为 1.5%；这个对比描述的是报告所分析的提交样本，不等于工具因果责任，更不能推算所有团队的泄露概率。GitGuardian 分析原文
排查时要分开看三种证据：已跟踪文件及提交历史、工作区内尚未跟踪的文件、端点上的配置与运行痕迹。提交前扫描只能作为其中一层；例如，GitHub 的文档也说明，部分成对凭据必须同时出现在同一文件并被推送，才会触发相应检测。没触发告警不代表本地设备干净。GitHub 关于密钥扫描范围的说明
开发设备上的配置、日志与临时产物
AI 编码 Agent 可能把 API 密钥留在哪些本地文件里？应从工具实际使用的用户目录与项目目录入手，而不是假定所有产品都采用相同路径。检查 Agent 和 IDE 配置、环境变量文件、项目指令文件、会话记录、缓存、调试日志、导出对话、临时脚本及终端输出。路径和留存行为会随工具、版本、登录方式和管理策略而变，先对照正在使用版本的官方说明。
以 Claude Code 为例，Anthropic 的文档说明本地会话记录保存在用户设备上，并受相应组织的数据留存设置影响；因此，清理远端项目或删除 Git 分支，并不能证明本机记录已一并清除。Anthropic 对本地会话留存的说明
逐个文件核对凭据来源、所有者、权限范围和最后使用情况。优先检查 Agent 可读取的配置与日志；对命令行调试输出，搜索凭据标识符或授权头名称即可，不要把疑似密钥复制到工单、聊天或在线扫描工具中。检查结果记录文件路径、时间和凭据类型即可，记录中不要保存密钥明文。
注意：“Agent 配置里出现凭据”说明需要核实其暴露范围，不等同于 Agent 已经调用该凭据，更不等同于发生了未授权操作。还需结合服务端审计记录、令牌使用时间和权限范围判断。
Shell 历史、未跟踪文件与 MCP 配置
Shell 历史可能留下直接输入的令牌、带认证信息的连接字符串，或可还原敏感信息的命令参数。临时文件、崩溃转储和调试输出也可能记录环境变量或接口响应。检查时分别标注文件是否被 Git 跟踪、是否出现在提交中、是否只存在于端点；三个位置的证据和清理方式不同。
为什么只扫 Git 仓库和 CI 可能漏掉开发者端点凭据？因为一次命令可能把敏感值写进本地历史或日志，却从未进入暂存区、提交或流水线输入。即便提交前拦截生效，也无法自动清理设备上既有的会话记录和缓存。扫描提交解决的是代码传递路径，不是整台设备的凭据盘点。
MCP 排查要同时看配置文件、连接器使用的凭据及其授权范围。确认凭据是静态写在配置中，还是通过授权流程取得；再核对它能访问哪些服务、数据和操作。GitGuardian 报告发现的 24,008 个独特密钥来自其研究的公开 MCP 配置文件样本，报告还提到其中有 2,117 个有效密钥。这些数字描述公开样本，不是全部 MCP 配置的普查结果，不能据此断言每个 MCP 部署都存在相同问题。GitGuardian 年度报告的数据说明
MCP 的授权也不只是“配置中有没有一串密钥”。协议文档对访问令牌受众和服务器端验证等要求有具体说明；核查时，应区分配置暴露、凭据仍然有效、凭据权限过宽和已发生异常调用这些不同事实。MCP 授权规范说明
共享 CI Runner 的痕迹与本机排查对照
共享 Runner 与个人开发设备不能用同一份检查清单代替。个人设备重点看用户目录、编辑器与 Agent 缓存、Shell 历史和本地会话；Runner 则要核对任务结束后的工作区、临时目录、环境变量注入方式、日志归档、缓存复用和任务间隔离。任务完成不代表临时凭据已销毁，尤其是重复使用的自托管 Runner。
| 场景 | 优先检查对象 | 可留存的证据 | 处置重点 |
|---|---|---|---|
| 个人开发设备 | 用户配置、会话与日志、缓存、Shell 历史、临时文件 | 文件路径、所属账户、凭据权限、出现时间 | 撤销或轮换后，清理并复查设备副本 |
| MCP 连接 | 客户端配置、服务器地址、授权方式、连接器所需凭据 | 配置来源、授权主体、可访问资源、调用审计 | 按实际权限回收令牌，核实是否有异常调用 |
| 共享 CI Runner | 工作区、环境注入、日志与缓存、任务结束后的机器状态 | 作业记录、令牌作用域、任务隔离及清理记录 | 回收流水线凭据，检查后续任务能否接触旧痕迹 |
GitHub 文档指出，自托管 Runner 不一定在每个任务后自动获得干净实例；其安全参考建议采用短生命周期 Runner，并提醒重复使用硬件仍需确保环境清理。这个措施可降低跨任务残留风险，却不是凭据治理的完整保证。自托管 Runner 安全参考
发现凭据后的处置与复核里程碑
MCP 配置文件中的密钥暴露后，先做什么？先判断它是否真实凭据、仍然有效，以及能访问哪些资源；若无法迅速排除有效性，就按潜在暴露处理并联系凭据所有者。优先撤销或轮换，再清理配置、历史和缓存副本。仅删除文件不会让已经复制出去的令牌失效。
按以下里程碑推进，避免只做“删文件”就结束：
- 确认凭据身份：标记令牌类型、签发主体、所属项目和权限范围；不要将明文贴进处置记录。
- 缩小仍可用权限：若凭据有效或权限影响面无法确认，及时撤销；若工作流仍依赖它，则按服务端流程轮换为新凭据，并同步更新必要的部署配置。
- 追踪使用情况：查看相应服务的认证日志、令牌使用记录、异常访问和受影响工作流。配置暴露本身并不能证明凭据已经被使用。
- 清理残留位置：分别处理仓库历史、本地未跟踪文件、Agent 会话、Shell 历史、临时产物和 CI 日志；留存的审计证据应避免包含秘密本身。
- 验证旧凭据失效：保存撤销状态或服务端验证结果，并确认旧凭据不能再完成认证。GitHub 对支持的令牌类型提供凭据撤销流程；其他服务则应使用各自的管理端或 API。GitHub 凭据撤销说明
- 分别复测扫描与清理：重新检查相关代码、设备目录和 Runner 环境。代码扫描通过只说明扫描范围内未发现匹配项，不证明端点记录、备份或服务端日志已全部清除。
发现后应该撤销还是轮换？如果令牌不再需要、疑似正在被滥用或权限过大，先撤销；若系统必须继续访问，则先准备权限更小的新凭据并更新依赖，再撤销旧凭据。选择要依据凭据类型、权限、使用状态和业务依赖，而不是仅看扫描工具给出的告警等级。
本周可执行的决策条件
- 若凭据已公开、有效性不明或具有广泛权限，先撤销，再检查服务端日志并恢复必要的最小权限访问。
- 若凭据尚未进入公开位置，但落在 Agent 日志、Shell 历史或本地临时文件中，按可能已被本机其他进程读取来处理；核对文件权限与使用记录后再决定轮换范围。
- 若 Runner 可被多个项目或任务复用，且无法证明作业结束后完成清理，就先暂停共享凭据复用，检查隔离、缓存和回收记录；不能证明旧任务痕迹已清除时，改用干净任务环境。
- 若扫描只覆盖仓库与 CI，立即把开发者端点检查加入排查范围；若已有端点扫描，也要抽样核对它覆盖的目录、文件类型和排除项，不能把“已部署”当作完整覆盖的证据。
仓库扫描、端点检查和 Runner 管理各自提供不同证据，任何单项都不能证明绝对安全。对于短期试点或需要临时测试环境的团队，RunMini 的远程 Mac 租赁可以减少把测试任务长期留在个人设备上的需要，但租用 Mac 本身不会自动隔离凭据：仍需配置最小权限、按任务回收令牌，并检查本地会话和执行痕迹。若正在评估远程开发环境，可结合云端 Mac 部署场景和远程环境中的 iOS 开发需求判断是否适合试点；需要物理接口、长期稳定运行或持续重负载的团队，则应先比较自购设备与现有环境的维护和权限治理责任。