Security teams keep asking me what MCP security actually means. Not in a "please define the acronym" way. In a "we found three MCP servers running on developer laptops and nobody knows who owns them" way. That's the real question. And it's a different question than the ones most API security guides are written to answer.
MCP security is not API security with a new name. The protocol creates a trust relationship between AI agents and production systems that most existing controls were never designed to inspect. A standard API gateway watches the perimeter. MCP hands an AI agent the keys to what's inside and then asks you to figure out governance later.
This is the part teams learn late.
The attack surface nobody budgeted for
- MCP creates a bidirectional trust path between AI agents and internal systems that standard API gateways don't inspect.
- 53% of MCP servers use long-lived static secrets - the exact credential pattern that makes supply-chain compromise easy.
- Registry-level hijacking is possible without any code-level vulnerability; metadata alone is enough.
- A hardened LLM plus hardened underlying systems still leaves you exposed if the MCP server layer is uncontrolled.
- Classic vulnerabilities apply at scale: 43% command injection, 22% path traversal in tested implementations.
What MCP Security Actually Means
MCP security covers the controls, safeguards, and monitoring applied to MCP hosts, servers, and registries to prevent data exposure, unauthorized tool execution, and protocol-level abuse. That definition sounds manageable until you look at what it has to cover in practice.
Standard API security protects a request/response boundary. You authenticate at the edge, you validate inputs, you log what crosses the line. MCP does something structurally different. It creates a bidirectional trust relationship between an AI agent and the systems it connects to, meaning the agent doesn't just query a resource, it can invoke tools, read files, execute commands, and chain those actions together across multiple connected systems. The AI agent is inside the perimeter. The MCP server acts as the bridge.
That bridge is what most API gateways are not built to inspect. They can see that a request happened. They generally cannot see what the AI agent was told, what tool it decided to call, or whether the tool description it trusted had been tampered with upstream. The attack surface extends to the protocol layer, the registry where servers are discovered, and the host environment where the agent runs. None of those layers exist in a conventional API integration.
This distinction matters because teams that treat MCP as "just another integration" apply the wrong controls, audit the wrong logs, and miss the wrong failures - usually until something has already moved data it shouldn't have.
How MCP Works and Where the Trust Boundary Sits
The Model Context Protocol has three components, and each one carries a distinct trust-boundary problem. Understanding them separately is not academic. It's the difference between knowing where to put the controls and installing them in the wrong place.
The host is the environment where the AI agent actually runs. An IDE like Claude Desktop or Cursor is a host. So is an orchestration platform, an agentic pipeline runner, or a custom application that embeds an AI model. The host decides which servers the agent can reach, manages how the agent's context is constructed, and ultimately determines the blast radius if something goes wrong. A compromised or misconfigured host doesn't just expose one tool. It exposes everything the agent can see from that environment.
The client is the protocol-level connector. It handles the actual communication between the host and a specific MCP server: initiating sessions, sending requests, receiving tool responses. The client is what translates an agent's intent into a concrete network call.
The server is what exposes tools, resources, and prompts to the agent. It's the component that sits closest to your actual systems - your databases, your source code repositories, your cloud APIs. When the agent calls a tool, the server executes it. That execution can read files, trigger CI/CD pipelines, run queries, or call downstream APIs depending on what the server exposes.
What matters here is that these components form a chain of delegated trust. The host trusts the client. The client trusts the server. The server trusts the tool definitions it exposes. An attacker who can influence any link in that chain can influence agent behavior - not by attacking the LLM directly, but by manipulating the environment the LLM operates in.
MCP Host and MCP Client: What Each Component Controls
Teams conflate these two constantly. I've seen security architects scope controls for the client layer because that's where the network activity happens, while completely missing that the host is where the agent's permissions are actually defined.
The MCP host controls the broader execution environment. It defines which servers the agent can connect to, manages local MCP server configuration, and determines what context the agent receives. The host is where the security perimeter should be established first, because it governs the agent's entire action space. A misconfigured host is a misconfigured blast radius.
The MCP client sends protocol-level requests to a specific server. It is a connector, not a governor. The client doesn't decide what the agent is allowed to do - that's the host's job. But the client does establish the session, handle authentication, and manage the transport layer for each server connection. It's a narrower control point than most teams assume when they hear "client."
MCP operates with these two components working in sequence. The host sets the environment; the client executes within it. Fail to distinguish them and you end up with access controls in the wrong place - which is exactly where most misconfigurations start.
Where the MCP Server Fits Into an Agentic AI Pipeline
The MCP server is the highest-value target in the pipeline. Everything the AI agent can actually do flows through it. One or more MCP servers expose the tools, resources, and prompts the agent can invoke - and "tools" in this context means real system access: read a file, query a database, push code, call an external API, send a notification.
When an AI agent makes a call to the MCP server, it's not asking a question. It's requesting an action. The server's response shapes what the agent does next. Available tools are listed in the server's manifest, and the agent selects from them based on its instructions and context. This is why MCP server security matters more than it might look from the outside: control the server, control the agent's actions. Compromise the server, and the agentic AI pipeline becomes a delivery mechanism for whatever the attacker wants run.
This is where the ticket usually starts.
MCP Security Risks You Will Actually Encounter
The risks in an MCP deployment are not hypothetical edge cases written up by researchers who want conference talks. They're measurable, they're reproducible, and several of them are present in the majority of real-world implementations. The threat landscape breaks into a few distinct categories, and they require different defenses.
Context Poisoning and Indirect Prompt Injection via MCP
This one catches teams off guard because it doesn't look like a vulnerability from the outside. A malicious actor doesn't need to attack the AI model or the underlying database. They just need to get malicious content into the model's context window via MCP - through a document the agent reads, an API response it receives, or a tool output it processes.
Once that content is in context, it can issue instructions to the model that override or redirect its behavior. The user doesn't see it. The visible interface looks normal. But the agent may now be exfiltrating credentials, sending data to an attacker-controlled endpoint, or taking actions the user never authorized - all because an external input in the MCP environment told it to. Invariant Labs has demonstrated this attack class with working examples against real MCP deployments. The defense isn't to trust the model more. It's to segregate untrusted external content so it never reaches the model's context as an instruction-bearing input.
Command Injection, Path Traversal, and SSRF: Classic Vulnerabilities That Still Apply
A recurring misconception is that MCP's security story is mostly about prompt injection - an AI problem that requires AI defenses. The data says otherwise.
An empirical study of MCP implementations found that 43% of tested servers had command injection flaws, 22% allowed path traversal or arbitrary file reads, and 30% had SSRF vulnerabilities. These are traditional web application weaknesses showing up in AI tooling at rates that would be alarming in any other context. They apply here because MCP servers accept inputs, pass them to system commands and file operations, and make outbound network requests - all the same patterns that produce these vulnerabilities in conventional applications.
The MCP framing doesn't change the underlying mechanics. A server that passes unsanitized input to a shell command is vulnerable to command injection whether an LLM generated that input or a human typed it. What changes with MCP is the attacker's reach: they can influence the input without ever directly touching the server, by manipulating what the AI agent was told to send.
📊 By the numbers:
In tested MCP implementations, nearly half had exploitable command injection flaws and nearly a third had SSRF vulnerabilities. These aren't edge cases or theoretical exposures - they're the same vulnerability classes that produced major breaches in conventional web infrastructure, now appearing in the layer that hands AI agents direct access to internal systems.
Registry-Level Server Hijacking and Supply-Chain Risk
This is the one that refutes the "if we harden the LLM and harden the underlying systems, MCP is infrastructure-level plumbing" argument most directly.
A measurement study of 67,057 MCP servers across six public registries found 833 vulnerable servers and 18 with suspicious descriptions enabling invocation manipulation and registry-level hijacking. The attack doesn't require a code-level vulnerability. Weak ownership checks and untrusted metadata in the registry are enough. An attacker who can insert a malicious or modified server into the registry that an agent or developer discovers can shape model reasoning and agent behavior at scale, before the agent ever reaches the hardened LLM or the hardened database.
Third-party MCP servers pulled from public registries carry supply-chain risk comparable to unvetted npm packages - and in the MCP ecosystem, the vetting infrastructure is far less mature. Security researchers have demonstrated tool poisoning attacks where seemingly benign server descriptions contained hidden instructions that caused agents to exfiltrate data or redirect actions without any visible indication to the end user. The mcp ecosystem's discovery layer is an attack surface. Teams that don't treat it as one are making an assumption the data doesn't support.
Security Controls That Actually Move MCP Risk From Theoretical to Manageable
Theory ends here. The following controls address the specific failure modes above, not the general category of "securing AI systems." They're drawn from the Coalition for Secure AI's practical MCP guide and the Astrix Security research on MCP credential practices.
Authentication, Authorization, and Least-Privilege Tool Access
Start with identity. Every MCP server connection should require strong authentication. TLS at minimum; mutual TLS for server-to-server connections where you control both ends. Credentials should be short-lived and scoped - not API keys stored in environment variables, which the Astrix Security "State of MCP Server Security 2025" found in 79% of implementations and which are exactly the kind of static secret that makes credential theft straightforward.
MCP authorization should be scoped to exactly what the AI agent needs for the task it's performing - not what's convenient to expose. A tool that an agent needs to read CRM records should not also have write access unless the workflow explicitly requires it. Treating MCP tools as a trust boundary, as the security community recommends, means restricting access to specific directories and APIs rather than granting broad permissions and trusting the model to stay in bounds.
A practical starting checklist:
- Replace static API keys with OAuth or short-lived tokens Only 8.5% of MCP servers currently use OAuth. That number needs to be much higher in any deployment you control.
- Scope credentials per tool, not per server One server exposing ten tools should not use one set of credentials with access to everything all ten tools might theoretically need.
- Rotate secrets on a schedule, not on a breach If credential rotation requires manual steps, it won't happen consistently. Automate it or accept that it won't happen.
- Audit tool permission scope quarterly Available tools accumulate scope over time. What started as read-only access tends to expand. Review it.
Input Validation, Sandboxed Execution, and What Not to Log
Given the command injection and path traversal rates in real deployments, treating all external inputs as untrusted is not optional. Validate and sanitize everything before it reaches a tool that executes commands, reads files, or makes outbound requests. This isn't specific to MCP - it's standard secure coding practice that the AI framing sometimes causes teams to skip because they think the model is the validation layer. It is not.
Sandboxed execution limits the blast radius when something gets through. An MCP server that spawns child processes or accesses the local filesystem should run in an environment where those capabilities are explicitly constrained - specific directories, specific network destinations, no access to production secrets from within the sandbox. Strict filesystem and network limits are a named best practice for a reason: a local MCP server with unrestricted filesystem access is a path traversal vulnerability waiting for someone to find the input.
On logging: audit every tool invocation. Log what was called, with what arguments, and what was returned. But a malicious MCP server might try to extract sensitive tokens from logs if those logs are accessible. Do not log raw credential values, auth tokens, or secrets that appear in payloads. Log enough to reconstruct what happened; not enough to hand an attacker what they need if the log is compromised. This is the Black Hills Information Security recommendation that teams consistently skip.
Monitoring MCP Interactions and Keeping Visibility Across the Graph
An MCP server doesn't make one API call. It can trigger chains of tool calls across multiple systems, and those chains can branch. A single compromised interaction can propagate through a workflow in ways that are invisible in any single system's logs but clearly visible in a graph-level view of the interaction sequence.
Continuous monitoring for MCP deployments means tracking not just whether a tool was called, but what it called downstream. Watch for: tool calls to resources outside their expected scope, unusual argument patterns (long strings in filesystem paths, unexpected network addresses), authentication failures on tool invocations, and any tool that suddenly starts executing more frequently than its baseline. Stale MCP server configuration files are also a signal - a server that hasn't been touched in six months may have drifted from its original security posture without anyone noticing.
Teams building this in Latenode have an advantage: the AI Agent Builder allows multi-step orchestration where each agent action is a discrete workflow step with its own execution log. That means tool call chains become visible as structured execution sequences rather than opaque inference traces - a practical way to get the graph-level visibility that MCP monitoring requires, without building a custom observability stack from scratch.
Who Actually Needs MCP Security Controls and What They Are Trying to Prevent
Three teams are dealing with different versions of this problem right now. Each one is trying to prevent a specific failure, not a general category of "AI security risk."
Security and platform engineering teams exposing observability and CI/CD data to AI agents
These teams are connecting AI agents to deployment pipelines, monitoring systems, and infrastructure APIs so developers can query build status, trigger rollbacks, or investigate incidents through a conversational interface. What they're trying to prevent is an uncontrolled production pathway: an agent that can read deployment logs can, under the wrong conditions, also trigger deployments. The threat model is misconfigured tool scope plus a sufficiently persuasive prompt injection in an incident report or log entry. The control they're missing most often is least-privilege tool access - read access and write access separated cleanly at the MCP server layer. AI adoption in this context moves fast enough that security controls are added after the fact, which is exactly when the exposure has already happened.
Developer experience and AI tooling teams building IDE integrations and code assistant workflows
These teams connect MCP servers to source code repositories, issue trackers, and code review systems so AI assistants can help developers find context, suggest fixes, and understand codebases. What they're trying to prevent is unauthorized code changes and credential exfiltration via tool poisoning - a third-party MCP server that looks like a useful code search tool but contains hidden instructions in its tool description that redirect the agent to exfiltrate API keys from .env files. Security professionals in this space are increasingly treating every third-party MCP registry entry the way application security teams treat unvetted npm packages: as an untrusted artifact that requires review before use in production. AI assistants with access to code repositories are high-value targets, and the registry supply-chain vector is the one most developer tooling teams haven't fully accounted for.
AppSec and DevSecOps teams trying to get ahead of a new AI security surface
These teams are dealing with MCP as shadow IT: new AI tools keep appearing in production environments, each with its own MCP server configuration, no central inventory, and unclear access scopes. What they're trying to prevent is registry hijacking and unaccounted access paths - situations where an agent has been granted access to a system that compliance requires be audited, but nobody added the MCP server to the asset inventory because it was installed by a developer on a Friday afternoon. The new AI challenge here isn't a technical one. It's a governance one. The agents themselves are increasingly well-governed; the servers they connect to are not.
Three Misconceptions About MCP Security That Create Real Gaps
These three misconceptions show up repeatedly before incidents. Not at the theoretical stage, where they'd be easy to correct. At the design stage, where they shape the architecture.
Misconception one: MCP is just another plugin system, so API security controls cover it. This one sounds reasonable until you look at the trust model. A conventional API integration has a defined client, a defined endpoint, and a fixed set of operations the client can request. MCP allows an AI agent to dynamically discover and invoke tools based on its runtime context and instructions. The agent's decisions are shaped by inputs the security stack often never touches - tool descriptions, context injected from external documents, registry metadata. Standard API controls can't audit what the agent was told to decide; they can only observe what it subsequently requested. That gap is the attack surface that's specific to MCP.
Misconception two: if the LLM is hardened and the underlying systems are hardened, MCP is middleware-level afterthought. This is the framing that security-conscious teams fall into most often, which is also why it's the most dangerous one. Teams that have invested heavily in LLM safety and infrastructure hardening tend to treat MCP as plumbing - the pipe between two secure things. But that pipe is exactly the attack path the registry-scale research identified. The arXiv study of 67,057 servers found conditions for registry-level hijacking across public registries without any code-level vulnerability in the underlying systems. The agent can only act through MCP tools. Control the tools, and you control the agent - regardless of how hardened the model or the database behind it might be.
🤔 Wait.
If an AI agent can only act through MCP tools, then a compromised MCP server has direct access to everything the agent was granted permission to touch. The LLM's safety training doesn't help here - safety training is about what the model refuses to generate, not about what a manipulated tool instruction tells it to execute. The blast radius of a compromised server is exactly equal to the server's permission scope. Have you scoped that out recently?
Misconception three: prompt injection is the only real MCP security issue, so if you handle that, you're covered. The Equixly injection and SSRF statistics refute this directly. 43% command injection, 30% SSRF, 22% path traversal - these are classical infrastructure vulnerabilities appearing in AI tooling at rates that would trigger remediation programs in any conventional context. Prompt injection is a real and important threat class. It is not the only one. MCP servers accept inputs from AI agents and execute real operations against real systems. They're web-accessible services. They should be treated with the same secure development practices as any other web-accessible service.
I keep seeing teams skip the classical vulnerability work because the MCP security conversation has been dominated by the AI-specific attack vectors. That framing is accurate as far as it goes. It doesn't go far enough.
What the Future of MCP Security Looks Like as the Ecosystem Matures
Some things are clearly in progress. Others are genuinely open problems that no vendor or standards body has resolved.
Registry governance is the most obvious gap. The mcp security checklist conversation has matured rapidly in the past year, but there's still no standardized server verification process for public registries. Anyone can publish an MCP server. The adoption of MCP across developer tools has outpaced the ecosystem's ability to vet what's being adopted. Remote MCP servers discovered through public registries carry the same supply-chain risk as unreviewed open-source packages, without even the social governance signals that npm and PyPI communities use to identify suspicious packages.
Standardized server signing is the technical answer, but supporting MCP ecosystem-level signing requires coordination across multiple registry operators and toolchain providers. That coordination is early-stage. The Astrix research finding that 88% of servers require credentials while most use static secrets suggests the identity layer needs standards work before the signing layer will matter.
Cross-agent context abuse is an emerging threat model that's not well-defined yet. As multi-MCP deployments become common - one agent invoking tools from several servers, sharing context across them - the interaction surface for context poisoning and privilege escalation grows in ways that single-server security models don't address. Who bears responsibility for auditing a context chain that crosses three servers owned by three teams? That question doesn't have a clean answer today, and I expect it to generate the first wave of serious agentic AI incidents when someone finds out the hard way.
References
- Astrix Security - State of MCP Server Security 2025: Research Report - 05/02/2026
- OX Security - The Architectural Flaw at the Core of Anthropic's MCP - 14/04/2026
- arXiv - Security Threat Modeling for Emerging AI-Agent Protocols - 16/04/2026
- Invariant Labs - MCP Security Notification: Tool Poisoning Attacks - 31/03/2025
- Xinyi Hou - Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions - 24/05/2026
- Coalition for Secure AI - Securing the AI Agent Revolution: A Practical Guide to Model Context Protocol Security - 20/01/2026
- EWright3 - MCP Servers Are a Shadow IT Problem You Don't Know You Have Yet - 05/05/2026
- Docker - What's Next for MCP Security? - 05/05/2025
- Invariant Labs - MCP Security Notification: Tool Poisoning Attacks - 31/03/2025
- OWASP Foundation - MCP Tool Poisoning - 24/05/2026
- Simon Willison - Model Context Protocol has prompt injection security problems - 09/04/2025
- arXiv - A First Look at the Security Issues in the Model Context Protocol Ecosystem - 17/10/2025
