10 min read - Supabase Scoped Tokens: Replace Account-Wide CI Credentials

Supabase made scoped personal access tokens generally available on 6 October 2026. A day earlier, GitHub added secret-scanning patterns for Supabase OAuth and scoped personal access tokens. Teams can now find broad automation credentials, replace them with purpose-bound tokens and make leaks cheaper to contain.

This is more than an environment-variable swap. A token used by the CLI, a deployment workflow and an AI agent may look identical in a secrets store while carrying different authority. Map the consumers first or you risk breaking production work and recreating the same exposure under a new prefix.

For a startup or mid-market team, the goal is one identity per automated job, with an owner, a resource boundary and the fewest permissions that job can prove it needs.

The release changes the control plane

Supabase personal access tokens authenticate to the Management API and tools built on it, including the Supabase CLI and MCP server. The Supabase GA announcement says a scoped token can be limited to selected projects or organizations, granted read or read-write access per capability, and given an expiry of up to one year. Existing account-level tokens keep working until they expire or someone deletes them.

That last detail creates the migration task. Nothing automatically narrows an old token. Supabase's personal access token documentation states that a classic token carries the account holder's permissions across every organization and project they can reach, including projects they join later. A scoped token only narrows the user's existing access; it cannot grant rights the user does not have.

GitHub's 5 October changelog names two newly detected Supabase secret types: supabase_oauth_access_token and supabase_scoped_personal_access_token. This improves discovery, including historical rescans where the feature applies, but it does not identify which business process owns a token or whether its permission set is sensible. Detection is the alarm; the access model determines the damage.

Do not mix management tokens with project API keys

Teams often call every Supabase credential an "API key." That shorthand is dangerous during an incident. The credentials answer different questions and require different containment steps.

Supabase's API key guide documents this separation. Publishable keys are designed for public clients and depend on correct grants and Row Level Security. Secret keys belong only in controlled backend components and bypass Row Level Security. Neither is a personal access token for the Management API.

An incident runbook should start by classifying the credential. Rotating a publishable key while leaving an overbroad RLS policy in place solves the wrong problem. Removing a personal access token from Git history without revoking it leaves the management credential usable.

Build a consumer register before replacing anything

Start with current use, not the token list in a dashboard. Search CI secret names, deployment definitions, developer setup notes, scheduled jobs, local credential stores and MCP configuration. Do not print secret values during the search. Record metadata that lets an owner act without seeing the token itself:

Do not create one replacement token for "CI." A preview deployment that reads project settings, a release job that deploys an Edge Function and a nightly diagnostic agent do not need the same rights. Separate tokens make the blast radius legible and let you revoke one workflow without stopping the others.

Prove the smallest permission set

For each consumer, begin with the project boundary and read-only access. Add a capability only after a test shows the workflow cannot complete without it. Supabase documents the required permissions for Management API endpoints, CLI commands and MCP tools. For example, its current PAT guide says supabase link needs read access to Project Settings, API Keys and API Key Secrets. A later database command may use a separate database password, so the PAT's scope does not limit that connection.

Inventory every credential used in the full job, including database passwords, rather than checking only SUPABASE_ACCESS_TOKEN.

For unattended MCP use, follow the tighter path in the Supabase MCP documentation: bind the server to one project, enable read-only mode, restrict feature groups, and issue a scoped PAT containing only the permissions needed by the enabled tools. Supabase recommends interactive OAuth for normal hosted MCP use; a manual PAT is mainly for CI or clients that cannot complete the browser flow.

Keep approvals for write operations outside the model's discretion. A token boundary limits what an agent can attempt, while a reviewed change path decides what should happen. Our guide to cybersecurity controls for AI-assisted development covers the wider code, data and delivery boundary.

Migrate without hiding broken assumptions

Replace one consumer at a time:

1. Name the workflow owner and expected project, commands and write actions.
2. Create a separate scoped token with a short initial expiry and the smallest tested permission set.
3. Install it in the CI or secrets store without exposing its value in logs, arguments or generated files.
4. Run the workflow against a non-production target, then exercise its failure and rollback paths.
5. Switch the production consumer, verify one normal run, and delete the old account-level token.
6. Record the token owner, scope, storage location, creation date, expiry and revocation procedure.

Watch for implicit login behavior. Supabase says the browser flow for supabase login still creates an account-level token. In CI, pass the scoped value through SUPABASE_ACCESS_TOKEN or use supabase login --token; do not assume a successful login produced a narrow credential.

Keep the old token only through the cutover test. If the workflow cannot operate with a reasonable scope, document the missing permission or product constraint instead of quietly restoring classic access.

Turn a scanning alert into an incident record

GitHub says secret scanning examines Git history across branches and several collaboration surfaces, including pull requests, issues, discussions, wikis and secret gists. Availability differs by repository type and GitHub plan, as documented in the secret scanning overview. Confirm coverage rather than assuming every private repository has it.

When an alert arrives, assign an incident owner and treat the committed credential as compromised. GitHub's alert-resolution guidance calls for updating dependent services, replacing the credential and checking provider logs for unauthorized activity. Removing the string from the current branch does not revoke it, and GitHub does not automatically close an alert merely because the file changed.

Record where the token appeared, what it could reach, any unexpected use, and when consumers moved to a replacement. Revoke first when exposure is public or abuse is plausible. Do not rewrite shared Git history by default; revocation removes the credential's power without disrupting clones and references.

OWASP's Secrets Management Cheat Sheet adds the operational pieces scanners cannot supply: owner and lifecycle metadata, separate identities for CI jobs, constrained authorization, monitored use, rotation and explicit revocation. These controls turn a new detector into a repeatable response rather than another security inbox.

The decision for a small team

Migrate now if any persistent classic PAT sits in CI, an automation script or a manually authenticated MCP client. Begin with the easiest read-only consumer, learn the permission model there, then move deployment jobs with stronger testing and approval. Delete unused tokens rather than reproducing them with a narrower scope.

Pause a cutover when nobody owns the workflow or its other credentials remain unknown. Run a short discovery exercise instead of granting a permanent account-wide exception. Exceev's services approach connects technical assessment, engineering changes and handover for teams that need help with that work.

Before deleting the last broad token, verify these points:

• every active consumer has its own named identity and owner;
• each token reaches only the required project or organization;
• read-write permissions correspond to observed commands or tools;
• expiry and renewal have an owner and a tested path;
• scanning covers the repositories and collaboration surfaces you rely on;
• the incident runbook revokes credentials, checks activity and updates every consumer.

Scoped tokens reduce the cost of a mistake only when the old authority disappears. The migration is complete when a leaked workflow token can affect one known job and one known boundary, not when the dashboard shows a new token type.

Sources and limitations

We opened and reviewed every source below on 7 October 2026.

• Supabase's scoped PAT announcement establishes the GA date, scope controls, expiry and continued validity of existing tokens.
• Supabase's personal access token guide documents classic and scoped authority, CLI behavior, permissions and database credentials.
• Supabase's API key guide distinguishes public keys, secret keys, Row Level Security and management credentials.
• Supabase's MCP guide documents authentication, CI tokens, project scoping, read-only mode and feature restrictions.
• GitHub's detector announcement names the newly detected Supabase OAuth and scoped personal access token types.
• GitHub's secret scanning overview documents scan surfaces, rescans, availability and remediation.
• GitHub's alert-resolution guide documents the compromised-secret response and manual alert closure.
• The OWASP Secrets Management Cheat Sheet supplies independent guidance on inventory, CI identity, rotation and revocation.

We did not inspect a Supabase account, test the GA controls, run secret scanning against a repository or measure a migration. Product behavior, permission names, plan eligibility and detection coverage may change after the review date. The operating pattern above is not legal advice, a compliance finding or a security guarantee for Exceev or any client.