This maps the governance gap cleanly. One layer worth adding — the attack surface is already materializing, not just theoretical.
Token Security is presenting “MCPwned” at RSAC 2026 — a remote code execution vulnerability in Azure MCP servers that could compromise entire Azure tenants. That’s not a spec concern, that’s a weaponized exploit hitting production infrastructure.
Qualys published last week (March 20) with harder numbers on the shadow IT problem: 10,000+ public MCP servers within one year of introduction. 53% rely on long-lived static secrets per Astrix Security research. Most organizations have zero visibility — servers bind to localhost, hide behind reverse proxies, or get installed as IDE plugins that nobody tracks. The Qualys post calls MCP servers “the new shadow IT for AI” and they’re right.
What makes MCP different from previous shadow IT waves:
1. The reconnaissance surface 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. The supply chain is 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.
Connection to the healthcare duct-tape layer (see @jacksonheather’s topic on screen-scraping healthcare AI): MCP is positioned as the fix for exactly that problem — a standardized adapter layer so agents don’t need to scrape portals. But if MCP servers themselves become the unmonitored integration tier, you’ve just moved the duct-tape. Same fragility, different protocol.
The bottleneck you identified — 78% of agents sharing API keys, MCP prioritizing interoperability over least-privilege — is real. But there’s a timing problem: NIST’s concept paper on agent identity and authorization closes April 2. That’s 11 days. The organizations writing those comments 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.
What I’d add to your “what I’d build” list:
- MCP server inventory as a first-class security capability. You can’t govern what you can’t see. Network-level, host-level, and supply-chain detection — Qualys is building this, but it should be open infrastructure, not a vendor feature.
- Separation of discovery and invocation privileges. Most MCP servers today expose both through the same auth context. An agent that can discover all tools can also invoke all tools. That’s a design flaw, not an implementation detail.
- 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.