The Model Context Protocol (MCP) is one of those quiet technologies that reshapes the software ecosystem without calling attention to itself. It lives at the boundary between large language models and the operational systems that actually run the enterprise—databases, ticketing systems, identity platforms, CI/CD pipelines, SaaS applications, and the mishmash of APIs that connect them all.
Where APIs let software talk to software, MCP defines how AI agents talk to everything else.
At its core, MCP is a consistent protocol that allows AI clients—assistants, agents, or embedded models—to communicate with tool servers. Think of it as a USB‑C port for AI tools, with actions and data access as the payload.
This structure brings order to what would otherwise be a wild west of plugins and custom integrations. But it also creates a new control surface—one that must be treated with the same rigor as any other API boundary.
Here’s where MCP security stands today, the risks enterprises need to understand, and what’s coming next.
The MCP Architecture
Fundamentally, MCP is a control and messaging protocol that sits between an AI client and any number of tool-providing servers. The diagram may look deceptively simple, but the operational reality is that it introduces a new orchestration layer—one that security teams must evaluate like an API mesh backed by a probabilistic engine.
The MCP Client
The MCP client is the AI-side execution environment. It might be:
- A desktop assistant
- An internal containerized agent
- An embedded AI module inside a SaaS product
Its form depends entirely on where and how it’s deployed.
The Authorization Model MCP Does Not Supply
This is the point most enterprise MCP writing gets wrong, and it is worth stating plainly: MCP does not define a role-based access control model. Authentication is optional rather than required. The protocol does not specify how a session — or, since July 2026, an individual request — maps to a verifiable enterprise identity. The NSA’s May 2026 guidance makes exactly this observation, and adds that many production MCP server implementations ship with no authentication controls at all.
MCP assumes an authorization layer it does not provide. Whatever RBAC governs your agents is something your organization built, bought, or forgot to install. Where that layer exists, it has to determine three things:
- Which tools and actions a given agent may invoke
- What credentials the client may use to reach MCP servers
- How state — conversational and operational — is maintained and scoped
Where it does not exist, the effective policy is whatever the service account behind the tool happens to permit. That is the default condition in a large share of deployments today, and it is the single most important thing for a security leader to verify before an MCP rollout leaves pilot.
Key Risks
The MCP client carries several important risks:
- Client compromise → exposes downstream tools
- Prompt injection → influences which tools are called and how
- State confusion → multi-turn conversations blur intent
The client is not “just UI.” It is an automation engine with delegated authority. Security models must treat it accordingly.
The MCP Server
The MCP server is where theoretical AI behavior becomes real-world side effects—which is precisely why most risk accumulates here. Once you expose tools, resources, or prompts, you’re effectively publishing a micro-API surface.
Tools
Executable actions—anything from “create a ticket” to “provision infrastructure.”
Tools carry verbs, and verbs carry risk.
Resources
Data sources such as files, APIs, or customer records.
Poor scoping turns these into liability.
Prompts
Reusable instruction sets.
These can quietly encode business workflows—and expand agent capabilities without formal review.
Key Risks
Familiar patterns appear here, often amplified:
- Over-privileged service accounts
- Insufficient parameter validation
- Capability creep as new tools quietly accumulate
- Trust amplification where agent recommendations bypass human skepticism
In effect, every MCP server functions as:
- An API gateway + a service account + business logic + user trust.
And when trust is amplified, blast radii expand—often quietly.
Security teams have seen versions of this in SOAR, RPA, and integration middleware. What’s new is how aggressively AI agents explore the capabilities you give them.
Deterministic vs. Probabilistic Control
This is the shift that makes MCP genuinely different from the middleware it resembles.
Traditional automation is deterministic. Run this task. Call this API. Move this file. The intent is declared before execution, and every control in the stack — RBAC, schema validation, approval workflow — was designed around that declaration.
MCP orchestration is probabilistic. The agent predicts what a competent operator would try to do next, then does it.
Validation and RBAC were built for explicit intent, not inferred intent. Controls now need to authenticate the agent, authorize the action, validate the parameters, and — new territory — evaluate whether the intent itself is reasonable. Security moves from verb validation toward behavioral validation.
The next frontier is making agent inference auditable and governable.
Where MCP Sits in The Enterprise Stack
In a modern stack diagram, MCP occupies an awkward but strategically revealing spot. It perches above the APIs that expose raw capabilities, lurks below the business logic that defines actual policy and process, and runs parallel to the automation and orchestration layers enterprises already use. That is a diplomatic way of saying MCP inserts itself directly into the chain of authority without automatically inheriting the guardrails of any of its neighbors.
This overlap makes MCP feel, at times, like a service mesh, an API gateway, iPaaS tooling, or RPA automation. Like every tool in that family, it inherits both their power and their vulnerabilities — with one difference. The others execute a playbook. MCP executes a guess.
In a modern architecture, MCP occupies a revealing position:
- Above APIs → abstracting raw capabilities
- Below business logic → executing policy rather than defining it
- Parallel to automation platforms → but driven by intent rather than fixed playbooks
This overlap makes MCP feel, at times, like:
- A service mesh
- An API gateway
- iPaaS tooling
- RPA automation
And like every tool in that family, it inherits both their power and their vulnerabilities.
What Changed in the 2026-07-28 Specification
On 28 July 2026 the MCP maintainers shipped the largest revision of the protocol since launch, along with updated first-tier SDKs. The headline is that MCP is now stateless at the protocol layer. Several of the changes invalidate assumptions baked into MCP threat models written in 2025.
| Change in 2026-07-28 | What it replaces | Security consequence |
| Stateless protocol core | The initialize / initialized handshake and protocol-level sessions, including the Mcp-Session-Id header | Session-scoped monitoring and rate limiting no longer have an anchor. Every request must carry its own identity and version metadata, and every request must be authorized on its own merits. |
| Server-minted state handles | Cross-call state that used to ride the session | State is now ordinary tool arguments. Handle forgery, weak handle scoping, and cross-tenant handle reuse become live risks — and they are invisible to controls that watched the session header. |
| server/discover RPC (mandatory) | Capability exchange during the handshake | A single unauthenticated-by-default endpoint now advertises a server’s full capability surface. Treat it as reconnaissance-relevant and decide deliberately who may call it. |
| Multi Round-Trip Requests (MRTR) | Server-initiated requests such as roots/list, sampling/createMessage and elicitation/create | Servers now signal that they need more information by returning an input_required result the client retries. Approval and human-in-the-loop checkpoints must be rebuilt around the retry, not around an inbound server call. |
| Authorization hardening | Looser OAuth practice in earlier revisions | Clients must validate the iss parameter (RFC 9207) before redeeming an authorization code, must key stored credentials by issuer, and must re-register when the authorization server changes. |
| Client ID Metadata Documents | OAuth 2.0 Dynamic Client Registration (RFC 7591), now deprecated | A concrete migration item for anyone who stood up MCP auth in 2025. DCR remains only for backwards compatibility with authorization servers that cannot do better. |
| Roots, Sampling and Logging deprecated | Three long-standing core features | Functional through a minimum twelve-month window, but threat models and tooling built around Sampling in particular now have an expiry date. |
| Extensions promoted: MCP Apps and Tasks | Experimental status | Server-rendered UI delivered into the agent client is untrusted content and must be sandboxed. Long-running tasks extend the window in which delegated authority is live. |
Two governance changes matter as much as the technical ones. The specification now carries a formal feature lifecycle — Active, Deprecated, Removed — with a minimum twelve-month window between deprecation and earliest removal, and a published registry of deprecated features. And a formal extensions framework means new capabilities can ship and stabilize as opt-in extensions before, if ever, entering the specification proper. For security architects, that is the difference between a protocol you can write a three-year control plan against and one you cannot.
The practical migration note: existing servers and clients did not break on 28 July. New clients that speak 2026-07-28 fall back when they reach an older server. But the transport rework is a clean break, and organizations running MCP in production should be validating against the new revision now rather than at the next audit.
The Record Is No Longer Theoretical
Through 2025 the case for taking MCP seriously rested on architecture. It now rests on incidents.
- postmark-mcp (September 2025). An npm package impersonating a legitimate Postmark integration shipped fifteen clean, functional versions before a later release added a single line that silently blind-copied every processed email to an attacker-controlled address. It is the first tracked malicious MCP server supply-chain incident. Because it was a behavioral backdoor rather than a code flaw, no CVE was assigned — and pulling the package from the registry did not stop deployed environments from leaking.
- CVE-2025-6514, mcp-remote. A critical command injection flaw in an OAuth proxy with more than 437,000 downloads, used in integrations from Cloudflare, Hugging Face, and Auth0. A malicious endpoint could send a crafted authorization URL that reached the system shell, yielding remote code execution on the client machine and access to API keys, cloud credentials, local files, and SSH keys.
- Smithery platform compromise (October 2025). A path traversal flaw in a managed MCP deployment platform allowed an attacker to read arbitrary files from the container filesystem, including environment files holding API keys, database credentials, and OAuth secrets for more than 3,000 deployed MCP applications. Managed marketplaces are themselves an attack surface.
- CVE-2025-54136 in Cursor. A high-severity flaw allowing a malicious MCP server to achieve persistent code execution on a developer’s machine through the IDE’s handling of MCP configuration.
- SDK-level RCE (April 2026). Researchers disclosed an architectural remote code execution vulnerability in the reference MCP SDK. Because so much of the ecosystem builds on that SDK, the flaw propagated to inheriting frameworks, with CVEs assigned across LangFlow, LiteLLM, Agent Zero, GPT Researcher, and others.
Two structural lessons run through all of them. First, verification of identity is not verification of behavior: a verified publisher can still ship a malicious update. Second, the blast radius of a compromised MCP server is the union of every credential the agent was trusted with — which, in most deployments, nobody has inventoried.
One number worth putting in front of a board: GitGuardian’s 2026 secrets-sprawl research found 24,008 secrets in MCP-related configuration files on public GitHub, of which 2,117 were still valid. Gartner projected in April 2026 that by 2028, 25 percent of enterprise GenAI applications will experience five or more minor security incidents per year, up from 9 percent in 2025 — and tied the increase explicitly to MCP.
Guidance Has Arrived
On 20 May 2026 the NSA’s Artificial Intelligence Security Center published a Cybersecurity Information Sheet titled “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation.” It is seventeen pages, public release, and it is measured rather than alarmist. The core finding is that MCP’s adoption has outpaced the development of its security model, leaving organizations exposed to risks the protocol’s designers did not fully anticipate.
Among the risks it names: uncontrolled automated actions, where an AI system using MCP independently decides to invoke new tools or take new actions; and insufficient input screening, where data passes between systems without adequate checks on what it contains, allowing hidden instructions to slip through.
Its recommendations translate cleanly into a control set:
- Go beyond the official MCP documentation. Vendor security guidance is a floor, not a program.
- Use only actively maintained MCP tools from reputable providers and repositories.
- Apply your most rigorous existing software vetting — code audit included — to any MCP tool before deployment.
- Separate systems and data by trust level, and keep agent networks segmented from sensitive data stores.
- Put a filtering outgoing proxy or enterprise DLP in front of external MCP connections, with resource URLs and access methods pinned tightly enough to limit unintended leakage.
- Sign MCP messages with expiration timestamps and replay protection.
NIST launched its AI Agent Standards Initiative in February 2026, which points the same direction: agent communication security is moving from optional good practice toward a formal expectation. When defense agencies publish protocol-specific guidance, it is a signal that the protocol has become load-bearing infrastructure.
The Current State of MCP Security
The Current State of MCP Security
Enterprise security around MCP environments is improving but still maturing. Most organizations have the basics — identity controls, segmentation, logging — but the recurring gaps are consistent:
- Misconfiguration, including servers exposed without authentication or transport security
- Tool sprawl and an uninventoried server estate
- Over-permissioned integrations and long-lived static credentials
- Lack of consistent policy enforcement across clients, servers, and the agents between them
- No human checkpoint on destructive or irreversible actions — deletions, bulk modifications, financial transactions, external data transfers, outbound communications
The architecture itself is elegant. Its risk comes from delegation at scale. Treat MCP servers like plugins and you will get plugin-level security. Treat them like production integration infrastructure — inventoried, vetted, scoped, monitored, and subject to change control — and you have a fighting chance.
Enterprises that build their MCP governance program this year will spend it shaping policy, tooling, and contractual language. Enterprises that wait will spend the same year writing postmortems.
MCP provides the wiring. Security still needs to install the circuit breakers.