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 3 days ago | parent | next [-]

Totally 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

▲ quotemstr 2 days ago | parent [-]

> 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 2 days ago | parent [-]

For 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 2 days ago | parent [-]

> 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 2 days ago \| parent [-]
		`> 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.

▲ nijave 2 days ago | parent | prev | next [-]

Yes 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

▲ anthonypasq 2 days ago | parent | prev | next [-]

i 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.

▲ SpaceL10n 2 days ago | parent | prev [-]

Was 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.