Invariant Labs, an AI agent security company, publishes research on attacks against MCP tools and AI agents.
HN links it for the GitHub MCP vulnerability write-up, and commenters debate whether the fault lies with tooling given to the LLM.
A curated list of awesome Model Context Protocol solutions for for building, finding, hosting, learning, securing, and using MCP offerings. Sharing the current list here :
--- Private Registries
Ready-to-use pluggable MCP server implementations where MCP servers and tools are managed by the organization. They usually come with auth, guardrails, observability and more.
Composio (https://composio.dev) - Skills that evolve for your Agents. More than just integrations, 10,000+ tools that can adapt — turning automation into intuition.
Docker MCP Catalog (https://hub.docker.com/mcp) - Ready-to-use container images for MCP servers for simple Docker-based deployment.
Glama (https://glama.ai/) - Managed MCP platform: directories, hosted servers, AI gateway, agents/automations, logging/traceability, and public MCP API.
Gumloop (https://www.gumloop.com/mcp) - Workflow automation platform with built-in MCP server integrations. Connects MCP tools to automate workflows and integrate data across services.
Klavis AI (https://www.klavis.ai/) - Managed MCP servers for common AI tool integrations with built-in auth and monitoring.
Make MCP (https://www.make.com/en) - Integration module for connecting MCP servers to Make.com workflows. Enables workflow automations with MCP servers.
mcp.run (https://mcp.run) - One platform for vertical AI across your organization. Instantly deploy MCP servers in the cloud for rapid prototyping or production use.
Pipedream (https://mcp.pipedream.com/) -…
I've recently written a custom MCP server.
> An MCP server is at it's heart some 'thing' that provides a set of 'tools' that an LLM can invoke.
A "tool" is one of several capabilities that a MCP server can provide to its callers. Other capabilities include "prompt" and "resource".
> This is done by adding a 'tool definition'. A 'tool definition' is content that goes into the LLM prompt. That's how it works. How do you imagine an LLM can decide to use a tool? It's only possible if the tool definition is in the prompt.
I think you're using an expansive definition of "prompt" that includes not just the input text as provided by the user -- which is generally what most people understand "prompt" to mean -- but also all available user- and client-specific metadata. That's fine, just want to make it explicit.
With this framing, I agree with you, that every MCP server added to a client -- whether that's Claude.app, or some MyAgent, or whatever -- adds some amount of overhead to that client. But that overhead is gonna be fixed-cost, and paid one-time at e.g. session initialization, not every time per e.g. request/response. So I'm struggling to imagine a situation where those costs are anything other than statistical line noise, compared to the costs of actually processing user requests.
> https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview#tool-use-system-prompt
To be clear, this concept of "tool" is completely unrelated to MCP.
>…
> 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.
[0] https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
One of the biggest issues I see, briefly discussed here, is how one MCP server tool's output can affect other tools later in the same message thread. To prevent this, there really needs to be sandboxing between tools. Invariant labs did this with tool descriptions [1], but I also achieved the same via MCP resource attachments[2]. It's a pretty major flaw exacerbated by the type of privilege and systems people are giving MCP servers access to.
This isn't necessarily the fault of the spec itself, but how most clients have implemented it allows for some pretty major prompt injections.
[1] https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks [2] https://www.bernardiq.com/blog/resource-poisoning/
I believe one of the main differences is that our scanner looks for toxic flows between mcp endpoints regarding how they interact with one another. Unless I'm missing something, the Cisco tool does not support this.
Our research lab discovered this novel threat back in July: https://invariantlabs.ai/blog/toxic-flow-analysis and built the tooling around it. This is an extremely common type of issue that many people don't realize (basically, when you are using multiple MCP servers that individually are safe, but together can cause issues).
I believe the issue here is with tooling provided to the LLM. It looks like GitHub is providing tools to the LLM that give it the ability to search GitHub repositories. I wouldn't be shocked if this was a bug in some crappy MCP implementation someone whipped up under some serious time pressure.
I don't want to let Microsoft of the hook on this but is this really that surprising?
Update: found the company's blog post on this issue.
https://invariantlabs.ai/blog/mcp-github-vulnerability