411–420 of 502 posts
A key tool missing in most applications of MCP is better underlying authorization controls. Instead of granting large-scale access to data like this at the MCP level, just-in-time authorization would dramatically reduce the attack surface. See the point from gregnr on > 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, a…
Earlier quoted context omitted.
That "problem" remains unsolved because it's actually a fundamental aspect of reality. There is no natural separation between code and data. They are the same thing. What we call code, and what we call data, is just a question of convenience. For example, when editing or copying WMF files, it's convenient to think of them as data (mix of raster and vector graphics) - however, at least in the original implementation,…
> There is no separation of code and data on the wire - everything is a stream of bytes. There isn't one in electronics either - everything is signals going down the wires. Would two wires actually solve anything or do you run into the problem again when you converge the two wires into one to apply code to the data?
> A developer may occasionally use cursor’s agent to list the latest support tickets and their corresponding messages. When would this ever happen? If a developer needs to access production data, why would they need to do it through Cursor?
"Find tickets involving feature X"
"Find tickets where the customer became angry or agitated"
We're doing something similar at work to analyze support cases. We have some structed fields but want to also do some natural language processing on the ticket to extract data that isn't captured in the structured fields.
Think topic extraction and sentiment analysis of ticket text
We're not using MCP but looking into LLM enrichment/feature extraction
If you're hooking up an LLM to your production infrastructure, the vulnerability is you.
Mitigations also need to happen on the client side. If you have a AI that automatically can invoke tools, you need to assume the worst can happen and add a human in the loop if it is above your risk appetite. It's wild how many AI tools just blindly invoke tools by default or have no human in loop feature at all.
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…
"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
Maybe I'm getting too old but the core problem here seems to be with `execute_sql` as a tool call! When I learned database design back in the early 2000s one of the essential concepts was a stored procedure which anticipated this problem back when we weren't entirely sure how much we could trust the application layer (which was increasingly a webpage). The idea, which has long since disappeared (for very good and pra…
If the LLM has access to executing only specific stored procedures (I assume modern DBMSs can achieve that granularity, but I haven't checked), then the problem mostly (entirely?) disappears. It limits the utility of the LLM, as it cannot answer any question one can think of. From one perspective, it's just a glorified REST-like helper for stored procedures. But it should be secure.
I'd probably lean towards doing it outside SQL, though (with some other API written in a general purpose programming language)
Enterprise readiness is hard to find in the hobbyist dev tools ecosystem community. Let's hope this lights a fire under them
To get them motivated or burn it all down?
Earlier 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…
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…
You could allow unconstrained selects, but as you note you either need row level security or you need to be absolutely sure you can prevent returning any data from unexpected queries to the user.
And even with row-level security, though, the key is that you need to treat the agent as an the agent of the lowest common denominator of the set of users that have written the various parts of content it is processing.
That would mean for support tickets, for example, that it would need to start out with no more permissions than that of the user submitting the ticket. If there's any chance that the dataset of that user contains data from e.g. users of their website, then the permissions would need to drop to no more than the intersection of the permissions of the support role and the permissions of those users.
E.g. lets say I run a website, and someone in my company submits a ticket to the effect of "why does address validation break for some of our users?" While the person submitting that ticket might be somewhat trusted, you might then run into your scenario, and the queries need to be constrained to that of the user who changed their address.
But the problem is that this needs to apply all the way until you have sanitised the data thoroughly, and in every context this data is processed. Anywhere that pulls in this user data and processes it with an LLM needs to be limited that way.
It won't help to have an agent that runs in the context of the untrusted user and returns their address unless that address is validated sufficiently well to ensure it doesn't contain instructions to the next agent, and that validation can't be run by the LLM, because then it's still prone to prompt injection attacks to make it return instructions in the "address".
I foresee a lot of money to be made in consulting on how to secure systems like this...
And a lot of bungled attempts.
Basically you have to treat every interaction in the system not just between users and LLMs, but between LLMs even if those LLMs are meant to act on behalf of different entities, and between LLMs and any data source that may contain unsanitised data, as fundamentally tainted, and not process that data by an LLM in a context where the LLM has more permissions than the permissions of the least privileged entity that has contributed to the data.