Supabase MCP Server: Unspoken Privilege Inversion Problem

The Supabase MCP server (Supabase MCP server) hands your AI assistant a master key to your entire database — and calls it a feature. The official Model Context Protocol implementation from Supabase connects AI assistants to your projects, enabling natural language interaction for database operations, schema management, migrations, Edge Function deployment, cost control, and log retrieval. That breadth is genuinely impressive. It’s also a security architecture that would make most CISOs break into a cold sweat.

Here’s the core tension I keep coming back to: Supabase has built one of the most capable MCP servers in the ecosystem, shipped enterprise-grade OAuth through the recent Enterprise-Managed Authorization stable release, and positioned itself as the default backend for AI-assisted development. Yet the default configuration still allows an AI agent to bypass every Row-Level Security policy you’ve configured and execute arbitrary SQL against your production database. The protocol-level authentication story has matured dramatically. The authorization model within the tools themselves hasn’t kept pace.

What the Supabase MCP Server Actually Does

The server organizes its capabilities into eight feature groups — Database, Debugging, Development, Edge Functions, Account Management, Branching, Knowledge Base, and Storage — with all groups except Storage enabled by default. You get execute_sql for running raw queries, apply_migration for schema changes, deploy_edge_function for pushing code, plus log retrieval, TypeScript type generation, and project management tools.

The hosted remote server at mcp.supabase.com uses OAuth 2.1 authentication, which means you’re not pasting API keys into your IDE config. CLI and self-hosted environments offer a limited tool subset without OAuth 2.1. In June 2026, Supabase also launched an official ChatGPT app integration providing 29 tools for database and backend management, available on all Supabase plans with paid ChatGPT subscriptions. They released a Plugin for AI Coding Agents that bundles the MCP server with agent skills for one-step setup in Claude Code, Cursor, Codex, and Gemini CLI.

Supabase has clearly invested heavily on the infrastructure side. The repository even transferred from supabase-community/supabase-mcp to supabase/mcp in June 2026, with mcp-server-supabase v0.8.2 released on June 5, 2026 — a signal that this is now a core product, not a community side project.

The Privilege Inversion Pattern

Supabase explicitly recommends configuring the MCP server in read-only mode and project-scoped mode because the default configuration uses service_role credentials that bypass Row-Level Security. That recommendation exists for good reason. Security researchers demonstrated that the Supabase MCP server can leak an entire SQL database through indirect prompt injection when using default service_role credentials, which bypass RLS, in a Cursor IDE environment.

Let me break down what that means in practice. Your Supabase project has three default roles: anon (for unauthenticated access), authenticated (for logged-in users), and service_role (for server-side operations). RLS policies restrict what anon and authenticated roles can see and modify. The service_role exists specifically to bypass RLS — it’s meant for trusted server-side code where you’ve already validated permissions in your application logic.

When you connect the MCP server without read-only mode, your AI assistant operates as service_role. Every RLS policy you’ve carefully crafted becomes irrelevant. An indirect prompt injection — hidden instructions in a support ticket, a malicious document, even a crafted database value — can convince the agent to execute_sql and dump every table in your database. The agent isn’t malicious. It’s just following instructions, and the instructions came from data it shouldn’t have treated as instructions.

This is what I call the privilege inversion: the MCP server creates a situation where AI agents operate with database credentials that bypass all Row-Level Security, enabling complete database exfiltration through indirect prompt injection, while the industry simultaneously standardizes authentication without addressing this fundamental authorization gap. EMA solves the “who can connect” problem beautifully. It doesn’t solve the “what can they do once connected” problem at all.

The Pricing Trap: Why $25 Isn’t the Real Number

Supabase markets the Pro plan at $25 per organization per month as the sweet spot for production apps. The plan includes $10 in compute credits, covering one Micro compute instance. That sounds reasonable until you look at what actually happens when you put a real workload behind it.

Compute is billed hourly, ranging from $0.01344/hr for Micro ($10/month) to $5.12/hr for 16XL ($3,730/month), with Small at $0.0206/hr ($15/month) and Medium at $0.0822/hr ($60/month). Edge Function invocations run $2 per million for usage exceeding plan quotas; Pro and Team plans include 2 million invocations per month. The Spend Cap, available only on the Pro plan, disables further usage of covered items after quota exhaustion — but doesn’t cover compute or explicitly opted-in services.

Independent analysis projects that a B2B SaaS with 30,000 monthly active users on the Pro plan typically incurs $150–$300 per month total when compute upgrades and egress overages are included. That’s a 6-12x multiplier on the advertised base price. The $25 Pro plan functions as a gateway drug: its “unlimited projects” and generous included quotas mask a cost structure where compute add-ons and egress overages typically multiply the base price 5-10x for production workloads.

For a concrete scenario: a 50-developer team running a single Supabase project on the Pro plan with Small compute (2 GB RAM, 90 connections) would pay $30/month [$25 Pro plan + $15 Small compute - $10 monthly credit], excluding egress, storage, and Edge Function overages. Add a second project, bump to Medium compute for production, serve enough data to exceed the 250 GB egress allowance, and costs escalate quickly.

Plan	Base Price	Typical Production Cost	What Changes
Free	$0	$0	Paused after 7 days inactivity; not for production
Pro	$25/org/month	$150–$300/month at 30K MAUs	Compute upgrades, egress overages, storage
Team	$599/org/month	$599+/month	SOC2, 14-day backups, priority support
Enterprise	Custom	Custom	Custom SLAs, compliance

The Spend Cap provides some protection against runaway bills from attacks or bugs, but it’s a blunt instrument — it cuts off service entirely rather than throttling, and it doesn’t cover compute. You’re either paying for overages or your users are hitting errors.

Enterprise Authentication vs. Authorization Reality

Supabase is a launch partner for MCP Enterprise-Managed Authorization (EMA), which reached stable status on June 18, 2026, enabling zero-touch OAuth provisioning through identity providers like Okta. This is genuinely valuable for enterprise adoption. Before EMA, onboarding 50 developers across 10 MCP servers meant 500 individual OAuth flows. Now an admin configures access once in Okta, and engineers inherit approved server access on first login.

But here’s the contradiction: EMA solves authentication at the organizational level — who can connect to which MCP server. It doesn’t address authorization within the tools themselves. Your developers can now seamlessly authenticate to the Supabase MCP server through corporate Okta. Once connected, they (or their AI agents) still operate as service_role with full database access unless you’ve manually configured read-only mode and project scoping.

The industry has standardized how enterprises authenticate to MCP servers. It hasn’t standardized what those servers can do once authenticated. Supabase’s aggressive positioning of MCP as an enterprise-ready solution while the default configuration allows complete database exfiltration represents a dangerous prioritization of growth and convenience over security. The company should mandate read-only mode and project-scoped access as non-negotiable defaults before marketing MCP to enterprises.

What You Should Actually Do

If you’re connecting the Supabase MCP server to your development workflow today, here’s the minimum viable security posture:

1. Always use project_ref scoping. Restrict the server to a single project. Without this, the server has access to every project in your organization.

2. Enable read-only mode unless you specifically need write access. The read_only flag runs every query as a read-only Postgres user. You can always spin up a separate MCP instance with write access for migration work.

3. Never connect the MCP server to a production database with write access. Use a development or staging branch. Supabase’s branching features require a paid plan, but they’re worth the cost for isolating AI agent access from production data.

4. Monitor your compute and egress usage from day one. The gap between advertised pricing and actual production costs catches most teams off guard. Set up billing alerts before you need them.

5. Treat AI agent access as you would a service account with elevated privileges. Because that’s exactly what it is.

For teams evaluating whether to build or buy their MCP integration, the calculus depends heavily on your scale and compliance requirements. If you’re a small team building an internal tool, the Supabase MCP server with proper scoping is probably sufficient. If you’re building customer-facing features that touch sensitive data, you’ll need to think carefully about the authorization model — and whether the current generation of MCP servers gives you enough granular control.

The Supabase MCP server is a remarkable piece of engineering that dramatically lowers the barrier to AI-assisted database management. But capability without appropriate guardrails isn’t a feature — it’s a liability waiting to be exploited. The industry needs to move faster on tool-level authorization standards before an indirect prompt injection incident makes the case for us.