Executive summary
This blog post provides a security analysis for teams that are building Model Context Protocol (MCP)-exposed services.
Most MCP security discussions have so far focused on the agent being diverted to misuse its connected MCP servers.
MCP servers themselves, however, are also direct attack surfaces.
Traditional application security risks apply directly to MCP, with additional considerations.
The MCP protocol naturally reveals capabilities and potential business logic attack maps.
MCP tools often use permissive validation to accommodate large language model (LLM) inputs, increasing exposure to injection risks in downstream systems.
MCP servers might fail to enforce authorization, expose excessive tools, skip object-level checks, and trust agent-supplied parameters, enabling unauthorized access and privilege escalation.
High-volume MCP agent traffic (parallel, rapid tool calls) creates a risk of denial-of-service (DoS)–like load and rapid cost exhaustion, requiring identity-aware rate limits and strict accounting.
The Model Context Protocol (MCP) has quickly become the primary mechanism for connecting AI agents to external services. MCP standardizes how agents discover and invoke capabilities, much like REST once standardized how web applications communicate over HTTP.
Most of the discussion so far about MCP security has focused on how poorly designed, compromised, or malicious MCP components can influence or manipulate an AI agent’s behavior, or how an agent can be tricked into manipulating its MCP servers.
Typical scenarios involve poisoned tools, tool shadowing, rug-pull attacks, and compromised context designed to steer the agent toward unintended actions. These risks are well reflected in several OWASP MCP Top 10 threats, including:
These all describe ways attackers can exploit MCP to shape the agent’s reasoning and decision flow.
A second threat surface: MCP servers themselves
There is, however, a second threat surface that has received far less attention: the organizations building and exposing services through MCP for external agents to consume. We have previously discussed the different MCP patterns that organizations are adopting. In this context, the MCP server itself becomes a direct target.
MCP servers expose capabilities, data access, and automation interfaces. Like APIs, they can be probed and interacted with directly by attackers without necessarily manipulating an agent first. Attackers may send malformed protocol messages, enumerate tools and resources, extract business logic from tool descriptions, exploit authentication or authorization gaps, or trigger excessive resource consumption.
Some server-side concerns do appear in the current MCP threat model. For example, the following security concerns touch on weaknesses in how MCP servers manage credentials, permissions, and access control:
These threats, however, are typically framed by how a compromised MCP component influences an agent’s behavior, or how the agent can be manipulated into misusing its connected MCP servers.
The perspective we explore in this blog post is slightly different. We look at MCP servers as directly reachable services and examine how attackers might interact with them the same way they target any exposed web application interface by identifying direct exploitation paths against the MCP service itself.
From API to MCP: Similar surface, new exposure
When organizations expose capabilities through MCP, they are effectively publishing an AI-native API. However, compared with today's APIs, MCP inherits and extends this attack surface in multiple ways, including:
Protocol-level attacks
Version downgrade
Malformed message injection
Oversized payloads
Protocol-level attacks
MCP is a structured JSON-RPC–based protocol with defined message types, versioning, and schema expectations. Like any protocol implementation, the server-side parsing logic that handles incoming messages is an attack surface on its own.
MCP is a structured JSON-RPC–based protocol with defined message types, versioning, and schema expectations. Like any protocol implementation, the server-side parsing logic that handles incoming messages is an attack surface on its own.
Version downgrade
MCP includes protocol version information as part of the initialization handshake. During this step, the client declares the protocol version it supports so the server can determine compatibility. In most implementations, the server either accepts compatible versions or rejects unsupported ones.
However, if an MCP server maintains backward compatibility with older protocol versions, the version value may influence how the request is processed. In such cases, an attacker might attempt to declare an older version to trigger legacy code paths, weaker validation logic, or deprecated behaviors. Although MCP itself does not define a downgrade mechanism, improper version handling in server implementations may expose legacy functionality.
Malformed message injection
MCP parsers consume JSON structures with defined schemas. Sending messages that deviate from those schemas — such as injecting unexpected fields, using invalid field values, or structuring messages in ways the specification forbids — can exercise error handling code that was written quickly and tested lightly. Malformed inputs have historically been a reliable path to crashes, information leaks, or exploitable conditions in protocol parsers.
Particular variants that are worth attention include:
Injecting nonexistent fields to test whether the server silently ignores or logs them
Sending fields with out-of-range or type-incorrect values to trigger exception paths
Duplicate field injection where a server's parser may resolve duplicate keys differently than the application layer expects, creating an inconsistency that an attacker can exploit
Using special fields names that affect object construction and might trigger unsafe deserialization or prototype pollution
Oversized payloads
MCP messages carrying tool arguments and resource URIs have no intrinsic size limit imposed by the protocol. An attacker can send arbitrarily large payloads to exhaust memory, cause slow processing, or trigger DoS conditions on the server. Without explicit limits on message size and argument count and length, MCP endpoints are vulnerable to resource exhaustion attacks through payload volume alone.
Natural introspection and business logic attack map
The MCP mandates “list/tools” and “list/resources” capabilities that provide a catalog of your internal capabilities. An attacker that connects directly does not have to guess. Your server proactively broadcasts every "verb" it can perform, including descriptions of the business logic. You are handing the attacker a searchable catalog of your attack surface.
To be useful to an LLM, an MCP server must describe its tools in plain English (the description field); in a generic API, the documentation is for the developer. In MCP, the descriptions are functional metadata for the caller, which creates an “instructional” attack surface.
A searchable catalog of your attack surface
An attacker doesn't just see the parameters; they see the intended use cases and logic shortcuts you've baked into the description to help the AI. For example, if your description says, "Do not use this for admin records," an attacker now knows exactly where the sensitive data lives and that the underlying code might rely on client-side AI cooperation rather than server-side enforcement.
An attacker doesn't need to guess what “POST /api/v1/u-7nd-1” does. Your server will explicitly tell them: "This tool deletes user records based on a secondary email lookup," which provides a readable map of your business logic to anyone who can connect. You are handing the attacker a searchable catalog of your attack surface.
An attacker hitting the server directly can chain these deterministic functions together to create complex, unintended workflows.
The descriptions that help legitimate AI agents also provide very convenient help to offensive agents. Now, something that the traditional scanners were struggling with (i.e., translating generic APIs to a structured business logic) can more easily be exploited.
Injection attacks
Because MCP tools expect to be called by an LLM, which can be wordy or imprecise, developers often write the underlying deterministic logic to be more flexible to avoid breaking the AI's flow. As a result, they may make server-side validation more permissive than in a standard API. Parameters might be less strict — for example, a generic "search_query" string — allowing more flexible inputs instead of strict validation.
MCP tools frequently accept arguments that are later used to construct queries, commands, shell invocations, or downstream API calls against back-end systems. This validation slack creates a natural vector for injection attacks.
Back-end injection via tool arguments
Tool arguments used to build database queries without parameterization, shell commands without escaping, or LDAP filters without validation are vulnerable to the same injection classes that have plagued web applications for decades.
The MCP layer does not change the underlying risk, it simply adds a new path through which attacker-controlled input can reach vulnerable back-end code. Structured Query Language injection injection (SQLi), NoSQL injection, and command injection remain fully applicable.
Server-side request forgery
MCP remote resources retrieval tools — sometimes named fetch_url, crawl, import_document, or retrieve_external_data — are intended for obtaining external content, yet without strict validation they can expose systems to server-side request forgery (SSRF). An attacker can supply crafted URLs that target internal services, metadata endpoints, or private APIs reachable from the server’s network.
Since outbound requests are expected behavior for these tools, SSRF activity may not appear suspicious at the application layer. Without strict URL validation, outbound filtering, and metadata protections, an MCP server can become a pivot point into internal infrastructure.
Prompt injection via tool arguments
When an MCP tool internally relies on a downstream LLM to process its inputs, the tool arguments themselves can become a prompt injection vector. If the tool forwards these arguments directly into an LLM prompt without proper isolation or validation, the injected instructions can override the intended task, manipulate the tool’s output, or trigger unintended actions in downstream systems.
In this scenario, the vulnerability exists inside the MCP service implementation rather than in the calling agent, which expands the attack surface to the tool’s internal AI components.
Sensitive information disclosure
MCP tools that return data may return more than they should. This problem exists in traditional APIs, but it is amplified in MCP contexts because agents may automatically process and forward returned data to other tools, to external services, or into the context window of an LLM that may summarize or reproduce it in unexpected ways.
Technical information leaks
Error messages, stack traces, internal service names, infrastructure details, and debug information returned in MCP error responses give an attacker a detailed map of the underlying system. Because MCP developers aim to support the AI workflow, they may include more detailed information about why the initial request failed, allowing the agent to correct and retry it properly. A well-crafted sequence of malformed requests may elicit progressively more revealing error messages.
In its specification, MCP follows a JSON-RPC–style pattern, and developers can implement custom errors. The following example shows how an error message may reveal that the tool relies on a database behind the scenes, guiding an attacker to attempt database-focused attacks.
{
"jsonrpc": "2.0",
"id": "request-id",
"error": {
"code": -32603,
"message": "Database connection timeout"
}Personally identifiable information and business-sensitive data oversharing
As in APIs, over-returning data is a common API design shortcut. An LLM often prefers “give me everything relevant” to avoid follow-up calls and to hedge uncertainty. That pushes tool authors to return rich objects instead of minimal projections. Many MCP tools expose “search”, “get”, “list”, or “retrieve” primitives that map to back-end objects, and the easiest implementation is to return the back-end object as is.
This becomes a significant exposure when the recipient is an autonomous agent that may store, log, embed, or retransmit that data in ways the server operator cannot anticipate.
Broken authentication
Authentication in MCP is not defined by the protocol itself and is, instead, left to the implementer. This is both flexible and dangerous. Teams building MCP servers often focus on functionality first and authentication second, especially in early iterations in which the client is an internal agent. As those servers get exposed to broader audiences, authentication gaps become exploitable.
Common failure patterns include servers that rely solely on network-level controls ("only internal agents can reach this") without application-layer authentication or weak session handling, such as session IDs in URLs.
The agent-native nature of MCP clients complicates authentication further. Agents may operate with delegated credentials, service account tokens, or synthetic identities that are difficult to trace back to the originating human user, which creates accountability gaps that matter for audit and incident response.
Authorization and access control failures
Even when authentication is correct and the server can validate the caller, authorization is a separate problem. MCP exposes capabilities as tools, resources, and prompts. Not every agent should have access to every tool. Not every tool invocation should be permitted for every input.
Excessive tool exposure
MCP tool listings describe what the server can do. If all agents are allowed to use any tool without regard to their role or context, it may lead to unauthorized actions or improper access to data.
Broken object-level authorization and multi-tenancy risk
Any tool that retrieves a document by ID, reads a user record by account number, or accesses a workflow by handle becomes an attack surface if it only checks authentication. Without per-object authorization, a legitimate agent can enumerate or guess identifiers to access other users’ or tenants’ data, leading to unauthorized disclosure, cross tenant data exposure, and privilege escalation.
In agentic systems, multi-tenancy significantly amplifies this risk. Frameworks built around the MCP enable a single agent to interact with multiple tenants’ data through shared tools and context, creating a high-impact isolation challenge. A common antipattern is exposing tenant identifiers (for example, tenant_id, account_id) as tool arguments. This allows the agent, whether inadvertently or through manipulation, to alter these parameters and access data across tenants.
Although the manipulation may originate at the agent layer, the MCP server is the true enforcement boundary and, therefore, the primary attack surface. If the server trusts agent-supplied parameters or relies on a single shared agent identity, it effectively externalizes authorization decisions to an untrusted component. Mitigation requires the MCP server to enforce strict tenant isolation: Bind every request to a trusted user identity, derive tenant context server-side, and do not expose tool arguments that include tenant identifiers.
Malicious tool chaining
Agents invoke multiple tools in sequence as part of reasoning chains. A sequence of individually permitted tool calls may combine to achieve an operation that no single call would allow. Authorization logic that evaluates each tool invocation in isolation, without understanding the broader context of what an agent is attempting to accomplish across a session, is vulnerable to this class of compositional attack.
Direct resource URI manipulation
MCP introduces the concept of Resources and Resource Templates to mitigate agent context window overload.
An MCP Resource is a piece of server-exposed data (like files, logs, or schemas) accessible via URIs (e.g., “protocol://resource}”).
A Resource Template is a dynamic URI pattern (e.g., “get document by ID”) that allows the MCP server to expose different items using the same URI structure (e.g., “protocol://{resource_id}”).
By employing these concepts, MCP ensures that the model only retrieves necessary data, avoiding the need to include everything upfront in the agent's context window. In practice, many MCP servers expose templated URIs like file://, fetch://{url}, or postgres://{schema}/{table} to enable flexible data access.
But when these servers are reachable externally, this flexibility becomes risky: Attackers can enumerate resources, read unintended files via path traversal (e.g., file:///app/config/../../etc/passwd)l, trigger SSRF (e.g., fetch://169.254.169.254/...), or exploit weak URI parsing for template injection. This could turn MCP servers into direct data exposure and internal access surfaces rather than just passive context providers.
Unbound consumption and denial of wallet
Agentic workloads have fundamentally different traffic patterns than human-driven interactions. An agent pursuing a complex goal may invoke hundreds of tool calls in rapid succession, and multiple agents running in parallel may all target the same MCP server simultaneously.
Without appropriate controls, this creates a DoS risk that is structurally different from traditional API abuse, which can arise from entirely legitimate agents, not just adversaries.
Rate limiting and throttling
MCP servers need rate limiting strategies that account for agent traffic patterns: per-identity limits, per-session limits, and global capacity controls. Limits tuned for human-interactive APIs are almost certainly too permissive for agentic consumers and too restrictive in the wrong dimensions.
Cost and quota exhaustion
Many MCP tools ultimately invoke paid back-end services, such as LLM APIs, cloud functions, and third-party data providers. An agent, whether compromised, misconfigured, or by simply pursuing a poorly specified goal, can exhaust quotas and rapidly run up costs.
Budget controls and per-caller spending limits are not just operational concerns; they are security controls that limit blast radius.
Conclusion
The MCP has quickly become the standard mechanism through which AI agents interact with external systems. As adoption has accelerated, the security conversation has largely centered on protecting agents from malicious or compromised MCP components that attempt to manipulate their reasoning or how an agent can be induced to misuse its MCP servers.
This blog post highlighted another important perspective: MCP servers themselves are network-accessible services that can be directly targeted by attackers. When organizations expose capabilities through MCP, they effectively publish AI-native APIs that reveal tools, resources, and operational logic in a structured and machine-readable way. This transparency improves agent usability but also provides attackers with a clear map of the system’s capabilities.
Act now
Akamai enables organizations to act now. By building on our existing edge, API, and application security platform and extending it with MCP-aware intelligence, we help teams identify where MCP is emerging, apply practical guardrails during experimentation, and manage risk as exposure grows.
This approach allows organizations to adopt MCP today while relying on Akamai to evolve protection, visibility, and control as MCP use develops.
Tags
