Supabase personal access tokens can now be scoped to one project
Scoped PATs limit a token to specific projects or permissions instead of full account access, and are now the default when you create one in the dashboard.
Supabase personal access tokens can now be scoped to specific projects or organisations, rather than inheriting everything the account holder can do. The feature went generally available on 6 October.
Until now, every personal access token (PAT) carried full account-level access: anything its creator could do in the dashboard, across every project and organisation they belonged to. A scoped token instead grants read or read-write permissions per capability (database, auth, storage, and so on), limited to chosen projects or organisations, with an expiry of up to a year. Creating one now shows a review step listing the exact access being granted and a risk level. Scoped tokens work with the Management API, the CLI (supabase login --token or SUPABASE_ACCESS_TOKEN), and the Supabase MCP server, which checks each tool call against the token’s permissions. They’re now the default when you create a new token in the dashboard, and existing account-level tokens keep working until they expire or are deleted.
supabase login --token sbp_scoped_xxxxxxxxWhy it matters: PATs increasingly end up in CI pipelines and MCP servers wired into coding agents, which multiplies the places a leak or a misfiring agent can do damage. A scoped token limits that to one project’s database or logs, rather than every project in your account.