让 AI agent 帮忙改代码，改动很快就能准备好。但如果它把数据库密码或 API key 一起提交了，谁来发现？发现后，又要多久才能让这串凭据失效？代码生成可以越来越快，泄露后的处理却可能仍在等人逐条查看告警、联系负责人、撤销并替换凭据。
软件生产提速，保护软件的能力也必须提速。这正是 GitHub 讨论的核心问题。仅仅要求开发者更小心，无法消化不断增长的代码量。平台需要在提交前拦住更多泄露，并让漏网凭据的处置更少依赖人工。
泄露总量与单次推送风险，要分开看
GitHub 引用的数据显示，平台上每三个 pull requests（代码变更请求）中，就有一个涉及 AI agent；一年前，这个比例还不到十分之一。如果这一速度持续，未来两年内，推送到 GitHub 的大部分代码可能由 agent 编写，其中不少代码可能不会被人完整阅读。这里的后半段是趋势推测，并非已经发生的事实。
代码量增加，意味着凭据保护需要检查的内容也增加。GitHub 表示，公开可见的代码中，大约每两秒就会出现一个新的 secret（密码、令牌等敏感凭据），这一数量在过去三年里每年翻倍。但总量上升，不能直接证明每次提交都变得更危险。
从 2024 年第二季度到 2026 年第二季度，接受检查的 pushes（代码推送）数量增长至原来的 2.84 倍，携带凭据的 pushes 数量增长至原来的 2.59 倍。在九个完整季度的数据中，GitHub 没有发现每次 push 携带凭据的比例存在统计上可检测的变化趋势。
另一个信号来自开发者如何处理拦截。在同一时期，开发者绕过 push 环节拦截的比例，从 6.63% 线性下降至 3.93%。这说明，至少在这项行为指标上，开发者更少选择忽略风险、继续推送。
这些数据不足以证明 AI agent 对安全没有影响，但它们不支持把泄露增长简单归因于“开发者用了 AI，就更粗心了”。更直接的解释是，即使每次推送的风险比例不变，推送数量翻倍，预期泄露数量也会翻倍。评估团队的安全状况时，应同时看代码活动量和泄露比例，也要看绕过拦截的行为，不能只盯着告警总数。
发现凭据只是开始，让它失效才是关键
凭据泄露和普通代码错误有一个重要区别：那串字符可能直接打开真实系统的大门。把它从当前文件中删除，不代表它已经失效；它也可能仍然留在 repository history（仓库历史）里。处置时，必须考虑凭据本身是否还能被使用。
GitHub 给出的人工处置数据并不轻松：手动撤销 secret 的平均时间徘徊在 40 天左右，约五分之一超过 90 天。这意味着，暴露的凭据可能在数周甚至数月内仍然可用。如果每次暴露都需要同样多的人工处理，代码活动量翻倍，处理工作量也会跟着翻倍。
GitHub 因此把 secret scanning（敏感凭据扫描）与能够执行处置的系统连接起来。其 secret scanning partnership program 覆盖超过 150 家技术合作伙伴：GitHub 与参与的凭据签发方共同建立检测器，并向它们报告公开暴露，以便对方采取行动。
2026 年第二季度，公开扫描平均每秒成功报告 26 次凭据匹配。这个数字包含重复观察，不能理解为每秒新增 26 个不同的泄露凭据。收到通知后，许多参与合作的签发方会立即撤销相应凭据，包括 OpenAI API keys、Google Cloud account credentials、Slack webhooks、Hugging Face user tokens 和 SendGrid keys 等。
自动撤销后，凭据所有者可能仍需替换令牌，让依赖它的服务恢复正常。不过，最紧迫的“让泄露凭据不能再用”这一步，可以不必等开发者找到并处理 GitHub 告警。
使用 AI 工具的团队选择安全方案时，可以先追问两件事：它能不能发现泄露，发现后能不能推动撤销？只有通知、没有后续动作的系统，仍会把大量压力留给人。
push protection 越早拦截，后面的处置就越少
相比泄露后再补救，push protection（推送时的凭据拦截）把检查提前到了代码进入仓库历史之前。发现能够识别的凭据时，它会阻止推送，让开发者或 agent 先修改代码，再继续提交。
这时处理起来通常更简单：凭据还没有越过 push 边界，系统只需要判断允许还是阻止。一旦它进入仓库历史，就可能被用于访问真实系统，调查、撤销和替换的工作，以及潜在损失，都可能随之而来。提前纠正一次提交，和事后处理一次暴露，承担的成本并不相同。
要让这种拦截成为默认保护，检测器必须足够准确。GitHub 与技术合作伙伴一起提高检测精确率，达到有把握的程度后，才会面向开发者社区默认启用相应凭据的 push protection。否则，误报会不断打断开发者，也会让下一次真正的拦截更难获得信任。
GitHub 在文章中披露，过去一个月，push protection 至少每秒拦下一次 secret。对于与签发方关联的凭据，GitHub 拦下的数量已经超过漏过的数量。这说明，具备明确识别方式的凭据，已经能从提交前检查中获得较强保护。
但把更多 secret 类型纳入统计后，情况仍有明显缺口：push protection 约能在进入仓库历史前阻止 30% 的新检测凭据，剩余约 70% 要到凭据暴露后才被发现。这个比例与前面的结果并不矛盾，两者统计的凭据范围不同。
团队因此不能因为已经启用 push protection，就省去泄露后的扫描与处置。实际选择应覆盖两个阶段：提交前减少暴露，提交后及时发现并撤销漏网凭据。前一道关卡越有效，后面的人工负担才越有机会下降。
没有固定格式的密码，需要结合上下文识别
有些凭据比较容易辨认。服务商签发的 token 可能带着可识别的前缀，检测器可以据此判断它属于哪一类。内部数据库密码却可能只是一串没有固定格式的字符，单看它本身，很难与普通文本区分。
这类 secret 的线索往往藏在周围代码和实际语境中。可以把它理解为辨认一把钥匙：印着明确标记的钥匙容易认出来，没有标记的钥匙，就需要看看它放在哪儿、准备开什么门。上下文能提供识别线索，但不能保证所有密码都能被准确识别。
GitHub 此前已经用上下文寻找推送后的这类凭据，但要把判断提前到 push 环节，要求会更严格。适合放进告警列表、等待人工复核的发现，未必适合立即阻止一次推送。
GitHub 将这里的难题概括为四个相互牵制的条件：precision（精确率）和 latency（延迟），以及 throughput（吞吐量）和 cost（成本）。检查既要少误报，又要足够快，还要承受大量提交，并保持可接受的运行成本。某一项做不好，都可能限制保护覆盖面。
对开发者来说，准确性关系到工作是否被无谓打断；对平台来说，速度与吞吐量，加上成本，决定了检查能否广泛运行。这也是为什么“用一个更强的模型检查所有代码”还不算完整答案。模型需要适合提交过程中的实时判断，也要能在事后给出分析。
ModernBERT 的价值，在于把上下文判断放进推送过程
GitHub 与 Microsoft Applied Sciences 合作，构建了经过微调的 ModernBERT classifier（分类模型）。它结合上下文评估候选 secret，任务是做分类判断，不生成代码或文章。
按照 GitHub 披露的结果，这个模型比现有基于 LLM 的处理流程更精确，评估一批候选凭据所需时间不到两毫秒，运行成本也足够低，可以大规模用于 push 的关键处理环节。两毫秒指的是候选批次的模型评估时间，不能直接理解为整个推送检查只需要两毫秒。
GitHub 表示，把该模型纳入 push protection，有望让可提前阻止的 secret 数量增加到现有的两倍以上。这里讨论的是可预防凭据的覆盖能力，不代表所有泄露都会减半，也不代表模型能够识别每一种密码。
文章发布时，这项功能仍处于 private preview（私有预览）。GitHub 当时计划在当月晚些时候，向 Enterprise Cloud 和 GitHub Teams 上拥有 GitHub Secret Protection 的组织开放，并说明该功能会消耗 AI credits。评估是否采用时，需要核对实际开放状态和组织所用产品，也要核对额度安排，不能把发布计划当成已经普遍可用。
GitHub 还提出，将模型带到 push 之外的开发入口，包括 Copilot CLI 和 Copilot App 的/security-reviewcommand。文章没有展开这些入口的具体检查范围与工作流程，因此仅凭这次介绍，还不足以判断它们能替代多少人工审查。
回到开头的问题，agent 更快地完成代码修改，凭据保护不能只靠人更快地读完每一行。更可执行的做法，是先梳理项目使用的凭据类型，核对哪些已能在 push 前拦截、哪些暴露后能够自动撤销，再为需要人工替换的凭据明确处理责任。
代码生产能力增长时，安全系统也需要承担更多识别和处置工作。否则，省下来的开发时间，很可能又被不断积压的泄露告警拿走。
