Supabase MCP can leak your entire SQL database

CEO of General Analysis here (The company mentioned in this blogpost)

First, I want to mention that this is a general issue with any MCPs. I think the fixes Supabase has suggested are not going to work. Their proposed fixes miss the point because effective security must live above the MCP layer, not inside it.

The core issue that needs addressing here is distinguishing between data and instructions. A system needs to be able to know the origins of an instruction. Every tool call should carry metadata identifying its source. For example, an EXECUTE SQL request originating from your database engine should be flagged (and blocked) since an instruction should come from the user not the data.

We can borrow permission models from traditional cybersecurity—where every action is scoped by its permission context. I think this is the most promising solution.

I broadly agree that "MCP-level" patches alone won't eliminate prompt-injection risk. Latest research also shows we can make real progress by enforcing security above the MCP layer, exactly as you suggest [1]. DeepMind's CaMeL architecture is a good reference model: it surrounds the LLM with a capability-based "sandbox" that (1) tracks the provenance of every value, and (2) blocks any tool call whose arguments originate from untrusted data, unless an explicit policy grants permission.

[1] https://arxiv.org/pdf/2503.18813

> unless an explicit policy grants permission

Three months later, all devs have “Allow *” in their tool-name.conf

This seems like the most obvious solution.

"Just don't give the MCP access in the first place"

If you're giving it raw SQL access, then you need to make sure you have an appropriate database setup with user/actor scoped roles which I don't think is very common. Much more common the app gets a privileged service account