GitHub announced on October 5, 2026 that it added new detectors to its secret scanning program: Lovable tokens, Supabase keys and Pydantic AI Gateway credentials now join the list of secrets automatically flagged in repositories. For web projects leaning heavily on Supabase as a backend-as-a-service, the update shrinks the exposure window when a key gets committed by mistake.
Four new detectors, two different mechanisms
GitHub’s secret scanning works through two distinct mechanisms. So-called “partner” secrets are forwarded directly to the issuer when found in a public repository, allowing near-instant revocation without any action from the developer. “User” secrets trigger a standard alert instead, visible in the repository’s security tab, whether public or private. With this update, Supabase joins the partner program for two token types: supabase_oauth_access_token and supabase_scoped_personal_access_token. Lovable Labs does the same with lovable_api_key, while Pydantic Services adds logfire_token and pydantic_ai_gateway_api_key.
Why Supabase specifically
Supabase has become a popular open-source alternative to Firebase for many front-end projects, often paired with AI-assisted app builders like Lovable, where a key can end up pasted into a config file without the developer fully weighing the scope of a broad-access token. A leaked Supabase personal access token can potentially grant access to an entire organization’s projects, databases included. Joining the partner program means any Supabase key found in a public repository now triggers a direct notification to Supabase, which can invalidate the token before the repository’s maintainer even notices.
| Provider | Secret type detected | Program status |
|---|---|---|
| Supabase | OAuth token, scoped personal access token | Partner (automatic revocation in public repos) |
| Lovable Labs | Lovable API key | Partner (automatic revocation in public repos) |
| Pydantic Services | Logfire token, Pydantic AI Gateway key | Partner (automatic revocation in public repos) |
Worth checking. Automatic revocation only applies to public repositories. In a private repository, a leaked Supabase key generates a security alert but stays active until someone manually revokes it on the Supabase side: secret scanning reduces the risk here, it doesn’t eliminate it for organizations working exclusively in private repos.
The best practice remains unchanged by this announcement: never commit a key, even temporarily, and rely on environment variables loaded at deploy time. That’s the same guidance already covered on Mail Studio around hardening the WordPress login screen, where managing application credentials plays a central role.
# Check whether a Supabase key is sitting in the local Git history
git log -p --all | grep -E "supabase_(oauth_access_token|scoped_personal_access_token)"
# In .gitignore, always exclude environment files
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
A Supabase key forgotten in a public repository is no longer just a theoretical risk: it now triggers an automatic notification to the provider, able to revoke it before the repository’s maintainer even notices.
For teams already running dedicated secrets managers across multiple projects, this expansion of secret scanning doesn’t replace a vault, but it closes part of the gap between a leak and its detection. It fits a broader pattern at GitHub, which has steadily widened its partner program throughout 2026 as new cloud services and generative-AI tooling gain traction among web developers, a trend already tracked in the roundup of web development CLI tools on Mail Studio.
What to remember
GitHub has added Lovable, Supabase and Pydantic to its partner secret scanning program: any key from these providers found in a public repository is now automatically forwarded to the issuer for revocation. The protection still only covers public repositories and the specific secret types a detector recognizes, which doesn’t exempt teams from solid secret-management practices upstream.
I welcome this expansion, but I stay cautious about how it gets read. It treats the symptom, not the cause. The real question has been the same for years: why do broad-access keys keep ending up in commits in the first place. As long as AI-assisted scaffolding tools keep generating config files with plaintext keys by default, secret scanning will remain a useful safety net, not a fix. — Simon Janvier
Further reading: official announcement on the GitHub changelog.
