What is Model Context Protocol (MCP)?

MCP Security Explained #

The Model Context Protocol did not arrive with a security warning. It arrived as a productivity breakthrough, a standard that lets AI assistants reach beyond the chat window and interact directly with tools, files, APIs, and pipelines. By the time security teams started asking what is MCP, it was already running inside developer environments at scale.

That gap between adoption and governance is exactly where supply chain attacks land. Understanding what is Model Context Protocol, how MCP servers work, and what risks they introduce is now a core requirement for any DevSecOps team operating in an AI-native environment.

What Is the Model Context Protocol? Definition #

The Model Context Protocol (MCP) is an open standard that defines how large language models communicate with external tools, data sources, and services. Where a traditional AI assistant responds only with text, an MCP-enabled assistant can take action (reading files, querying APIs, running commands, installing dependencies, and interacting with CI/CD pipelines) through a structured interface that connects the model to the developer’s environment.

MCP was introduced by Anthropic in November 2024 and has since been adopted across major AI coding tools including Claude, Cursor, Windsurf, and GitHub Copilot. It provides a common language for AI-to-tool communication, similar to how HTTP provides a common protocol for web communication.

If the AI assistant is the brain, the MCP server is the nervous system that connects it to the body of developer tooling.

How Does It Work? #

MCP operates through a client-server architecture with three components:

• The MCP host is the application the developer works in, an IDE like VS Code, Cursor, or Windsurf, or an AI assistant like Claude. The host manages connections to MCP servers and controls what the model can access.
• The MCP client lives inside the host and maintains a one-to-one connection with each MCP server. It translates model requests into structured tool calls and returns results to the model.
• The MCP server is the bridge to external capability. It exposes tools, resources, and prompts that the model can invoke. An MCP server might connect to a file system, a GitHub repository, a database, a CI/CD platform, or a security scanner. Each tool call the model makes goes through the MCP server, which executes it and returns the result.

When a developer asks an AI assistant to scan a project, fix a vulnerability, or install a dependency, the model does not perform those actions directly. It sends a structured request to the relevant MCP server, which performs the action using authorized local tools and returns the output.

MCP vs Traditional AI Assistants: What Changed? #

Before MCP, AI coding assistants were fundamentally passive. They could read code you pasted into the chat and suggest changes, but they could not act on your environment directly. MCP changes that model entirely.

The difference matters for security because it changes what an AI assistant can reach. A traditional assistant that gives bad advice costs you a code review cycle. An MCP-enabled assistant that takes a bad action (installing a malicious dependency, executing a compromised build script, or forwarding credentials to an external endpoint) costs you an incident.

MCP turns AI assistants from advisors into operators. That shift requires the same security controls you apply to any operator with access to your infrastructure.

What Is an MCP Server? #

An MCP server is a lightweight process that exposes capabilities to MCP-compatible AI clients. It defines a set of tools (discrete actions the model can invoke) along with resources the model can read and prompt templates it can use.
MCP servers exist for a wide range of integrations: file system access, GitHub, Slack, databases, security scanners, and CI/CD platforms. Developers can run MCP servers locally, within their organization’s infrastructure, or connect to third-party hosted MCP servers provided by external vendors.
That last category is where the security risk becomes concrete. A third-party MCP server is an external process with access to the developer’s environment. Research shows that 5.5% of public MCP servers carry tool-poisoning flaws and 43% carry command-injection vulnerabilities, meaning a significant share of publicly available MCP servers can be weaponized to manipulate AI behavior, exfiltrate data, or execute unauthorized commands.

MCP Security Risks: What DevSecOps Teams Need to Know #

MCP introduces a new attack surface that traditional AppSec tools were not built to cover. The key risks are:

Shadow MCP servers. Developers configure MCP servers locally without formal approval or governance, creating an inventory gap. Security teams cannot protect what they cannot see.

Tool poisoning. A malicious MCP server exposes tools that appear legitimate but execute harmful actions when invoked by the model. Because the model trusts the tool definitions it receives, it may invoke a poisoned tool without any visible indication that something is wrong.

Prompt injection via MCP. Malicious content in files, documents, or API responses can inject instructions into the model’s context, manipulating its behavior. An MCP server that reads external content and passes it to the model without sanitization is a direct prompt injection vector.

Dependency tampering. MCP servers that manage package installation or dependency resolution can be compromised to install malicious packages. When an AI agent installs a dependency autonomously through an MCP server, there is no human reviewer between the malicious package and the pipeline.

Credential exposure. MCP servers frequently handle authentication tokens, API keys, and environment variables. An insecure MCP configuration can expose these credentials through the model’s context or through logs.

Unauthorized tool execution. Without strict allowlists, an MCP-enabled assistant can invoke tools that exceed its intended scope, modifying production infrastructure, accessing sensitive repositories, or making API calls to external services.

Security Best Practices #

Securing MCP requires treating every MCP server as a privileged integration, not a developer convenience.

• Block malicious dependencies at the endpoint. When an MCP-enabled agent installs a dependency, that installation should be intercepted and scanned before execution. Signature-based detection is not sufficient; malicious packages targeting AI tooling are being published faster than signatures can track them.

• Inventory every MCP server. Know what MCP servers are configured across your developer environments, locally, in your CI/CD pipelines, and in your IDE configurations. Shadow MCP is the same problem as shadow IT, with direct access to your tooling.

• Enforce an MCP allowlist. Only approved MCP servers should be permitted to run. Any unapproved server attempting to connect should be blocked at the endpoint before it can interact with the model.

• Apply least privilege to MCP tool definitions. Each MCP server should expose only the tools required for its specific function. A file-reading server has no business exposing package installation capabilities.

• Validate and sanitize content passed through MCP. Any external content (files, API responses, database results) that passes through an MCP server and into the model’s context is a potential prompt injection vector. Treat it as untrusted input.

• Monitor MCP interactions at runtime. Log every tool call the model makes through MCP servers. Anomalous patterns (unexpected tool invocations, outbound connections from build environments, tool calls outside normal working hours) are early indicators of compromise.

Real-World Security Incidents #

MCP security is not theoretical. In early 2026, research from Queen’s University documented that MCP stacks have a 92% exploit probability when multiple plugins are combined. The PromptMink campaign (attributed to North Korean state-sponsored group Famous Chollima) specifically engineered malicious npm packages to deceive AI coding agents operating through MCP-like interfaces into installing credential-stealing malware. The packages were designed to look legitimate to AI agents even when a human reviewer would have flagged them.

In June 2026, Xygeni confirmed the ollama-helpers and openai-agents-helpers clusters (over 35 combined versions published in coordinated waves) directly targeting packages used in agentic development workflows where MCP connections are common. When an AI agent installs a dependency autonomously through an MCP server, there is no human reviewer between the malicious package and execution.

What Is MCP in the Context of AI Supply Chain Security? #

MCP sits at the intersection of AI security and software supply chain security. It is the layer that connects AI models to the tools, repositories, and infrastructure that define the modern SDLC, which makes it simultaneously the most powerful integration point and the most exposed attack surface in AI-native development.

Traditional AppSec stops at the repository. EDR watches the operating system. Neither was built to understand MCP servers, tool calls, or AI-mediated dependency installation. The gap between them is exactly where MCP-based attacks land.

Securing MCP requires visibility into what MCP servers are running, what tools they expose, what the model is invoking, and whether the dependencies and files being handled have been validated. That is AI inventory, behavioral monitoring, and supply chain security combined into a single problem.

Securing MCP With Xygeni
#

MCP security requires more than policy documents and best-practice checklists. It requires continuous visibility into what MCP servers are running across your developer environments, behavioral monitoring of every tool call the model makes, and the ability to block malicious dependencies at the endpoint before they execute, before a signature exists. Understanding what is Model Context Protocol is key.

Xygeni’s AI Security platform covers the full MCP attack surface: inventorying every MCP server through AI-SPM, detecting tool poisoning, prompt injection, and insecure MCP configurations through AI Security scanning aligned to OWASP MCP Top 10, and enforcing policy at the developer endpoint through Shield, blocking unapproved MCP servers and malicious dependencies before they reach the pipeline.

If your teams are running AI coding assistants, the MCP layer is already part of your attack surface. The question is whether you can see it.

FAQ #