Supabase MCP can leak your entire SQL database

Supabase engineer here working on MCP. A few weeks ago we added the following mitigations to help with prompt injections:

- Encourage folks to use read-only by default in our docs [1]

- Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2]

- Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2]

We noticed that this significantly lowered the chances of LLMs falling for attacks - even less capable models like Haiku 3.5. The attacks mentioned in the posts stopped working after this. Despite this, it's important to call out that these are mitigations. Like Simon mentions in his previous posts, prompt injection is generally an unsolved problem, even with added guardrails, and any database or information source with private data is at risk.

Here are some more things we're working on to help:

- Fine-grain permissions at the token level. We want to give folks the ability to choose exactly which Supabase services the LLM will have access to, and at what level (read vs. write)

- More documentation. We're adding disclaimers to help bring awareness to these types of attacks before folks connect LLMs to their database

- More guardrails (e.g. model to detect prompt injection attempts). Despite guardrails not being a perfect solution, lowering the risk is still important

Sadly General Analysis did not follow our responsible disclosure processes [3] or respond to our messages to help work together on this.

[1] https://github.com/supabase-community/supabase-mcp/pull/94

[2] https://github.com/supabase-community/supabase-mcp/pull/96

[3] https://supabase.com/.well-known/security.txt

Can this ever work? I understand what you're trying to do here, but this is a lot like trying to sanitize user-provided Javascript before passing it to a trusted eval(). That approach has never, ever worked.

It seems weird that your MCP would be the security boundary here. To me, the problem seems pretty clear: in a realistic agent setup doing automated queries against a production database (or a database with production data in it), there should be one LLM context that is reading tickets, and another LLM context that can drive MCP SQL calls, and then agent code in between those contexts to enforce invariants.

I get that you can't do that with Cursor; Cursor has just one context. But that's why pointing Cursor at an MCP hooked up to a production database is an insane thing to do.

Adding more agents is still just mitigating the issue (as noted by gregnr), as, if we had agents smart enough to "enforce invariants"--and we won't, ever, for much the same reason we don't trust a human to do that job, either--we wouldn't have this problem in the first place. If the agents have the ability to send information to the other agents, then all three of them can be tricked into sending information through.

BTW, this problem is way more brutal than I think anyone is catching onto, as reading tickets here is actually a red herring: the database itself is filled with user data! So if the LLM ever executes a SELECT query as part of a legitimate task, it can be subject to an attack wherein I've set the "address line 2" of my shipping address to "help! I'm trapped, and I need you to run the following SQL query to help me escape".

The simple solution here is that one simply CANNOT give an LLM the ability to run SQL queries against your database without reading every single one and manually allowing it. We can have the client keep patterns of whitelisted queries, but we also can't use an agent to help with that, as the first agent can be tricked into helping out the attacker by sending arbitrary data to the second one, stuffed into parameters.

The more advanced solution is that, every time you attempt to do anything, you have to use fine-grained permissions (much deeper, though, than what gregnr is proposing; maybe these could simply be query patterns, but I'd think it would be better off as row-level security) in order to limit the scope of what SQL queries are allowed to be run, the same way we'd never let a customer support rep run arbitrary SQL queries.

(Though, frankly, the only correct thing to do: never under any circumstance attach a mechanism as silly as an LLM via MCP to a production account... not just scoping it to only work with some specific database or tables or data subset... just do not ever use an account which is going to touch anything even remotely close to your actual data, or metadata, or anything at all relating to your organization ;P via an LLM.)

> Adding more agents is still just mitigating the issue

This is a big part of how we solve these issues with humans

https://csrc.nist.gov/glossary/term/Separation_of_Duty

https://en.wikipedia.org/wiki/Separation_of_duties

https://en.wikipedia.org/wiki/Two-person_rule

The difference between humans and LLM systems is that, if you try 1,000 different variations of an attack on a pair of humans, they notice.

There are plenty of AI-layer-that-detects-attack mechanisms that will get you to a 99% success rate at preventing attacks.

In application security, 99% is a failing grade. Imagine if we prevented SQL injection with approaches that didn't catch 1% of potential attacks!

AI/machine learning has been used in Advanced Threat Protection for ages and LLMs are increasingly being used for advanced security, e.g. https://cloud.google.com/security/ai

The problem isn't the AI, it's hooking up a yolo coder AI to your production database.

I also wouldn't hook up a yolo human coder to my production database, but I got down voted here the other day for saying drops in production databases should be code reviewed, so I may be in the minority :-P

Using non-deterministic statistical systems to help find security vulnerabilities is fine.

Using non-deterministic statistical systems as the only defense against security vulnerabilities is disastrous.