Skip to content

NerdlystTech · Markets · Code

Supabase MCP Server: Your App’s RLS Now Guards Every AI Agent

Padlock on a laptop keyboard symbolising Supabase MCP server security for AI agents
Photo by Sasun Bughdaryan on Unsplash

Supabase now lets you give your own app a Supabase MCP server, so your customers can use it from ChatGPT or Claude by signing in with the account they already have. The clever part: every tool call runs as that signed-in user, so the Row Level Security rules you already wrote decide what each AI agent can see.

Supabase published the details on 22 October 2026, following its Supabase Select conference. Here is how it works, what you have to set up, and where it can still go wrong.

Key takeaways

  • A new MCP Server block in the Supabase Library adds a ready-made server to your project as an Edge Function that you own and can change.
  • Supabase Auth’s OAuth 2.1 server handles sign-in and consent, then issues each agent a token tied to one real user.
  • Tools query Postgres with a client scoped to that user, so you don’t need a service role key and your existing RLS policies still apply.
  • Tools can also return interactive UI inside the chat through the MCP Apps extension.
  • Agent sign-ins count toward your monthly active users, but several agents acting for one person count as one MAU.

What is a Supabase MCP server, exactly?

MCP, the Model Context Protocol, is the open standard AI assistants use to call outside tools. An MCP server is a list of actions such as “list my open tasks” or “create an invoice” that a chatbot can trigger for you.

Until now, Supabase’s own MCP server was mostly for developers, letting coding agents manage your database. The new announcement from Raul Barroso, Greg Richardson and Saxon Fletcher is different. It is for your end users. Your product gets its own server, and your customers reach it from the chat app they already use.

Think of it as adding a second front door to your app. The website is one door and the chatbot is the other, but both lead to the same rooms with the same locks.

How does the sign-in flow keep agents honest?

The flow follows OAuth 2.1, the current version of the standard that “Sign in with Google” buttons use. Here is what happens when someone adds your server to Claude or ChatGPT:

  1. The MCP client starts with your server’s URL. Middleware points it to your project’s OAuth server.
  2. The user signs in through your app and approves the client on a consent page that you host.
  3. Supabase Auth issues an access token for that user, and the client sends it with every tool call.
  4. A helper called withOAuthProtectedResource() handles discovery and sends an OAuth challenge when a request arrives with no token.
  5. withSupabase({ auth: 'user' }) checks the token and gives your tool a database client scoped to that user. Postgres then applies RLS.

RLS, or Row Level Security, is a Postgres feature that filters rows per user at the database level. If your policy says “users only see their own todos”, an agent holding Alice’s token physically cannot read Bob’s rows, however cleverly someone words a prompt.

Opinion: this is the right default. Most MCP security trouble starts when a server holds one powerful key and trusts the model to behave. Pushing the check down into the database removes that trust problem.

What do you need to set up?

The starting command is npx shadcn@latest add https://supabase.com/library/r/mcp.json. It copies an Edge Function into supabase/functions/mcp with an MCP handler, auth middleware, a whoami tool for checking identity and a tools/index.ts file where you register tools. The pieces compare like this:

PieceWhat it does
MCP Server blockGenerates the server code you own and edit
Supabase Auth OAuth 2.1 serverRuns sign-in, consent and token issuing
@supabase/serverGives each tool a user-scoped Supabase client
@supabase/middlewareChains request middleware with pipeline
Official MCP TypeScript SDKHandles the protocol and tool registration
ZodDefines and validates tool inputs

On the project side, you switch to asymmetric signing keys, enable the OAuth 2.1 server and, if you want clients to register themselves, turn on dynamic client registration. You also add the OAuth Consent block to your frontend, point the Auth Site URL at it and set verify_jwt = false for the function in config.toml. That last step sounds alarming. It is needed because discovery requests arrive without a token, and the middleware does the real check.

Supabase’s MCP authentication guide adds some fine print. Authorization codes expire after 10 minutes, redirect URIs must match exactly and refresh tokens rotate automatically. It also warns that open dynamic registration lets any MCP client sign up, so you should watch registrations and validate redirect URIs.

What can a tool actually do?

Supabase’s example is a list_open_tasks tool. It reads an RLS-protected todos table, returns up to 20 unfinished tasks and carries a readOnlyHint annotation so clients know it changes nothing.

Tools can also call database functions, trigger other Edge Functions or hit your existing APIs. Supabase’s advice is to keep business rules in that shared code, so the chatbot and the website never drift apart.

The showcase is Sizzle, a demo app that turns product photos into video ads. From ChatGPT or Claude, a customer can list products and generate an ad. Using MCP Apps, the official extension Anthropic and OpenAI co-developed for in-chat interfaces, ChatGPT shows a product card with a video player built from the web app’s own React components.

Who should use this, and what are the catches?

If you run a SaaS on Supabase and customers ask “can I do this from ChatGPT?”, this is the shortest route so far. For agent-first products, there is also a Headless App block with browser sign-in, example task tools and an RLS-protected database.

The catches are real, though:

  • Your RLS has to be good. The model only works if your policies are tight. A sloppy policy now leaks through a chatbot too. Supabase’s troubleshooting notes even suggest checking that policies account for the MCP client’s client_id.
  • UI depends on the client. MCP Apps rendering varies by chat app. Plan for a plain-text fallback.
  • MAUs add up. There is no separate MCP charge, but agent sign-ins count toward monthly active users.

Before you ship, run the server through a checker like the one in our QAmcp explainer, and work through our 7-point AI agent checklist.

What happens next

The helpers aren’t tied to Supabase Edge Functions. They work with standard Web Request and Response handlers, including Cloudflare Workers, and with other MCP libraries. You just set the public MCP URL and the Supabase Auth URL yourself.

The bigger trend is clear. Apps are getting a second interface built for agents, much like the 100,000 Commerce.com stores now exposed through WebMCP. Expect more backend platforms to bundle OAuth, consent screens and MCP scaffolding together, and expect the security bar to rise with them.

FAQ

Do I need the service role key for a Supabase MCP server?

No. The @supabase/server helpers give each tool a client scoped to the signed-in user, so queries run under that user’s RLS policies instead of bypassing them.

Which AI apps can connect to it?

Any MCP client that supports OAuth, including ChatGPT and Claude. Interactive MCP Apps UI depends on the client, and Supabase’s demo shows it in ChatGPT.

Does it cost extra?

Supabase lists no separate MCP authentication fee, but agent sign-ins count toward monthly active users. Several agents acting for the same person count as one MAU.

Next step: pick one read-only query your users run all the time, wrap it as your first tool and test it as two different accounts before you add anything that writes data.

1 comment

Leave a Reply