Every AI assistant that reads a file, queries a database, or calls an internal tool must connect to that system somehow. Before late 2024, that connection was custom-built every time, a fragile, one-off integration for every pairing of AI model and external system. Model Context Protocol changed that by giving AI applications a standardized way to talk to external tools and data sources. It has since become one of the fastest-growing pieces of infrastructure in enterprise AI, and, for the same reason, one of the least governed.
Furthermore, MCP matters not because it is new technology for its own sake, but because it now sits underneath a large and growing share of agentic AI deployments, often without the authentication, logging, or access controls a system with this much reach would normally require.
What Is Model Context Protocol?
Model Context Protocol, or MCP, is an open standard, originally introduced by Anthropic in November 2024, that defines a consistent way for AI applications to discover and interact with external tools, data sources, and services. Instead of building a custom integration for every combination of AI model and system it needs to reach, a developer implements MCP once, and any compatible AI application can connect to any compatible server.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, making it a vendor-neutral, community-governed standard. It is now supported across major AI platforms, including tools from OpenAI, Google, and Microsoft, and is often described as a universal connector for AI, similar to how a single port standard replaced a drawer full of proprietary cables.
How Does Model Context Protocol Work?
MCP operates on a client-server architecture built around three components.
- The host application: This is the AI assistant, IDE, or agentic workflow platform the end user interacts with. It manages overall context and coordinates connections to one or more MCP servers.
- The MCP client: Embedded within the host, the client manages the connection to an individual MCP server and handles discovery of the tools that server exposes.
- The MCP server: This is the component that exposes specific tools, resources, and prompts, such as a database query function, a file system connector, or an internal API, that the AI application can use.
When a host connects to a server, the client requests a list of available tools, and the AI model decides which ones to invoke based on the task at hand. The specification standardizes how that discovery and invocation happens, but leaves authentication, authorization, and transport security largely up to whoever implements each host, client, and server.
Why Does MCP Matter for Enterprise AI?
Before MCP, connecting an AI model to internal systems required a fragile, custom integration for every pairing of model and tool, an approach that does not scale as organizations adopt multiple AI platforms and dozens of internal systems. MCP solves what is often called the M×N integration problem: instead of building M times N custom connectors for M AI applications and N tools, developers build M clients and N servers, and any client can talk to any server.
Adoption has moved quickly as a result. According to Wiz’s research on MCP security, MCP servers were present in at least 80 percent of observed cloud environments by early 2026, with roughly 5 percent of those environments running at least one internet-facing MCP server. That speed of adoption is precisely why governance leaders need to understand the protocol now. It has become common enough that attackers can reasonably assume an MCP integration exists somewhere in a target environment.
What Are the Security Risks of MCP?
Because the protocol standardizes discovery and invocation but not security controls, an MCP server is only as secure as the team that deployed it. Several risk patterns recur across early enterprise deployments.
- Missing authentication: Independent research scanning more than 500 MCP servers found that 38 percent lacked any authentication, meaning any client that could reach the server could invoke its tools.
- Excessive agency: MCP servers frequently expose more capability than a task requires, letting an AI agent take actions well beyond what it was asked to do.
- Rogue server registration: Weak session binding and the absence of server attestation can allow session hijacking or the acceptance of untrusted servers into a workflow.
- Prompt injection through tool descriptions: Malicious instructions embedded in a tool’s description or returned data can manipulate an AI agent into taking unintended actions, since the model treats that content as legitimate context.
- Supply chain exposure: A compromised or poisoned MCP server can act as a backdoored dependency, similar in effect to a compromised software library, except the entry point is a tool description rather than code.
Who Is Responsible for Securing MCP Deployments?
Responsibility for MCP security is distributed across roles that do not always coordinate closely today. Development teams building or integrating MCP servers are responsible for implementing authentication, input validation, and least-privilege scoping at the server level. Security and identity teams need to bring MCP servers into existing identity and access management programs, since an MCP server effectively functions as a privileged service account once connected. Governance and risk teams need to treat MCP servers as part of the AI supply chain, subject to the same scrutiny applied to any other third-party integration. Without clear ownership across these functions, MCP servers tend to get deployed the same way shadow IT tools historically have quickly, and without a formal security review.
Where Do MCP Deployments Typically Break Down?
MCP risk concentrates in a few predictable places. Local, developer-run MCP servers are often assumed to be safe because they run inside a user’s own environment, but convenience frequently overrides secure configuration, and a locally deployed server can quietly become internet-facing. Internal MCP servers built quickly to connect an AI assistant to a database or internal API often skip authentication during proof-of-concept phases, and those configurations sometimes reach production unchanged. Third-party and marketplace MCP servers introduce vendor risk that traditional software procurement was not built to evaluate, since a poorly secured server can be added to a workflow as easily as any legitimate one.
How Should Organizations Secure Their MCP Deployments?
Treating MCP as enterprise infrastructure, rather than a developer convenience, changes how it gets secured. Inventory every MCP server in use, including locally run instances, the same way any other asset would be tracked, since unmonitored servers cannot be governed.
- Enforce authentication and least-privilege scoping: On every server, rather than assuming an internal network boundary provides sufficient protection.
- Extend monitoring and logging: To cover MCP tool invocations, feeding that telemetry into existing SIEM and SOAR workflows so unusual tool usage can be detected the same way anomalous account activity would be.
- Apply human approval gates: For any MCP-connected action that is irreversible or high-impact, such as financial transactions or destructive data operations.
- Assess third-party MCP servers through vendor risk processes: Evaluating data handling, authentication support, and maintenance practices before connecting them to production systems.
In a Nutshell
Model Context Protocol solved a real integration problem, and its rapid adoption reflects that. But infrastructure that spreads this quickly, across development teams, business units, and vendor ecosystems, tends to outpace the governance built around it. Organizations that treat MCP servers as privileged, monitored components, rather than lightweight developer tooling, will be better positioned as agentic AI adoption continues to accelerate.
The gap between how fast MCP is being deployed and how well it is being governed is exactly where the next wave of AI-related incidents is likely to originate.
| Talk to Ampcus Cyber to assess whether your organization’s MCP deployments are inventoried, authenticated, and monitored before an attacker finds the one that isn’t. |
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
