服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 五类检测器包括 Lovable API Key、Logfire Token、Pydantic AI Gateway API Key，以及两类 Supabase token。
- 截至核对日，五类均支持用户告警；只有 Lovable 与两类 Supabase 标为支持伙伴通知。伙伴通知与仓库中的用户告警是不同通道。
- 这五类当前均未标为支持推送保护、有效性检查、扩展元数据或 Base64 格式检测，不能从“能检测”推出“会拦截”。
- 公共仓库的秘密扫描自动免费运行；组织的私有及内部仓库需符合套餐条件并启用 GitHub Secret Protection。
新增了哪些凭据类型？先按准确名称核对
GitHub 在2026年10月5日公告新增这些检测器；这篇文章按2026年11月6日重新核对的支持表整理适用范围，不把旧公告描述为当天新发布。这里检测的是服务商有特定格式的凭据，与用 AI 模型识别无固定格式密码的能力分开判断。
Lovable Labs 对应 lovable_api_key；Pydantic Services Inc. 对应 logfire_token 和 pydantic_ai_gateway_api_key。前者是 Logfire Token，后者是 Pydantic AI Gateway API Key；不要只按服务商名称把两种类型合并。
Supabase 对应 supabase_oauth_access_token 和 supabase_scoped_personal_access_token，分别是 OAuth 访问 token 与限定权限的个人访问 token。这份名单没有宣称覆盖这些平台的所有密钥版本或其他凭据；核对时保留准确 secret type。
用户告警与伙伴通知，分别发给谁？
官方当前支持表把五类都列为支持 User alert，即面向仓库用户的告警。Lovable 与两类 Supabase 同时标为支持 Partner 通知；两类 Pydantic 没有这一标记。不能把没有伙伴通知，误读为公共仓库完全没有用户告警。
用户告警显示在仓库的 Security and quality 页签。伙伴通知则直接报告给凭据签发服务商，不作为伙伴告警显示在仓库里；同一种凭据可以分别支持这两条通道。10月5日公告明确，Lovable 加入伙伴计划，公共仓库中匹配的凭据会转交给它处理。
通知服务商的目的是让服务商能够撤销或轮换凭据，但“已通知”不等于某一把密钥已实际失效。判断自己的暴露结果时，需要核对签发平台上的实际状态与团队处置记录。
为什么检测支持不代表推送时会被拦截？
截至2026年11月6日，这五行的 Push protection、Validity check、Metadata check 和 Base64 均为不支持。推送保护是在推送环节提供拦截的独立能力；已有秘密扫描检测器，不会自动补齐这项能力。
因此，推送成功不是这五类凭据未泄露的证明；没有有效性检查，也不能期待告警自动告诉你凭据是否仍可使用。Base64 一栏未支持时，同样不能把原文凭据的检测范围外推到其编码形式。
例如，假设维护者把 Lovable API key 写进提交，随后推送成功。这个假设仅说明如何理解支持边界：不能据此认定凭据安全、未被检测或已被撤销。不要为了验证检测器而把真实凭据提交到仓库。
哪些仓库可用，需要什么资格？
GitHub 文档说，公共仓库的秘密扫描自动免费运行。组织所有的私有及内部仓库，则需在 GitHub Team 或 GitHub Enterprise Cloud 上启用 GitHub Secret Protection；“新增检测器”不会替私有仓库自动取得许可。
对于用户所有的仓库，当前文档列出的资格为采用 Enterprise Managed Users 的 GitHub Enterprise Cloud，或企业已启用 GitHub Secret Protection 的 GitHub Enterprise Server。仓库所有权、可见性和托管平台都要按自己的情况核对，不要只凭个人 Copilot 订阅判断。
公开资料在这里说明功能资格，没有给出这五类检测器独立的逐国家开放表、逐账号启用时间或新增单项价格。具体许可与平台版本应以适用文档及账号条款为准；本文不把资格说明换算成费用承诺。
仓库维护者现在怎样安排检查？
第一，列出项目实际使用的凭据类型，按上面的五个准确名称查当前支持表，再确认仓库的所有权、可见性、托管平台与 Secret Protection 状态。不要把“Partner”列当成仓库可用性开关。
第二，在有权限的仓库查看 Security and quality 中的实际告警。官方说明秘密扫描检查所有分支的完整 Git 历史，并会在新增类型后定期重新扫描；检测器公告不是某个仓库已经扫描完成的收据。
第三，若发现真实凭据暴露，按签发平台和团队流程立即轮换受影响凭据，核对依赖配置与处置结果。GitHub 指出，单纯从历史中删除秘密不能替代让已暴露凭据失效。保留必要的时间与类型记录，避免在工单、聊天或新的提交中再次复制真实凭据。
资料来源
常见问题
这些服务商凭据类型和 AI 检测的通用密码是一回事吗？
不是。本文核对的是 Lovable、Pydantic 和 Supabase 的五种服务商凭据模式。GitHub 文档另将 AI-detected pattern 列为一类，并以 password 为例。各类支持的告警和其他能力应按对应支持表分别核对。
仓库改为私有后，是否可以忽略以前的暴露？
不能仅凭可见性变化判断已暴露凭据是否失效。应继续按签发平台与团队流程核对和轮换；同时重新检查私有仓库适用的 Secret Protection 资格。本文没有执行扫描，也没有验证任何真实密钥状态。