What Is Model Context Protocol (MCP)?

Legacy AI models operated solely on what they were trained on. To generate real business value, models need to read, write, and act on current information inside the organization.

Why AI Models Need MCP: The Custom Integration Problem

A trained model knows only what existed at its cutoff. It doesn’t know about changes a sales team made an hour ago, the ticket support closed minutes before the model runs, or the file finance saved yesterday. To make relevant decisions, the AI model needs safe, governed, real-time access to current data.

Before MCP, engineering teams solved this with custom code. Every model needed its own integration to every database, SaaS application, and internal tool. Connect three models to four systems, and the result is 12 separate integrations to build, secure, and maintain. This is the M x N problem, and it scales poorly. Each new model or data source multiplies the number of connections a security team has to write, patch, and monitor, which creates inevitable vulnerabilities.

The scale of the challenge is measurable. Zscaler ThreatLabz found that enterprise AI and machine learning (AI/ML) activity grew 91% year over year in 2025, spreading across more than 3,400 applications. Data transfers to AI tools rose 93% in the same period, reaching 18,033 terabytes. Few security teams can hand-code and secure a custom integration for every one of those connections. Managing that volume without a shared standard has become an operational security bottleneck.

How MCP Acts as the USB-C for AI Applications

Anthropic built MCP to solve that problem with an open standard: a common architecture for every client and server relationship. In this model, each AI application acts as an MCP client, and each data source or tool exposes an MCP server. Any client may communicate with any server with no additional custom coding needed between them.

MCP changes the math. With M models and N data sources, teams once had to write M x N integrations. With MCP, they build M clients and N servers, and every one of them interoperates.

Take the earlier example. Three models and four systems drop from 12 integrations to 7. The gap widens with every model or system added, so AI adoption can outpace the integration workload. That math explains how fast MCP has spread.

MCP runs on three defined roles and one common message format. Understanding each part shows where the security risk sits.

The Core Triad: Hosts, Clients, and Servers

Before MCP, developers built a custom connector between every model and every data source they wanted it to reach. MCP replaces that tangle with a three-part structure, and each part has a distinct job.

• Host: the AI application a user works in, such as Claude Desktop or an AI-enabled integrated development environment (IDE)
• Client: the component inside the host that opens and holds a secure connection to a single server
• Server: the lightweight service that supplies data, files, or tools to the client

Within this host sits the MCP client. This dedicated component opens and maintains a connection to a single server. Multiple clients may operate within a given host, and each client controls its own independent connection to a server. As such, if a session fails or is compromised, it cannot cause a cascading effect on other sessions.

The MCP server is the lightweight service that presents enterprise data, tools, and prompt templates to the client in a format usable by the model. A server may reside locally on a laptop, accessing local files, or it may run in the cloud as a front end to an enterprise database that many users share. Regardless of where it runs, a server presents only what it was designed and authorized to present.

How the Transport Layer and JSON-RPC Move Messages

All traffic between a client and a server uses JSON-RPC 2.0,  a simple request-and-response format that gives every MCP message the same structure. How those messages travel is the transport layer’s job, and MCP defines two transport methods.

Standard Input/Output (stdio) transports all data within one machine. The client runs the server as a process, and the two exchange JSON-RPC messages via the standard input/output streams. Because no network ports are opened during this exchange, it can be very fast and provides good protection against outside interference.

Server-Sent Events (SSE) transmit data over HTTP and are designed to allow communication with servers teams have no local control over. The client opens one long-lived connection to receive server events and sends its own requests to a separate endpoint. SSE lets teams communicate over the internet using shared systems, and that flexibility puts the burden on the security team to get authentication and encryption right.

The table below summarizes the differences between these two mechanisms:

The choice between these two transport protocols isn't based on performance alone. Local transport keeps exposure contained. SSE opens a network path that security teams must protect like any other exposed endpoint.

MCP servers build their functionality around three primitives. Each primitive transfers control to a different entity, and understanding where that control sits is just as important as understanding how the primitive works.

Prompts: Standardizing the User Interface

Prompts are predefined templates that standardize how users interact with the model. Examples include structuring a code review, filing a bug report, or generating a summary in a consistent, repeatable format.

Users usually choose prompts through a slash command in modern development tools. This design choice gives users predictability because they always know which workflow will run before it executes.

Resources: Providing the Contextual Data

Resources are read-only data that a client can pull into the model’s context. Examples of resources include local files, real-time API queries, and static database views.

Each resource has its own address, allowing clients to specifically identify which resource they wish to retrieve. Resources provide the model with the necessary background information to produce an accurate response based on current information, rather than relying on stale training data.

In this case, control resides with the application hosting the model. The host determines which resources to load at what time, and this allows developers to establish a governance policy to determine what context is delivered to the model in the first place.

Tools: Enabling Models to Take Action

Tools are executable functions that allow a model to perform some type of action in the real world, rather than simply reading about it. Examples of tools include sending emails, modifying records, and executing queries. Each tool includes a name, description, and defined input schema, and they are controlled by the model itself. 

The LLM interprets user intent from the conversation and determines whether a tool call is appropriate without requiring manual intervention. While this ability is what makes tools so powerful, it's also precisely why tools should receive the most thorough security evaluation of the three primitives. A tool that can act without human approval can also act on the wrong record, the wrong inbox, or the wrong database.

The speed of MCP adoption is what makes it a governance priority. An open standard that connects AI models to an organization’s most sensitive systems needs the same zero-trust scrutiny as every other access path into the network.

The Linux Foundation Transition and the Open Ecosystem

In December 2025, roughly a year after its initial release, Anthropic donated MCP to the Agentic AI Foundation (AAIF), which was established as part of the Linux Foundation. Anthropic, Block, and OpenAI co-founded the AAIF, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. No single vendor owns or steers the standard.

Major model providers and cloud platforms now build on the same open specification, and the open source ecosystem has grown with them. More than 10,000 active public MCP servers now cover everything from developer tools to Fortune 500 deployments. The vendor-neutral design is what will keep MCP relevant, and it comes with a cost. No vendor is accountable for how MCP behaves inside a given environment, so each organization writes and enforces its own rules. 

The Data Exposure Surface of AI Integrations

Connecting an internal server directly to an AI model opens a new channel for sensitive data to leave enterprise control, and organizations are already testing the limits of that channel. The Zscaler ThreatLabz 2026 AI Security Report recorded a 93% year-over-year jump in corporate data moving into AI tools in 2025, totaling 18,033 terabytes. ChatGPT alone triggered 410 million data loss prevention (DLP) policy violations, including attempts to share Social Security numbers, source code, and medical records.

And that is AI use before MCP multiplies the number of connection points. AI and ML transactions across the Zscaler cloud grew 91% year over year. Exposing a raw database through an MCP server without real-time monitoring compounds that leakage risk, because every query can pull sensitive information out.

MCP vs. APIs

A standard API offers a fixed set of endpoints, and every model that relies on it needs its own custom integration code written against that specific interface. MCP is designed to solve this limitation. It defines one standard way for any compliant model to discover and call whatever a server exposes, without a developer first hand-coding the connection.

APIs transfer data on request. MCP adds a layer that's built specifically for AI, letting a model reason about which tool to call and when. That flexibility is also the tradeoff. An API only does what its code allows, while an MCP server can be steered by a model's own immediate decisions. And that difference is exactly what security controls need to account for.

The Threat of Autonomous, Machine-Speed Exploits

A malicious prompt injection can let an attacker take control of a model-controlled tool, turning a benign MCP server into a foothold for lateral movement through the enterprise network. The model itself does not have to be compromised. The model simply has to execute commands embedded in data it would normally never process.

The speed of that risk is what's most alarming. In simulated adversarial testing by ThreatLabz, the median time to critical AI failure was 16 minutes, and attackers fully compromised 90% of all test systems within 90 minutes.

Attacks on AI applications now run at machine speed. Defenses have to run there, too. An uninspected MCP endpoint is a weak link in the enterprise supply chain.

These practices are a starting point for bringing MCP servers under zero trust control.

Verify and Inspect

• Require mutual Transport Layer Security (TLS) on all remote MCP transport layers. The client and server must authenticate before exchanging any messages.
• Authenticate every call, not just the session. A tool call is a request to verify, never a standing privilege. 
• Inspect outbound traffic from every MCP server in real time. Continuous inline inspection catches intellectual property and sensitive records leaving through a server before they reach an external destination.
• Configure runtime guardrails to identify normal tool-calling patterns for each server. If a sequence of tool calls deviates from those patterns, flag and block it as the first indication of unauthorized use of the server session.

Discover and Govern

• Only allow each server access to functions, commands, or operations that it was designed to run. There is no reason why a server intended to read customer records, for instance, should also be able to write changes to a production database.
• Run automated AI red team testing against every custom MCP server on a set schedule. Manual testing cannot keep pace with how fast vulnerabilities surface in a server built in-house.
• Map every live connection among applications, clients, and servers. A connection that’s not visible cannot be secured.
• Maintain continuous discovery of new MCP endpoints as teams stand them up. Shadow deployments spread fastest in the gap between what inventory shows and what developers actually built.

These steps work together. A zero trust model for MCP means verifying identity, inspecting traffic, and mapping dependencies as one discipline.

Most MCP security failures trace back to a handful of avoidable setup errors. Watch for these as teams roll out new servers.

• Granting broad permissions by default: A server designed to answer questions ends up with write access to production data because no one scoped it down.
• Skipping authentication on SSE endpoints: Teams treat internal MCP servers with trust by default, leaving remote connections open to anyone on the network.
• Trusting third-party servers without review: A community-built server goes into production straight from a public directory with no one checking what it requests access to.
• Running local servers with excessive file access: A stdio server configured to read an entire directory when it only needs one file.
• Skipping logging and monitoring: No record of which tools were called, when, or by which session, so a breach goes unnoticed.
• Letting shadow deployments spread: Developers standing up servers for testing that never get decommissioned or added to inventory.

Zscaler brings zero trust discipline directly to MCP. Zscaler AI Security auto-discovers every MCP server, agent, and model across the environment, tracing data-to-AI lineage in one unified view. Zscaler AI Guard inspects prompts and tool calls in real time, blocking injection attempts before they reach a model.

Paired with Zscaler AI Security Posture Management (AI-SPM), these capabilities add continuous posture visibility and inline data loss prevention. Together, they make MCP a governed, auditable, and continuously monitored part of the AI stack.

See a Zscaler demo.