Supabase scoped personal access tokens went GA Oct. 6. The MCP server now checks token permissions, closing the gap that left AI agents on full-access tokens.
Supabase made scoped personal access tokens generally available on Oct. 6. The Supabase MCP server now enforces a token’s permissions, closing the gap that mattered most during the alpha (Supabase changelog, Oct. 6, 2026).
What changed since the alpha #
Firerun reported on Aug. 18 that scoped tokens did not yet work with MCP. Anyone connecting an AI agent still had to hand over a full-access token. Per the GA changelog, each MCP tool call now checks the token’s permissions, and the dashboard’s token detail view lists which tools a given token can call.
The rest of the design is as it was in the alpha. A token covers selected projects in one organization, or all projects in selected organizations. Each capability, such as projects, database, auth or storage, is read or read-write. Expiry runs to a custom date up to one year out. A review step shows the granted access and a risk level. The token value appears once.
Where it applies #
- Management API: scoped tokens work on all
/v1and/v2endpoints. A 403 response lists what was missing in amissing_permissionsarray. - CLI:
supabase login --tokenor theSUPABASE_ACCESS_TOKENvariable. Browser login still creates an account-level token.supabase whoamidoes not work with scoped tokens. - SQL: queries run read-only unless the token has Database read-write. Revealing secret API keys needs the API Key Secrets permission.
A token never exceeds its owner’s access. Each request checks the owner’s current role. Lose access to a project and the token loses it too. Scopes still can’t be edited after creation. Changing one means deleting the token and minting another.
Nothing is revoked #
Supabase said no existing token is being revoked. Account-level tokens work until they expire or are deleted. GitHub secret scanning detects both kinds. Supabase recommends replacing account-level tokens with scoped ones carrying only what each integration needs.
The take #
The alpha was a security feature with a hole exactly where the risk is growing: agents. An MCP client acts with less supervision than a person at a terminal, and until this release the only way to give one Supabase access was a token that could touch every project on the account. That is fixed.
What is not fixed is the default. Legacy tokens stay available. The dashboard still offers them behind “Create legacy token.” Teams wiring up agents should set a short expiry and grant read-only on the project in question. Delete the old account-level token after the replacement works. Scopes can’t be edited, so expect to repeat this.