By Tom Schreck | Trace3 Senior Consultant, AI Solutions
Your developers are already using Model Context Protocol (MCP). Will you govern its adoption, or lose visibility into what they're deploying?
Model Context Protocol (MCP) solves integration fragmentation in AI applications. Before MCP, every AI application needed custom integrations for each data source (GitHub, Slack, databases, etc). Think of it as "USB-C for AI" - standardized connectors allowing any AI assistant to access external systems [7].
The value is real. Developers write integrations once, and any MCP-compatible AI can use them. That's why adoption has been rapid. Claude Desktop, Cursor, VS Code, and Zed all added support within months. MCP grew from 1,600 to over 17,000 servers in less than a year [2, 32]. Your developers want this because it eliminates redundant integration work.
Your security teams are raising red flags. And they're not wrong.
Both reactions are justified. AWS concluded MCP is "not production ready yet" [3]. Yet blocking it entirely creates its own risks: shadow AI deployments, competitive disadvantage, and developer friction that drives workarounds.
There's a maturity gap where valuable technology meets an immature ecosystem. How will you navigate it?
The finding: Security controls exist in the protocol but aren't enforced. Every protection is optional, and users can bypass all of them with a single configuration line.
What this means: Installing an MCP stdio (standard input/output) server grants it the same access you have. Any file you can read, any command you can run, unrestricted network access.
Technical detail: The MCP protocol specification states, "Authorization is OPTIONAL for MCP implementations" [10]. This creates two security postures:
The evidence: CVE-2025-6514 affected 437,000+ downloads with a CVSS score of 9.6 [14]. Installing an MCP stdio server is functionally equivalent to running arbitrary code with your full user privileges [8].
The bottom line: An MCP stdio server inherits the user's exact access level. Files, commands, credentials - whatever the user can access, the server can access. The server becomes you. There's no separate permission system, no sandbox, no way to limit it.
The finding: About 75% of MCP servers are built by individuals, not companies [11]. There's no centralized security review, no vendor accountability, and no way to enforce quality standards.
What this means: Traditional enterprise security assessments don't work here. No vendor to assess. No contracts to review. No security questionnaire to send. A developer finds an MCP server on GitHub, copies the config, and it's running. Your procurement process never sees it.
The critical risk: Even if you vet what a server does today, it can change tomorrow. MCP servers can modify their tool definitions post-installation without consent [27]. You approved a database reader; it adds filesystem access. You approved read-only operations; it adds write capabilities. The contract changes without re-approval.
The evidence: Five critical CVEs disclosed in year one, with CVSS scores reaching 9.6 [14, 15, 16]. Download counts don't correlate with security:
Even Anthropic's official servers have had critical vulnerabilities [15]. Backslash Security found hundreds more servers with known vulnerabilities [13]. The broader ecosystem? Command injection affects 43% of tested implementations [24].
The bottom line: You can't vet MCP servers like traditional software. No vendor to audit. No contracts. No guarantees. And even if you approve a server today, it can change its capabilities tomorrow without permission. Your risk assessment becomes obsolete the moment the server updates.
The finding: 53% of MCP servers rely on static API keys and Personal Access Tokens stored in plaintext configuration files [1].
What this means: One stolen config file compromises everything your AI accesses. These files may contain AWS credentials, GitHub SSH keys, database passwords, and SaaS API keys - all in plaintext [18, 19].
The evidence: Trail of Bits identified insecure credential storage as the #1 MCP vulnerability [18]. Astrix Security's analysis of 5,200 servers found only 8.5% use OAuth [1].
Plaintext credentials violate SOC2 [20], ISO27001 [21], HIPAA [22], and PCI-DSS [23] requirements. Organizations can't deploy MCP in regulated environments without fixing this.
The bottom line: One stolen config file exposes everything. AWS keys, database passwords, API tokens - all in plaintext. An attacker doesn't need to compromise the server itself, just read a text file. This violates every major compliance framework and makes MCP unusable in regulated environments.
The instinct to block MCP until it matures is understandable. It's also increasingly difficult to enforce.
Shadow AI deployments: Developers who need MCP will find ways to use it. Personal laptops. Unapproved accounts. Local environments that bypass corporate controls. You lose visibility into what's deployed and where sensitive data flows.
Competitive pressure: Organizations that figure out safe MCP adoption gain velocity in AI implementation. Your competitors are solving this problem, not avoiding it. The gap widens while you wait.
Developer friction: Talented AI engineers want modern tools. Blanket prohibitions without alternatives drive them toward organizations with more progressive AI strategies.
Integration debt: Without MCP, teams will have to build custom integrations which increases technical debt.
The choice isn't "MCP security issues" versus "no risk." It's governed adoption versus ungoverned adoption with shadow deployments and competitive lag.
This pattern is not new. Docker launched in the early 2010s with security vulnerabilities. By 2025, containers are standard in enterprise environments [17].
MCP is at year one.
The difference? The ecosystem is actively responding. Enterprises want MCP to mature faster because they need AI now.
Anthropic: Released a major security update in June 2025. They upgraded to OAuth 2.1, required secure session IDs, and published Security Best Practices [10, 29].
Cloud Security Alliance: Launched a "Secure Autonomy" project with hardening guides, audit frameworks, and best practices [4].
OWASP: Created the MCP Top 10, a community-driven risk catalog mapping critical concerns like model misbinding, context spoofing, and prompt-state manipulation [5].
Docker: Built MCP Gateway with container isolation, native OAuth handling, and cryptographically signed images [6].
Security vendors: Automated assessment tools are emerging: MCP SafetyScanner [28], MCP-scan for detecting attacks, and runtime protection tools like MCP Guardian and MCP-Shield [30].
Astrix: Released an open-source MCP Secret Wrapper that pulls secrets from vault at runtime [1].
Microsoft: Published security guidelines for protecting against indirect prompt injection attacks [31].
The ecosystem is moving fast, but you can't wait for MCP to mature. Here's how to adopt it safely based on your risk tolerance.
For experimental/development use:
For limited production use:
For mission-critical systems:
You don't need to choose between security and speed. You need a strategy that handles MCP's limitations. Trace3's AI governance consulting helps organizations:
Adopt MCP at a pace that matches your risk tolerance, with controls that fit your environment.
Evaluating MCP adoption? Or discovering it's already deployed? We can help.
Contact Trace3 for a trustworthy AI assessment to understand your current exposure and risk profile. We can discuss your AI governance strategy to build frameworks that enable AI innovation without compromising security. MCP will mature. The question is whether you'll be ready when it does.
[32] mcp.so. "MCP Server Marketplace." Available: https://mcp.so/
Tom Schreck is a Senior Consultant, AI Solutions at Trace3. He helps clients cut through the AI hype to find what's worth building now versus what's still maturing. Tom specializes in agentic AI patterns and solution development, translating emerging technologies into actionable strategies that help organizations innovate with confidence.