MCP security
Definition
MCP security is the practice of controlling which Model Context Protocol servers an AI agent can reach, what those servers can ask of it, and what data passes through them.
The Model Context Protocol is the interface that lets an agent discover tools, read resources and use prompts from a server that someone else wrote. That server becomes part of your agent's authority: it decides which tools exist, what their descriptions say, and what comes back when they run.
This entry covers the risks that make MCP a security topic rather than a plugin format, how those risks show up on ordinary developer machines, and a defense order that starts with inventory.
Why it matters
MCP spread faster than any review process could follow. A study of 1,899 open-source MCP servers found that 7.2 percent have general vulnerabilities and 5.5 percent show MCP-specific tool poisoning (MCP at First Glance, June 2025). A separate credential survey of more than 5,200 servers found that 88 percent require credentials, 53 percent use long-lived static secrets, and only 8.5 percent use OAuth (State of MCP Server Security 2025).
The attacks work on the models, not only on the servers. On a benchmark of 20 agents against 45 real MCP servers, tool poisoning reached a 72.8 percent attack success rate on one widely used model, and no model refused more than 3 percent of the attacks (MCPTox, August 2025). The first public tool poisoning disclosure showed hidden instructions in a tool description making a coding agent read an SSH private key and an MCP configuration, then exfiltrate both (Invariant Labs, April 2025).
Supply chain failures are already assigned CVEs. Command injection in a popular MCP client bridge, when connecting to an untrusted server, was rated 9.6 (CVE-2025-6514). The OWASP MCP Top 10 is still in beta, and it already lists token mismanagement, scope creep, tool poisoning, supply chain, command injection and shadow servers as separate risks (OWASP MCP Top 10).
How it works
Four failure patterns explain most MCP incidents.
The server is trusted with more than it needs. A filesystem server granted the home directory can read every cloud credential on the machine. Scope is set when the server is wired up, usually by whoever was in a hurry, not when the tool is called.
The tool description is the attack surface. Descriptions, names and schemas are read by the model as context, before any decision about the call. Hidden instructions there are prompt injection that arrives through the catalogue, and a model has no reliable way to tell a description from an instruction.
The server is unknown. Servers appear in configuration files, in project scaffolding and in dependencies. A shadow MCP server is not visible to the team that owns the endpoint, and its absence from any allowlist is exactly why it matters.
Credentials are standing grants. A static token in a configuration file is readable by any process with access to that file, and it stays valid long after the task that needed it. Most MCP servers still work this way.
How to defend against it
- Inventory before policy. Find every MCP server on every endpoint, local and remote, with the client that wired it up and the version it runs. You cannot allowlist a server you cannot name.
- Allowlist by identity and version. Deny unknown servers by default where the team is regulated, and pin the version of the ones you approve, because a server update can change a tool description.
- Treat tool descriptions as untrusted content. Review descriptions when you approve a server, watch for changes, and never treat a description as a policy statement.
- Scope credentials to the call. Prefer short-lived leases issued at the moment of use over static keys in a configuration file, and never place a standing secret in an MCP configuration that the agent can read.
- Decide per tool and per resource, not per server. A server that is approved for reading documentation is not approved for writing to a repository.
- Record every call. Server identity, tool, arguments, decision and result belong in one audit record that you can export, because MCP08 on the OWASP list is the absence of that record.
- Review the supply chain. Prefer maintained servers, check how they are published, and pin dependencies as you would for any other package that runs with your credentials.
How Alyria handles it
Alyria (alyria.ai) treats the MCP call as the security event. Beacon inventories every MCP server on an endpoint, including the local servers a coding agent starts over a pipe, and evaluates policy on each call locally, where the call originates, with no cloud round trip. Lyra writes the rule as a capability, so an agent may call this tool on this resource and nothing else, and it follows the data across tools rather than judging one call in isolation. Umbra issues short-lived leases at the moment of use instead of leaving a static key in a configuration file, and records each hand-off. Spectra emits every call as OpenTelemetry to Alyria Cloud or to your own SIEM, and Observatory shows which servers exist across the fleet, which are unsanctioned, and what each of them did. Constellation applies a prompt-injection content-safety layer to what agents read and write through the mesh, and the OWASP Agentic Top 10 coverage page maps these controls to ASI04 supply chain and ASI10 rogue agents.
Related standards
- OWASP MCP Top 10 (beta): MCP03 tool poisoning, MCP05 command injection, MCP08 lack of audit and telemetry, MCP09 shadow MCP servers.
- OWASP Top 10 for Agentic Applications: ASI04 agentic supply chain vulnerabilities.
- OWASP Top 10 for LLM Applications: LLM06 excessive agency.
- NIST AI RMF: MAP and MEASURE, which cover third-party components and continuous monitoring.
- ISO/IEC 42001: supplier and lifecycle controls for AI systems that include external tools.
- SOC 2: CC9.2 vendor and business partner risk management.
Frequently asked questions
- What is an MCP server, in one paragraph?
- The Model Context Protocol is an open interface that lets an AI agent discover and call tools, read resources and use reusable prompts from a server. A server can run as a local process the agent starts, or sit remotely behind HTTP. Either way, the server decides what the agent can do, which makes it a security boundary.
- Why does a network gateway miss local MCP servers?
- A local server that the coding agent starts over standard input and output produces no network connection to inspect. The traffic in the sense that matters is a function call inside the agent process, plus a pipe to a child process. A gateway sees neither.
- What is tool poisoning?
- A malicious or compromised server puts hidden instructions in a tool's name, description or schema. The model reads the description before it decides anything, so the description itself becomes the attack. It is prompt injection delivered through the tool catalogue.
- Should we ban MCP servers we have not approved?
- Blocking unknown servers is the right default for regulated teams, but inventory has to come first. Most organizations find servers a developer added to a config file for a deadline, which is a conversation before it is a policy.
- Are long-lived API keys in MCP configs a real problem?
- They are the common case. In a 2025 survey of more than 5,200 open-source MCP servers, 88 percent required credentials and 53 percent used long-lived static secrets, while only 8.5 percent used OAuth. A static key in a config file is a standing grant to every process that can read the file.