5 ms·
Pavlo is right to be skeptical about MCP security. The entire philosophy of MCP seems to be about maximizing context availability for the model, which stands in
by A1aM0 9mo ago
Pavlo is right to be skeptical about MCP security. The entire philosophy of MCP seems to be about maximizing context availability for the model, which stands in direct opposition to the principle of Least Privilege.
When you expose a database via a protocol designed for 'context', you aren't just exposing data; you're exposing the schema's complexity to an entity that handles ambiguity poorly. It feels like we're just reinventing SQL injection, but this time the injection comes from the system's own hallucinations rather than a malicious user.
- Miyamura80 9mo agoTotally agree, unfettered access to databases are dangerous There are ways to reduce injection risk since LLMs are stateless and thus you can monitor the origination and the trustworthiness of the context that enters the LLM and then decide if MCB actions that affect state will be dangerous or not We've implementeda mechanism like this based on Simon Willison's lethal trifecta framework as an MCP gateway monitoring what enters context. LMK if you have any feedback on this approach to MCP security. This is not as elegant as the approach that Pavlo talks about in the post, but nonetheless, we believe this is a good band-aid solution for the time bein,g as the technology matures https://github.com/Edison-Watch/open-edison https://github.com/Edison-Watch/open-edison
- quotemstr 9mo ago> Totally agree, unfettered access to databases are dangerous Any decent MVCC database should be able to provide an MCP access to a mutable yet isolated snapshot of the DB though, and it doesn't strike me as crazy to let the agent play with that.
- thesz 9mo agoFor this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, and not many databases have them. Also, a double COMMIT may propagate changes outside of agent's playbox.
- quotemstr 9mo ago> For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, Correct, but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway (although you might have to factor out things like row watermarks to lookaside tables if you want to let them be branchy instead of XID being a write lock.) You could version the index B-tree nodes too.
- thesz 9mo ago> but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway You are talking about code that have to be written and tested. Also, do not forget about double COMMIT, intentional or not.
- SpaceL10n 9mo agoWas the trade-off so exciting that we abandoned our own principles? Or, are we lemmings? Edit: My apologies for the cynical take. I like to think that this is just the move fast break stuff ethos coming about.
- anthonypasq 9mo agoi dont know anyone with a brain that is using a DB mcp with write permissions in prod. i mean trying to lay that blame on a protocol for doing something as nuts as that seems unfair.
- nijave 9mo agoYes and no. Least privilege has existed in databases for a very long time. You need to implement correct DB privileges using user/roles, views, and other best practices. The MCP server is more like a dumb client in this setup. However, that's easy for people to forget and throw privileged creds at the MCP and hope for the best. The same stands for all LLM tools (MCP servers or otherwise). You always need to implement correct permissions in the tool--the LLM is too easily tricked and confused to enforce a permission boundary