Glossary · By Riley Quinn (pen name) · 15 October 2026

What Is the Model Context Protocol (MCP)? A Security-First Explainer

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems. An AI application, the host, runs one MCP client per MCP server. Servers expose tools the model can call, resources that supply data, and prompts that template interactions. Messages use JSON-RPC 2.0 over stdio or Streamable HTTP.

That definition explains why MCP matters to security teams. Every MCP server you connect gives an AI model new capabilities, and the protocol itself leaves most of the enforcement to you. This explainer covers how MCP works, what changed in the current specification, and where the security responsibilities sit.

How MCP works

According to the MCP architecture documentation, there are three participants:

Host: the AI application, such as a chat app or an IDE, which coordinates one or more MCP clients.
Client: a component inside the host that maintains a connection to one MCP server. The host creates one client for each server.
Server: a program that provides context and capabilities to the client. It can run locally on the same machine or remotely as a service.

Servers offer three main building blocks, which the specification calls primitives: tools, functions the model can execute; resources, data for the user or the model; and prompts, templated messages and workflows. Tools are model-controlled, meaning the model can discover and call them on its own based on the conversation. That is the source of most MCP risk.

The specification defines two standard transports. With stdio, the client launches the server as a local subprocess and exchanges messages over its standard input and output. With Streamable HTTP, each message is an HTTP POST to a single server endpoint, which suits remote servers shared by many clients.

What changed in the 2026-07-28 specification

The current protocol version is 2026-07-28, according to the project's versioning page. The changelog lists several changes that matter for security and operations:

MCP is now stateless. The initialize handshake was removed, and every request carries its protocol version and client capabilities.
No more protocol-level sessions. The Mcp-Session-Id header was removed from Streamable HTTP. Servers that need state now pass explicit handles as ordinary tool arguments.
A new discovery call. Servers must implement server/discover.
Deprecations. Roots, Sampling and Logging are deprecated. The older HTTP+SSE transport, deprecated since the 2025-03-26 version, is now formally reclassified as Deprecated, and users should migrate to Streamable HTTP.

The stateless design brings a new risk. The Security Best Practices guide says "MCP servers MUST NOT treat possession of a state handle as authentication." In our assessment, teams moving servers to the new version should treat state handles like any other identifier an attacker can guess or steal, and bind them to the authenticated user on the server side.

Where MCP security responsibilities sit

The specification is direct about its limits. It says "Tools represent arbitrary code execution and must be treated with appropriate caution," that hosts must get explicit user consent before invoking any tool, and that tool descriptions "should be considered untrusted, unless obtained from a trusted server." It also says "MCP itself cannot enforce these security principles at the protocol level." In practice, security depends on how hosts, clients and operators implement them. Five points stand out:

Keep a human able to say no. The tools specification says "there SHOULD always be a human in the loop with the ability to deny tool invocations." See human-in-the-loop.
Treat tool descriptions as input, not trusted text. The local server security guide notes that a server sends its tool names and descriptions to the client "and the model reads them as instructions." That is the mechanism behind tool poisoning.
Do not mistake stdio for isolation. The same guide says "The stdio transport is not a sandbox" and that a malicious server can influence how the agent uses the tools of every other configured server. Use real sandboxing for servers you do not fully trust.
Control where servers can connect. The guide advises denying network access where none is needed and using an egress proxy with a domain allowlist. Our MCP SSRF analysis shows what goes wrong when this is missing.
Get authorization right on remote servers. The authorization specification is optional, and applies to HTTP transports only. When used, the server acts as an OAuth 2.1 resource server and "MUST validate that access tokens were issued specifically for them as the intended audience." Passing a client's token straight through to a downstream API is an anti-pattern the project warns against. Scope permissions using least privilege.

For how MCP fits into the wider agent threat picture, see our agentic AI security landscape.

Frequently asked questions

What is MCP in simple terms?

MCP, the Model Context Protocol, is an open-source standard for connecting AI applications to external systems such as data sources, tools and workflows. The project compares it to a USB-C port for AI applications: one standard way to plug a model into many systems.

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

The host is the AI application. It creates one MCP client for each MCP server it connects to, and each client keeps a dedicated connection to its server. The server is the program that provides context and capabilities, either locally over stdio or remotely over Streamable HTTP.

What is the latest version of the MCP specification?

As of 15 October 2026, the current protocol version is 2026-07-28. Its headline change is a stateless core: the initialize handshake and protocol-level sessions were removed, and every request carries its protocol version and client capabilities.

Does MCP have built-in authentication?

Authorization is optional in MCP. For HTTP-based transports, the specification defines an OAuth 2.1 based flow in which the MCP server acts as a resource server and must only accept access tokens issued for it. Servers using stdio should instead take credentials from the environment.

Is MCP secure?

The specification sets security principles, such as user consent before tool calls and treating tool descriptions as untrusted, but states that MCP itself cannot enforce them at the protocol level. Security depends on the host, the client, the servers you install and how you run them.

Sources

This article is analysis. Bylines on AIAgentThreats are disclosed pen names of our editorial team. Spotted an error? Email info@aiagentthreats.com. See our Editorial Standards.