Scoped Tokens Do Not Retire Broad Credentials

Summary

Supabase now lets teams create personal access tokens scoped to specific organizations, projects and permissions. That gives an integration a smaller set of capabilities than a full-account token. The operational change is not automatic: existing broad tokens continue to work until they expire or are deleted, and a separate database-password connection is not constrained by the token’s scope.

Key Updates

• Scope the credential to the job. Supabase says token scoping is generally available and Dashboard-created tokens are scoped by default, though full-account tokens remain an option. A token can be limited by resource, permission and expiry, and its effective access is also bounded by the owner’s current role.
• Read-only is not a complete description of sensitivity. Supabase says the Dashboard’s Read-only preset includes permissions to read secrets such as API keys. For an integration needing only database reads, its example starts with No access and grants Database read. Even read access can expose sensitive data; the choice must match the task.
• Old access stays in place. Existing full-account tokens continue to function until expiry or deletion. Scope and permissions are fixed when a scoped token is created, so a change requires a replacement. Creating that replacement alone does not revoke the original.
• The access path matters. The current documentation says the CLI browser login creates a full-account token, while a Dashboard-scoped token can be supplied explicitly. Commands connecting with a database password are not limited by the personal access token’s permissions. The CLI command supabase link can also require additional read permissions, including access to API key secrets.

Why It Matters

A narrowly scoped token can reduce the consequences of a leaked credential, but only for requests governed by that token. The integration may still have an older token, a database password, or other credentials with different authority. A migration record should describe those paths rather than treating one new credential as proof that the entire workflow is constrained.

This is a practical extension of Tech Radar’s earlier coverage of task-scoped agent authority: the question here is how to move one existing integration from a standing broad credential to a narrower one without confusing a successful replacement with removal of the old access.

Builder Takeaway

Choose one non-production integration and map the exact resources and operations it needs. Create a replacement token with only those permissions and an appropriate expiry; in a safe environment, verify both an expected allowed operation and a deliberately out-of-scope request that should be denied. Check the integration for database passwords or other credentials that follow a different authorization path. After the replacement is deployed and its owners have verified the workflow, retire the old token through the normal credential process. Record the result and review any additional permissions requested by the workflow before granting them.