These attacks are mostly just more examples of being on the wrong side of the airlock (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...). None of these involve crossing a privilege boundary, they just found a weird way to do something they could already do
An MCP server is running code at user-level, it doesn't need to trick an AI into reading SSH keys, it can just....read the keys! The rest of these are the same complaints you can levy against basically any other developer tool / ecosystem like NPM or VS Code Extensions
> None of these involve crossing a privilege boundary, they just found a weird way to do something they could already do
It's slightly more subtle than that.
The tool poisoning attack allows the provider of one tool to cause the AI to use another tool.
So if you give the AI some random weather tool from some random company, and you also give the AI access to your SSH key, you're not just giving the AI your SSH key, you're also allowing the random company to trick the AI into telling them your SSH key.
So, yes, you gave the AI access to your key, but maybe you didn't realise that you also gave the random weather company access to your key.
It’s more like installing a VS Code plugin with access to your file system that can also download files from GitHub, and if it happens to download a file with the right content, that content will cause the plugin to read your ssh keys and send them to someone else.
Any program with access to both trusted and untrusted data needs to be very careful to ensure that the untrusted data can’t make the program do things that the user doesn’t want. If there’s an LLM involved with access to privileged tools, that becomes impossible.
> An MCP server is running code at user-level, it doesn't need to trick an AI into reading SSH keys, it can just....read the keys!
If you go to the credited author of that attack scenario [0], you will see that the MCP server is not running locally. Instead, its passing instructions to your local agent that you don't expect. The agent, on your behalf, does things you don't expect then packages that up and sends it to the remote MCP server which would not otherwise have access.
The point of that attack scenario is that your agent has no concept of what is "secure" it is just responding faithfully to a request from you, the user AND it can be instructed _by the server_ to do more than you expect. If you, the user, are not intimately aware of exactly what the fine-print says when you connect to the MCP server you are vulnerable.
We’re not longer living in the 90s where we’re dividing the world just in secure or insecure. We’re living in a reality where everything should be least privileges.
Using a code completion service should not give that service full control over your computer.
except that leads to a security world with restrictions escalation.. security exploiters battling system designers with civilians repeatedly and unapologetically pushed into tinier and tinier "user boxes" .. not everything is world network facing. not every product needs to phone home and auto-update on networks.
There are privilege boundaries within which this fundamentally is a problem as well, for example inside banks where this could be used to silently monitor for events that could then be used to trigger frauds or other bad things.
The problem is that it is very hard to see how you can prove this is going to be safely implemented, for example, is it possible to say that your sharepoint or confluence is "safe" in terms of all the content that's in there? I do not think so...
An MCP server is running code at user-level, it doesn't need to trick an AI into reading SSH keys, it can just....read the keys! The rest of these are the same complaints you can levy against basically any other developer tool / ecosystem like NPM or VS Code Extensions