GitHub 数据：AI 智能体已包办三分之一拉取请求，密钥防护必须跟上代码生产速度
GitHub 连续九个季度的观察显示，AI 智能体提交的拉取请求占比已从一年前的不足十分之一升至约三分之一，同期被扫描的推送量增长 2.84 倍。但单次推送中携带密钥的比例并未明显上升，开发者主动覆盖拦截的比例反而从 6.63% 降到 3.93%。这说明问题不在开发者变粗心，而在于泄露的发现与处置仍主要靠人力，跟不上代码生产的速度。
代码生产加速，防护也要加速
今天 GitHub 上每三个拉取请求（pull request，即开发者提交待合并的代码变更）中，就有一个出自 AI 智能体（agent，能自主完成任务的 AI 程序）。一年前这个比例还不到十分之一。按当前趋势，未来两年内推送到 GitHub 的代码大部分可能由智能体编写，其中不少甚至不会被人完整读过。
开发者和智能体都在提速，防护也必须跟上代码生产的速度。具体是两件事：在泄露发生前拦下更多，以及在仍有漏网时，让处置少依赖人工。
对习惯用 AI 编程助手、甚至靠「氛围编程」边聊边出代码的团队来说，这组数字提醒的正是这一点：代码产出越快，密钥暴露的窗口越大，仅靠人工盯审查已经不现实。
相关数据来自连续九个季度的观察。GitHub 还与 Microsoft Applied Sciences 合作训练了一个微调分类器，把推送保护（push protection，在代码推送到仓库之前拦截其中密钥的机制）扩展到非结构化密钥。该模型能在不到两毫秒内评估一整组候选密钥，有望让被拦截的密钥数量翻一倍以上。
不是粗心，是被甩在了后面
公开可见的代码中，大约每两秒就出现一个新密钥，过去三年这一数字每年翻一番。
人们很容易得出「AI 让开发者变粗心了」的结论。但从 2024 年第二季度到 2026 年第二季度，被扫描的推送量增长了 2.84 倍，其中携带凭据（credential，即密码、令牌这类访问凭证）的推送增长了 2.59 倍。在完整的九个季度数据里，单次推送的密钥出现率并没有明显、可统计的趋势变化。
另一组数据更能说明问题：开发者比以往更清楚意外泄露的风险，也更不愿接受这种风险。同一时期，开发者在推送环节选择覆盖（override，即无视拦截继续推送）的比例从 6.63% 线性下降到 3.93%。
这些数字对「智能体让开发者变粗心」的流行说法构成了反证。
九个季度的推送量与密钥出现率
- 公开推送量从 2.02 亿增至 5.74 亿，约 2.8 倍
- 时间跨度：2024 年第二季度至 2026 年第二季度
- 2026 年第二季度：5.74 亿次推送中，0.47% 含密钥
- 纵轴范围：推送量 0–6 亿；密钥出现率 0%–1.0%
数据来源：公开推送，2024 年第二季度至 2026 年第二季度。
泄露次数翻倍，人工处置也翻倍
推送检出率，指的是含密钥的推送在全部推送中的占比，统计覆盖各类受支持的提供商格式，也包括 GitHub 自家的令牌。关键在于：比例固定时，活动量翻倍，预期的泄露次数就翻倍。如果每次泄露都要投入同样的人力，工作量也随之翻倍。
现实是，人工撤销密钥平均耗时约 40 天，大约每五个里就有一个超过 90 天。一边是软件开发在加速，一边是泄露的凭据在数周乃至数月内仍然可用，因为人工修复的速度赶不上开发节奏。只提醒开发者「多加小心」解决不了这个问题。随着代码量增长，要让软件开发保持可持续，必须阻止更多泄露，并减少剩余泄露所耗费的人力。
防护能力靠算力扩展
过去几年，GitHub 在密钥扫描上最大的进展，来自把检测能力与能够实际处置的一方打通。通过密钥扫描合作伙伴计划，GitHub 的目录已覆盖 150 多家技术合作伙伴。GitHub 会与参与计划的密钥签发方一起搭建检测器，并把公开泄露上报给相关方，方便对方及时响应。
2026 年第二季度，公开扫描平均每秒成功上报 26 条凭据匹配，其中包含重复观察。接到通知后，很多合作伙伴会直接撤销令牌，比如 OpenAI API 密钥、Google Cloud 账号凭据、Slack webhook、Hugging Face 用户令牌、SendGrid 密钥等。令牌所有者可能还需要更换令牌，但撤销这一步不必等开发者看到 GitHub 告警再处理。
推送保护介入得更早：可识别的凭据还没进入仓库历史，就会被它拦下，开发者或智能体有机会在事情变成需要调查的泄露之前改好。GitHub 会和技术合作伙伴一起提升检测器准确率，直到有足够把握，为开发者社区默认对这些密钥开启推送保护。
多亏合作伙伴的努力，过去一个月里，推送保护平均每秒至少拦下一次密钥泄露。对于发行方绑定的凭据（issuer-bound credentials），GitHub 拦下的密钥数量已经超过漏网的数量。
补救的规模，仍然取决于人力
覆盖更多密钥类型后，推送保护能在约 30% 的新检测到的密钥进入仓库历史之前将其拦下；剩下 70% 的密钥，则是在凭据已经泄露之后才被发现。
换句话说，防护的规模靠算力支撑，补救的规模仍然靠人力支撑。拒绝一次推送，消耗的是算力；清理一个已经暴露在可见历史里的密钥，消耗的是开发者的时间和精力。代码量继续涨，就必须拦下更多泄露，同时降低漏网之鱼所需的人力，否则引入的漏洞会多到收拾不过来。在开发流程中更早识别出更多这类密钥，是平台必须承担的工作。
密钥保护里的「四体问题」
密钥还没被推送到远端时，拦截它的代价很小，决定也很直接：拦下或放行。一旦推送出去，同一个字符串就可能登录真实系统，代价也就没有上限。
很多时候，唯一的检测线索来自周围代码和外部环境：服务商签发的令牌可能带有可识别的固定前缀；内部数据库密码则可能毫无结构，根本找不到规律。推送之后，平台已经能借助上下文找出这些密钥，难点在于如何把这种依赖上下文的判断与其他因素平衡好。
GitHub 把这称为密钥保护领域的「四体问题」：精确率、延迟、吞吐量和成本，四个彼此牵制的约束。防护措施必须对得起开发者花的时间。一个适合留待事后复查的发现，未必足以成为阻止一次推送的理由。误报会打断开发者，也会让下一次拦截更难被信任。检查如果太慢、太贵、太难扩展，就会限制它能运行的频率。
推送时不到 2 毫秒完成防护
GitHub 的 AI 通用密钥检测模型会利用周围的代码上下文，在数据库 URL、Kubernetes Secret 清单和 Dockerfile 中拦截类似密码的值，同时放行 changeme 这类占位符。新的 ModernBERT 分类器只在上下文中判断候选字符串像不像密钥，不生成代码或文本。它不仅比原先依赖大语言模型的检测流程更精确，而且速度极快，能在不到两毫秒内评估一批候选密钥。
成本效益也足够高，可以在关键路径上大规模运行。把该模型纳入推送保护（在代码推送环节拦截密钥的机制）后，可拦截的密钥数量增加了一倍以上。
该功能目前处于私有预览阶段。本月晚些时候，它将面向 Enterprise Cloud 和 GitHub Teams 中拥有 GitHub Secret Protection 的组织开放，使用时消耗AI 积分（GitHub 的 AI 用量计费单位）。
我们还会把模型用到推送之外的其他开发界面。从今天起，只要组织启用了 AI 密钥检测，就会自动用上新模型。这些推送后扫描生成的警报仍然包含在组织的密钥扫描订阅里，不用额外付费。该模型也会随 GitHub Enterprise Server 3.23 以公开预览形式提供，让 Secret Protection 客户即使在气隙环境（与互联网物理隔离的网络）里也能收到 AI 检测警报。
我们把这个分类器接入了 Copilot CLI 和 Copilot App 的 /security-review 命令。这样，即使组织没有购买 GitHub Secret Protection，Copilot 用户也能在推送前处理密钥。相关 AI 积分用量会记入 AI 使用洞察中的 GitHub Secret Protection。
展望未来
我们希望看到的未来，是开发者能把更多工作交给智能体，而不必盯着每一个请求；组织保护凭据安全所需的人力，也不再随着代码量一起上涨。我们在保护软件上取得的进展，应该追上生产软件的速度。
我们希望人们能构建更多软件，也希望保护软件的能力与创造软件的能力同步增长。