Leaked PlanetScale, Neon and Aiven Tokens: Response

A leaked token or password for a managed database platform is two problems at once: control of the platform account and direct access to the data inside it. PlanetScale, Neon and Aiven each issue a control-plane credential (service tokens, API keys, personal and application tokens) and a data-plane credential (database passwords, role passwords and connection URIs), and both kinds turn up in repositories, CI logs and .env files. This page sets out, per platform, what each credential reaches, how to revoke or rotate it without breaking production, what GitHub secret scanning will and will not catch, and which logs show what the credential did. It is written for platform engineers, database administrators and incident responders who own these accounts. For the general credential incident process see the Leaked Credential Response Playbook; for database credential design see the Database Credential and Access Security Guide.

Key takeaways

Split every leak into control plane and data plane. A PlanetScale service token, Neon API key or Aiven token can create branches, passwords and users; a database password or connection URI reads and writes data directly. Treat each with its own containment step.
Database passwords rotate by replacement, not by edit. PlanetScale passwords are deleted and recreated, Neon role passwords are reset per branch, and Aiven service user passwords are reset per service, so every consumer must be updated in the same change.
Branches multiply credentials. PlanetScale passwords are scoped to one branch and Neon roles exist on every branch, so a single leaked secret can have siblings on preview and development branches that also need rotation.
Partner alerts differ. GitHub notifies all three providers about public leaks, but Neon secrets have no push protection and no private repository user alerts in GitHub's pattern list, so private repository scanning needs your own rules for Neon.
Audit windows are short. PlanetScale keeps its organisation audit log for 15 days and Aiven keeps organisation event logs for 30 days, so export evidence on day one of the incident.

How identity and access work in managed database platforms

All three platforms separate the account that manages databases from the credentials applications use to connect. The table summarises the credential types as their documentation describes them.

Platform	Control-plane credential	Data-plane credential	Expiry by default
PlanetScale	Service tokens (ID plus token value) with organisation permissions such as `create_databases` and per-database permissions such as `read_branch`, `create_branch`, `delete_branch`; OAuth tokens	Database passwords: a unique username and password pair per branch, of type Primary, Replica or Read-only region	No expiry stated for service tokens; passwords exist until deleted
Neon	Personal API keys (all projects the user can reach), organisation API keys (all organisation projects), project-scoped keys (one project, Editor access)	Postgres roles and passwords, usually consumed as a connection URI; roles exist per branch	API keys have no expiry and are valid until revoked
Aiven	Session tokens, personal tokens, and application tokens issued to application users	Service users and passwords on each service (for example PostgreSQL, Kafka, Valkey)	CLI-created personal tokens default to a 30 day max age; session duration is set at creation

Two design facts drive leak response. First, the control-plane credential can usually mint new data-plane credentials, so an attacker holding a service token or API key can create a fresh database password that survives your rotation of the leaked one. Second, Neon's documentation states that roles created through the Console, CLI or API are granted neon_superuser membership, which includes CREATEDB, CREATEROLE, BYPASSRLS and REPLICATION. A leaked connection URI for such a role is close to full control of that database, including the ability to create new roles.

Admin roles and privileged access

PlanetScale: only organisation administrators can grant create_databases to a service token, and permissions granted for all databases cannot be disabled for an individual database. A token that holds all-database access is therefore an organisation-wide credential. Only organisation administrators can read the audit log, so make sure the incident team includes one.
Neon: personal API keys can be revoked only by the account owner; organisation and project-scoped keys can be revoked by organisation admins. If a personal key leaks and the owner is unavailable, the organisation-level fallback is to remove that user from the organisation, which ends the key's access to organisation projects.
Aiven: creating application users requires the organization:app_users:write permission or role:organization:admin, and reading organisation event logs requires organization:event_logs:read. Organisation authentication policies can disable personal tokens for managed users and restrict access to allowed IP ranges, which Aiven states also applies to personal and application tokens.

Keep the set of people who can mint organisation-wide tokens small, and review it as part of privileged access reviews. See the NHI Ownership Guide for assigning an accountable owner to every token.

Integrations, API tokens and service accounts

Most leaks come from automation: a deploy pipeline, a migration script, a preview environment or a developer's .env file. The safer patterns, per platform:

PlanetScale service tokens for CI: PlanetScale reads PLANETSCALE_SERVICE_TOKEN_ID, PLANETSCALE_SERVICE_TOKEN and PLANETSCALE_ORG from the environment, and the API takes the header Authorization: <SERVICE_TOKEN_ID>:<SERVICE_TOKEN>. Grant per-database permissions, not all-database permissions, and one token per pipeline so revocation does not break unrelated jobs. A token cannot approve a deploy request it created, which preserves a two-party check on schema changes.
Neon project-scoped keys: a project-scoped key cannot delete the project, manage project access, create projects or perform organisation actions. Use it for per-project automation instead of a personal key, which follows the person across every project they can reach.
Aiven application users: Aiven describes application users as the way to give non-human users programmatic access, with access granted through organisation roles and permissions. Set a session duration and an IP allowlist when you generate each token, because both can be set only at creation.
Connection strings: store them in a secrets manager and inject them at runtime. A connection URI in a .env file is a password in plain text. The 230 Million AWS Cloud Environments campaign harvested exposed .env files that held cloud, database and social media credentials. See the Environment Variables and .env Files guide.
Credentials handed to third parties: consultants and support teams often receive connection strings. In the Red Hat Consulting GitLab breach, attackers claimed that customer engagement reports contained tokens and database connection strings, and customers were advised to rotate credentials shared with Red Hat. Issue third parties their own, time-limited credentials so you can revoke them alone.

Logging and detection

What GitHub secret scanning covers

GitHub's supported patterns list (checked 28 October 2026) shows the following for these providers. "Partner" means GitHub notifies the provider when the secret appears in a public repository; "User alert" means alerts in your own repositories with GitHub Secret Protection.

Secret (GitHub name)	Secret type	Partner	User alert	Push protection	Validity check
PlanetScale Database Password	`planetscale_database_password`	Yes	Yes	Yes	No
PlanetScale Service Token	`planetscale_service_token`	Yes	Yes	Yes	No
PlanetScale OAuth Token	`planetscale_oauth_token`	Yes	Yes	Yes	No
Neon API Key	`neon_api_key`	Yes	No	No	No
Neon Connection URI	`neon_connection_uri`	Yes	No	No	No
Aiven Auth Token	`aiven_auth_token`	Yes	Yes	Yes	No
Aiven Service Password	`aiven_service_password`	Yes	Yes	Yes	No

What the providers do with a partner alert also differs. PlanetScale states that when a password or service token is committed in plain text to a public GitHub repository it is notified and deletes the credential, which cuts off access. Neon states that it validates the credential and notifies its security team. Plan for both outcomes: a PlanetScale leak can cause an outage when the credential is deleted, and a Neon leak may leave the credential live until you act. No validity check is listed for any of these secrets, so triage cannot rely on GitHub to say whether a found secret still works. See the Git Secret Scanning Guide and Push Protection Guide.

Platform audit evidence

Platform	Where	Events that matter in a leak	Retention and access
PlanetScale	Organisation settings, audit log; API `/v1/organizations/:name/audit-log` with a service token holding `read_audit_logs`	`service_token` created, deleted, updated bulk database access, token leaked; `access_token` token leaked; `database_branch_password` created, deleted, password leaked, updated IP restrictions; `postgres_role` created or deleted; organisation SSO and membership changes	15 days; organisation administrators only
Neon	API key metadata (`last_used_at`, `last_used_from_addr`); application logs for "password authentication failed"	Last use of a key and the source address; failed logins after rotation show consumers you missed	No customer audit log is described in the security overview checked
Aiven	Admin, Event logs; `avn user access-token list`; Authentication tokens section of each application user	Actions by user and target resource; token last used time, last IP and last user agent	30 days; `organization:event_logs:read` or organisation admin

Platform logs show control-plane activity. Queries run with a leaked database password appear only in database-level logs (for example PostgreSQL connection and statement logging), so enable them before you need them. See the Database Audit Log Detection Guide.

Leak response, step by step

Identify the credential type and scope. Use the secret type from the scanner alert. For a control-plane credential, list what it can do (PlanetScale token permissions, Neon key type, Aiven user roles). For a database credential, identify the branch or service and the role's privileges.
Export evidence first. Pull the PlanetScale audit log through the API, export Aiven event logs, and record Neon key last_used_at and last_used_from_addr. Retention is days, not months.
Contain the control plane. PlanetScale: pscale service-token delete <SERVICE_TOKEN_ID> or Delete service token in the dashboard. Neon: neon api-keys revoke <key-id> or DELETE /api/v2/api_keys/{key_id}; revoked keys return 401 Unauthorized and cannot be reactivated. Aiven: avn user access-token revoke <token_prefix> for personal tokens, or Admin, Application users, Authentication tokens, Actions, Revoke.
Rotate the data plane. PlanetScale: delete the password under Organization, Database, Settings, Passwords; active clients are disconnected and open connections are dropped within five minutes. Neon: reset the role password on every branch through the Console or POST /api/v2/projects/{project_id}/branches/{branch_id}/roles/{role_name}/reset_password; Neon notes there is no CLI command for this. Aiven: avn service user-password-reset <service> --username <user> --new-password <password>.
Hunt for persistence. Look for credentials the attacker may have created: new PlanetScale passwords or service tokens, new Postgres roles (PlanetScale postgres_role events, Neon roles you do not recognise), new Aiven service users (avn service user-list) and application users. Remove anything unexplained.
Assess data access. Review database logs for the leaked username from the exposure time onwards, and treat the incident as a possible data breach until shown otherwise. Use the Database Breach Response Playbook if data was read.
Clean the source. Remove the secret from the repository history, CI logs or file share, and confirm forks and caches. Rotation, not deletion of the commit, is what ends the exposure.

Zero-downtime option: where a hard cut is not acceptable, Neon documents creating a parallel role with the same access, moving services across one at a time, then resetting the old role's password. The same pattern works on PlanetScale (create a second password on the branch, migrate, then delete the leaked one). Only use it when the leak is not being actively exploited.

Hardening baseline

Control	PlanetScale	Neon	Aiven
Network restriction	Per-password IP restrictions (Manage IP restrictions)	IP Allow on the Scale plan, optionally for protected branches only; AWS PrivateLink for organisation accounts	Allowed IP ranges in the authentication policy and per token at creation
Least privilege	Per-database token permissions; Replica and Read-only region passwords for read workloads	Project-scoped keys; SQL-created roles without `neon_superuser` for applications	Application users with organisation roles; personal tokens disabled by policy
Lifetime	No token expiry stated, so schedule rotation	No API key expiry, so rotate manually	Set `--max-age-seconds` or session duration; avoid `--extend-when-used` for automation
Branch protection	Branch-scoped passwords	Protected branches: child branches get new role passwords	Not applicable

Framework mapping

Framework	Reference	Why it applies
MITRE ATT&CK	T1552.001 Credentials In Files; T1078.004 Cloud Accounts	Secrets found in files and repositories; use of valid platform accounts
NIST SP 800-53 Rev. 5	IA-5, IA-5(7), AC-2, AC-6, AU-6, SC-7	Authenticator management and no embedded static authenticators; account and privilege control; log review; network boundaries
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03, RS.MI-01	Credential management, least privilege, monitoring and containment

Common misconfigurations

Rotating the password but not the token: the attacker uses the still-valid service token or API key to mint a new database password. Always revoke control-plane credentials found in the same file or pipeline.
Resetting one branch: Neon role resets are branch-scoped, and PlanetScale passwords are per branch. Preview branches with copies of production data keep the leaked credential alive.
Superuser application roles: applications connecting as a role with neon_superuser membership, or a PlanetScale password with a more privileged role than the workload needs, turn any connection string leak into full database control.
Relying on GitHub for Neon: without push protection or private repository alerts for Neon secrets, internal repositories can hold Neon URIs indefinitely. Add custom patterns or a second scanner.
Losing the audit window: waiting a fortnight to investigate means PlanetScale evidence from the exposure period is gone. Stream audit logs to your SIEM routinely.
Personal credentials in automation: a Neon personal key or Aiven personal token in CI stops working when the person leaves, or worse, keeps working with all of that person's access.

Practitioner checklist

Inventory every PlanetScale service token, Neon API key and Aiven token, with an owner and the pipeline that uses it.
Replace personal credentials in automation with PlanetScale per-database tokens, Neon project-scoped keys or Aiven application users.
Remove neon_superuser members and over-privileged password roles from application connection strings; use read-only roles where possible.
Apply IP restrictions to production passwords and tokens, and private networking where the plan supports it.
Stream PlanetScale audit logs (API) and Aiven event logs to the SIEM, and alert on token leaked and password leaked events.
Add custom secret scanning patterns for Neon secrets in private repositories.
Write and rehearse a per-platform runbook: revoke token, rotate passwords on every branch or service, hunt for new roles and users.
Track metrics: time from alert to revocation, number of tokens without owners, share of automation on non-personal credentials, and secrets found per month.

Database platform tokens: Revoke, rotate and trace leaked PlanetScale, Neon and Aiven credentials