Supabase Scoped Access Tokens Reach GA, and MCP Now Honors Them

Supabase made scoped personal access tokens generally available on Oct. 6, and the Supabase MCP server now checks each token's permissions on every tool call, closing the gap that during the alpha forced anyone connecting an AI agent to hand over a full-access token. Scoped tokens cover selected projects in one organization or all projects in selected organizations, with each capability such as projects, database, auth or storage set to read or read-write and expiry up to one year out; Supabase said no existing token is being revoked and recommends replacing account-level tokens with scoped ones. A 403 response on the Management API's /v1 and /v2 endpoints lists what was missing in a missing_permissions array, and scopes still cannot be edited after creation, so changing one means deleting the token and minting another.

Supabase Scoped Access Tokens Reach GA, and MCP Now Honors Them 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 https://supabase.com/changelog/scoped-personal-access-tokens-ga . 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 /v1 and /v2 endpoints. A 403 response lists what was missing in a missing permissions array. - CLI: supabase login --token or the SUPABASE ACCESS TOKEN variable. Browser login still creates an account-level token. supabase whoami does 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.