Most active commenters
  • nurettin(3)

←back to thread

786 points rexpository | 21 comments | | HN request time: 1.06s | source | bottom
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(32): >>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 #>>44512202 #
tptacek ◴[] No.44503406[source]
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.

replies(11): >>44503684 #>>44503862 #>>44503896 #>>44503914 #>>44504784 #>>44504926 #>>44505125 #>>44506634 #>>44506691 #>>44507073 #>>44509869 #
1. LambdaComplex ◴[] No.44504926[source]
Right? "Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data?" The entire point of programming is that (barring hardware failure and compiler bugs) the computer will always do exactly what it's told, and now progress apparently looks like having to "discourage" the computer from doing things and hoping that it listens?
replies(3): >>44506071 #>>44508125 #>>44511375 #
2. skinner927 ◴[] No.44506071[source]
Microsoft’s cloud gets hacked multiple times a year, nobody cares. Everyone is connecting everything together. Business people with no security training/context are “writing” integrations with Lego-like services (and now LLMs). Cloudflare hiccups and the Internet crashes.

Nobody cares about the things you’re saying anymore (I do!!). Extract more money. Move faster. Outcompete. Fix it later. Just get a bigger cyber incident insurance policy. User data doesn’t actually matter. Nobody expects privacy so why implement it?

Everything is enshitified, even software engineering.

replies(3): >>44506197 #>>44507237 #>>44507424 #
3. nurettin ◴[] No.44506434{3}[source]
> Capitalist incentivized

And what's the alternative here?

replies(4): >>44506564 #>>44507338 #>>44507397 #>>44508168 #
4. noduerme ◴[] No.44506564{4}[source]
Longer term thinking.
replies(2): >>44506722 #>>44507274 #
5. reddalo ◴[] No.44507237[source]
>Microsoft’s cloud gets hacked multiple times a year

What cloud? Private SharePoint instances? Accounts? Free Outlook accounts?

Do you have any source on this?

replies(2): >>44508089 #>>44509188 #
6. nurettin ◴[] No.44507274{5}[source]
Reinvesting and long term thought isn't orthogonal.
7. bakuninsbart ◴[] No.44507338{4}[source]
Rewriting the cloud in Lisp.

On a more serious note, there should almost certainly be regulation regarding open weights. Either AI companies are responsible for the output of their LLMs or they at least have to give customers the tools to deal with problems themselves.

"Behavioral" approaches are the only stop-gap solution available at the moment because most commercial LLMs are black boxes. Even if you have the weights, it is still a super hard problem, but at least then there's a chance.

8. benreesman ◴[] No.44507397{4}[source]
The alternative to mafia capitalism in the grips of what Trading/Finance/Crypto Twitter calls `#CrimeSeason` is markets refereed by competent, diligent, uncorrupted professionals and public servants: my go-to example is Brooksley Born because that's just such a turning point in history moment, but lots of people in important jobs want to do their jobs well, in general cops want to catch criminals, in general people don't like crime season.

But sometimes important decisions get made badly (fuck Brooksley Born, deregulate everything! This Putin fellow seems like a really hard worker and a strong traditional man.) based on lies motivated by greed and if your society gets lazy about demanding high-integrity behavior from the people it admits to leadership positions and punishing failures in integrity with demotions from leadership, then this can really snowball on you.

Just like the life of an individual can go from groovy one day to a real crisis with just the right amount of unlucky, bit of bad cards, bit of bad choices, bit of bad weather, same thing happens to societies. Your institutions start to fail, people start to realize that cheating is the new normal, and away you go. Right now we're reaping what was sowed in the 1980s, Gordon Gecko and yuppies would love 2025 (I'd like to think Reagan would feel a bit queasy about how it all went but who knows).

Demand high-integrity behavior from leaders. It's not guaranteed to work at this stage of the proceedings, but it's the only thing that has ever worked.

9. sgt101 ◴[] No.44507424[source]
Companies are suffering massive losses from Cyber, and there are state actors out there who will use these failures as well. I really don't think that organisations that fail to pay attention will survive.
10. Orygin ◴[] No.44508089{3}[source]
Small sample: https://www.virtru.com/blog/industry-updates/microsoft-data-...

I also can't find the news, but they were hacked a few years ago and the hackers were still inside their network for months while they were trying to get them out. I wouldn't trust anything from MS as most of their system is likely infected in some form

11. ttoinou ◴[] No.44508125[source]

   The entire point of programming is that (barring hardware failure and compiler bugs) the computer will always do exactly what it's told
New AI tech is not like regular programming we had before. Now we have fuzzy inputs, fuzzy outputs
replies(3): >>44508167 #>>44509702 #>>44512080 #
12. lou1306 ◴[] No.44508167[source]
Given our spectacular inability to make "regular" programs secure in the absence of all that fuzziness, I don't know if it's a good idea.
replies(2): >>44508754 #>>44511558 #
13. cess11 ◴[] No.44508168{4}[source]
Organised labour.
replies(1): >>44508437 #
14. nurettin ◴[] No.44508437{5}[source]
Sounds ominous.
15. koakuma-chan ◴[] No.44508754{3}[source]
> Given our spectacular inability to make "regular" programs secure in the absence of all that fuzziness

"our" - *base users? I only hear about *base apps shipping tokens in client code or not having auth checks on the server, or whatever

replies(1): >>44509929 #
16. skinner927 ◴[] No.44509188{3}[source]
https://www.theguardian.com/technology/2024/apr/03/microsoft...
17. ep103 ◴[] No.44509702[source]
> Now we have fuzzy inputs, fuzzy outputs

_For this implementation, our engineers chose_ to have fuzzy inputs, fuzzy outputs

There, fixed that for you

18. lou1306 ◴[] No.44509929{4}[source]
I just meant very generally that we (humans) are still struggling to make regular programs secure, we built decades worth of infrastructures (langages, protocols, networks) where security was simply not a concern and we are still reckoning with that.

Jumping head first into an entire new "paradigm" (for lack of a better word) where you can bend a clueless, yet powerful servant to do your evil bidding sounds like a recipe for... interesting times.

19. scott_w ◴[] No.44511375[source]
That word "discourage" is what worries me. Like, with my code, I either introduced a bug/security hole or I didn't. Yes, I screw up but I can put things in place to logically prevent specific issues from occurring. How on earth do I explain to our Security team that the best I can hope for is that I'm asking an LLM nicely to not expose users' secrets to the wrong people?
20. docsaintly ◴[] No.44511558{3}[source]
We are talking about binary computers here, there is no such thing as a "fuzzy" input or a "fuzzy" output.

The fact is that these MCPs are allowed to bypass all existing and well-functioning security barriers, and we cross our fingers and hope they won't be manipulated into giving more information than the previous security barriers would have allowed. It's a bad idea that people are running with due to the hype.

21. b00ty4breakfast ◴[] No.44512080[source]
>Now we have fuzzy inputs, fuzzy outputs

I concede that I don't work in industry so maybe I'm just dumb and this is actually really useful but this seems like the exact opposite of what I would want out of my computer about 99.98% of the time.