Oso posted a blog post [1] about this yesterday that's quite informative. I separated posted it on HN [2], but linking here.
[1] https://www.osohq.com/post/why-llm-authorization-is-hard [2] https://news.ycombinator.com/item?id=44509936
Supabase MCP can leak your entire SQL database
441–450 of 502 posts
Re: Supabase MCP can leak your entire SQL database
#442Earlier quoted context omitted.
Yes, the vast amount of effort, time and money spent on making the world secure things and checking that those things are secured now being dismissed because people can't understand that maybe LLMs shouldn't be used for absolutely everything.
Someone posted Google's new MCP for databases in Slack, and after looking at it, I pulled a quote about how you should use these things to modify the schema on a live database. It seems like not only do they want us to regress on security, but also IaC and *Ops I don't use these things beyond writing code. They are mediocre at that, soost def not going to hook them up to live systems. I'm perfectly happy to still pre…
> I pulled a quote about how you should use these things to modify the schema on a live database.
Agh.
I'm old enough to remember when one of the common AI arguments was "Easy: we'll just keep it in a box and not connect it to the outside world" and then disbelieving Yudkowsky when he role-played as an AI and convinced people to let him out of the box.
Even though I'm in the group that's more impressed than unimpressed by the progress AI is making, I still wouldn't let AI modify live anything even if it was really in the top 5% of software developers and not just top 5% of existing easy to test metrics — though of course, the top 5% of software developers would know better than to modify live databases.
Re: Supabase MCP can leak your entire SQL database
#443Earlier quoted context omitted.
You're overcomplicating a thing that is simple -- don't use in-band control signaling. It's been the same problem since whistling for long-distance, with the same solution of moving control signals out of the data stream. Any system where control signals can possibly be expressed in input data is vulnerable to escape-escaping exploitation. The same solution, hard isolation, instantly solves the problem: you have to r…
The problem is that the moment the interpreter is powerful enough, you're relying on the data not being good enough at convincing the interpreter that it is an exception. You can only maintain hard isolation if the interpreter of the data is sufficiently primitive, and even then it is often hard to avoid errors that renders it more powerful than intended, be it outright bugs all the way up to unintentional Turing com…
(I'll reply to you because you expressed it more succinctly)
Yes and no. I think this is exactly the distinction that's been institutionally lost in the last few decades, because few people are architecting from top (software) to bottom (physical transport) of the stack anymore.
They just try and cram functionality in the topmost layer, when it should leverage others.
If I lock an interpreter out of certain functionality for a given data stream, ever, then exploitation becomes orders of magnitude more difficult.
Dumb analogy: only letters in red envelopes get to change mail delivery times + all regular mail is packaged in green envelopes
Fundamentally, it's creating security contexts from things a user will never have access to.
The LLMs-on-top-of-LLMs filtering approach is lazy and statistically guaranteed to end badly.
Re: Supabase MCP can leak your entire SQL database
#444Supabase 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 t…
Co-founder of General Analysis here. Technically this is not a responsibility of Supabase MCP - this vulnerability is a combination of: 1. Unsanitized data included in agent context 2. Foundation models being unable to distinguish instructions and data 3. Bad access scoping (cursor having too much access) This vulnerability can be found almost everywhere in common MCP use patterns. We are working on guardrails for MC…
Good luck sanitizing code. This is an unfixable problem in transformer architecture and goes a long way past just blunt instructions
Re: Supabase MCP can leak your entire SQL database
#445Earlier quoted context omitted.
You're overcomplicating a thing that is simple -- don't use in-band control signaling. It's been the same problem since whistling for long-distance, with the same solution of moving control signals out of the data stream. Any system where control signals can possibly be expressed in input data is vulnerable to escape-escaping exploitation. The same solution, hard isolation, instantly solves the problem: you have to r…
> You're overcomplicating a thing that is simple -- don't use in-band control signaling. On the contrary, I'm claiming that this "simplicity" is an illusion. Reality has only one band. > It's been the same problem since whistling for long-distance, with the same solution of moving control signals out of the data stream. "Control signals" and "data stream" are just... two data streams. They always eventually mix. > Th…
(Broad reply upthread)
Is it more difficult to hijack an out-of-band control signal or an in-band one?
That there exist details to architecting full isolation well doesn't mean we shouldn't try.
At root, giving LLMs permissions to execute security sensitive actions and then trying to prevent them from doing so is a fool's errand -- don't fucking give a black box those permissions! (Yes, even when every test you threw at it said it would be fine)
LLMs as security barriers is a new record for laziest and stupidest idea the field has had.
Re: Supabase MCP can leak your entire SQL database
#446Earlier quoted context omitted.
I don't think anyone has a cohesive definition of "agent", and I wish tptacek hadn't used the term "agent" when he said "agent code", but I'll at least say that I now feel confident that I understand what tptacek is saying (even though I still don't think it will work, but we at least can now talk at each other rather than past each other ;P)... and you are probably best off just pretending neither of us ever said "a…
"agent", to me, is shorthand for "an LLM acting in a role of an agent". "agent code" means, to me, the code of the LLM acting in a role of an agent. Are we instead talking about non-agent code? As in deterministic code outside of the probabilistic LLM which is acting as an agent?
What does "acting in a role of an agent" mean?
You appear to be defining agent by using the word agent, which doesn't clear anything up for me.
Re: Supabase MCP can leak your entire SQL database
#447Earlier quoted context omitted.
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 produc…
Add another LLM step first. I don't understand why companies would pass user input straight into the support bot without first running the input through a classification step? In fact, run it through multiple classifier steps, each a different model with different prompts. Something like: - You are classifier agent screening questions for a support agent. - The support agent works for a credit card company. - Your jo…
Using LLMs to filter requests to LLMs is a flawed strategy because the filtering LLM can itself be tricked by a specially crafted prompt injection. Here's an example of that from 2022: https://simonwillison.net/2022/Sep/12/prompt-injection/#more...
Re: Supabase MCP can leak your entire SQL database
#448Earlier quoted context omitted.
Database providers do just throw a postgres prompt at developers though, right? And that is what Supabase is – an infra provider.
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?
Re: Supabase MCP can leak your entire SQL database
#449Earlier quoted context omitted.
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.
Re: Supabase MCP can leak your entire SQL database
#450Earlier quoted context omitted.
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 produc…
The main problem seems to me to be related to the ancient problem of escape sequences and that has never really been solved. Don't mix code (instructions) and data in a single stream. If you do sooner or later someone will find a way to make data look like code.
There is no technical problem with escape sequences if all consumers/generators use the same logic/standard...
The problem is when some don't and skip steps (like failing to encode or not parsing properly).