Model Context Protocol (MCP) Security Explained

The Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools and data through a uniform client-server interface, and MCP security is the practice of governing that connection so an agent cannot be steered into reading, executing, or exfiltrating something it should not. In under two years MCP went from a single vendor's specification to the default way coding agents and assistants reach the outside world, and with that reach came a new attack surface: every MCP server is a piece of software that runs with real access, chosen and invoked by a model responding to input that may be adversarial. This guide is the pillar for our MCP cluster. It defines what MCP is, explains why it is a security surface, and gives an overview of the controls that matter, then links down to the deep dives rather than repeating them.

What MCP actually is

MCP standardizes a problem every agent had to solve on its own: how to discover and call external capabilities. Before MCP, connecting an agent to a database, a ticketing system, or a filesystem meant a bespoke integration for each one. MCP replaces that with a single protocol, so any compliant agent can talk to any compliant server. The design borrows the shape of a client-server protocol and defines a small number of moving parts.

• Host and client. The host is the agent application (a coding agent, an assistant, an IDE). Inside it, an MCP client manages connections to servers and relays the agent's requests.
• Server. An MCP server exposes capabilities to the client. One server might wrap a database, another the local filesystem, another a SaaS API. A single agent commonly connects to several servers at once.
• Primitives. Servers offer three things the agent can use: tools (actions the agent can invoke, like run a query or write a file), resources (data the agent can read), and prompts (reusable prompt templates). Tool descriptions and resources are text the model reads and trusts.
• Transport. The client and server exchange messages over a transport. The two common ones are stdio, where the server runs as a local subprocess, and streamable HTTP, where the server is reached over the network.

The value is obvious: write a server once and every MCP-capable agent can use it. That same universality is what makes the security story matter, because one server, or one poisoned tool description, can affect every agent that connects to it.

Why MCP is a security surface

An MCP server is best understood as a plugin with production access that the agent, not a human, decides when to run. That framing surfaces the core problem. The agent selects which tool to call based on natural-language context, and that context can include untrusted content the agent read mid-task. So the decision to invoke a high-privilege tool is being made by a component that can be manipulated, on top of a server that may hold broad, standing access. Five properties turn that into a distinct surface worth governing.

• Broad, standing access. A server often gets more scope than any single task needs - full filesystem read, write and delete, or an API token with wide permissions - because that was faster to configure. The agent inherits all of it.
• Instruction-carrying metadata. Tool descriptions, resources, and prompt templates are text the model treats as trusted guidance. Hidden directives there are a delivery path for prompt injection.
• Local command execution. A stdio server is launched as a local process, so installing and starting one is running a local command with the user's privileges.
• Weak or optional authentication. Many servers, especially local and community ones, authenticate weakly or not at all, and remote servers historically shipped before the authorization model matured.
• An unvetted supply chain. Public MCP directories list thousands of servers with no signing, review, or version pinning, so a trusted install can pull malicious or abandoned code.

None of these is exotic. They are the familiar problems of plugins and packages, sharpened by the fact that the thing choosing when to act is a model responding to input you do not fully control.

The MCP risk map: components and transports

Different parts of MCP carry different risks. The table below maps each component and transport to the primary security concern it introduces, so a team can reason about where controls need to sit.

Tool poisoning and the instruction layer

The risk most teams miss is that a server does not have to run malicious code to be dangerous. A tool description or a returned resource is text the agent reads and follows. A server can place hidden or obfuscated instructions there - tell the agent to also send data somewhere, weaken a check, or invoke another tool - and the agent may comply because it treats tool metadata as trusted. This is indirect prompt injection delivered through the tool layer, and static code scanning does not catch it because the payload is prose. It also feeds directly into data-exfiltration chains like the lethal trifecta, where private data access, untrusted content, and external communication combine into near-guaranteed leakage.

stdio and local command execution

The stdio transport is convenient because it needs no network setup - the client just spawns the server as a subprocess. But that convenience is also the risk: starting a stdio MCP server means executing a local command with the user's privileges, so a trojanized server package can run arbitrary code at launch. This is a property of how the transport works rather than a single fixable bug, which is why provenance, pinning, and isolation matter so much for stdio servers. We walk through the mechanism and its implications in the MCP stdio by-design remote code execution guide.

Authentication and over-scoped tokens

Remote MCP servers reached over HTTP raise the classic questions: who is calling, and with what rights. The MCP authorization specification requires OAuth 2.1 for remote server access, which mandates PKCE (the S256 method) and HTTPS and drops insecure legacy flows. The least-privilege pattern is to exchange for a narrowly scoped, audience-restricted token that expires in minutes before a high-privilege call, rather than handing a server a static long-lived key. The full treatment, including why PKCE matters when a client cannot store a secret, is in OAuth for MCP servers explained.

The controls that matter

MCP security is not one setting. It is a small stack of controls, each matched to the risks above, and none of them work without the first one.

1. Inventory every MCP server. You cannot secure a server you have not found. Build an MCP server registry that records every server across every endpoint, its transport, its scopes, its source, and its owner.
2. Apply least privilege. Scope each server and its token to the task, not the maximum. Removing a capability like external egress can break an exfiltration chain architecturally. See least privilege for AI agents.
3. Authenticate remote servers with OAuth 2.1 and PKCE. Use short-lived, audience-restricted tokens for high-privilege calls, per the authorization spec.
4. Isolate stdio servers. Treat launching a stdio server as running untrusted code: pin versions, verify provenance, and sandbox where possible.
5. Vet the supply chain. Prefer signed, reviewed servers; pin versions; and re-review on update so a clean install cannot silently become a payload.
6. Enforce at runtime. Evaluate the tool calls an agent makes against policy before they execute, somewhere the agent cannot rewrite, so a poisoned or over-scoped server's action can be denied rather than run.

For the full control set, threat model, and hardening checklist, the deep dive is the MCP server security complete guide. This pillar is deliberately the map; that guide is the terrain.

How Anomity helps

Every control above assumes a capability most organizations lack: the ability to see and govern MCP servers across the fleet. That is the gap Anomity closes. Its category is agentic endpoint security, built on a simple principle - you can't govern what you can't see. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, and Linux) and discovers eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. For each MCP server it records the transport, configuration, source, and reachable scope - the inventory the registry demands - and sends metadata only over HTTPS, never source code or prompts, with secrets redacted on the endpoint.

At runtime, on agents that expose a hook, Anomity evaluates each tool call an MCP server would trigger and returns allow, deny, or log before it runs. That is the enforcement point for tool poisoning, over-privilege, and untrusted instructions alike: an unexpected shell command or network call can be denied rather than executed. Continuous policy means configuration or version drift surfaces as a change event, violations route to your SIEM, Slack, email, and Jira, and every server added, removed, or modified lands in a queryable 90-day audit trail. Anomity is SOC 2 Type II and complements rather than replaces your EDR/XDR, DLP, network and gateway controls, and GRC program. For the wider program this fits into, see the complete enterprise AI security guide.

You can't govern what you can't see.The Anomity principle

The bottom line

MCP earned its adoption by making agent integrations universal, and it earned its risk the same way: a single protocol that lets a model reach real tools and data, over transports that either run local commands or expose network services, on top of a supply chain that ships like documentation but executes like software. The risks are the familiar ones - injection through the instruction layer, over-privilege, local code execution, weak auth, and supply-chain compromise - and so are the controls: inventory first, then least privilege, OAuth 2.1 for remote servers, isolation for stdio, and runtime policy on every tool call. Start by seeing every MCP server across every endpoint. From there, the deep dives on server security, OAuth, the registry, and stdio execution give you the specifics. To see your own MCP posture, book a 30-minute demo.