Seventy-eight percent of enterprise AI teams now run MCP-backed agents in production, and 28% of the Fortune 500 operate their own MCP servers.
The ecosystem has passed 10,000 servers, with SDK downloads running at roughly 97 million per month.
Less than two years after Anthropic open-sourced the protocol, MCP is no longer the interesting experiment. It is the default way AI agents reach company data.
That is the good news.
The bad news is that adoption happened faster than security maturity. Most of those production deployments were stood up in the demo era — a shared API key in a config file, every tool exposed to every caller — and never hardened afterwards.
They work. They also hand an autonomous agent the keys to company data with less access control than you would accept for a summer intern.
From experiment to infrastructure
The timeline is worth appreciating, because it explains the problem.
MCP went from novelty to infrastructure in record time. Every major vendor now ships servers — Microsoft alone offers a catalog of 60+ MCP servers across Copilot, Copilot Studio, and Azure AI Foundry. And in five days, on July 28th, the largest specification revision since MCP launched becomes the official spec, starting a 12-month deprecation clock for older protocol versions.
A protocol with a formal deprecation policy is not an experiment anymore. It is plumbing.
And here is the thing about plumbing: experiments don't get attacked. Infrastructure does.
When 28% of the Fortune 500 runs something, that something becomes a target. The security posture that was fine for a weekend demo — because nothing valuable was behind it — is now sitting in front of CRMs, ERPs, financial data, and customer records.
The three ways teams are doing it wrong
I have looked at a lot of MCP deployments over the last year, and the failures cluster into three patterns.
1. Over-broad tool exposure
The most common mistake is the simplest one: the server hands every connected agent every tool it has.
Read the database? Sure. Drop the database? Also sure. Same catalog, same caller, no distinction.
This violates the oldest rule in security — least privilege — and it does so at the worst possible layer, because the caller is a language model. Every serious treatment of MCP security published this year lands on the same conclusion: the tool catalog an agent sees must be scoped to what that agent's user is allowed to do, not to what the server is capable of.
If the agent can enumerate a destructive tool, some prompt, someday, will convince it to call that tool.
2. Bolted-on or absent authentication
The second failure is authentication that isn't really authentication.
A long-lived API key pasted into a JSON config is not identity. It is a password that never rotates, shared by everyone who copies the config, tied to no user, and invisible to your identity provider.
The protocol itself has moved past this. The MCP team just promoted its Enterprise-Managed Authorization extension to stable status, which routes MCP server access through the organization's identity provider — with support already shipped by Anthropic across Claude, Claude Code, and Cowork, by Visual Studio Code, and server-side by Asana, Atlassian, Canva, Figma, Linear, and Supabase.
When the protocol's own answer to "who is calling?" is your IdP, a shared bearer secret in a dotfile is no longer a pragmatic shortcut. It is technical debt with a blast radius.
3. Trusting the conversation
The third failure is the subtle one, and it is the one that makes MCP security genuinely different from API security.
An agent is a confused deputy by construction. It reads tool results, web pages, emails, documents — and every one of those inputs is a potential instruction channel. Prompt injection through tool output is not a theoretical attack; it is the standard attack.
Which means one thing, architecturally: you cannot firewall a conversation. No system prompt, no guardrail phrasing, no "please only use tools responsibly" preamble will hold. If the security check lives in the prompt, the security check is a suggestion.
The permission decision has to live on the server, at the endpoint, enforced on every call regardless of what the model believes it is doing. I have written before that agentic AI without permission boundaries is just malware with UX — MCP at enterprise scale is exactly where that stops being a slogan and starts being an incident report.
What doing it right looks like
The fix is not exotic. It is three principles, each one mapping to a failure above.
Identity, not shared secrets. Every MCP session belongs to a real user, authenticated against real identity infrastructure, with a token that expires. Per-user, revocable, auditable.
Role-gated tool catalogs. The tools/list an agent receives is filtered by the caller's roles before the agent ever sees it. The agent cannot be talked into calling a tool it cannot enumerate.
Server-side enforcement as the last line. Even if the catalog leaks, even if the model hallucinates a tool name, the endpoint itself checks authorization on every invocation. The prompt proposes; the server disposes.
This is how Magic Cloud's MCP server is built, and it is worth describing not as a product pitch but as a worked example of the pattern — because Magic did not add security to MCP. The MCP layer inherits it.
Every MCP tool in Magic is an HTTP endpoint with its own authorization requirement. The access token is a real JWT tied to a real Magic user with real roles — the same auth system that protects the API protects the MCP surface, because they are the same surface. When an agent connects, the tool list it receives is the list of endpoints its user's roles permit, nothing more. And when it invokes a tool, the role check runs server-side, before any endpoint logic, on every single call.
There is no separate "MCP security model" to configure, drift, or forget. If a user cannot call an endpoint over HTTP, their agent cannot call it over MCP. One contract, enforced once, in one place.
That is what held up when a frontier coding agent spent a session actively trying to break it — and it is the same boundary that makes it safe to let an agent build an entire role-secured CRM in one conversation: the platform, not the prompt, decides what the agent can touch.
The window is closing
Here is why this matters now rather than eventually.
The July 28th spec release starts a 12-month deprecation clock. Every team running MCP in production will touch their stack in the next year whether they want to or not — to move off deprecated protocol versions if nothing else.
That migration is the natural moment to fix what the demo era left behind. Swap the shared key for identity-backed tokens. Scope the tool catalog by role. Push the permission check down to the server where it belongs. Doing it as part of a migration you already have to do is cheap. Doing it after an agent with a wide-open catalog gets injected by a poisoned tool result is not.
Being in the 78% is no longer the differentiator. Everyone is in the 78%.
The differentiator is being in the minority that can answer, precisely and per-user, the only question that matters once agents are in production:
What exactly can this agent do, and who said so?
Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.
Originally published at hyperlambda.dev.
Top comments (0)