Microsoft — The state of MCP security in 2026: OAuth, supply chain, and shadow servers

2026-06-28 Security by al-ice.ai Editorial

AI relevance: As MCP becomes the de facto protocol for agent-to-tool communication, Microsoft's security team lays out the seven risk categories every enterprise running agentic AI must now govern — from tool poisoning to shadow MCP servers no one registered.

What happened

Microsoft published its second annual State of MCP Security assessment, a comprehensive mapping of the attack surface that has emerged around the Model Context Protocol as it moved from experiment to production infrastructure across enterprises. The post coincides with the MCP specification's latest release candidate, which raises the security baseline with per-request identity, OAuth 2.1 with PKCE, and a new MCP Apps capability that lets servers ship interactive UI rendered inside a host sandbox.

The seven risk categories

1. Tool poisoning (indirect prompt injection via tool descriptions). An agent treats tool schemas and outputs as trustworthy. An attacker who can plant instructions in a tool description or parameter schema steers the agent — exfiltrating data, invoking the wrong tool, or triggering unapproved actions. Control: treat tool descriptions as untrusted input; require human approval for tool lists; show full tool calls, not friendly summaries.
2. Confused deputy / authorization bypass. The biggest expansion since last year. MCP servers are now OAuth 2.0 resource servers with guidance hardened around OAuth 2.1, PKCE, and audience-bound tokens. A server acting with its own broad privileges on behalf of an underprivileged user is the core confused-deputy pattern. Control: audience-bound tokens so a token minted for one server cannot be replayed against another; identity-aware gateway in front of every server.
3. Excessive scope / credential concentration. A single MCP server often holds credentials for several systems at once — full mailbox access where read-only would do. One leaked token becomes a breach of every system it touches. Control: least-privilege per resource, short-lived tokens, and agent identity via Microsoft Entra Agent ID for class-level policy.
4. Supply chain / rug pull. A typosquatted package, a compromised dependency, or a change of ownership behind the same URL turns a trusted server hostile. The server you approved is not the server you are running. Control: design-time catalog with known-good tool definitions, pin and alert on drift, route everything through a gateway that re-checks identity on every call.
5. Shadow MCP servers. Shadow AI for the agent era: a developer stands up a server for a demo, a team wires an agent to whatever endpoint is handy, nobody registers it. You cannot govern, patch, or revoke what you cannot see. Control: design-time registry plus runtime gateway; use the GSA AI Gateway to surface unregistered servers.
6. Command injection via STDIO servers. Many MCP servers run locally over STDIO, spawning subprocesses and touching the filesystem. Unsanitized input into a shell or file path is command injection or path traversal — one of the largest MCP vulnerability classes this year. Control: input sanitization, seccomp/AppArmor profiles, read-only filesystems.
7. Unregistered server sprawl across environments. MCP servers proliferate faster than security teams can inventory them. Dev, staging, and production each accumulate servers with different security postures. Control: central registry, environment-scoped policies, and continuous reconciliation between design-time catalog and runtime gateway.

What changed in the latest release candidate

Per-request identity. Requests now carry what they need so a gateway can inspect and enforce on every call instead of trusting a hidden session.
Tighter client-server identity checks. Mutual authentication between MCP clients and servers is more rigorously specified.
MCP Apps sandbox. A new capability lets a server ship interactive UI that the host renders inside a sandbox — reducing the risk of server-side HTML injection into agent front-ends.
OAuth 2.1 + PKCE as the recommended auth model. Strict redirect-URI matching and audience-bound tokens are now the documented baseline.

Why it matters

MCP is infrastructure now, not a prototype. The protocol has crossed the line from "interesting standard" to "the way agents connect to tools in production." Security posture must match.
The protocol does not enforce security for you. Microsoft's central thesis: MCP defines how clients and servers talk; the locks are yours to fit. "We reviewed MCP last year" is out of date — revisit assumptions with each release.
Agent identity is the missing primitive. Entra Agent ID signals that treating agents as first-class identities (not just service accounts) is becoming table stakes for governance and kill-switch capability.
Supply chain is the new perimeter. Rug-pull and shadow-server risks mean that continuous verification — not one-time approval — is the only viable control posture.

What to do

Adopt OAuth 2.1 with PKCE now. Migrate every MCP server to audience-bound tokens with strict redirect-URI matching. Put an identity-aware gateway (Azure API Management or equivalent) in front of every server.
Register every MCP server in a design-time catalog. Pin tool definitions and alert on drift. Use Azure API Center or equivalent to maintain a known-good baseline.
Deploy a runtime gateway. All MCP traffic should route through a gateway that re-checks identity and policy on every call — no implicit trust for "internal" servers.
Give every agent an identity. Evaluate Microsoft Entra Agent ID or equivalent so you can apply policy to agent classes and execute kill-switches in one operation.
Scan for shadow servers. Use the GSA AI Gateway or network-level discovery to find MCP servers your team didn't register. Ungoverned servers are where supply-chain problems hide.
Map to OWASP MCP Top 10. Microsoft's MCP Azure Security Guide maps the risks to existing Azure controls — use it as a checklist.