←back to thread

801 points rexpository | 2 comments | | HN request time: 0.403s | source
Show context
rhavaeis ◴[] No.44503524[source]
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 be able to know the origins of an instruction. Every tool call should carry metadata identifying its source. For example, an EXECUTE SQL request originating from your database engine should be flagged (and blocked) since an instruction should come from the user not the data.

We can borrow permission models from traditional cybersecurity—where every action is scoped by its permission context. I think this is the most promising solution.

replies(2): >>44503628 #>>44508488 #
1. rexpository ◴[] No.44503628[source]
I broadly agree that "MCP-level" patches alone won't eliminate prompt-injection risk. Latest research also shows we can make real progress by enforcing security above the MCP layer, exactly as you suggest [1]. DeepMind's CaMeL architecture is a good reference model: it surrounds the LLM with a capability-based "sandbox" that (1) tracks the provenance of every value, and (2) blocks any tool call whose arguments originate from untrusted data, unless an explicit policy grants permission.

[1] https://arxiv.org/pdf/2503.18813

replies(1): >>44504522 #
2. tatersolid ◴[] No.44504522[source]
> unless an explicit policy grants permission

Three months later, all devs have “Allow *” in their tool-name.conf