MCP Supply Chain Vulnerability Explained: Why Anthropic's "Expected Behavior" Problem Is a Warning for Every AI Agent Deployment

The Model Context Protocol was supposed to be the boring plumbing that made AI useful. Instead, it has become the clearest example yet of a hard truth about the agent era: the most dangerous flaws in AI systems will not be bugs. They will be features working exactly as designed.

MCP is Anthropic's open standard for connecting AI models to the outside world. Instead of a chatbot that only knows what it was trained on, MCP lets an assistant reach into real tools, file systems, databases, ticketing systems, payment platforms, code repositories, internal wikis. It turned the AI assistant from a talker into an operator.

That power is now the center of a security conversation the industry cannot ignore. The issue sits in a category of risk that is genuinely uncomfortable to explain to a board of directors: the dangerous behavior is expected behavior. Nothing crashed. No memory was corrupted. No password was stolen in the traditional sense. The protocol did precisely what it was built to do, and that is exactly what makes it a supply chain nightmare.

What MCP Actually Is, and Why It Spread So Fast

The design is elegantly simple. An AI application acts as a host. It connects to one or more MCP servers, each of which publishes a menu of "tools," "resources," and "prompts." When a user asks for something, the model reads that menu and decides which tool to call. The host brokers the request, the server executes it, and the result comes back into the conversation.

Why did this spread across the industry so quickly? Because it solved a real, painful problem. Before MCP, every AI vendor built its own custom connector to every data source. It was a mess of one-off integrations. MCP gave everyone a shared language, in the same way that a universal adapter simplifies a drawer full of mismatched chargers.

The result was explosive ecosystem growth. Thousands of community-built servers appeared, wrapping everything from spreadsheets to source control to customer relationship software. Many were built by enthusiastic developers in an afternoon. Most are useful. Some are excellent. And a small number are, or will become, weapons.

The Vulnerability That Isn't a Bug

Here is the core problem in plain terms. MCP lets an AI model discover tools and trust what it reads about them. Four "expected behaviors" create the attack surface.

1. Tool descriptions are instructions the model obeys

Every MCP server ships a text description of each tool, what it does, when to use it, what arguments it takes. To a human, this looks like documentation. To a language model, it is input. A description can be written to nudge the model toward a behavior the user never asked for. Attackers do not need to break into anything. They only need to publish a helpful-looking tool with a description that quietly steers the model.

2. The catalog is discovered at runtime

The model does not carry a fixed list of trusted tools. It reads whatever the connected servers advertise. That is what makes MCP flexible, and it is what makes the trust boundary so thin. The assistant trusts the menu because the menu is the protocol.

3. Approved tools can change after approval

A server can be perfectly safe on the day it is installed and different a month later after an update. The user approved version one. The model is now calling version two. This is the classic supply chain "rug pull," and agents are especially exposed because so few deployment pipelines re-review server updates before they reach a live agent.

4. Credentials flow through the agent

This is the highest-impact risk. When an agent acts on your behalf, it often acts with your permissions. A malicious or compromised server can exploit that relationship, asking the agent to perform actions the user never intended, using tokens the user already granted. In security terms this is a confused deputy problem. In practical terms: the assistant has your keys, and something else has the assistant's ear.

Why "Supply Chain" Is the Right Frame

MCP servers are distributed like open-source packages. Anyone can publish one. They depend on other packages. They run on someone else's infrastructure or on your laptop with whatever privileges you granted. Small install footprint, enormous privilege. If that sounds like the software supply chain problems of the last decade, that is because it is one.

But there is a critical difference that makes this generation harder. In a traditional supply chain attack, malicious code has to run. It has to trip an antivirus scanner, match a signature, show up in a log. In an agent supply chain attack, the payload can be natural language. It does not execute. It persuades. It looks like a normal conversation between a model and a tool it was told to trust.

That is why the phrase "expected behavior" matters so much. Vulnerability scanners look for crashes and memory errors. This class of risk produces neither. Auditors compare code changes, not intent changes. A poisoned tool description is invisible to tooling that was built to find buffer overflows. The best defense of a hostile MCP server is that it never did anything unusual.

What This Means for the Future of AI

Agents are becoming privileged identities, and the industry is not treating them that way yet. We are handing AI systems long-lived credentials, write access to production systems, and the ability to chain actions across dozens of tools. Every one of those grants multiplies the blast radius of a single manipulated tool call. The MCP issue is an early signal that agent identity and permissions need to be designed as carefully as human identity was.

The ecosystem will go through the same maturation curve as open-source software. Early package managers were a free-for-all. Over years, the industry added signed releases, dependency manifests, provenance records, and curated registries. Expect the same for tools: signed MCP servers, verifiable publisher identities, tamper-evident tool manifests, and vetted internal catalogs. The organizations that build this discipline early will move faster later, because they will be able to safely grant agents more autonomy.

Safe defaults will decide the winners. Platforms that make the secure path the easy path, automatic permission scoping, update review, human approval for destructive actions, will win enterprise deals. Platforms that leave every choice to the user will lose them.

Trust becomes a product. Expect a new layer of vendors whose entire business is answering one question: can this tool be trusted right now, for this action, by this agent? That is a genuinely new market created by an old problem.

Liability will get uncomfortable. When an agent is manipulated into sending the wrong email or moving the wrong funds, who is responsible, the model maker, the tool author, the marketplace, or the company that deployed it? The answer will be written in contracts and insurance policies long before it is written in law. Organizations should be negotiating those terms now.

A Practical Playbook for Businesses

None of this argues for abandoning MCP. It argues for treating it like production infrastructure instead of a fun experiment.

• Inventory every server. You cannot secure what you have not catalogued. Most organizations have no idea how many MCP servers are connected to their assistants, or who installed them.
• Treat tool descriptions as untrusted input. Review them the way you review code from a new vendor. Assume some are adversarial.
• Apply least privilege, hard. Scoped, short-lived tokens per tool. Read-only where possible. Never hand an agent a broad credential because it is convenient.
• Pin versions and review diffs. An approved tool must stay approved. Re-review updates before they reach a live agent.
• Require human approval for irreversible actions. Payments, deletions, external communications, and permission changes deserve a confirmation step.
• Log every tool call. Full audit trails of what the agent asked for and what came back are your only forensic tool when something goes wrong.
• Isolate and constrain. Run servers in containers with tight network egress rules. Block anything that should not be reaching out.
• Prefer curated and first-party servers. Popularity is not a security control, but obscurity is not one either.
• Red-team the agent, not just the app. Test whether a hostile tool description can change behavior. Most teams have never tried.

The Bigger Picture: Trust as the Real Infrastructure

The MCP story is a preview of where AI is heading. The interesting question is no longer whether a model is smart. It is whether the system around the model can be trusted when the model is acting on its own. Capability has outpaced the trust layer, and the gap is where incidents happen.

The good news is that this is a solvable problem, and the solutions are familiar even if the details are new. Sign what you ship. Know who published it. Give the smallest permission that works. Watch what happens. Ask a human before the irreversible step.

The uncomfortable lesson is the framing itself. When a system's most dangerous behavior is expected behavior, no patch will save you. The fix is architectural, procedural, and cultural, and it needs to start before the next agent gets its credentials.

Conclusion

Anthropic's Model Context Protocol did something genuinely important: it gave AI a standard way to touch the real world. That is the foundation of everything agentic. But the same openness that made it spread so fast is what makes it a supply chain risk. The tools are discovered at runtime, the descriptions are read as instructions, the credentials are real, and the behavior is exactly as designed.

For businesses, the takeaway is not to slow down, it is to build the guardrails in parallel with the rollout. For the industry, it is a reminder that the hard part of AI was never the model. It is the trust infrastructure around it. The organizations that understand this will be the ones still standing, and still shipping, when the next tool in the catalog turns out to be something other than helpful.