Supabase MCP can leak your entire SQL database

Serious question here, not trying to give unwarranted stress to what is no doubt a stressful situation for the supabase team, or trying to create flamebait.

This whole thing feels like its obviously a bad idea to have an mcp integration directly to a database abstraction layer (the supabase product as I understand it). Why would the management push for that sort of a feature knowing that it compromises their security? I totally understand the urge to be on the bleeding edge of feature development, but this feels like the team doesn't understand GenAi and the way it works well enough to be implementing this sort of a feature into their product... are they just being too "avant-garde" in this situation or is this the way the company functions?

I have no association with Supabase, but in their defense, apart from adding a caution note, there's nothing else that Supabase needs to do, from my perspective.

As far as I am concerned, this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions while developing their system.

This.

As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it?

edit: keeping in mind the use cases they are pushing in their documentation are for local development

This is developers using a developer feature that makes perfect sense with developer databases in developer environments, but in prod. That is a story as old as COBOL.

It’s one of European civilization’s biggest issues; being far too concerned with doing things, before ever even considering whether those things should be done that way, or at all.

> this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions

Just like SQL injection attacks aren't something to worry about, right?

Have we learned nothing from three decades of internet security experience? Really? Yes. It seems we've learned nothing. I weep for the future.

Database still support RAW queries. So, yeah developer are responsible for proper usage of the tools.

There are whole ecosystems of tools designed around the need to isolate queries, though. You don't just throw a Postgres prompt at your developers and tell them to be careful, because if you do little Bobby Tables pwns your stuff.

We know this is how this works. We lived through it. Why on earth do you think the results will be any different this time?

Database providers do just throw a postgres prompt at developers though, right? And that is what Supabase is – an infra provider.

Yes this. First thing I thought — don’t even have the prod credential anywhere near my machine

I literally cannot believe the hysteria around what is obviously a development tool.

Are we also getting up in arms that [insert dev tool of choice] has full access to your local database? No, we aren't.

I've always taken these types of MCPs tools to be a means of enabling LLMs to more effectively query your DB to debug it during development.

I think it's a flaw in end-user MCP combined with agentic, where the end-user chooses the combination of tools. Even if the end-user is in an IDE.

The trouble is you can want an MCP server for one reason, flip it on, and a combination of the MCP servers you enabled and that you hadn't thought of suddenly breaks everything.

We need a much more robust deterministic non-LLM layer for joining together LLM capabilities across multiple systems. Or else we're expecting everyone who clicks a button in an MCP store to do extremely complex security reasoning.

Is giving an LLM running in an agentic loop every combination of even these vetted Microsoft MCP servers safe? https://code.visualstudio.com/mcp It seems unlikely.

Reflecting on this whole situation, I suspect MCP is fundamentally insecure, in which case Supabase should refuse to implement it.

MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem.

Supabase's response (in the top comment in this post) of making it read-only or trying to wrap with an LLM to detect attacks... Neither of those help the fundamental problem at all. Some other tool probably has write capabilities, and the wrapping isn't reliable.

> MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem.

That's exactly the problem here: the ability for end users to combine MCP tools means that those end users are now responsible for avoiding insecure tool combinations. That's a really hard thing for end users to do - they have to understand the lethal trifecta risk in order to make those decisions.

That's an argument, I guess, for absolving Supabase for explicit responsibility for the resulting hilarity. It's not an argument that MCP prompt hacking is "not a serious security hole", which is the point I responded to upthread.

It's only a security hole if you give access to users though, right? If you are the one using the Supabase MCP, how is it any different than any other root access to a DB?

Because of lethal trifecta attacks: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

If you are the person using the LLM tool, a prompt injection attack in a database row that you are allowed to view could trick your LLM tool into taking actions that you don't want it to take, including leaking other data you are allowed to see via writing to other tables or using other MCP tools.