On October 5 GitHub added five new types to secret scanning. Secret scanning finds credentials such as API keys committed to repositories.
The new types are lovable_api_key, logfire_token, pydantic_ai_gateway_api_key, supabase_oauth_access_token and supabase_scoped_personal_access_token.
Lovable Labs also joined the secret scanning partner program. When a lovable_api_key is found in a public repository, GitHub forwards it to Lovable so the credential can be revoked or rotated.
Identifying a credential and notifying a party that can act are linked but not the same change. It does not mean every token gets the same protection.
Repository alerts, partner alerts and per-pattern features
GitHub splits alerts into two paths. User secrets generate secret scanning alerts for repository users when found in public or private repositories, and Partner secrets are reported automatically to the issuer when found in public repositories.
According to the documentation, partner alerts go directly to the provider and are not reported in the repository’s Security and quality tab.
The support table lists push protection and validity checks separately per pattern. All five new types are marked as having neither push protection nor validity checks.
In the support table, logfire_token and pydantic_ai_gateway_api_key are not marked for public repositories, only for private repositories with GitHub Advanced Security.
Partner forwarding gives the issuer a chance to act. It does not guarantee automatic revocation.
Combining token type and response path
Some operational questions cannot be answered by the number of detector types. Who sees the incident, and who can invalidate the exposed credential?
Repository admins often handle code cleanup while another team manages service accounts. Provider notification is useful but does not replace an organization’s incident record.
Conversely, a quiet repository screen does not mean the provider was not notified. The unit of review is the combination of token type and response path, not the product name.
A check that starts from the credentials actually in use
The check works best starting from a list of credential types the application actually uses. Those identifiers are compared against the current support table and the features enabled in the repository.
Record the person or team responsible for investigating alerts, revoking or rotating leaked credentials and updating dependent services.
This is a recommended operational check, not a procedure verified on a customer account. There is no reason to commit a real credential to confirm ownership is assigned.
Controlled validation within an authorized scope
If controlled validation is needed, the rule is to use only provider-approved dummy or test credentials and explicitly authorized test repositories.
Define the expected observation first. Local blocking, a repository alert and an issuer response are different outcomes, and a test that proves one does not prove the others.
Leave no usable secret in the evidence. Deleting a test commit does not undo the fact that a real credential was exposed.
Caveats: wider recognition and what was not verified
The direct benefit of this release is wider recognition coverage, not a completed incident-handling process.
This article reviewed the announcement and documentation only and did not test detection, private-repository eligibility or provider response. It did not run or verify the individual features of the five types either.
A new detector type tells you a secret can be found; who receives that alert and what they do with it is still the organization’s to decide.