TL;DR: Model Context Protocol has gone from about 100,000 monthly downloads in November 2024 to over 400 million today. Most production agents still call MCP servers without authentication. The protocol is neutral by design, so governance has to be enforced at a deployment-layer gateway. That gateway gives security teams a single answer to which agents called which tools against which data.

Key Takeaways: - 12 of 18 production agents we audited had no authentication on their MCP connections. Another 24% of public MCP servers operate the same way. - MCP standardizes how agents discover and call tools. It does not enforce what they are permitted to do, so security must be added at the gateway. - The four risk categories close only when a single inline enforcement point sits between every agent and every server. These are prompt injection, identity escalation, shadow servers, and missing audit trails. - A 90-day phased roadmap gets CTOs to answerable governance in a quarter. The alternative is the multi-year timeline an in-house build typically takes.

Model Context Protocol downloads hit 400 million a month. Our audit of 18 production agents found 12 had no authentication on their MCP connections. Growth has outpaced governance by 18 months. Security teams are the last to know.

MCP did not grow gradually. It exploded. Monthly server downloads went from about 100,000 in November 2024 to over 8 million by April 2025. An 8,000% surge in five months.

Today the protocol clears 400 million downloads a month. That puts it in the same adoption tier as the package managers that built the modern web. The problem is the shape of that curve.

MCP adoption crossed from experimental to enterprise-critical in under 18 months. Most security review cycles still move slower than the protocol's adoption curve. The gap means agents call tools in production before the security team has a document describing what an MCP server is.

When we audited 18 production agents across regulated industries, 12 were calling MCP servers with no authentication layer. The pattern is not unique to us. Builder surveys confirm the same picture: 24% of MCP servers in the wild run without authentication, and 50% of builders now cite security complexity as their top challenge.

The download curve looks like a victory lap. The audit results suggest it is a supply-chain liability growing in plain sight.

MCP is an open protocol specification, not a security product. It standardizes how agents discover tools, declare their capabilities, and exchange results. What it does not do is decide whether an agent is permitted to call a given tool.

That authorization has to be added at the deployment layer. The standard pattern is a gateway or inline enforcement point positioned between agents and MCP servers. It owns the trust boundary the protocol deliberately leaves undefined.

Most teams miss this. They assume MCP inherits OAuth or mTLS from the underlying transport. It does not.

Each MCP server implementation decides on its own whether to require auth. Many simply don't. The assumption is invisible until an auditor asks who called what.

Multi-agent pipelines make it worse. Identity delegation breaks down across chains. A token issued to one agent often grants the same downstream access to every agent it calls.

Add tool discovery on top, and the trust boundary dissolves into a mesh of implicit grants. Audit trails disappear with it. Every agent registers and connects to MCP servers on its own. Security teams cannot answer which servers are live, which tools they expose, or who invoked them yesterday.

This is the same blind spot that already plagues mesh mTLS deployments, just relocated to the agent layer. If the protocol is deliberately neutral and most teams skip the auth step, the failure is structural. So the fix has to be structural too.

Authentication closes a slice of the surface. The audit findings cluster into four distinct categories. Each needs its own enforcement. An auth check alone addresses only the identity layer, leaving the other three risk categories exposed. - Prompt injection through compromised MCP resources. An attacker poisons a tool description or resource payload to steer an agent into leaking data or calling a destructive tool. The agent never knew it was being manipulated. It just followed the description it was given. - Identity blind spots and privilege escalation. Identity delegation collapses across multi-agent chains. A low-privilege agent can inherit the access of a higher-privilege one two hops upstream. This is the same blast radius pattern that IAM drift creates for human identities, extended to non-human actors at machine speed. - Supply chain risk from shadow and poisoned MCP servers. A server registered by a well-meaning developer can quietly expose internal tools to any agent on the network. A "safe" server can change its tool definitions after approval, the tool drift or rug pull pattern. We mapped the same surface in our 400M unvetted tools analysis, and the registration problem has not shrunk. - Disappearing audit trails. Without a centralized enforcement point, tool calls leave scattered logs that don't survive agent restarts, context-window rolloffs, or server redeployments. The trail is technically present but practically gone.

These four categories are why 50% of builders rank security as their top challenge. Auth is necessary. It is far from sufficient.

Each category maps to a specific enforcement point. The pattern that closes all four is the same: a single inline gateway that sits between every agent and every MCP server.

A gateway is not a sidecar on every agent. It is a single control point that every MCP connection funnels through. It is the choke point that makes the four risk categories addressable in one place.

Schema validation at the edge. Every tool call gets inspected against the server's declared schema before execution. A call to a tool not in the approved schema gets blocked, regardless of what the agent requested. This closes the prompt injection and rug pull surfaces, because a poisoned description cannot smuggle in a tool the gateway has not registered.

Identity propagation as a first-class concern. The gateway issues short-lived, scoped tokens to each agent and re-validates them on every hop. Tenant isolation becomes a property of the token, not a hope about the agent's prompt. This is the missing control that Zero Trust mesh mTLS leaves on the table for human-to-service calls, finally extended to agent-to-tool.

Cryptographic audit trails. Every usage record is cryptographically signed at creation and pushed to an append-only log. The audit trail is auditable because it cannot be rewritten after the fact, which is what compliance teams actually need.

This is the tamper-proof metering pattern: sign at creation, append on the way out, and refuse to backfill. Anything else is a journal an adversary can edit.

The gateway is the only architecture that lets a security team answer four questions they are already being asked. Which servers are live? Which tools are exposed? Which agents invoked them? What data moved? Without it, you are stacking more agents on a broken trust model and hoping compliance will not notice.

Knowing the pattern is one thing. Shipping it inside a 90-day window is where most CTOs stall.

The four phases below have been refined across regulated industries. They map cleanly to a calendar quarter. Each phase produces a deliverable your CISO can show an auditor, not a slide deck.

Phase 1 - Discovery (Weeks 1-2). Inventory every MCP server in the environment. List every tool each server exposes and every agent that can reach them.

Most teams discover servers they were not previously aware of, including shadow servers registered by individual developers. The output is a single source of truth, a registry the rest of the roadmap assumes exists.

Phase 2 - Inline Gateway (Weeks 3-6). Deploy a single enforcement point between agents and MCP servers. Route all MCP traffic through it. This is where the first real "who called what" visibility goes live.

Tool schema validation starts blocking the calls that should never have been allowed.

Phase 3 - Identity and Tenant Isolation (Weeks 7-10). Replace ad-hoc tokens with short-lived, scoped credentials issued by the gateway. Enforce tenant boundaries at the token level. An agent in tenant A cannot reach tenant B's data, even if a multi-agent chain tries to escalate.

This is where teams that pass AI governance audits actually do their work.

Phase 4 - Immutable Audit (Weeks 11-12). Switch audit logging to a cryptographically signed, append-only store. This is the layer that closes a compliance audit cleanly. It distinguishes an MCP rollout you can defend from one you cannot.

A typical deployment lands in a single quarter. An in-house team needs years to build the same stack from scratch. The gateway pattern is reusable across every agent and every server you add later.

That gap is where most enterprise MCP programs quietly die on the vine. Once those four phases ship, the questions your CISO and your auditors ask stop being unanswerable. The dashboard at the end of Phase 4 changes what the security team can actually prove.

The single dashboard at the end of Phase 4 is what justifies the entire program. From it, you can answer questions that have been unanswerable for the last 18 months: - Which MCP servers are in production, which tools each one exposes, and which agents can invoke them. Answerable in under 60 seconds. - Which agent called which tool against which tenant's data, with a signed audit record that survives server restarts and context rolloffs. - Whether a tool call matches its declared schema, whether the calling agent had the right scope, and whether the action was destructive enough to require human-in-the-loop approval.

The retention is what makes this real. Our deployments are still running in production long after go-live, and clients continue to renew. That is the signal the governance layer holds up past the first quarter.

The same stack handles enterprise AI systems in regulated industries where compliance teams demand agent-to-data access controls.

For a CTO, the payoff is not a security tool. It is the ability to keep shipping agents at MCP speed. It is the answer to the most basic governance question: what are our agents actually doing right now.

Teams that have built this with us at Levitation keep building on it. Once the answer is in place, every new agent you ship inherits it for free.

Does MCP have built-in authentication?

No. MCP is a protocol specification that standardizes how agents discover and call tools. It does not include built-in enforcement for what an agent is permitted to do. Authentication and authorization must be added at the deployment layer, typically through a gateway or inline enforcement point between agents and MCP servers.

How is MCP security different from traditional API security?

Traditional API security assumes a stable client identity calling a fixed endpoint. MCP agents dynamically discover tools, chain calls across multiple servers, and pass context between each other. This breaks identity delegation. It creates audit trail gaps standard API gateways were not designed to handle.

What is tool poisoning in MCP?

Tool poisoning is when a malicious or manipulated tool description steers an agent into leaking data or taking a destructive action it was never asked to. It is one of four core risk categories in MCP. The others are identity blind spots, supply chain exposure to shadow servers, and disappearing audit trails.

How do you audit MCP agent activity for compliance?

Effective MCP audit requires a single enforcement point. It logs every tool call with the calling agent's identity, the tool invoked, the schema validated, and the tenant affected. Records should be cryptographically signed at creation. They should be stored in an append-only log so the trail cannot be rewritten after the fact. This is the standard a compliance audit actually requires.

What is AI agent tenant isolation and why does MCP break it?

Tenant isolation means an agent authorized to touch one customer's data cannot reach another customer's data, even through indirect calls. MCP breaks it because identity delegation collapses across multi-agent chains. A token issued to one agent often grants the same downstream access to every agent it calls. A low-privilege agent can inherit high-privilege scope unless isolation is enforced at the gateway rather than in the agent.