←back to thread

779 points rexpository | 2 comments | | HN request time: 0.533s | source
Show context
gregnr ◴[] No.44503146[source]
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

replies(31): >>44503188 #>>44503200 #>>44503203 #>>44503206 #>>44503255 #>>44503406 #>>44503439 #>>44503466 #>>44503525 #>>44503540 #>>44503724 #>>44503913 #>>44504349 #>>44504374 #>>44504449 #>>44504461 #>>44504478 #>>44504539 #>>44504543 #>>44505310 #>>44505350 #>>44505972 #>>44506053 #>>44506243 #>>44506719 #>>44506804 #>>44507985 #>>44508004 #>>44508124 #>>44508166 #>>44508187 #
IgorPartola ◴[] No.44503439[source]
> Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2]

I genuinely cannot tell if this is a joke? This must not be possible by design, not “discouraged”. This comment alone, if serious, should mean that anyone using your product should look for alternatives immediately.

replies(2): >>44503731 #>>44504247 #
Spivak ◴[] No.44503731[source]
Here's a tool you can install that grants your LLM access to <data>. The whole point of the tool is to access <data> and would be worthless without it. We tricked the LLM you gave access to <data> into giving us that data by asking it nicely for it because you installed <other tool> that interleaves untrusted attacker-supplied text into your LLMs text stream and provides a ready-made means of transmitting the data back to somewhere the attacker can access.

This really isn't the fault of the Supabase MCP, the fact that they're bothering to do anything is going above and beyond. We're going to see a lot more people discovering the hard way just how extremely high trust MCP tools are.

replies(1): >>44505105 #
1. saurik ◴[] No.44505105[source]
Let's say I use the Supabase MCP to do a query, and that query ever happens to return a string from the database that a user could control; maybe, for example, I ask it to look at my schema, figure out my logging, and generate a calendar of the most popular threads from each day... that's also user data! We store lots of user-controlled data in the database, and we often make queries that return user-controlled data. Result: if you ever do a SELECT query that returns such a string, you're pwned, as the LLM is going to look at that response from the tool and consider whether it should react to it. Like, in one sense, this isn't the fault of the Supabase MCP... but I also don't see many safe ways to use a Supabase MCP?
replies(1): >>44506105 #
2. ImPostingOnHN ◴[] No.44506105[source]
I'm not totally clear here, but it seems the author configured the MCP server to use their personal access token, and the MCP server assumed a privileged role using those credentials?

The MCP server is just the vector here. If we replaced the MCP server with a bare shim that ran SQL queries as a privileged role, the same risk is there.

Is it possible to generate a PAT that is limited in access? If so, that should have been what was done here, and access to sensitive data should have been thus systemically denied.

IMO, an MCP server shouldn't be opinionated about how the data it returns is used. If the data contains commands that tell an AI to nuke the planet, let the query result fly. Could that lead to issues down the line? Maybe, if I built a system that feeds unsanitized user input into an LLM that can take actions with material effects and lacks non-AI safeguards. But why would I do that?