Supabase Finally Lets You Scope a Personal Access Token

Supabase began rolling out scoped personal access tokens to alpha users on August 10, 2026, according to a changelog post from the Supabase team published August 4. Until now, every Supabase PAT carried the same blast radius: full control of the account that minted it, including every organization and project on it, with no way to narrow that down.

---

What shipped

Creating a scoped token now means choosing what it can touch before it exists. Access can be limited to selected projects within one organization, or to every project across selected organizations. Within that boundary, permissions are granted per capability, projects, database, auth, storage and more, each as read or read-write, rather than as one bundled all-or-nothing grant. Expiry is required, with presets or a custom date up to a year out. Before a token is created, a review screen shows the resulting access level and a risk assessment.

The tradeoff is rigidity: scopes are fixed at creation. Widening or narrowing a token’s access later means deleting it and generating a new one, not editing it in place. Existing full-access tokens keep working exactly as before; Supabase says they’re “discouraged” going forward but isn’t forcing a migration. One gap the team has flagged itself: scoped tokens don’t yet work with the Supabase MCP server, so anyone connecting an AI agent through MCP still needs a legacy, full-access token for that specific use case.

Why it matters: the account-wide blast radius was a known complaint

The request predates the feature by nearly three years. An October 2023 GitHub issue, tagged to Supabase’s own core team, asked for exactly this: the ability to generate a token scoped to a single org or project instead of the whole account. Supabase’s own token-creation UI has long carried a version of the warning “personal access tokens can be used to control your whole account… be careful when sharing them,” a risk for any team that pastes a PAT into a CI secret, a local .env file or a third-party integration. A single leaked full-access token has meant a leaked account; scoping caps what a compromised token can actually reach.

The take

This is a security feature shipped later than it should have been, and Supabase’s own alpha notes concede as much by pointing back at the years-old ask. The design is sound: least-privilege by default, an explicit risk review before creation, and a non-breaking rollout that leaves existing tokens alone. The MCP gap is the one to watch, since MCP-connected agents are exactly the kind of automated, less-supervised client a scoped token exists to contain, and until that’s closed, teams wiring up AI tooling are stuck choosing between MCP support and least privilege. Turn it on for CI and integration tokens now. Anything that needs MCP still means a legacy token, for the moment.