Support branch/environment-scoped access for Supabase MCP

[nannestad]

Feature request

The problem

Supabase MCP is currently scoped at the project level (project_ref), but Supabase environments are often managed through branches within a project (for example: main = production, development = development, staging = persistent staging, plus feature branches).

This creates a mismatch with the MCP security guidance. The MCP docs explicitly recommend not connecting the MCP server to production and state that it is designed for development and testing purposes. However, if MCP access is granted at the project level, there is currently no clear way to restrict the MCP to only safe non-production branches/environments within that project.

For teams using branch-based environments, this makes least-privilege access difficult:

• we want the AI tool to work against development/staging branches
• we do not want it to be able to access production
• but the current MCP model appears to treat the whole project as the access boundary

This feels at odds with the Supabase environment model based on branching.

Relevant docs:

• MCP guide: https://supabase.com/docs/guides/getting-started/mcp
• In particular, the guide recommends not connecting MCP to production, while MCP configuration is documented as project-scoped via project_ref.

Proposed solution

I would like MCP access controls that align with Supabase branching/environment workflows.

Possible solutions:

• allow MCP to be scoped to a specific branch/environment, not just a project
• allow an explicit denylist/allowlist for branches (for example: deny main, allow development and staging)
• allow tool permissions to vary by environment (for example: read-only on production, broader access on dev/staging)
• provide dashboard-level AI access policies that distinguish production from non-production environments

Any of these would make it much easier to follow the current recommendation to avoid production access while still using MCP in projects that rely on branch-based environments.

Currently alternatives

Current workarounds are not ideal:

• using a separate non-production project only for MCP access
• relying on read_only=true, which helps but does not fully solve the environment-separation problem
• trusting user/tool discipline not to target production branches
• disabling MCP entirely for projects that use branch-based environment separation

These workarounds either add operational overhead or do not provide a strong enough safety boundary.

Additional context

The request is mainly about aligning the MCP permission model with Supabase’s own branching/environment model and with the guidance in the MCP docs.

From the docs:

• MCP is documented as project-scoped via project_ref
• account tools are disabled in project-scoped mode
• branching tools exist
• the docs recommend not connecting MCP to production and say MCP is intended for development/testing

That combination suggests there is currently a gap between the recommended safe usage and the available access boundaries.

[gregnr]

Hey @nannestad sorry for the slow response! This is really good feedback, thank you. You're right - the current permission / scoping logic doesn't fit well into the branching lifecycle. We're currently working on fine-grain permission scoping that gives you control over which permissions are set during OAuth consent (including things like project - replacing the need for an explicit project_ref param). I'm wondering if branches are something we can also incorporate into this. Let me discuss further with the team and I'll follow up once we have a clearer idea on how this can all fit together.

[Ram9199]

@nannestad this branch/environment scoping request is exactly the kind of thing MCP permission models need to represent explicitly.

Project-level access is too coarse if main, staging, and feature branches have different blast radius. A runtime policy record could bind each tool call to:

• project ref
• branch/environment
• tool name
• required scope
• decision reason
• approval/delegation id if a broader action is allowed temporarily

That would let Supabase keep OAuth consent as the capability ceiling while still enforcing per-environment policy at execution time. We have been validating this capability-vs-runtime-decision split in Agent_Sudo: https://github.com/Kisyntra/Agent_Sudo