MCP is becoming the backbone of every AI agent stack.
Nobody is governing it yet.

Model Context Protocol is now the standard integration layer connecting AI agents to your tools, databases, and APIs. It also has over 40 documented security vulnerabilities and zero coverage in any existing compliance framework.

If you are building any product that uses AI agents, a copilot, an automated workflow, or a customer-facing assistant, there is a very high probability that Model Context Protocol is already part of your stack. MCP is how your agent connects to your database, calls your APIs, reads your files, and invokes tools on behalf of your users. Anthropic, OpenAI, Google, and Cursor have all adopted it. Enterprise platforms are standardizing on it. It is, in the words of its most common description, the "USB-C port for AI agents."

And like USB-C, connecting the wrong thing to it can cause serious damage.

In January 2026, the Coalition for Secure AI, a body that includes Google, Microsoft, and a consortium of enterprise security researchers, published a white paper cataloging nearly 40 MCP-specific security vulnerabilities. These are not theoretical risks. One of the documented threat scenarios — resource content poisoning — directly mirrors the mechanics of the Asana AI data contamination incident, one of the first major enterprise agentic AI security breaches on record.

Here is what makes this a compliance problem, not just a security problem: your SOC 2 audit, your ISO 27001 certification, and your HIPAA documentation were not built to evaluate MCP. Enterprise security teams are increasingly asking MCP-specific questions during vendor reviews. And the companies that can answer them will close deals faster than the ones that cannot.

What MCP is and why it changes the compliance surface entirely

MCP is an open protocol that standardizes how AI agents communicate with external tools and data sources. Before MCP, every integration was a custom build a bespoke connector between your agent and each API, database, or service it needed to access. MCP replaces that with a single, consistent interface: the agent speaks MCP, the tool speaks MCP, and they communicate through a server that brokers the connection.

This is genuinely useful. It dramatically reduces integration complexity and enables AI agents to be composable. You can connect a new tool to your agent without rewriting any agent logic. Claude Desktop, Cursor, and dozens of enterprise agent platforms have adopted MCP as their primary integration layer precisely because of this.

But the compliance surface it creates is fundamentally different from that of a traditional API.

The critical difference: In traditional API security, component A communicates with component B using deterministic logic that your security team can audit, test, and model. In MCP architectures, the router between components is an LLM, a probabilistic, non-deterministic system that interprets intent, makes judgment calls, and can be manipulated through the content it processes. Existing compliance controls cannot inspect semantic intent. They cannot verify that the conversation that triggered an API call was legitimate.

This matters for compliance because the risk is not in your infrastructure; it is in the decision layer. And no current certification framework has controls for a decision layer that reasons, hallucinates, and can be redirected through crafted inputs.

40+ - MCP-specific security vulnerabilities documented by the CoSAI white paper, January 2026

5 - Distinct vulnerability layers across transport, identity, context, privilege, and supply chain

0 - MCP-specific controls in any current SOC 2, ISO 27001, or HIPAA framework

The five layers of MCP risk

The CoSAI white paper and security research from Aembit and Adversa AI converge on a common structure: MCP vulnerabilities span five distinct layers, each creating compliance exposure that traditional frameworks do not address.

Layer 1

Transport & Communication

Insecure channels between agent, MCP server, and tools — including DNS rebinding, replay attacks, and unencrypted context in transit

Layer 2

Authentication & Identity

Static API keys, long-lived tokens, improper token delegation, and unauthenticated endpoints that let bad actors impersonate legitimate agents

Layer 3

Context Integrity

Poisoned context that propagates through agent workflows, context leakage across unrelated processes, and mid-flow context hijacking

Layer 4

Authorization & Privilege

Overbroad agent permissions, privilege escalation through breached tools, and lateral movement across interconnected MCP workflows

Layer 5

Supply Chain

Malicious tool descriptors, typosquatted MCP servers, configuration poisoning, and shadow services that bypass monitoring entirely

The seven MCP threats your security team has probably never modeled

The CoSAI white paper identifies seven threats that are particularly unfamiliar to enterprise security teams — not because they are obscure, but because the attack surface they exploit is brand new. These are the threats most likely to appear in a vendor security questionnaire in the next 12 months.

Threat 01 Identity Spoofing

Weak or misconfigured MCP authentication allows attackers to impersonate legitimate clients or agents. The spoofed agent gains unauthorized access to server resources and corrupts audit trails, making the breach appear as legitimate activity in your logs.

Compliance gap: SOC 2 Logical Access controls assume identity is verified at the human or service level. MCP agent identity is dynamic, session-based, and inherited has no corresponding control in any existing framework.

Threat 02 Tool Poisoning

Malicious modification of tool metadata, configuration, or descriptors causes agents to invoke compromised tools without any visible indication of wrongdoing. The agent operates normally; it is the tool that has been subverted.

Compliance gap: ISO 27001 Annex A.15 covers supplier relationships and procurement. It does not address the integrity of runtime tool descriptors, where an agent dynamically loads and trusts tool definitions that may have been tampered with since deployment.

Threat 03 Full Schema Poisoning (FSP)

Attackers compromise entire tool schema definitions at the structural level, injecting hidden parameters, altered return types, or malicious default values that affect all subsequent tool invocations. FSP is particularly dangerous because it appears legitimate to monitoring systems while corrupting every subsequent interaction.

Compliance gap: This attack has no equivalent in traditional application security. No existing penetration testing methodology or compliance control addresses schema-level integrity for dynamically composed AI tool chains.

Threat 04 Resource Content Poisoning

Attackers embed hidden malicious instructions within data sources that MCP servers retrieve and feed to the agent. When the agent processes this content, the hidden instructions are executed as commands — a form of indirect prompt injection that operates at the data layer rather than the interface layer.

Real incident: The Asana AI data contamination breach followed this exact pattern, in which the intersection of agentic permissions and poisoned content led to real data exfiltration in a production enterprise environment.

Threat 05 Typosquatting & Confusion Attacks

Malicious actors register MCP servers or tools with names nearly identical to legitimate ones, exploiting both human error during configuration and the LLM's tendency to hallucinate similar-sounding tool names. The agent invokes the wrong tool, allowing the attacker to access the interaction.

Compliance gap: Software composition analysis (SCA) tools cover package manager typosquatting. No equivalent tooling exists for MCP server registries, a new attack surface with no current compliance control.

Threat 06 Shadow MCP Servers

Unauthorized, unmonitored MCP server instances deployed by development teams to speed up integration create governance blind spots. These shadow servers bypass monitoring and policy enforcement entirely and are indistinguishable from legitimate servers to the agents that connect to them.

Compliance gap: Shadow IT policies and asset inventories cover traditional software deployments. Shadow MCP servers spun up in minutes with a few lines of code are invisible to these controls, creating immediate compliance exposure.

Threat 07 Overreliance on the LLM

MCP server developers often build overly permissive tools, assuming the LLM will invoke them safely. This assumption is structurally incorrect; models can be manipulated via prompt injection, make autonomous judgment errors, and can be silently swapped for weaker versions. Security decisions delegated to the LLM are not security decisions at all.

Compliance gap: No current framework defines what "safe LLM judgment" means as a security control, or how to validate that an LLM is making access decisions within acceptable parameters.

Where your current compliance stack leaves you exposed

The fundamental problem is not that MCP is insecure by design; it is that the compliance frameworks your enterprise buyers rely on were built for a world where software behaves deterministically. MCP puts a probabilistic, manipulable reasoning engine at the center of your integration layer. Every existing control assumes that it is not the case.

MCP risk layer coverage by existing compliance framework

The bottom line: Of the seven MCP risk layers identified by CoSAI, two have zero coverage in any existing compliance framework, and five have only partial coverage that does not extend to the agentic attack surface. If your enterprise buyers are starting to ask MCP-specific security questions, and the leading ones already are, your current compliance documentation cannot answer them.

Why is this becoming an enterprise deal blocker in 2026

MCP security is moving from a security engineering concern to a procurement concern faster than most compliance teams realize. Three forces are converging:

Enterprise security teams are building MCP-specific questionnaires. The same buyers who started requiring SOC 2 before it was mandated are now drafting AI vendor questionnaires that specifically ask about MCP governance, agent identity controls, and tool chain integrity. The buyers at financial institutions and healthcare companies are ahead of the market on this.

Regulators are paying attention. The EU AI Act's provisions on high-risk AI systems, combined with GDPR's data processing requirements, create indirect compliance obligations for any MCP implementation that processes personal data through an agent, regardless of whether MCP is named explicitly. The NIST AI Agent Standards Initiative, launched in February 2026, specifically highlights agent security and identity as core regulatory pillars.

The incidents are starting. The Asana AI data contamination breach demonstrated that resource content poisoning is not a theoretical risk. As more enterprises deploy MCP-connected agents, the incident rate will rise, and with it, the expectation that vendors can demonstrate they have controls in place.

The competitive dynamic: MCP security compliance is at the same stage that SOC 2 was in 2012. Not yet mandatory. But the early enterprise deals are going to companies that can answer the question, while those that cannot are watching those deals go to competitors who can.

Building MCP security into your compliance posture: where to start

The CoSAI white paper and security research from across the industry converge on the same foundational principles. These controls must be in place before your first MCP-specific enterprise security review.

The MCP compliance readiness checklist

• Maintain an MCP server inventory. Every MCP server your product deploys or connects to must be documented, including shadow servers deployed by development teams outside the security team's visibility.

• Replace static credentials with short-lived, scoped tokens. API keys in configuration files are the most exploited entry point for MCP identity attacks. Agent credentials should be issued just-in-time, scoped to the specific task, and automatically revoked when the session ends.

• Validate and sanitize context at every trust boundary. Before an agent accepts context from any source, validate its origin and structure. Before passing context to a tool, verify its contents against expected schemas. Treat all LLM and MCP outputs as untrusted by default.

• Enforce least-privilege tool access per request. Agents should not hold standing access to every tool in your MCP stack. Permission should be evaluated at the moment of each tool invocation, based on the specific action being requested.

• Require signed artifacts for all MCP tool deployments. Tool descriptors, schemas, and MCP server configurations should be cryptographically signed and verified before deployment — the same way you would treat package manager dependencies.

• Log every agent authentication event and tool invocation. Centralized, immutable logs of every MCP interaction agent identity, tool called, parameters passed, authorization decision, outcome — are the foundation of any MCP compliance audit trail.

• Implement human-in-the-loop for sensitive tool invocations. Any MCP tool that can take an irreversible action, such as sending an email, executing a payment, or modifying production data, should require explicit human confirmation that cannot be bypassed by the agent itself.

• Document your MCP risk position. Map your MCP implementation against the five vulnerability layers and create a documented risk register. Enterprise buyers who ask about MCP security want to see evidence of structured thinking, not just technical controls.

The result: MCP governance as a competitive advantage

MCP security compliance is not about adding another audit to your roadmap. It is about recognizing that the integration layer connecting your AI agents to the rest of the world has become a primary risk surface, one that your buyers are beginning to evaluate, and that your existing compliance stack was not designed to address.

For AI SaaS companies selling to enterprises, getting ahead of MCP governance means you can answer the questions your buyers are starting to ask before those questions become deal blockers. The company with documented MCP controls, a maintained server inventory, and a clear agent credential policy will close enterprise deals that the company without them will lose to procurement friction.

For compliance teams, MCP represents the clearest current example of the broader pattern: AI-specific risks are outpacing the frameworks that enterprise buyers use to evaluate vendor security. The companies that build AI-native compliance postures now, rather than waiting for the frameworks to catch up, will be the ones that enterprise buyers learn to trust first.

MCP is the backbone of AI agent integration. Governing it is not optional. It is the next frontier of enterprise AI compliance and the frontier is here now.