3 ms·

This isn’t new or novel. Replace “MCP” with any other technology that exposes sensitive or dangerous actions to 3rd parties. The solution is always the same: us

This isn’t new or novel. Replace “MCP” with any other technology that exposes sensitive or dangerous actions to 3rd parties. The solution is always the same: use fine grained permissions, apply the principle of least privilege, and think about your threat model as a whole; make sure things are auditable. Here’s a nonexhaustive list of other technologies where we’ve dealt with these problems. The solutions keep getting reinvented: - Browsers - Android Apps - GitHub actions - Browser extensions - <insert tool here> plugin framwork Nothing about this is unique to MCP. It’s frustrating that we as a species have not learned to generalize. I don’t think of this is a failure of the authors or users of MCP. This is a failure of operating systems and programming languages, which do not model privilege as a first class concept.

MoonGhost 1y ago
> The solution is always the same: use fine grained permissions, apply the principle of least privilege, And one of the most important: keep it sandboxed as much as possible. Also if the tool is directly accessible by 3d party and in turn has access to sensitive data it may be a good idea to split it. For example: 3d party in order to access some database requests login and password. Instead the tool should return some temporary token. After verification, of course. Which is much harder to misuse. Then token, though the tool, is used to access. In this case we split tool in two: one is user's frontend, and another hold all security things including logins and passwords.