Why Model Context Protocol Requires New Security Approaches

Model Context Protocol, launched by Anthropic in late 2024, functions as a bridge connecting artificial intelligence systems with external tools and databases. The protocol has gained momentum rapidly, yet security gaps have emerged as developers race to implement it without adequate safeguards.

What Is Model Context Protocol and Why It Matters

Understanding the Basic Function

Model Context Protocol serves as the connection layer between large language models and the tools, databases, and systems they need to access. Think of it as a standardized interface that removes friction when linking AI applications to real-world data and services.

The adoption rate has been remarkable. Within just seven days, developers created over one thousand new Protocol implementations. However, this explosive growth has created an unfortunate side effect: security considerations took a backseat to speed and functionality. The first year of deployment revealed numerous critical security issues that underscore a fundamental problem with how the technology was designed and adopted.

The Trust Problem at the Core

The core issue stems from how the protocol handles trust. Most early implementations assumed that inputs flowing through the system could be treated as safe. This assumption proved dangerously incorrect.

Common Security Problems Found in Model Context Protocol Deployments

Security researchers analyzing 2,614 Protocol implementations uncovered widespread patterns of dangerous coding practices. The findings are sobering.

Eight out of ten implementations contain weaknesses that allow attackers to access files outside intended boundaries. Two-thirds incorporate APIs vulnerable to code execution attacks. One-third use functions that accept unsanitized commands from users. Smaller percentages suffer from cross-site scripting flaws, SQL injection points, and open redirection issues.

These are not cutting-edge attack vectors. Each category appears on the OWASP Top 10 and CWE Top 25 lists that security teams have known about for years. The vulnerability types are well-understood and documented. What changed is the attack surface and how these old problems manifest in AI-powered systems.

Real-World Security Incidents in 2025 and 2026

Three Flaws in Anthropic's Reference Implementation

Three separate security flaws appeared in Anthropic's own reference implementation of the git server tool. Released on January 20, 2026, these vulnerabilities demonstrated how easily classic security mistakes slip into production code.

• The first issue allowed the git initialization function to create repositories anywhere on a system's storage. There was no check to confirm that the requested location matched the allowed directory.
• A second vulnerability in the same tool had an identical root cause: path arguments were never verified against the approved scope.
• The third problem involved passing user input directly to git commands without any cleaning or filtering.

The dangerous part about these flaws in an AI context: attackers do not need direct access to victim systems. They can hide malicious instructions inside readme files or GitHub discussions. When an AI assistant reads this content, the hidden instructions get executed as actual tool commands.

The Framelink Figma Server Breach

The Framelink Figma server, one of the most popular add-on tools with over 600,000 installations, contained a command injection flaw. The function that handled web requests constructed curl commands by directly inserting unsanitized user input into shell commands. An attacker could inject shell control characters through file identifiers: fileKey="$(id>/tmp/TEST)".

What made this particularly dangerous was the indirect attack path. Hackers could embed instructions in design files or comments. When an AI coding assistant processed these files, it would call the vulnerable function with malicious input. The assistant, interpreting this as legitimate work, would execute the attacker's code.

DNS rebinding attacks made things worse. A victim could visit a malicious website that redirects requests to their local Protocol server, triggering code execution with zero assistance from the AI system.

Code Generation Tools Inherit Upstream Vulnerabilities

The Orval code generation tool inherited flaws from upstream data sources. It reads API specification files and generates client code automatically. When generating Protocol servers, it failed to properly escape text fields. An attacker controlling an API specification could inject executable code:

paths:
  /pet/findByStatus:
    get:
      summary: Finds Pets by status.' + require('child_process').execSync("open -a Calculator").toString(),//

This pattern appeared twice in the same tool, affecting different code paths. Each time, the issue involved untrusted strings being concatenated directly into executable code.

Classic attack methods are exploiting new infrastructure. The weaknesses are old, but the application surface is fresh. Protocol implementations combine multiple sources of untrusted data, creating compound risks that organizations have not yet learned to manage.

Why Traditional Security Models Fail with AI Tools

The Fundamental Trust Assumption Problem

The fundamental problem lies in trust assumptions. Most teams assume that data coming from AI systems or Protocol servers can be trusted. This is incorrect for multiple reasons.

Large language models process text and follow instructions. They cannot distinguish between directions from actual operators and directions hidden within content they are asked to analyze. Every document, webpage, message, or response an AI reads becomes a potential injection point. Security designs that rely on the AI system filtering out malicious input will eventually break.

How Protocol Servers Become Attack Vectors

Protocol servers that pull information from outside sources face the same trust problem. A server reading git repositories, API definitions, Figma files, or API responses is consuming potentially hostile content. The server cannot assume this data is harmless just because it arrived through expected channels.

When an AI system or Protocol server produces output, that output is untrusted by definition. If the input was vulnerable to manipulation, so is the output. Any code using results from these systems must validate and clean that data before using it in sensitive operations.

Learning from Related Incidents Outside MCP

A separate incident in vLLM, another AI tool, showed this pattern clearly. The system loaded custom code modules from Hugging Face during startup without checking whether the code came from a trusted source. Attackers who could influence what code appeared in a model repository could execute arbitrary commands when the system started.

The security boundary existed in the documentation but was not enforced in the actual code.

Security Practices for AppSec Teams Managing Protocol Deployments

Pros and Cons of Current Model Context Protocol Security Approaches

Frequently Asked Questions About Model Context Protocol and Security

What exactly is Model Context Protocol and how does it work?
Model Context Protocol provides a standard method for AI systems to access external tools and data sources. Instead of each AI platform building its own custom connections, Protocol creates a uniform interface. This allows the same tool to work with multiple AI systems. It resembles USB-C for artificial intelligence: one standard that works everywhere.

Why are there so many security issues if the standard is new?
Speed outpaced security. Developers wanted to implement and deploy quickly. The protocol's design did not build in strong security requirements from the start. Companies released tools before considering how attackers might misuse them. The security community had not yet adapted its threat models to this new architecture.

Can attackers really execute code through hidden instructions in documents?
Yes, through a technique called prompt injection. When an AI system reads a document containing hidden instructions, it processes those instructions as valid commands. If the document is processed by an AI connected to Protocol servers with execution abilities, the attacker's instructions can run arbitrary code. This works even if the user never intended to run that code.

What is DNS rebinding and why does it matter for Protocol security?
DNS rebinding is an attack where a malicious website tricks a user's browser into sending requests to their local computer. A victim could visit an evil website that redirects requests to their Protocol server without their knowledge. The server would execute commands from the website. This happens automatically without the AI system's involvement.

Should organizations stop using Model Context Protocol?
Not necessarily. The protocol serves genuine purposes. However, organizations must treat it differently than they treat trusted internal systems. Apply security scanning to every tool. Verify all inputs. Clean all outputs. Monitor for unusual activity. Use the same rigor you apply to internet-facing systems.

How do I know if I have vulnerable Protocol servers?
Check your deployments against published security advisories. Review tool repositories for recent fixes. Test your servers with malicious inputs to see if they fail safely or execute code. Use automated scanning tools designed for code security analysis. Consult security experts if you are unsure.

What is the difference between direct and indirect attacks on Protocol tools?
Direct attacks come from someone with access to the Protocol server who sends bad input directly. Indirect attacks involve hiding malicious instructions in documents or data that an AI system will process, which then passes poisoned input to the Protocol server. Indirect attacks are harder to detect because they travel through the AI system as intermediary.

Are classical attack types different when they occur in AI infrastructure?
The attack types are identical. Path traversal, command injection, code insertion: these have existed for decades. The difference is the new attack vectors. AI systems introduce additional ways to send poisoned input to vulnerable tools. The combination of old vulnerabilities with new delivery methods creates unprecedented risk.

How Organizations Should Adjust Their Security Strategy

The critical insight from Model Context Protocol's first year is this: artificial intelligence infrastructure requires application security discipline, not just safety measures focused on the AI model itself. Treating AI systems and Protocol servers as trusted components leads to breaches.

Teams that change their threat models now will avoid learning these lessons the hard way. The approach is straightforward: treat AI outputs and Protocol inputs as hostile. Validate everything. Clean everything. Monitor everything. The vulnerabilities are not new, but the paths attackers can take to exploit them are.

Organizations implementing Protocol must also recognize that individual tools might be secure, but combinations create new risks. Security reviews must examine complete chains: which servers work together, what data flows between them, where trusted boundaries actually exist.

The gap between how fast people adopted Protocol and how slowly they added security controls created these problems. Closing that gap is the only way forward. This means slowing down implementation slightly to do proper security work, inventorying every deployment, auditing tool code before installation, and monitoring systems for exploitation attempts.

Application security teams should move this to the top of their priority list. The attacks are real. The vulnerabilities are documented. The fixes are known. Execution is what matters now.