You Can't Secure the MCP Servers You Can't See

The July 28 Model Context Protocol (MCP) spec is the moment the protocol grew up: a stateless core that scales on ordinary HTTP, and Enterprise-Managed Authorization promoted to stable so an org can gate every server through its own identity provider. That is a real unlock. It is also why your attack surface just got bigger — and why the teams that get breached this year won't be the ones running one MCP server. They'll be the ones running forty and watching three.

The spec got enterprise-ready. The attack surface got wider.

Centralized auth is a security win at the door. But 'enterprise-ready' means more servers, more teams standing them up, and more tools an agent will call without a human in the loop. Security researchers have spent the run-up to July 28 pointing at exactly this: the spec hardens the front door while the number of doors multiplies.

The breaches aren't in the protocol. They're in the fleet.

The headline MCP security incidents of early 2026 didn't exploit a flaw in the spec. They exploited the gap between how many servers a team runs and how many it can actually see.

• Poisoned tool descriptions: Microsoft flagged that a crafted tool description can steer an agent into leaking data — you only catch it if you inspect what each server exposes, not just that it responds.
• Agentjacking: attackers inject instructions into data an agent reads, and the coding agent executes them as commands. The blast radius is every server that agent can reach.
• Config auto-loading (the Amazon Q CVE, CVSS 8.5): an agent auto-loaded MCP configs from a workspace directory without consent, opening a path to credential exfiltration. The failure was inventory and consent, not cryptography.

Three questions most teams can't answer about their MCP fleet

If security is now an operations problem, these are the operational questions that decide whether an incident is contained or catastrophic.

• Inventory: How many MCP servers are live across your org right now — including the ones a single team spun up last week?
• Change: Which servers changed their exposed tools or auth posture since the last time anyone looked?
• Drift: Which servers are still on the pre-July-28 transport, or diverging from the config you think is deployed?

Most teams can answer the first question with a guess and the next two with a shrug. That's the gap.

Visibility is the control

You cannot secure, audit, or deprecate a server you can't see. The July 28 spec gives you a stronger door; it does not give you a map of the building. That map — a live inventory of every MCP server, what it exposes, how it authenticates, and what changed — is the control plane security actually runs on.

That's the layer MCPOrbit is built for: fleet-wide visibility into every MCP server you run, so 'is this server safe to trust?' becomes a question you can answer with data instead of a shrug. Centralized auth decides who gets in. Fleet observability decides whether you'd even notice if something went wrong.