Skip to content

CONCEPT Cited by 1 source

Leaked-credential auto-invalidation

Definition

Leaked-credential auto-invalidation is the safety primitive where a platform that issues credentials for its own service automatically revokes any credential that is detected leaking into a public location — typically a public GitHub commit — faster than automated credential-harvesting scrapers can exploit the leak. The canonical SLO is seconds — not minutes or hours — because public-GitHub scrapers scanning for leaked credentials typically operate in the 1–5-minute window, so the revocation must beat that race.

The primitive composes with platform-managed credentials: since the platform owns the credential namespace and issues credentials in a recognisable format, external substrates like GitHub's secret- scanning partner program can recognise the credential class cleanly, and the platform can revoke with confidence that nothing else is using that credential format.

The PlanetScale instance

Sam Lambert (PlanetScale CEO, 2023-06-28):

"If you accidentally push a PlanetScale database credential into a public GitHub repository, it will be automatically invalidated within seconds to prevent unwanted data access." (Source: sources/2026-04-21-planetscale-how-planetscale-keeps-your-data-safe)

Composes with the sibling statement from the same post:

"we ensure all credentials are generated by PlanetScale to guarantee they meet the strictest complexity requirements."

— i.e., PlanetScale owns the credential format, so GitHub's secret- scanning can recognise PlanetScale credentials cleanly without false positives, and PlanetScale can revoke them without breaking any other legitimate use of the credential string.

The race being won

The threat model is:

  1. Developer accidentally commits a credential to a public GitHub repo.
  2. git push completes.
  3. The credential is now publicly visible.
  4. Automated scrapers (black-hat actors running crawlers against the public-commits firehose) detect the credential and start attempting to use it.
  5. The credential, if used, grants access to the database.

The window between step 2 and step 4 is what defines the urgency. At modest-volume GitHub activity, scrapers typically pick up new leaked credentials in the 1–5-minute range. High-value credentials (AWS access keys, cloud-provider keys) are typically in the faster end of that range because the economic incentive to harvest them is high.

Within-seconds revocation beats even the fastest-scanner case — the credential is invalidated before the scraper can use it. The remaining risk is that the leaked credential was committed before the detection substrate saw it (e.g., force-pushed then force- deleted without GitHub notifying the secret-scanning partner program) or that the repo was private at push time and made public after a delay.

Enabling conditions

Leaked-credential auto-invalidation requires:

  1. Platform owns the credential namespace. The platform must be able to recognise its own credentials in a leak notification and revoke them atomically. Not compatible with customer-chosen passwords or federated credentials not owned by the platform.
  2. Recognisable credential format. A regex pattern that's unlikely to false-positive on other strings. Cloud providers use prefixes (AKIA, ya29., ghp_); PlanetScale presumably uses its own.
  3. Integration with a leak-detection substrate. GitHub's secret-scanning partner program is the canonical substrate — GitHub scans every public push for partner-registered patterns and notifies the issuer. Other substrates: Gitleaks, TruffleHog, custom scrapers.
  4. Low-cost credential rotation. The platform must be able to revoke a credential without breaking the tenant's service — i.e., the operator needs to be able to issue a new credential and redeploy. In practice this means the operator runs multiple credentials at a time (one per service / environment) so revoking one doesn't kill everything.
  5. Notification to the owner. The platform needs to tell the credential owner their credential was leaked so they can rotate in their infrastructure before their service breaks.

Contrast with username/password

Traditional self-hosted database deployments use user-chosen usernames and passwords. These are not auto-invalidatable because:

  • The database platform doesn't see the credential leak — it's on GitHub, not the database.
  • Even if a third-party scraper notified the database platform, username/password credentials look like arbitrary strings — indistinguishable from any other string.
  • Revoking them requires operator action (dropping the user, issuing a new password).

This is one of the concrete security advantages of a managed database-as-a-service over self-hosted — the platform can provide primitives that require credential-format ownership.

Composition with other safety primitives

Auto-invalidation is the outer-layer response to a leak. It does not prevent the leak in the first place. The inner-layer defenses are:

  • Short-lived credentials (e.g., OIDC-issued tokens valid for 1 hour) — even if leaked, the exposure window is capped by the token's TTL.
  • IP allow-lists — even if leaked, the credential can only be used from pre-registered IPs.
  • Principal-rewrite proxies (see patterns/external-credential-store-with-principal-rewrite) — client-facing credentials map to backend identities via a proxy, so leaked client credentials don't give direct database access.
  • Multi-factor authentication — leaked credentials alone don't admit a session.

Auto-invalidation is the "we lost the other defenses, now what" primitive. Defense-in-depth framing: it's the last line before data access.

Seen in

  • sources/2026-04-21-planetscale-how-planetscale-keeps-your-data-safe — Canonical wiki introduction of the primitive. Sam Lambert (PlanetScale CEO, 2023-06-28) names auto-invalidation as one of the seven defensive layers in PlanetScale's data-safety envelope. Verbatim: "If you accidentally push a PlanetScale database credential into a public GitHub repository, it will be automatically invalidated within seconds to prevent unwanted data access." The mechanism is not disclosed — likely GitHub's secret-scanning partner program, but the post doesn't say.
Last updated · 550 distilled / 1,221 read