GitHub secret scanning added five credential patterns on October 5: Lovable API keys, Pydantic Logfire tokens, Pydantic AI Gateway API keys, Supabase OAuth access tokens and Supabase scoped personal access tokens. Public Lovable API keys also enter GitHub’s partner-notification path, while the other four additions generate repository alerts.
GitHub’s changelog makes that reporting boundary explicit. A detected string is not automatically a revoked credential, and maintainers still need to trace its use, rotate it at the issuer and remove it from active automation.
One detector has partner reporting; all five produce findings
GitHub classifies lovable_api_key as a partner secret. When that pattern appears in a public repository, GitHub forwards it to Lovable Labs so the provider can revoke or rotate it before abuse. The same Lovable pattern is also included in the general detector list.
The other new identifiers are logfire_token, pydantic_ai_gateway_api_key, supabase_oauth_access_token and supabase_scoped_personal_access_token. GitHub describes these as user secrets: a match generates a secret-scanning alert in eligible public or private repositories, but the provider-forwarding statement in this release applies specifically to Lovable’s partner pattern.
Detection changes the first response, not the cleanup rule
A new alert should start with the issuer, not with a commit deletion. Rotate or revoke the credential first, because removing a line from the current branch does not invalidate copies in clones, forks, caches or earlier Git objects. Then identify where the old value was used and replace it in deployment secrets, CI variables and local configuration.
Scope matters for the two Supabase additions. Supabase’s production guidance recommends keeping service-role secrets off clients and using access controls appropriate to the environment. A scoped personal access token can limit authority, but “scoped” does not make exposure harmless; the assigned scope and recent activity determine the practical response.
GitHub’s Advanced Security trial controls may affect which private repositories a team can evaluate, while public-repository partner scanning follows GitHub’s broader secret-protection program. Repository owners should confirm coverage in the security settings rather than assuming every organization plan scans every private codebase.
The added names matter for custom leak checks
Teams that supplement GitHub with pre-commit or CI scanners should update allowlists and incident runbooks with the exact new identifiers. An allowlist created for a test token can suppress a real successor if it is matched too broadly. OWASP’s secrets-management guidance similarly treats detection as one control in a lifecycle that includes inventory, rotation, revocation and auditing.
GitHub’s release expands recognition; it does not say that historical alerts have all been remediated or that every token-looking string is valid. The practical completion condition is an invalidated old credential, a verified replacement and a repository history reviewed for additional exposed values.
