Now in early access, book a 30-minute demo →
Top riskcritical

Malicious MCP Servers

An MCP server is code you invite into your agent's loop. Thousands circulate publicly with no central vetting, and installing a local one means running its code on the endpoint with the developer's full privileges.

Attackerpublishes / poisons Public MCP registryno central vetting MCP server processruns on the endpoint AI agentinstalls and trusts it Tool-call hookallow / deny / log Secrets + tokensenv vars, keys, sessions Attacker infraexfiltration publish / poison developer installs poisoned tools reads exfiltrates deny before run
A malicious MCP server: published to an unvetted registry, installed on the endpoint, then reaching secrets and attacker infrastructure with the agent's authority.

The Model Context Protocol lets an agent load typed tools from a server: query a database, read a wiki, drive a browser. That convenience hides a trust decision. An MCP server is not a passive API definition; it is code you invite into the agent's loop. A local stdio server runs as a process on the endpoint with the developer's own privileges - the same access to files, secrets, and network position the human has at the keyboard.

Thousands of MCP servers circulate publicly with no central vetting, installed from registries, gists, and READMEs on the strength of a name and a star count. That makes the server layer a supply chain - attacked at the point of trust, not the point of use.

How the attack works

Installing a server executes its code, and connecting to it loads its tool definitions - names, descriptions, and parameter schemas - into the agent's context. Both are attack surface: the description is read by the model as instructions, and the server's output is read as fact. Worse, trust is granted once and rarely revisited, so an update can silently swap what a tool does or says, and a server that was benign when you vetted it can turn hostile on its next release. See the defender's guide to AI supply chain attacks.

Attack scenarios

Mitigations

  1. Inventory every installed server first. You cannot govern servers you cannot see. Know which are installed across the fleet, and their source, owner, and version, before reasoning about any single one.
  2. Treat install as a code-execution event. Vet servers the way you vet dependencies: pin versions, prefer known owners, and review what a server can reach before allowing it.
  3. Re-evaluate on change. Updates are where rug pulls land. Catch version and configuration drift and re-approve, rather than trusting the original decision forever.
  4. Enforce at the tool-call boundary, and keep the trail. The moment a poisoned description or output becomes action is a tool call. A hook that evaluates each call against policy before it runs turns a malicious server into a logged, denied attempt, and retaining those calls lets you investigate which server did what and when.

How Anomity helps

Anomity's lightweight, unprivileged Endpoint Sensor discovers every MCP server across Windows, macOS, and Linux endpoints and records each one's source, owner, version, and reach, so the server supply chain is enumerable instead of invisible. It surfaces updates and config changes as change events, which is exactly where a rug pull would otherwise slip through. On agents that expose a hook, such as Claude Code's PreToolUse, each tool call is allowed, denied, or logged before it runs, containing a server whose descriptions or output have turned hostile. Violations route to SIEM, Slack, email, and Jira, and every call lands in a queryable 90-day audit trail.

See this surface in your own fleet

Anomity's Endpoint Sensor discovers every AI agent, MCP server, skill, and rules file on every endpoint, and governs each tool call at the hook. Book a 30-minute demo.

Ask AI about Anomity
ChatGPT Claude Perplexity Google AI Grok