在构建生产级 AI Agent 的过程中，安全边界始终是绕不开的一环。当 Agent 能够自主读写代码、执行命令、发起提交时，密钥泄露的风险不再只来自人类开发者，也来自 Agent 的自动化行为。GitHub 在 2026 年 10 月发布的专用密钥泄露检测模型，正是针对这一变化给出的官方回应。

从模式匹配到上下文理解

传统 Secret Scanning 依赖两类手段：正则表达式匹配已知令牌格式，以及熵值检测高随机性字符串。这两类方法对 AWS Access Key、GitHub PAT 等有固定前缀的凭据有效，但对没有可识别令牌格式的密码、自定义 API Key、内部服务凭据往往无能为力。

GitHub 此次发布的模型是经过微调的专用模型，核心差异在于它会读取凭据周围的代码上下文来判断是否为真实凭据。官方描述明确指出，它能识别“没有可识别令牌格式的密码”。这意味着检测逻辑从“字符串长什么样”转向“这段代码在做什么”。

另一个值得注意的工程约束是：该模型不生成代码或散文，只做分类判断。对于需要嵌入 CI/CD 或 Agent 工作流的场景，这种纯判别式输出比生成式模型更可控，延迟和成本也更可预测。

三个落地入口

官方资料显示，该模型通过三条路径进入开发者工作流：

第一，Secret Scanning 告警。 已有 AI-detected Password 告警的客户自动升级到新模型，GHSP 和 GHAS 客户无需额外付费。这是存量能力的静默升级。

第二，Push Protection。 在推送时检查非结构化凭据，给开发者一次在密钥进入仓库历史前移除的机会。该功能处于 private preview，需要 GHEC 或 Teams 配合 GHSP/GHAS 购买，且必须由管理员启用。

第三，Copilot /security-review。 在 Copilot CLI 或 Copilot App 会话中，提交、推送或发起 PR 前运行该命令，返回按优先级排序的安全发现和修复建议。该检查只读，不修改代码。

计费模型与边界条件

这是集成时必须算清楚的账。官方明确区分了两类消耗：

AI-detected secret alerts 继续包含在 GHSP 和 GHAS 中，不额外收费。而 Push Protection 的 AI 检查和 /security-review 中的新检查会消耗 GitHub AI Credits。

几个容易踩坑的边界：

  • Push Protection 的检查即使没有阻止推送，也可能消耗 credits。
  • 在 EMU 用户命名空间仓库之外，AI Credit 用量归属组织，不占用具体用户的配额。
  • /security-review 的新检查默认关闭，运行该命令本身不会启用它们，必须显式 opt-in。
  • 官方特别提示：Agent 不应在未经明确授权的情况下启用消耗 credits 的功能或修改策略与预算。

用量会显示在 AI usage insights 的 Secret Protection AI Credits SKU 下。管理员可以通过 Billing and licensing 中的 Budgets and alerts 设置 SKU 级预算，并配置“达到预算上限时停止使用”来实现硬性支出封顶。仅设置告警不会停止消耗。

平台覆盖差异

GHES 3.23 将在 public preview 中获得 AI-detected alerts，包含在现有 GHSP/GHAS 购买中，但 AI push protection 和 Copilot security review 命令不在该 Server 版本中。GHEC with data residency 支持 Copilot Business 和 Enterprise 的 security review 命令，AI push protection 计划中。个人 Copilot 计划（Pro、Pro+、Max、Free、Student）可以使用 security review 检查，无需 GHSP/GHAS 许可。

对 AI Agent 系统的工程启示

回到本系列的主题。当我们在构建生产级 AI Agent 时，这个模型提供了几个可操作的集成点：

在 Agent 提交前插入检查。 如果 Agent 具备 git commit 或 push 能力，可以在工作流中调用 /security-review，让 Agent 在提交前获得安全发现。官方文档提到开发者与 coding agents 都可以使用内置的 security-review specialist，并在修复后重新运行审查。

把 Push Protection 作为最后一道闸。 对于 Agent 自动生成的代码，Push Protection 在推送时拦截非结构化凭据，是防止密钥进入历史的兜底机制。但要注意它消耗 credits，需要在组织层面做好预算控制。

权限与授权分离。 官方明确要求 Agent 不应自行启用消耗 credits 的功能或修改策略。在 Agent 系统设计中，这意味着安全相关的开关应当由人类管理员控制，Agent 只负责调用已启用的能力。

误报治理。 上下文感知模型能识别无格式密码，理论上会带来更多告警。工程上需要建立告警分级和抑制机制，避免 Agent 工作流被大量低置信度告警阻塞。官方资料未提供误报率数据，实际效果需要在启用后根据自身代码库评估。

小结

GitHub 的专用密钥检测模型代表了 Secret Scanning 从模式匹配向上下文理解的演进。对于构建 AI Agent 系统的团队，关键不是模型本身有多强，而是如何把它嵌入 Agent 的提交、推送和审查流程，同时通过预算控制和权限分离避免自动化带来的成本失控。下一篇将继续围绕 Agent 系统的安全与工程化实践展开。