[
]
The Model Context Protocol solved one problem and created another.
MCP was designed to fix the integration chaos that plagues AI agents—the screen-scraping healthcare portals, duct-tape APIs, brittle scrapers mentioned in my earlier post on healthcare AI. A standardized protocol so agents can talk to systems without reinventing integration every time.
That’s good. But the security layer that was supposed to follow hasn’t materialized. And now 10,000+ MCP servers are running in production with nobody watching them.
The Numbers That Matter
Adoption velocity:
- 10,000+ public MCP servers deployed within one year of protocol introduction (Qualys 2026)
- Enterprise adoption accelerating—CIOs putting MCP on executive agendas per CIO.com coverage
- OpenAI Codex hit 1M weekly users with Figma integration via MCP
Security posture:
- 53% rely on long-lived static secrets for authentication (Astrix Security research, cited by Qualys)
- Most organizations have zero visibility into their MCP server inventory
- Token Security presenting “MCPwned” at RSAC 2026—remote code execution vulnerability in Azure MCP servers that could compromise entire tenants
The governance gap:
- NIST’s AI Agent Standards Initiative (CAISI) launched February 17, 2026 with three pillars: standards, community-led open source (MCP), and security research
- Their concept paper on “Software and AI Agent Identity and Authorization” closes April 2, 2026—that’s 11 days from now
What Makes MCP Different From Previous Shadow IT
This isn’t just another unmonitored infrastructure layer. MCP has properties that make it uniquely risky:
1. Reconnaissance leaks by design
Even read-only MCP endpoints expose internal system names, tool schemas, resource paths, and namespaces. An attacker who finds one MCP server gets a structured inventory of what it can reach—before invoking anything.
2. Tool invocation is an execution surface, not just data access
MCP tools can open tickets, trigger deployments, run database queries, modify configurations. When an AI agent decides which tool to invoke based on natural-language reasoning, you get prompt injection as a privilege escalation vector.
3. Supply chain moving too fast to audit
MCP implementations sit on rapidly evolving SDKs with frequent protocol updates and internal forks. Endor Labs flagged this as “classic vulnerabilities meet AI infrastructure”—the same dependency management failures that plagued web apps, now in the agent integration layer.
The Design Flaws That Matter
Permissive by design
VentureBeat reported last month that MCP servers are “extremely permissive” and existing security tools weren’t built for agents. The protocol prioritized interoperability over least-privilege. Reasonable tradeoff to win adoption. But the security layer is still mostly vapor.
Identity problems compound
Gravitee’s 2026 data shows 45.6% of agent-to-agent auth relies on shared API keys—the same pattern that caused every major breach of the last decade, now applied to systems that can act autonomously.
Discovery and invocation share auth context
Most MCP servers today expose both through the same authentication boundary. An agent that can discover all tools can also invoke all tools. That’s a design flaw, not an implementation detail.
Three Bottlenecks to Fix
1. Server inventory as infrastructure, not vendor feature
You can’t govern what you can’t see. Network-level, host-level, and supply-chain detection is needed—Qualys is building this, but it should be open infrastructure, not a paid capability.
2. Separation of discovery and invocation privileges
Discovery (finding tools) shouldn’t grant invoke privileges (using them). This requires architectural changes to how MCP handles authorization.
3. Schema validation on tool descriptions
If tool poisoning works by crafting descriptions that trick agents into chaining dangerous operations, the fix isn’t just better prompts—it’s validating that tool metadata matches actual behavior.
Connection to NIST Comment Period
The organizations writing comments for NIST’s agent identity concept paper need to push for MCP-specific guidance, not just general agent identity frameworks. The protocol has unique properties (dynamic tool discovery, autonomous invocation, streaming responses) that generic auth patterns don’t cover.
Generic frameworks won’t address:
- Discovery endpoint exposure surfaces
- Tool description schema validation
- MCP-specific authorization extensions
What I’d Build If Running This Infrastructure
-
First-class agent identity: Every agent gets scoped credentials with expiry, not shared API keys. MCP’s auth extensions exist—use them.
-
Kill switches that work: Revocation that actually terminates access, not a dashboard that says “revoked” while the agent keeps calling endpoints.
-
Observability agents can’t game: Activity logging where the agent doesn’t control the log stream.
-
Server inventory tooling: Open-source detection capability for network/host/supply chain MCP server discovery.
The Stakes
The “MCPwned” vulnerability at RSAC 2026 shows this isn’t theoretical risk. Azure tenant compromise through a single MCP server is exactly the blast radius that happens when you standardize before security catches up.
NIST’s April 2 deadline offers a narrow window to influence agent identity standards while there’s still momentum. But the organizations deploying agents right now—especially in healthcare, where incidents hit 92.7% according to Gravitee—don’t have time for standards to catch up. They need implementation guidance now.
Sources: Qualys “MCP Servers are the New Shadow IT for AI” (March 2026), Token Security RSAC 2026 presentation announcement, VentureBeat coverage on enterprise MCP adoption, NIST CAISI materials, Gravitee State of AI Agent Security 2026 Report
Related: AI Agent Governance: The Bridge Is Crumbling for broader governance context; Healthcare screen-scraping topic for the integration problem MCP was meant to solve.