Should my AI coding agent use a scoped Supabase access token?
Yes. Since scoped personal access tokens became generally available (Supabase's changelog entry is dated Oct 6, 2026), you can give the token your coding agent uses for the Supabase MCP server or CLI one project, only the permissions its job needs, and an expiry. Supabase's own docs say: "We recommend scoping every token, especially tokens for AI agents, automation scripts, and CI environments."
The token to replace is a full-access one. The Dashboard marks those with a Legacy badge, and per Supabase a full-access token "carries every permission on every organization and project you belong to, including ones you create or join later."
What changed
Tokens you create in the Dashboard are now scoped by default: resources (selected projects in one organization, or all projects in selected organizations), read or read-write per permission, and an expiry up to one year out.
Full-access tokens still work and can still be created ("Create legacy token"). Supabase isn't revoking or deprecating them; each works until it expires or you delete it.
The browser flow of supabase login still creates a full-access token. Supabase says it is changing that, but until then a CLI session your agent inherited from your login has your whole account.
A token never has more access than your own account: every request checks your current role as well as the token's scope.
Build the agent's token
On your access tokens page, create a token scoped to the one project the agent works on.
Start from the No access preset, then turn on only what the job needs. For an agent that inspects tables, generates types and runs read-only SQL, that is Database: Read. Supabase's blog advises against the "Read-only" preset here, because it includes secrets such as API keys.
Set an expiry that matches the work. Supabase: "If the agent's work is done in a week, its token should be too."
Read the review screen: it lists the Management API endpoints and MCP tools each permission unlocks, and rates the token Low, Medium or High risk. Copy the value; it is shown once, and scope can't be edited later (make a new token instead).
Put it where the agent reads it: the token your MCP client config passes to the Supabase MCP server, or SUPABASE_ACCESS_TOKEN for the CLI (it overrides a saved login). Then check that the scope bites. A read inside the scope should work and anything outside it should return 403:
The first should print 200 and the second 403. Over MCP, a SQL write with Database: Read fails with a Postgres permission error, and apply_migration needs its own Migrations read-write permission.
Find and retire full-access tokens
On the access tokens page, look for the Legacy badge. Each one reaches every project in your account, including projects created after the token.
Scoped tokens start with sbp_fc. A Supabase token in an agent config, .env file or CI secret that doesn't start with sbp_fc is worth looking up on that page.
For each one: create a scoped replacement for the tool that uses it, swap it in, confirm the tool still works, then delete the old token.
Keep in mind what scoping doesn't cover: CLI database commands that connect with SUPABASE_DB_PASSWORD aren't limited by the token's permissions, and the project's secret (service_role) key still bypasses Row Level Security wherever it is used.
Ship Check Kit · $29
Rather not run it by hand?
A scoped token limits what your agent can do to Supabase. The Ship Check Kit checks what the app it built lets everyone else do: SC-RLS-02 probes what the public key can read, SC-RLS-04 whether users can edit their own plan or role, and SC-SEC-01 and SC-SEC-02 look for secrets in git history and the browser bundle. Four of 44 launch checks, each with the evidence and the fix.
