MCP server security is the practice of knowing which MCP servers run on your developers' machines, what each one can reach, and whether anyone reviewed it before an agent started using it. It matters because an MCP server is a program that runs with the developer's full access, and it gets installed by editing a config file, with no ticket and no review. This article explains what an MCP server can do on a laptop, what went wrong in three real incidents, and how to review a server before it runs.
What is an MCP server?
The Model Context Protocol, MCP, is the way AI coding agents such as Claude Code, Cursor and Codex CLI connect to tools. An MCP server is a small program that offers the agent a set of tools: read this database, send this email, open this ticket, search this wiki. The agent calls a tool, the server does the work, and the result goes back into the agent's context as text.
Installing one takes a single line in the agent's config file. From then on the server starts with every session, and the agent can call any tool it offers without asking. A developer who wants their agent to talk to Postgres, GitHub, Slack, Jira or a browser adds a server for each. A typical machine we scan runs between five and fifteen of them, and nobody on the security team chose any of them.
What can an MCP server do on a developer laptop?
Whatever the developer can do. Most MCP servers run as a local process under the developer's own account, so they inherit the developer's identity. That means a server can:
- Read every file the developer can read, including .env files, cloud CLI profiles, SSH keys and the keychain.
- Run commands and install packages.
- Reach any network destination the laptop can reach, including the internal ones.
- Hold long-lived credentials of its own, because most servers need a token for the service they wrap.
- Put text into the agent's context, which the agent treats as information and sometimes as instructions.
That last point is the one people miss. An MCP server is not only a way for the agent to act on the world. It is also a way for the world to speak to the agent. Every tool result it returns is text the model reads, and text the model reads can steer what it does next. That is the mechanism behind prompt injection on a laptop.
What has gone wrong with MCP servers so far?
None of these is a hypothetical. Each one is documented, and each shows a different way an MCP server goes wrong.
A copied package with one extra line. In September 2025, Koi Security found a package on npm called postmark-mcp that copied the real Postmark MCP server and added one line: every email sent through it was blind-copied to the author's address. The author published fifteen clean versions first, then added the backdoor in version 1.0.16. It reached about 1,500 downloads a week before it was pulled. Nobody who installed it did anything wrong. They installed a server whose name matched the tool they used.
A client that trusted the server. In July 2025, JFrog disclosed CVE-2025-6514 in mcp-remote, the proxy many developers use to reach remote MCP servers. A hostile server could put a crafted value in its OAuth response and run any command on the developer's machine. It scored 9.6 out of 10 and affected every version from 0.0.5 up to 0.1.16. The developer's only mistake was connecting to a server they did not control.
A legitimate server, steered by a stranger. In May 2025, Invariant Labs showed that GitHub's own MCP server could be used to leak private repositories. An attacker opens an issue in a public repository with instructions hidden in the text. A developer asks their agent to look at open issues, the agent reads the issue through the MCP server, follows the instructions, pulls data from a private repository, and posts it in a public pull request. Nothing in the server was broken. The agent had access to both repositories, and the server delivered the attacker's text into its context.
Three servers, three failures: a malicious package, a vulnerable client, and a clean tool carrying a hostile instruction. A review that only asks "is this package known bad" catches the first and misses the other two.
How to review an MCP server before it runs
A review does not need to be long. It needs to answer five questions, in this order.
- Where did it come from, and is the name honest? Find the project the server claims to be. Check that the package on npm or PyPI is published by the same people as the repository. The Postmark copy would have failed here.
- What does it do with what it receives? Read the code that handles the data flowing through it. A mail server that adds a recipient, a database server that logs queries somewhere, a search server that phones home. It is usually a few hundred lines and the suspicious part is short.
- Is there an advisory against this version? Match the exact version against the CVE and GitHub advisory feeds. mcp-remote had a fix out before most people knew there was a problem.
- Does it carry instructions for the agent? Some servers ship tool descriptions or README text that tell the agent to do things it should not, such as read a file and include it in the next call. An AI reviewer reading the package for that is faster and more reliable than a person skimming.
- What may it reach? Decide the credentials and destinations this server actually needs, and take away the rest. A server for one GitHub repository should not hold a token for all of them.
Do that once per server, record the answer, and you have MCP server security for one machine.
Why does reviewing one machine not solve it?
The trouble is that the review has to happen on every laptop, every time a server is added, and developers add them all the time. A written policy that says "review your MCP servers" is a wish. The only place the review can be enforced is the endpoint itself, at the moment the server appears.
That is how a sensor on each machine does it. It reads the agents' own config files, so within fifteen minutes of a server being added the console lists it by name, version and the agent that loads it. It matches the version against advisories. An AI reviewer reads the package for hidden instructions. A server that is unknown, vulnerable, or flagged is held: the agent cannot call it until someone on the security team has looked and approved. Every server that is already approved keeps running and developers never notice.
The console reports names, versions and hashes. It never sends the server's code, the credentials it holds, or the contents of the tool results back to anyone. The review is done on the machine, and only the verdict leaves it.
What to do this week
If you have a fleet of developer laptops and you do not know how many MCP servers they run, start there. List them. Match the list against the three failure modes above: copies with honest names, versions with an advisory, and servers whose results reach an agent with access to things the server should not know about. Then hold new ones until they are reviewed. That is the whole of MCP server security, and it is enough to have stopped all three incidents in this article.
Frequently asked questions
What is MCP server security? It is the practice of knowing which MCP servers run on your developers’ machines, what each one can reach, and whether it was reviewed before an agent started using it. An MCP server runs with the developer’s access, so an unreviewed one is an unreviewed program with the keys to the laptop.
Are MCP servers safe to install? Some are. The problem is that nothing checks. A developer adds a line to a config file and the server runs on every session from then on. In 2025 a copy of the Postmark MCP server on npm quietly copied every email to its author, and a critical flaw in mcp-remote let a hostile server run commands on the client. Review before it runs, or hold it until someone has.
What can an MCP server do on a developer laptop? Whatever the developer can do. It runs as a local process with the developer’s identity, so it can read .env files, cloud profiles and SSH keys, run commands, and reach the network. It also feeds text back to the agent, which means it can carry instructions the agent will follow.
How do you review an MCP server before it runs? Check where it came from and whether the name matches a real project. Read what it does with the data it receives. Look for a known advisory against that version. Then decide what it may reach. On a fleet, a sensor on each endpoint lists every server within fifteen minutes, matches it against advisories, has an AI reviewer read it for hidden instructions, and holds it until a person approves.