Model Context Protocol: What Security Teams Need to Know Before Agents Scale

AI agents used to be limited to what a single model could reason about inside a chat window. That changed when Anthropic introduced the Model Context Protocol (MCP) in November 2024, giving language models a standardized way to reach real tools, real data, and real systems without a custom integration for every connection. Since then, MCP has moved from a promising open-source release to the connective layer for agentic AI, adopted by OpenAI, Google DeepMind, Microsoft, and thousands of enterprise teams building autonomous workflows.

For security architects and platform teams, that pace of adoption raises a practical question. What is MCP, how does it actually work, and what needs to be in place before agents start using it at scale? This article breaks down the fundamentals: what the protocol is, how it works, its core architecture, and why getting it right matters more with every agent an organization puts into production.

What Is the Model Context Protocol?

The Model Context Protocol is an open standard that defines how AI models connect to external tools, data sources, and services. Before MCP, every connection between a model and a system such as a CRM, a code repository, or an internal database required its own custom-built integration. An organization running several AI applications against dozens of tools could end up maintaining hundreds of one-off connectors, each with its own authentication method, data format, and failure mode.

MCP replaces that fragmentation with a single, shared interface. A tool or data source exposes itself once, through an MCP server, and any MCP-compliant AI application can connect to it without additional custom code. It works in both directions: models can pull in context, such as a customer record or a file, and they can also trigger actions, such as updating a ticket or sending a message.

The protocol's growth has been fast by any standard. Within roughly a year of its release, MCP had been adopted across the major model providers and folded into mainstream developer tools, and in December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. That move made MCP vendor-neutral, community-governed infrastructure rather than a single company's standard, and it reflects how central the protocol has become to agentic AI development.

How the Model Context Protocol Works

MCP works through a request-and-response cycle between a model and the tools it needs. When an AI application starts a session, it discovers which tools, data sources, and prompt templates are available from each connected server. From there, three things happen every time the model needs to act:

1. Selection. Based on the user's intent and the conversation's context, the model decides which available tool fits the task.
2. Invocation. The application sends a structured request, typically formatted as JSON-RPC, containing the input parameters the tool needs.
3. Execution. The server carries out the request, whether that's a database query, an API call, or a file read, and returns the result for the model to use in its response or next action.

This cycle repeats for every tool call an agent makes, and a single task can involve dozens of them in sequence. Consider a support agent handling a customer escalation: it might query a CRM for account history, pull recent activity from a logging tool, draft a resolution, and then update a ticketing system, all through separate MCP servers coordinated by the same client. From the user's perspective, that looks like one smooth interaction. Under the hood, it's several independent trust boundaries being crossed in quick succession, which is exactly where governance needs to have visibility.

Core Architecture: Hosts, Clients, and Servers

MCP's architecture is deliberately simple on paper: a host, a client, and a server. Each one plays a distinct role, and each one introduces its own considerations for anyone responsible for securing the environment.

MCP Host

The host is the AI application the end user actually interacts with, such as an AI assistant, a coding tool, or an internal agent platform. The host manages the overall session, holds the model's context, and coordinates one or more clients on the model's behalf. Because the host is where user intent originates and where results are surfaced, it's also where consent and session isolation matter most. A host that fails to separate context between sessions creates the conditions for one user's data to leak into another's.

MCP Client

For every server it connects to, the host creates a dedicated client. The client manages that one connection: it handles authentication, discovers what the server exposes, and translates the model's tool selections into properly formatted requests. Clients and hosts typically run on the same machine or environment, which means a compromised client can expose every server it's connected to.

MCP Server

The server is where the actual capability lives. It can be local, such as a filesystem or a script running on the same machine, or remote, such as a hosted API sitting behind a company's firewall. Servers expose their capabilities through tools, resources, and prompts, and they can wrap anything from an internal ticketing system to a public SaaS product. Because servers often carry elevated permissions to do their job, an over-privileged or poorly maintained server is one of the most common ways an agent ends up with more access than it should have.

Key Features and Capabilities

MCP's capabilities are organized around three primitives, plus a set of protocol-level features that have matured as adoption has grown.

Tools, Resources, and Prompts

• Tools are actions the model can trigger, such as sending a message or creating a record.
• Resources are data the model can read, such as a file, a database row, or a support ticket.
• Prompts are reusable templates that structure how a model approaches a recurring task.

Together, these three fundamental building blocks let a single MCP server expose the full functional surface of a complex system in a way any compliant client can understand, without the client needing to know the details of how that system works internally.

Two-Way, Standardized Connections

MCP was built for two-way communication. A model doesn't just retrieve information; it can also act on it, which is what makes MCP foundational to agentic AI rather than simple retrieval-augmented generation.

A Maturing Security Baseline

The protocol's specification has evolved significantly since its initial release. OAuth 2.1 became the baseline authorization framework for remote MCP servers in the March 2025 update, and the November 2025 revision tightened those requirements further, mandating stricter proof-of-possession checks and closing gaps around token handling, alongside introducing asynchronous operations, statelessness, and server identity as official protocol features. These additions matter, but they define a baseline, not a guarantee. The specification standardizes how a model discovers and calls a tool; it leaves the actual implementation of authentication, authorization, and transport security to whoever builds and deploys each host, client, and server.

An Official Registry and Growing Ecosystem

MCP now has a community-driven registry for discovering available servers, official SDKs across major programming languages, and an ecosystem that includes pre-built connectors for common enterprise systems. That growth is a feature for developer velocity and a governance challenge in equal measure: the easier it is to add a new MCP server, the easier it is for one to appear in an environment without security ever knowing it's there.

Why MCP Matters for Agentic AI

MCP matters because it's the mechanism that turns a language model into something that can actually do things. A model with no tools can only respond to what it's asked in the moment. A model connected to MCP servers can look something up, take an action, and chain several of those together to complete a multi-step task without a human directing every move. That shift, from generating text to executing workflows, is the defining characteristic of agentic AI, and MCP is quickly becoming the default way that shift gets implemented.

That same capability is what makes governance non-negotiable. Because MCP standardizes tool discovery and invocation but doesn't enforce security at the protocol level, an MCP server is only as secure as the team that deployed it.

The risk isn't theoretical. In September 2025, researchers found a compromised npm package impersonating the legitimate Postmark email MCP server. The malicious version behaved identically to the real one for fifteen releases, earning trust and adoption, and then quietly added a single line of code that copied every outgoing email to an attacker-controlled address. Because MCP servers typically run with broad, pre-authorized access to whatever they connect to, the exposure extended to anything sent through that server, including password resets, invoices, and internal correspondence, for over a week before it was caught.

OWASP's MCP-specific security guidance documents this as one pattern among several. Alongside supply chain compromise, the most common MCP risks include tool poisoning, where a malicious or manipulated tool description misleads the model, and the confused deputy problem, where a server acts on its own broad privileges instead of the requesting user's actual permissions. Each traces back to the same root cause: a model, a client, or a user trusting an instruction, a tool description, or a dependency it has no reliable way to verify.

This is why full AI Security Posture Management (AISPM) needs to extend to MCP specifically, not just to the agents sitting on top of it. Discovery, risk assessment, and runtime enforcement all have to account for the fact that the agent, the client, and the server are three separate trust boundaries, each capable of failing independently.

Getting Started With MCP

Adopting MCP doesn't require choosing between speed and security, but it does require sequencing the two correctly.

1. Inventory before you integrate. Know which MCP servers, local and remote, are already in use across the organization before adding more. Shadow MCP adoption is easy when any developer can spin up a server in minutes.
2. Treat every server as untrusted until proven otherwise. Vet MCP servers the way you'd vet any third-party dependency with elevated access, and don't assume a tool's description or behavior at install time will hold at runtime.
3. Apply least privilege at the server level. Scope permissions to what a given tool actually needs, rather than relying on the model to self-limit what it invokes.
4. Build in human review for high-risk actions. Not every tool call needs approval, but the ones that touch sensitive data or take irreversible actions should.
5. Pair adoption with continuous visibility. Know what agents exist, which MCP servers they're connected to, and what they're actually doing at runtime, not just what they're configured to do.

Organizations that get this sequence right can move quickly on agentic AI without treating every new integration as a fire drill. Zenity's MCP Server Security Report breaks down the specific governance gaps showing up across real enterprise deployments, for teams that want a closer look before they scale further.

Securing MCP Before It Scales

The Model Context Protocol is a major unlock for what AI agents can do inside an enterprise. It's also a new, fast-growing attack surface that traditional application security tools weren't built to see.

Adopting MCP without visibility into what it's actually doing is not a risk worth taking as agents move from pilot to production. Zenity gives security teams the discovery, posture management, and runtime enforcement they need to let agents use MCP safely, from the first server they connect to the thousandth. Book a demo to see how Zenity secures MCP across your environment.

FAQs About the Model Context Protocol

What is the Model Context Protocol in simple terms?

The Model Context Protocol, or MCP, is an open standard that lets AI models connect to external tools, data, and services through one shared interface instead of a custom integration for every connection.

Who created MCP?

Anthropic introduced MCP in November 2024 and open-sourced it from the start. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a Linux Foundation initiative co-founded with Block and OpenAI.

Is MCP only used by Claude?

No. OpenAI, Google DeepMind, and Microsoft have all adopted MCP across their platforms, and it's supported by a wide range of developer tools and enterprise systems beyond any single model provider.

What's the difference between an MCP host, client, and server?

The host is the AI application the user interacts with. The client manages the connection to a single server on the host's behalf. The server exposes the actual tools, resources, and prompts that give the model something to work with.

Does MCP include built-in security?

MCP standardizes how models discover and call tools, and its specification now includes OAuth 2.1 for remote server authentication. It doesn't enforce authorization, input validation, or runtime monitoring, so the security of any given deployment depends on how it's implemented.

What are the biggest risks associated with MCP?

Common risks include servers with no authentication, tool poisoning through manipulated descriptions or outputs, and over-privileged servers that give a compromised or manipulated agent more access than intended.

How is MCP different from a typical API integration?

A traditional API integration is built for one specific connection. MCP is a shared protocol: build a server once and any MCP-compliant AI application can use it, which is what makes it scale across an ecosystem rather than one product at a time.

How should a security team get started with MCP governance?

Start with discovery. Before adding controls, security teams need a full inventory of which MCP servers are already connected to which agents, followed by risk assessment and runtime enforcement layered on top.