MCP Security: What We're Finding in AI Agent Assessments

The protocol that's becoming the standard interface between AI and enterprise systems has security gaps most organizations haven't yet learned to see.

When OpenAI adopted Anthropic's Model Context Protocol (MCP) in March 2025, it signaled a turning point for AI agent infrastructure. MCP standardizes how AI assistants connect to external tools - databases, file systems, APIs, cloud services. The industry called it "USB for AI."

That analogy is more apt than intended. Like USB before it, MCP prioritizes interoperability over security. And like USB, the security implications are arriving faster than the safeguards.

At Red Asgard, we've been assessing MCP deployments since the protocol gained enterprise traction. This article shares what we're finding - not as an exploitation guide, but as a practitioner's view of where the risks actually live.

The Trust Boundary Problem

Traditional security models assume a clear separation: users interact with applications, applications interact with backends. Authentication happens at each layer. Trust is explicit.

MCP introduces a new pattern:

AI Context -> MCP Server -> Backend Systems

The AI's context - which includes user input, retrieved documents, tool outputs, and injected instructions - becomes a control plane. Whatever influences that context influences what the AI asks the MCP server to do.

This is the fundamental shift. Security teams understand input validation for user-submitted data. They understand API authentication. They don't yet have mental models for adversarial context manipulation.

The MCP server sits in a privileged position. It bridges AI-generated intent with production databases, cloud credentials, and internal services. That trust boundary is where most vulnerabilities live.

What the Research Shows

Third-party research paints a consistent picture.

Knostic's July 2025 study discovered over 1,800 MCP servers exposed to the public internet. When researchers manually tested a sample, every single one allowed unauthenticated access to internal tool listings. Every one.

Astrix Security's October 2025 analysis of more than 5,000 open-source MCP implementations found that while most require credentials, over half rely on long-lived static secrets - API keys and personal access tokens that rarely rotate. The remainder require no authentication at all.

HiveTrail's research found that nearly half of open-source MCP servers contain command injection vulnerabilities. Many allow unrestricted URL fetches - a classic SSRF vector that can expose cloud metadata services and internal networks.

Trend Micro identified hundreds of MCP servers operating without client authentication or traffic encryption, collectively exposing over a thousand tools to potential attackers.

These aren't theoretical findings. They're the current state of deployed infrastructure.

The Specification Problem

The root cause isn't careless implementation. It's the specification itself.

MCP's official documentation states that authentication is "transport-dependent and optional." In practice, optional security features tend to remain optional. We've seen this pattern before - with early OAuth implementations, CORS configurations, and API key management. When the spec doesn't mandate protection, production deployments often lack it.

When authentication is optional in a protocol designed to bridge AI and privileged systems, insecurity becomes the default outcome.

This isn't a criticism of Anthropic's protocol design team. MCP solves real interoperability problems. But security practitioners should understand that "spec-compliant" and "secure" are not synonyms here.

MCP Architecture: Where Attacks Happen

Understanding the topology helps identify where risks concentrate:

+------------------+
|   AI Agent       |  (Claude Desktop, ChatGPT, Custom)
|   (Client)       |
+--------+---------+
         | MCP Protocol (JSON-RPC over stdio/SSE/HTTP)
         |
+--------v-----------------------------------------+
|           MCP Server                             |
|  +----------+  +----------+  +--------------+   |
|  | Tools    |  |Resources |  | Prompts      |   |
|  | (Actions)|  | (Data)   |  | (Templates)  |   |
|  +----------+  +----------+  +--------------+   |
+--------+-----------------------------------------+
         |
+--------v-----------------------------------------+
|    Backend Systems                               |
|  +- File System                                  |
|  +- Database (PostgreSQL, MySQL, SQLite)         |
|  +- Cloud APIs (AWS, GCP, Azure)                 |
|  +- Browser automation                           |
|  +- Internal services                            |
+-------------------------------------------------+

Attacks can occur at multiple points:

Client -> Server: Compromise the AI agent's context, manipulate what it requests
Server tools: Inject commands, poison implementations, exploit input validation failures
Server -> Backend: Leverage the server's privileged access to databases, filesystems, cloud APIs
Server exposure: Unauthenticated servers, LAN-accessible instances, misconfigured network bindings

Attack Surface Taxonomy

MCP exposes three primitives, each with distinct risk characteristics.

Tools: The Primary Target

Tools are functions the AI agent can invoke: execute_shell, query_database, read_file, send_email. The security assumption is that AI agents will only make benign tool calls.

That assumption breaks under adversarial conditions.

If you've done traditional API security work, think of tools as endpoints with minimal input validation and implicit trust in the caller. The difference is that the "caller" is an AI whose context can be manipulated by external data sources.

Common tool categories we encounter in assessments:

Tool Type	Examples	Primary Risk
Shell execution	`run_command`, `execute_shell`	Command injection, privilege escalation
Database access	`query_database`, `sql_execute`	SQL injection, data exfiltration
File operations	`read_file`, `write_file`, `list_directory`	Path traversal, sensitive data access
HTTP requests	`fetch_url`, `http_request`	SSRF, internal service access
Cloud APIs	`aws_cli`, `gcloud_run`	Credential theft, cloud pivot

Resources: Data Exposure

Resources are data endpoints - file paths, database tables, API connections. Standard web application vulnerabilities apply: path traversal, SSRF, access control bypasses. The difference is that these vulnerabilities exist in a new protocol that security tools don't yet scan for.

Prompts: Behavioral Influence

MCP servers can provide prompt templates to AI agents. Compromise a server in the supply chain, inject prompts that alter AI behavior for every future session. This is a persistence mechanism that doesn't require traditional malware.

The Audit Gap

Perhaps most significant for security teams is what they can't see.

Unlike HTTP, SSH, or SQL - protocols with well-established logging standards - MCP has no standardized audit format. Each implementation logs differently. Many don't log at all.

This creates an asymmetric advantage for attackers. Malicious tool calls blend seamlessly with legitimate AI agent activity. Traditional security monitoring, designed for human-initiated actions, struggles to distinguish between an AI assistant performing authorized work and one executing injected instructions.

In our assessments, we routinely ask: "Can you show us MCP tool call logs?" The answer is usually either "We don't log those" or "We log them, but they're not in our SIEM."

MCP activity is essentially invisible to most security operations centers.

What High-Severity CVEs Demonstrate

Theoretical risks have become practical exploits.

CVE-2025-32711 ("EchoLeak") demonstrated a zero-click attack against Microsoft 365 Copilot. CVSS 9.3. The attack embedded hidden instructions in email content - invisible to human readers but processed by the AI. Copilot could be manipulated into extracting sensitive data from its context and transmitting it externally. Microsoft patched the vulnerability in June 2025.

The significance: this worked against a production AI system with dedicated security teams and purpose-built defenses. Less hardened MCP deployments face similar or greater risk.

CVE-2025-6514 affected the widely-used mcp-remote package (over 437,000 downloads). CVSS 9.6. The vulnerability allowed remote code execution by tricking a victim into connecting to a malicious MCP server. One crafted server response could compromise the connecting machine entirely.

Related research from Backslash Security identified what they termed "NeighborJacking" - hundreds of MCP servers bound to all network interfaces, accessible to anyone on the same local network. In corporate environments with flat network architectures, this creates significant lateral movement opportunities.

These aren't isolated bugs. They're class-proofs - demonstrations that the vulnerability categories are exploitable at scale. When we conduct assessments, we test for these patterns - not to replicate the exact CVEs, but to identify whether the underlying vulnerability classes exist in our clients' deployments.

Attack Patterns We See in Practice

Without providing exploitation details, here are the patterns that consistently appear in our assessments:

Context Manipulation

Traditional prompt injection targets AI outputs. The more concerning pattern targets AI actions.

An attacker poisons a data source the AI will process - a webpage, a document, a database record. The AI reads the poisoned data. Hidden instructions alter its behavior. The AI invokes MCP tools with attacker-influenced parameters.

This is indirect and persistent. The attacker doesn't interact with the AI directly. They wait for the AI to come to them.

Authentication Bypass

When authentication is optional by specification and missing in practice, bypass is trivial. Many MCP servers accept connections from any source, enumerate their full tool inventory on request, and execute tool calls without verifying authorization.

Input Validation Failures

MCP tools frequently construct shell commands, SQL queries, or file paths from AI-provided input. Without proper sanitization, classic injection vulnerabilities apply. The protocol is new; the vulnerability classes are old.

Supply Chain Risks

Unofficial registries index over 16,000 MCP servers. Anyone can publish. Unlike npm or PyPI, which have implemented security scanning, MCP registries remain largely unvetted.

A malicious server can function normally while silently exfiltrating every query it processes. The tool works correctly. Users see expected behavior. The attacker accumulates data.

Typosquatting is trivial: database-connector vs databse-connector. Developers copy-paste configurations. Typos happen. The wrong server gets installed.

What We Typically Find in Assessments

Based on our experience, here's what we consistently discover:

Finding	Severity
Missing authentication on MCP servers	Critical
Command injection in tool handlers	Critical
Unrestricted URL fetches (SSRF)	High
Path traversal in file tools	High
Static/long-lived credentials	Medium
No structured audit logging	Medium
Network over-exposure (0.0.0.0 binding)	High

When we find an MCP deployment with proper authentication, input validation, and logging - that's unusual. We note it as a positive finding. It's that rare.

The pattern is consistent: rapid deployment to enable AI capabilities, minimal security consideration, and configurations that would never pass review for traditional API infrastructure.

What We Recommend to Clients

Based on our assessment experience, these are the priorities we recommend:

Immediate Actions

Inventory MCP deployments. Many organizations have adopted AI agents without centralized visibility into which MCP servers those agents connect to. You can't secure what you don't know exists.

Require authentication on all MCP servers. The specification makes this optional; organizational policy should not. Reject anonymous connections.

Treat AI-generated input as untrusted. Tools should validate all parameters regardless of source. The AI's context can be adversarial.

Assess network exposure. MCP servers bound to all interfaces, accessible from local networks, or reachable from the public internet represent immediate risk.

Short-Term Improvements

Implement logging standards. Decide now what MCP activity you need to capture. Waiting until after an incident to discover what wasn't logged is a painful lesson.

Segment MCP servers. They shouldn't have unrestricted access to cloud metadata services, internal APIs, or production databases beyond what they specifically need.

Review tool permissions. Each tool should have the minimum privileges required. An AI assistant doesn't need execute_shell with root access.

Longer-Term Maturity

Baseline normal behavior. Understand what legitimate AI agent activity looks like so you can detect deviations. This requires logging first - you can't baseline what you don't observe.

Include MCP in threat models. Most LLM threat models focus on prompt injection affecting outputs. Expand to include action-layer attacks. MITRE ATLAS provides a good starting taxonomy.

Integrate with security operations. MCP logs should feed into your SIEM. Tool calls should be correlatable with other security events. Build detection rules for anomalous patterns.

Conduct regular assessments. MCP deployments change as teams add new tools and capabilities. Point-in-time security reviews become stale. Build assessment into your AI governance cadence.

A Practitioner's Perspective

We've been doing security work for long enough to recognize familiar patterns in new packaging.

MCP's current state reminds us of early REST API security - everyone excited about the interoperability benefits, nobody thinking about authentication until the first breach. It reminds us of early container security - rapid adoption, security teams playing catch-up, "it works" prioritized over "it's secure."

The difference is that MCP sits at a particularly sensitive trust boundary. It's not just exposing data - it's providing a mechanism for AI-generated intent to execute privileged actions. That's a new kind of attack surface.

The good news: the vulnerabilities are fixable. Authentication can be required. Input validation can be implemented. Logging can be standardized. None of this is technically hard.

The challenge is organizational. MCP adoption is driven by AI teams eager to enable capabilities. Security review happens later, if at all. By the time someone asks "is this secure?" the deployment is in production, users depend on it, and remediation becomes painful.

Our recommendation: get ahead of it. If your organization is deploying AI agents, assess the MCP infrastructure now. The vulnerabilities are easier to fix before they're in production. The conversations are easier to have before there's an incident.

The window for proactive security is narrowing. The window for reactive incident response is always open, but nobody wants to enter through it.

The Window Is Open

MCP represents a genuine advancement in AI agent interoperability. The protocol solves real problems. Major players - Anthropic, OpenAI, and an expanding ecosystem - are investing heavily in its success.

But the security community has a narrow window to address foundational issues before the ecosystem matures. The vulnerabilities being discovered now are the kind that become permanent technical debt if not addressed early.

History offers cautionary precedents. USB took years to develop adequate security controls after widespread adoption. OAuth implementations still vary wildly a decade after standardization.

MCP is young enough that the right choices now could prevent those patterns from repeating. The question is whether organizations will address these issues proactively - or only after they become incident response lessons.

How Red Asgard Can Help

We offer specialized AI security assessments that include MCP infrastructure review:

MCP Security Assessment

Server discovery and enumeration
Authentication and authorization testing
Tool input validation analysis
Context manipulation susceptibility
Network exposure evaluation
Logging and monitoring gap analysis

AI Agent Security Review

End-to-end attack surface mapping
XPIA susceptibility testing
Supply chain risk assessment
Integration security review

Red Team Engagements

Adversarial simulation against AI agent infrastructure
Attack chain development and demonstration
Detection gap identification
Remediation validation

If your organization is deploying AI agents - or planning to - we'd welcome the opportunity to discuss your security posture.

Contact: [email protected]

This article reflects our assessment experience through December 2025. MCP security is an evolving field; specific vulnerabilities and mitigations may change as the protocol matures.

References

Share this article

Help spread the word about security best practices.