White Paper | 2026-03-27 | Status: draft
Agentic MCP Security Best Practices Guide
Executive Summary
The Model Context Protocol has transformed the way AI agents interact with external systems, providing a standardized interface through which large language models can invoke tools, access data, and coordinate with other agents. Anthropic introduced MCP in late 2024, and by 2025 it had achieved broad adoption across enterprise development environments, cloud-based AI platforms, and multi-agent orchestration frameworks. The November 2025 specification (version 2025-11-25) formalized OAuth 2.1 as the authentication standard for remote MCP servers, representing a significant maturation of the protocol’s security posture [1]. However, the rapid pace of MCP adoption has outrun security governance, and the protocol’s architecture introduces a set of attack surfaces that traditional application security controls are insufficient to address.
The consequences of this security gap have been concrete and measurable. Between January and February 2026, security researchers and the broader community filed over 30 CVEs targeting MCP servers, clients, and infrastructure components [2]. The highest-severity finding, CVE-2025-6514, carried a CVSS score of 9.6 and affected the widely-used mcp-remote proxy package across more than 437,000 installed environments [3]. Real-world incidents in 2025 included cross-tenant data exposure at Asana, prompt injection attacks against the GitHub MCP server, unauthenticated remote code execution in Anthropic’s own MCP Inspector developer tool, and multiple supply chain compromises through malicious npm packages [4]. By early 2026, security researchers had catalogued nearly 7,000 internet-exposed MCP servers, with roughly half operating without any authentication controls [5].
This whitepaper provides enterprise security practitioners, platform architects, and AI governance teams with a structured framework for understanding, assessing, and remediating MCP security risk. The document begins with an analysis of the MCP threat landscape organized across six threat categories, followed by security requirements for each control domain, a four-level MCP Security Maturity Model with specific controls at each level, and practical implementation guidance. A cross-reference table maps each threat category to the corresponding OWASP Agentic Security Initiative (ASI) risk, CSA AI Controls Matrix (AICM) control domain, and MITRE ATLAS technique.
The central conclusion of this analysis is that MCP security requires defense in depth: no single control is sufficient, and organizations must address authentication, tool integrity, session management, supply chain validation, execution isolation, and behavioral monitoring in concert. Enterprises that treat MCP as critical infrastructure — applying the same rigor they would to an API gateway or identity provider — will be substantially better positioned than those that rely on default configurations and trust-on-first-use assumptions.
1. Introduction: MCP and the Agentic Tool Interface
The Model Context Protocol is an open standard that defines how AI models — particularly large language models — communicate with external tools, data sources, and services. In architectural terms, MCP operates as a client-server protocol in which an MCP host (such as Claude Desktop, Cursor IDE, or an enterprise agent orchestration platform) maintains connections to one or more MCP servers, each of which exposes a set of tools, resources, and prompts that the LLM can invoke. The protocol was originally designed to solve a practical integration problem: each new tool connection previously required bespoke code, and there was no standard way for an AI agent to discover, understand, or safely invoke external capabilities [6]. MCP addressed this by defining a JSON-RPC 2.0-based transport layer, a standard tool description schema, and, as of the 2025 specification updates, a formal authorization framework based on OAuth 2.1 [1].
The architecture of MCP creates three trust boundaries that are each independently significant from a security perspective. The first is the boundary between the LLM and the MCP client: the model reads tool descriptions and constructs invocations, but it cannot independently verify that tool descriptions are accurate or unmodified. The second is the boundary between the MCP client and MCP servers: the client must authenticate to servers and validate server responses, but many current implementations do so inadequately or not at all. The third is the boundary between MCP servers and the downstream systems they access — file systems, databases, external APIs, and cloud services — where the server acts as an agent on behalf of the requesting model with potentially broad, poorly-scoped permissions. Attacks against any of these boundaries can have cascading effects throughout an agentic pipeline.
The rapid adoption of MCP has been driven by a practical ecosystem effect. As of early 2026, hundreds of officially maintained and community-contributed MCP servers exist for systems including GitHub, Slack, Google Drive, Jira, Salesforce, AWS, and dozens of other enterprise platforms. The MCP TypeScript SDK and Python SDK provide reference implementations that have lowered the barrier for building new servers significantly. This proliferation has created both opportunity and risk: enterprise organizations can now connect AI agents to virtually any system in their environment, but the security posture of those connections varies enormously. The Astrix Security State of MCP Server Security 2025 research report found that a significant proportion of publicly accessible MCP servers exposed sensitive credentials, lacked transport security, or contained exploitable input validation flaws [7].
Understanding MCP security therefore requires understanding the entire lifecycle of a tool invocation: from the moment an LLM reads a tool description, through the authentication and authorization flow, to the execution of the tool’s underlying operation and the return of results. This document addresses each phase of that lifecycle with threat analysis and corresponding controls.
2. MCP Threat Landscape
The threat landscape for MCP deployments is characterized by a convergence of attack vectors from several distinct security domains: API security, prompt injection, supply chain compromise, and session management vulnerabilities. What makes MCP distinctive is that these vectors interact and amplify each other. A supply chain attack that installs a malicious MCP server can enable tool poisoning; a session hijacking attack can allow token reuse across tool invocations; a tool poisoning attack can exfiltrate credentials that enable further compromise. Security practitioners must therefore understand each threat category both independently and in terms of how it combines with others.
2.1 Pre-Authentication Remote Code Execution (CVE-2025-6514)
CVE-2025-6514 represents one of the most severe vulnerabilities identified in the MCP ecosystem to date, carrying a CVSS base score of 9.6. The vulnerability was discovered by the JFrog Security Research Team and disclosed in mid-2025. It affected versions 0.0.5 through 0.1.15 of the mcp-remote package, a widely-used proxy component that enables MCP clients such as Claude Desktop to communicate with remote MCP servers [3]. The mcp-remote package serves as an OAuth relay: when a client needs to connect to a remote server, mcp-remote handles the OAuth flow and proxies the authenticated connection. With over 437,000 downloads at the time of disclosure, it was deeply embedded in the developer tooling supply chain.
The root cause of CVE-2025-6514 was a failure to sanitize the authorization_endpoint URL value received from a remote MCP server during the OAuth flow initialization. When mcp-remote connects to a server, that server can respond with OAuth server metadata including an authorization_endpoint value. The vulnerable code passed this value directly to the operating system’s open() function — the same function used to open URLs in a browser — without validation or escaping. A malicious MCP server could provide a specially crafted value such as ; malicious-command as the authorization endpoint, causing the system shell to execute arbitrary commands on the victim’s machine [3]. The attack required no user authentication bypass: simply connecting a client to a malicious server was sufficient to trigger exploitation.
The broader implications of CVE-2025-6514 extend beyond the specific vulnerability. It illustrates the fundamental risk of treating MCP servers as trusted entities by virtue of being reachable over the network. In the MCP ecosystem, the client-side assumption has often been that server operators are trustworthy because users chose to connect to them. CVE-2025-6514 demonstrates that this assumption fails catastrophically when users connect to servers from registries, community lists, or third-party recommendations without independent verification. The fix — upgrading to mcp-remote version 0.1.16 — addressed the specific injection vector, but the architectural lesson is that MCP clients must validate and sanitize all data received from servers before acting on it, regardless of the apparent trust level of the connection [3].
2.2 Tool Poisoning Through Hidden Instructions
Tool poisoning is a class of attack in which a malicious or compromised MCP server embeds adversarial instructions within its tool descriptions — the natural-language text that the LLM reads to understand what a tool does and how to use it. Because LLMs do not distinguish between genuine documentation and embedded directives, a model that encounters a poisoned tool description may follow the hidden instructions while appearing to the user to execute normal tool behavior. Invariant Labs published a foundational disclosure of this attack class in early 2025, demonstrating that a malicious server could instruct the LLM to read a sensitive file and silently pass its contents as a parameter to the tool call, which the server would then exfiltrate to an attacker-controlled endpoint before returning a normal-looking result [8].
The attack is particularly insidious because of its interaction with multi-server MCP configurations. In environments where a user has configured multiple MCP servers — one trusted, several third-party — a malicious server’s tool description can contain instructions that override or hijack behavior across other servers. Invariant Labs demonstrated a scenario involving the WhatsApp MCP server: a poisoned tool description on a secondary server instructed the LLM to exfiltrate the user’s entire WhatsApp message history through a seemingly benign tool invocation, with no visible indication of the data exfiltration in the tool’s output [4]. The attack effectively turns the LLM’s instruction-following capability against the user by exploiting the gap between what the model is told to do and what the user can observe.
Tool poisoning is structurally analogous to indirect prompt injection, which the OWASP Top 10 for Agentic Applications (2026) classifies under ASI01 (Agent Goal Hijack) [9]. The attack succeeds because tool descriptions exist in a part of the AI’s context that the user typically cannot inspect. Defenses must therefore operate at the tool description layer itself: organizations need mechanisms to validate tool descriptions against known-good baselines, detect anomalous content patterns, and alert when descriptions change between sessions. Invariant Labs released the open-source mcp-scan tool specifically to detect poisoned descriptions in MCP configurations, and enterprise deployments should integrate similar scanning into their MCP server registration workflows [8].
2.3 Rug Pull Attacks
Rug pull attacks — sometimes termed bait-and-switch attacks in the MCP literature — exploit the fact that MCP tool registrations are typically approved once and not continuously re-verified. In a rug pull scenario, an attacker first deploys a legitimate-appearing MCP server, induces users or automated systems to approve and register it, and then subsequently modifies the server’s tool definitions, descriptions, or underlying behavior to perform malicious actions [10]. Because the approval occurred for the original server configuration, the modified version continues to operate with inherited trust. The attack is particularly effective in enterprise environments where tool approvals are managed through change control processes that do not include re-validation triggers for post-deployment changes.
The Enhanced Tool Definition Interface (ETDI) framework, proposed in research published in 2025, provides a cryptographic approach to mitigating rug pull attacks by binding tool definitions to signed JSON Web Tokens (JWTs) and using OAuth 2.0 scopes to represent tool permissions [10]. Under ETDI, any change to a tool’s definition invalidates the existing signature, and MCP clients would detect the mismatch before allowing the modified tool to execute. This approach treats tool definitions as versioned, immutable artifacts rather than mutable server properties, and it shifts the trust model from “trust the server” to “verify the tool definition cryptographically.” Several enterprise MCP gateways have begun implementing variants of this approach, though it is not yet part of the base MCP specification.
From an operational security perspective, organizations can implement rug pull mitigations through a combination of policy and tooling. Version-pinning of MCP server configurations — similar to dependency pinning in software supply chain security — ensures that the exact server version approved during security review is the one in production use. Monitoring systems should alert when tool descriptions change between sessions, even for servers that have not been formally updated. User interfaces for MCP clients should surface tool description changes prominently rather than silently accepting them, giving users and security teams an opportunity to review modifications before they influence model behavior [10].
2.4 Session Hijacking
Session hijacking in the MCP context refers to an attacker’s ability to steal, predict, or intercept session tokens to assume control of an authenticated MCP session, allowing the attacker to issue tool invocations as a legitimate user or agent. The attack surface for session hijacking is broader in MCP deployments than in traditional web applications because MCP sessions are often long-lived, may be shared across multiple tool invocations in a single agentic pipeline run, and may carry access tokens for downstream systems with significant privileges [5].
The CVE-2025-6514 mcp-remote vulnerability illustrates one mechanism by which session tokens can be stolen: a malicious authorization_endpoint can be used to intercept OAuth tokens during the authentication flow, before the session is even established [3]. More broadly, MCP sessions transmitted over plaintext HTTP are vulnerable to interception through network-level man-in-the-middle attacks, and many early MCP server deployments were found to lack transport layer security entirely. The 2026 guidance from the Practical DevSecOps MCP security analysis found that a significant proportion of assessed MCP servers used plaintext HTTP endpoints, exposing OAuth tokens, API keys, and session metadata to interception [2]. A further attack vector identified in 2026 involves tunnel subdomain hijacking: when MCP servers are hosted through tunnel services such as ngrok, allowing subdomain reassignment after a tunnel session terminates can permit an attacker to register the same subdomain and intercept requests from clients that cached the old URL [5].
Session management hardening for MCP deployments requires TLS as a non-negotiable baseline for all remote connections, combined with short session token lifetimes, binding tokens to source IP or agent identity attributes, and implementing refresh token rotation to limit the value of any single captured token. The November 2025 MCP specification’s requirement for OAuth 2.1 with PKCE (Proof Key for Code Exchange) for all public clients addresses a significant subset of the authentication bypass risks [1], but organizations must also implement post-authentication session controls to limit the damage if a token is stolen after issuance.
2.5 Supply Chain Attacks
The MCP ecosystem inherits and amplifies the supply chain risks already well-documented for the broader JavaScript and Python package ecosystems. MCP servers are typically distributed as npm packages or PyPI packages, and they carry the same transitive dependency risks as any other open-source software. The September 2025 npm supply chain attack demonstrated the scope of this risk: attackers compromised the maintainer credentials for 18 widely-used packages including debug, chalk, and ansi-styles — all of which are indirect dependencies of the official MCP TypeScript SDK — and published malicious versions that could execute arbitrary code in any MCP server built from the SDK [11]. The attack reached an estimated 2.6 billion weekly download counts across the affected packages.
The first confirmed malicious MCP server discovered in the wild, the postmark-mcp package, illustrated a quieter form of supply chain attack: rather than dramatic payload execution, it silently added a BCC recipient to every email sent by AI agents using the server, redirecting copies of internal communications to an attacker-controlled address [4]. The attack was designed to evade detection by maintaining the appearance of normal operation. By February 2026, the Sandworm_Mode campaign had weaponized npm typosquatting to target AI coding assistants including Claude Code, Cursor, and Windsurf, installing rogue MCP servers through malicious packages that mimicked popular utilities, and using the installed servers to exfiltrate SSH keys, AWS credentials, npm tokens, and other secrets via prompt injection [11].
Supply chain security for MCP deployments requires treating MCP server packages with the same scrutiny applied to any third-party software dependency. Organizations should mandate the use of package registries that enforce provenance and signing, implement Software Bill of Materials (SBOM) generation for all MCP server deployments, and use dependency scanning tools that detect known malicious packages in addition to packages with known vulnerabilities. Private registries with curated, pre-approved MCP servers — rather than allowing direct installation from public registries — provide a significant reduction in supply chain attack surface for enterprise environments.
2.6 Cross-Tenant Information Leakage
In multi-tenant deployments of MCP servers — where a single server instance handles tool invocations from multiple organizations or users — inadequate tenant isolation can allow data belonging to one tenant to be accessed by another. This risk materializes through several mechanisms: insufficient access control on underlying data stores accessed by MCP tools; context sharing across invocations that inadvertently includes prior tenant’s data; vector database queries that lack enforced tenant-ID filters; and tool outputs that aggregate or cache results in ways that cross tenant boundaries. The Asana MCP security incident of June 2025 is the most publicly documented example, where a bug in Asana’s MCP server feature allowed project and task data belonging to one organization to become visible to other organizations [4].
The regulatory implications of cross-tenant information leakage are significant. In environments subject to data residency requirements, GDPR, HIPAA, or sector-specific privacy regulations, a cross-tenant data disclosure through an MCP server could trigger breach notification obligations, regulatory investigation, and material financial penalties. Unlike a traditional API data breach, MCP-mediated cross-tenant leakage may be difficult to detect after the fact: the LLM may incorporate leaked context into its responses without any explicit data transfer that would appear in conventional access logs.
Defense against cross-tenant leakage requires enforcing tenant identity at every layer of the data access stack. The MCP server must authenticate the requesting agent’s tenant identity and propagate that identity as a mandatory filter parameter to all downstream data access operations. Memory systems and vector stores should enforce namespace segmentation at the storage layer, not merely at the query layer, so that administrative errors or authorization bypasses cannot expose cross-tenant data. Enterprise deployments should run regular cross-tenant isolation tests — provisioning distinct test tenants, seeding them with canary data, and verifying through automated testing that agents in one tenant cannot retrieve the canary data of another [12].
3. Security Requirements by Category
The threat landscape described in the previous section maps to a set of concrete security control requirements across seven domains. Organizations deploying MCP should assess their current posture against each domain and use the maturity model in Section 4 to prioritize control implementation.
3.1 Authentication and Authorization
Authentication and authorization controls form the foundation of MCP security posture. All remote MCP server connections must use OAuth 2.1 as specified in the November 2025 MCP specification, with PKCE mandatory for all public clients [1]. OAuth 2.0 Authorization Server Metadata (RFC 8414) must be implemented for server discovery, and clients must validate the server metadata before initiating authentication flows rather than accepting server-provided endpoints without verification — the root failure that enabled CVE-2025-6514 [3]. Scopes should be defined at the tool level, not merely at the server level, following the principle of least privilege: a tool that reads files should not carry a scope that permits file deletion.
Authorization controls must extend beyond initial authentication to per-invocation verification. Each tool invocation should be evaluated against the requesting agent’s current permission set, which may vary based on context, user identity, and session state. Organizations should implement just-in-time (JIT) permission escalation for high-privilege tool operations, requiring explicit re-authorization rather than relying on session-level permissions granted at connection time. Service-to-service MCP connections — where one agent calls tools exposed by another — require mutual authentication using client certificates or signed JWTs to prevent unauthorized agent impersonation.
3.2 Tool Description Integrity
Tool description integrity controls address the tool poisoning and rug pull attack vectors. At a minimum, organizations should implement cryptographic signing of tool descriptions, where the signing key is associated with the verified identity of the MCP server operator. Clients should reject tool descriptions that fail signature verification or that arrive unsigned when the server configuration specifies that signing is required. Tool descriptions should be hashed at registration time and compared against the stored hash at each subsequent session, with client-side alerts or session termination triggered when mismatches are detected.
Content-based screening of tool descriptions should be deployed to detect embedded adversarial instructions. This screening can be implemented as a preprocessing step in the MCP client before tool descriptions are passed to the LLM, using pattern matching for known injection patterns, semantic analysis for suspicious instruction structures, or integration with dedicated prompt injection detection services. Organizations that allow users to configure their own MCP servers should provide scanning tools — similar to the Invariant Labs mcp-scan utility — as part of the standard developer tooling stack [8].
3.3 Session Management
Session management controls encompass the full lifecycle of an MCP connection, from initial authentication through token renewal and session termination. All session tokens must be transmitted exclusively over TLS 1.2 or higher, with TLS 1.3 preferred for new deployments. Session tokens should be bound to cryptographic proof of the requesting agent’s identity, such that a token stolen from one agent cannot be reused by another. Token lifetimes should be short — ideally no more than one hour for access tokens — with refresh token rotation implemented to ensure that each token refresh invalidates the prior refresh token.
MCP session state should be treated as security-sensitive data equivalent to authentication credentials. Agents should not cache session tokens in plaintext on disk, in environment variables, or in locations accessible to other processes. In containerized or serverless environments, session tokens should be retrieved from dedicated secret management services at runtime rather than injected as environment variables that persist in process memory. Session termination must invalidate all associated tokens and clean up any session state stored on the server side, preventing token reuse attacks against terminated sessions.
3.4 Message Signing and Verification
Message-level signing extends the integrity guarantees of authentication beyond the session establishment phase to cover individual tool invocations. In high-assurance MCP deployments, each tool invocation request should be signed by the requesting agent using a private key whose corresponding public key has been registered with the MCP server. The server validates the signature before processing the invocation, ensuring that the request originated from the authorized agent and has not been modified in transit. This control mitigates man-in-the-middle attacks that occur after TLS termination — for example, in environments where a reverse proxy or MCP gateway decrypts and re-encrypts traffic.
Tool invocation responses should similarly be signed by the MCP server, allowing the client to verify that the response originated from the legitimate server and has not been modified by a network-level attacker or a compromised intermediary. Response signing is particularly important for tool outputs that influence subsequent model behavior, such as search results, file contents, or API responses that the LLM will incorporate into its reasoning. The ETDI framework’s use of signed JWTs to bind tool definitions and permissions to verifiable server identities provides a model for how message-level signing can be integrated into the MCP protocol flow [10].
3.5 Supply Chain Security
Supply chain security controls govern the process by which MCP servers are selected, evaluated, deployed, and maintained. Organizations should maintain a curated registry of approved MCP servers that have undergone security review, with the registry enforcing version pinning to prevent silent upgrades to unreviewed versions. Software Bill of Materials generation should be mandatory for all MCP server deployments, capturing both direct and transitive dependencies and enabling rapid impact assessment when supply chain vulnerabilities are disclosed.
Continuous dependency monitoring should integrate with the SBOM to alert security teams when a new CVE affects a component used by a deployed MCP server. Organizations should establish a maximum permissible remediation window for critical supply chain vulnerabilities — ideally no more than 72 hours for CVSS 9.0+ findings — with automated tooling to block connections to servers whose dependency vulnerabilities exceed the remediation window. MCP servers sourced from external vendors or open-source registries should be isolated from production environments through a staging validation process that includes dynamic security testing before promotion to production.
3.6 Sandboxing and Tool Execution Isolation
Tool execution isolation controls limit the blast radius of a compromised or malicious MCP server by constraining the resources and system capabilities available to server-side code. MCP servers should execute in isolated runtime environments — containers, micro-VMs, or restricted language runtimes with system-call filtering — with the following controls enforced at the container or hypervisor layer rather than relying on server-side self-enforcement. Filesystem access should be blocked by default, with read-only access granted only to specific paths required by the server’s documented tool functionality. Outbound network access should be blocked by default and permitted only to explicitly whitelisted external endpoints, preventing data exfiltration to arbitrary attacker-controlled infrastructure. CPU and memory quotas should be enforced per-execution to prevent resource exhaustion attacks, and hard execution timeouts should terminate tool invocations that exceed documented runtime expectations.
The Docker MCP Gateway and similar enterprise MCP proxy products provide infrastructure for implementing these isolation controls without requiring custom containerization of each individual MCP server [5]. An MCP gateway acts as a smart proxy that intercepts all tool invocations, applies security policies, routes requests to isolated server instances, and returns sanitized responses to the requesting agent. Gateway-based architecture also provides a centralized enforcement point for audit logging, rate limiting, and anomaly detection, making it substantially easier to achieve consistent security posture across a diverse MCP server portfolio.
3.7 Monitoring and Anomaly Detection
Behavioral monitoring of MCP tool invocations provides the detection capability needed to identify attacks that bypass preventive controls. At a minimum, all MCP tool invocations should be logged with sufficient detail to reconstruct the full context of each call: the requesting agent identity, the tool name, the input parameters (with sensitive values redacted), the timestamp, the response status, and the duration. Logs should be forwarded to a centralized SIEM for correlation and retention in accordance with the organization’s incident response and forensic investigation requirements.
Anomaly detection should be applied to the invocation log stream to identify patterns indicative of attack: unusual volumes of tool calls from a single agent, tool invocations at unusual hours or from unexpected source IP addresses, sequences of tool calls that match known attack patterns (such as file enumeration followed by outbound data transfer), and tool call parameters that contain patterns associated with prompt injection or command injection. In agentic pipelines where the sequence of tool calls is relatively predictable, behavioral baselines can be established and used to flag deviations that warrant human review. The CSA AI Controls Matrix AICM-MON control domain provides a framework for defining monitoring objectives and metrics for AI agent deployments [13].
4. MCP Security Maturity Model
The MCP Security Maturity Model organizes the security controls described in Section 3 into four progressively rigorous levels. Organizations can use this model to assess their current posture, communicate gaps to stakeholders, and plan investment in security controls. Each level is defined by a set of specific, verifiable controls whose implementation can be assessed through audit, penetration testing, or automated configuration scanning. The model is designed to be cumulative: each level assumes that all controls from prior levels are in place.
Level 1: Basic Authentication and Transport Security
Level 1 represents the minimum viable security posture for any MCP deployment that connects to external systems or handles sensitive data. Organizations at Level 1 have addressed the most critical baseline risks: unauthenticated server access and unencrypted communications. The following controls are required to achieve Level 1 status.
All MCP server connections must be authenticated. Servers that permit unauthenticated connections — whether by design or misconfiguration — are below Level 1. For remote MCP servers, OAuth 2.1 must be implemented per the November 2025 MCP specification, with PKCE enforced for public clients [1]. For local MCP servers, the server process must validate the identity of the connecting client and reject connections from unauthorized processes. All remote MCP connections must use TLS 1.2 or higher with valid certificates issued by a recognized certificate authority; self-signed certificates are not acceptable in production environments at any maturity level. Organizations must maintain an inventory of all MCP servers in use, covering server name, version, deployment location, and business owner. Without a complete inventory, it is not possible to assess exposure to newly disclosed vulnerabilities.
Authorization at Level 1 requires that each MCP server operate under a service account with the minimum permissions needed for its documented tool set. Broad-scope credentials such as personal access tokens with administrative permissions should not be used for MCP server authentication to downstream systems. Basic audit logging of all tool invocations must be enabled, with logs retained for a minimum of 90 days. A documented process for MCP server security updates must exist and demonstrate at least quarterly reviews of known vulnerabilities in deployed server versions.
Level 2: Tool Integrity Verification and Session Hardening
Level 2 addresses the tool poisoning, rug pull, and session hijacking threat categories with controls that go beyond baseline authentication. Organizations at Level 2 have implemented mechanisms to verify that the tools they are using are behaving as intended and that session credentials cannot be trivially stolen or reused.
Tool description verification is the defining control of Level 2. Organizations must implement a process for recording the tool descriptions, schemas, and permission sets of each registered MCP server at deployment time, and for detecting changes between sessions. This can be implemented through client-side hashing and comparison, integration with a tool registry that stores approved tool definitions, or deployment of an open-source scanning tool such as mcp-scan [8]. Any detected change to a tool description must trigger an alert and require explicit re-approval before the modified tool is used in production.
Session hardening at Level 2 requires access token lifetimes of no more than one hour, refresh token rotation on each use, and prohibition of session token storage in plaintext files or environment variables. Session tokens must be transmitted exclusively over TLS-protected channels, and session state must be invalidated on explicit logout rather than expiring passively. Organizations must implement automated remediation workflows for CVEs in deployed MCP server dependencies, with a maximum 30-day remediation window for High and Critical severity findings. User-facing MCP configuration interfaces must display tool descriptions and alert users when descriptions change, rather than silently accepting updates.
Level 3: Full Message Signing, Supply Chain Controls, and Behavioral Monitoring
Level 3 represents a mature security posture suitable for enterprise MCP deployments handling sensitive data or operating in regulated environments. Organizations at Level 3 have implemented cryptographic controls on message integrity, formal supply chain governance, and continuous behavioral monitoring with documented response procedures.
Message-level signing is the foundational control of Level 3. All tool invocation requests must be signed by the requesting agent using an asymmetric key pair registered with the MCP server. Tool invocation responses must be signed by the MCP server. Signature verification must occur before any downstream processing of the request or response, and verification failures must result in immediate invocation rejection with security alerting. Key rotation must occur at least annually, with a documented process for emergency key revocation in the event of compromise.
Supply chain controls at Level 3 require an approved MCP server registry with formal intake review, SBOM generation for all deployments, continuous dependency vulnerability monitoring integrated with the SBOM, and automated blocking of MCP server connections when critical supply chain vulnerabilities exceed the 72-hour remediation window. Private MCP server registries must be used for production environments rather than direct installation from public registries.
Behavioral monitoring at Level 3 must include real-time anomaly detection on tool invocation logs, with defined thresholds and automated alerting for suspicious patterns including abnormal invocation rates, unusual data access sequences, and parameter patterns indicative of injection attacks. The monitoring system must integrate with the organization’s security operations center, and documented incident response playbooks must exist for each defined MCP threat category. Red team exercises targeting MCP deployments must be conducted at least annually, with findings tracked to remediation.
Level 4: Zero-Trust Architecture with Continuous Verification
Level 4 represents the highest level of MCP security maturity, appropriate for critical infrastructure deployments, high-value financial systems, and environments subject to the most stringent regulatory requirements. The defining characteristic of Level 4 is the elimination of persistent trust: every tool invocation is verified independently, regardless of the authentication status established at session initiation.
Zero-trust at Level 4 means that each tool invocation carries its own signed authorization token that is validated against current access control policy at invocation time, not merely at session establishment. This per-invocation authorization uses short-lived, scoped tokens — valid for a single use or a small number of uses within a defined time window — that are generated by a centralized authorization service based on real-time evaluation of the requesting agent’s identity, current task context, and the specific tool and parameters requested. Access control policy must be managed as code, with all changes subject to peer review, and the authorization service must support real-time policy updates without requiring session termination.
Continuous verification at Level 4 extends to tool description integrity, where cryptographic attestation of tool definitions is performed at each session establishment and additionally at configurable intervals during long-running agentic tasks. Supply chain attestation must include cryptographic signatures over the entire dependency tree of each deployed MCP server, with signatures generated as part of the build process and verified at deployment and at runtime. Execution isolation must use hardware-enforced boundaries — micro-VMs or hardware enclaves — rather than software containers alone. All security-relevant decisions must be logged in an immutable, append-only audit log that is isolated from the systems being monitored, preventing a compromised MCP server from modifying its own access records.
5. Implementation Guidance
Moving from assessment to implementation requires translating the maturity model’s control objectives into concrete technical changes within an organization’s existing infrastructure. This section provides practical, sequenced guidance for achieving each maturity level, beginning with the foundational controls that provide the greatest risk reduction per unit of implementation effort.
For organizations currently below Level 1, the immediate priority is achieving visibility and basic protection across the MCP deployment estate. The first step is inventory: organizations should identify all MCP servers in use, including both IT-managed deployments and developer-configured tools on individual workstations. Claude Desktop, Cursor IDE, VS Code Copilot, and similar AI development environments all support MCP, and individual developers may have configured dozens of MCP servers without central IT awareness. A combination of endpoint management tooling, network traffic analysis for MCP protocol signatures, and developer surveys can identify the full scope of the deployment. Once the inventory is complete, the organization can assess the authentication posture of each server and prioritize disabling or upgrading servers that permit unauthenticated connections.
For organizations progressing from Level 1 to Level 2, the critical investment is in tooling for tool description monitoring. A practical starting point is deploying the Invariant Labs mcp-scan tool as a pre-commit hook and CI/CD pipeline step, ensuring that tool description changes in any managed MCP server configuration are detected before deployment [8]. For enterprise environments with many MCP servers, a centralized tool registry that stores approved tool definitions — versioned and hashed — and provides a comparison API for clients to verify their current tool descriptions against the approved baseline is the scalable approach. Organizations should also implement the session hardening controls in this level as configuration changes to existing identity infrastructure, which typically requires coordination with the OAuth or identity provider team rather than custom development.
For organizations targeting Level 3, the most significant implementation effort is typically the behavioral monitoring and supply chain governance programs. On the monitoring side, the key challenge is extracting meaningful security signal from the high volume of tool invocation data generated by active agentic pipelines. Organizations should begin with a narrow set of high-confidence detection rules — known attack pattern signatures, rate limit violations, and access to known sensitive resources outside normal business hours — rather than attempting comprehensive behavioral baselining from the outset. The baseline can be refined iteratively as the monitoring program matures and security teams develop familiarity with normal invocation patterns for their specific agent workloads.
Supply chain governance at Level 3 requires establishing a governance process for MCP server approval that involves both security review and business stakeholder sign-off. Security review should include static analysis of the server package and its dependencies for known vulnerabilities, manual review of the tool definitions and permission requirements, and assessment of the server operator’s security practices and disclosure history. The governance process should be lightweight enough to not impede legitimate business use while providing meaningful risk reduction: a typical target is a one-week review cycle for standard MCP servers, with an expedited process for critical business needs. Organizations should use the CSA AICM supply chain control domain as a reference framework for defining review criteria [13].
For organizations pursuing Level 4, the most technically demanding requirement is the per-invocation authorization service. This service must be highly available — any availability gap would block all tool invocations — and must evaluate authorization decisions with latency low enough to not materially impact the responsiveness of agentic pipelines. Purpose-built policy-as-code engines such as Open Policy Agent (OPA) or Cedar Policy can serve as the evaluation layer, with policies stored in version-controlled repositories and pushed to the evaluation engine via a GitOps-style deployment pipeline. The authorization service should be architected as a separate, hardened service with its own access controls, audit logging, and key management infrastructure, isolated from the systems it governs.
6. Cross-Reference Framework Alignment
The following table maps each MCP threat category to the corresponding control and technique identifiers in the OWASP Top 10 for Agentic Applications (2026) [9], the CSA AI Controls Matrix (AICM) [13], and the MITRE ATLAS framework for adversarial AI threats [14]. This mapping enables organizations to integrate MCP security requirements into existing governance frameworks and to leverage existing control implementations where applicable.
| MCP Threat | OWASP ASI Category | AICM Control Domain | MITRE ATLAS Technique |
|---|---|---|---|
| Tool Poisoning (Hidden Instructions) | ASI01 — Agent Goal Hijack | AICM-AI-07: Prompt and Context Integrity | AML.T0051 — LLM Prompt Injection; AML.T0054 — Indirect Prompt Injection |
| Rug Pull / Bait-and-Switch | ASI02 — Tool Misuse | AICM-AI-07: Prompt and Context Integrity; AICM-SC-01: Supply Chain Integrity | AML.T0010 — ML Supply Chain Compromise |
| Pre-Auth RCE (CVE-2025-6514) | ASI05 — Unexpected Code Execution | AICM-VM-01: Vulnerability Management; AICM-SC-01: Supply Chain Integrity | AML.T0010 — ML Supply Chain Compromise; AML.T0011 — User Execution |
| Session Hijacking | ASI03 — Identity and Privilege Abuse | AICM-IAM-03: Session Management; AICM-IAM-01: Authentication | AML.T0012 — Valid Accounts; AML.T0015 — Credential Access |
| Supply Chain Attacks | ASI04 — Agentic Supply Chain Vulnerabilities | AICM-SC-01: Supply Chain Integrity; AICM-SC-02: Dependency Management | AML.T0010 — ML Supply Chain Compromise; AML.T0019 — Backdoor ML Model |
| Cross-Tenant Information Leakage | ASI06 — Memory and Context Poisoning | AICM-DG-02: Data Governance and Classification; AICM-IAM-04: Authorization | AML.T0025 — Exfiltration via ML Inference API |
| Insecure Tool Execution | ASI05 — Unexpected Code Execution; ASI02 — Tool Misuse | AICM-INF-02: Execution Isolation; AICM-MON-01: Behavioral Monitoring | AML.T0017 — Develop Capabilities; AML.T0043 — Craft Adversarial Data |
The OWASP Top 10 for Agentic Applications was finalized in December 2025 through collaboration with over 100 industry experts and practitioners [9]. The framework explicitly addresses MCP as a tool integration surface and includes a dedicated Practical Guide for Securely Using Third-Party MCP Servers. Organizations using the OWASP framework as their primary governance reference should ensure that their MCP security controls address all ten risk categories, not only those directly associated with tool invocation: in particular, ASI03 (Identity and Privilege Abuse) has significant implications for how MCP service accounts are provisioned and managed.
The CSA AI Controls Matrix (AICM) was released in July 2025 as a vendor-agnostic framework containing 243 control objectives across 18 security domains [13]. It maps to ISO 42001, ISO 27001, NIST AI RMF 1.0, and BSI AIC4, enabling organizations to use the AICM as a bridge between their existing compliance programs and AI-specific security requirements. The CSAI Foundation’s March 2026 announcement of a strategic mission around “Securing the Agentic Control Plane” signals that the AICM will receive continued updates to address emerging MCP and agentic security risks as the ecosystem matures [15].
MITRE ATLAS provides a knowledge base of adversarial tactics and techniques specific to AI and machine learning systems. The framework added 14 new agent-focused techniques in October 2025, in collaboration with Zenity Labs, including techniques for AI Agent Context Poisoning, Memory Manipulation, and Thread Injection [14]. Organizations that already use MITRE ATT&CK for enterprise security threat modeling can use the ATLAS framework’s shared taxonomy to extend their threat coverage to AI and agentic systems without building a parallel threat modeling process.
7. Key Takeaways
The MCP ecosystem has reached an inflection point. The protocol’s rapid adoption has produced a deployment landscape that includes both sophisticated enterprise implementations with strong security controls and thousands of internet-exposed servers operating with no authentication whatsoever [5]. The 30+ CVEs filed in the first two months of 2026 are not an anomaly; they are the predictable consequence of deploying a complex, permission-rich protocol at scale before security governance frameworks had matured [2]. Organizations that have not yet treated MCP as critical infrastructure must do so now — the attack surface is active, attackers are aware of it, and the consequences of compromise extend far beyond the MCP layer itself into the downstream systems that agents access.
The threat landscape analyzed in this document reveals a pattern that security practitioners will recognize from other rapidly-adopted technologies: the most consequential attacks are not exotic zero-days but fundamental security failures. CVE-2025-6514 was caused by the failure to sanitize a URL value [3]. The GitHub MCP prompt injection succeeded because of an overly broad personal access token [4]. The cross-tenant Asana exposure was a classic access control misconfiguration [4]. Tool poisoning succeeds because tool descriptions are implicitly trusted [8]. In each case, standard security engineering practices — input validation, least privilege, explicit trust verification, content screening — would have prevented or substantially mitigated the attack.
The MCP Security Maturity Model presented in this document provides organizations with a practical roadmap that is sequenced by risk reduction impact. Level 1 eliminates the most critical baseline risks: unauthenticated servers and unencrypted communications, which together represent the vulnerability class responsible for the majority of real-world MCP incidents to date. Level 2 addresses the tool integrity and session management risks that enable the tool poisoning and rug pull attack categories. Level 3 provides the supply chain governance and behavioral monitoring capabilities needed for production enterprise deployments. Level 4 achieves zero-trust across the full tool invocation lifecycle, appropriate for high-value or high-sensitivity deployments.
Alignment with established frameworks — OWASP ASI, AICM, MITRE ATLAS — ensures that MCP security investments are consistent with and complementary to broader AI security governance programs. Organizations should resist the temptation to treat MCP security as a standalone problem and instead integrate it into their existing application security, identity governance, supply chain security, and incident response programs. The technical controls described in this document are necessary but not sufficient: they must be embedded in organizational processes, governance structures, and security cultures that treat agentic systems as first-class security considerations.
References
[1] Anthropic. “Model Context Protocol Specification 2025-11-25: Authorization.” November 25, 2025. https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
[2] Practical DevSecOps. “MCP Security Vulnerabilities: How to Prevent Prompt Injection and Tool Poisoning Attacks in 2026.” March 2026. https://www.practical-devsecops.com/mcp-security-vulnerabilities/
[3] JFrog Security Research. “Critical RCE Vulnerability in mcp-remote: CVE-2025-6514 Threatens LLM Clients.” JFrog Blog, 2025. https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/
[4] Authzed. “A Timeline of Model Context Protocol (MCP) Security Breaches.” Authzed Blog, 2025–2026. https://authzed.com/blog/timeline-mcp-breaches
[5] Gopher Security. “Zero Trust Architecture for Decentralized MCP Tool Discovery.” March 2026. https://www.gopher.security/blog/zero-trust-architecture-decentralized-mcp-tool-discovery
[6] Anthropic. “Introducing Model Context Protocol.” Anthropic Blog, November 2024. https://www.anthropic.com/news/model-context-protocol
[7] Astrix Security. “State of MCP Server Security 2025: Research Report.” Astrix Security Blog, 2025. https://astrix.security/learn/blog/state-of-mcp-server-security-2025/
[8] Invariant Labs. “MCP Security Notification: Tool Poisoning Attacks.” Invariant Labs Blog, 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
[9] OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications 2026.” December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
[10] Anthropic Research. “ETDI: Mitigating Tool Squatting and Rug Pull Attacks in Model Context Protocol (MCP) by using OAuth-Enhanced Tool Definitions and Policy-Based Access Control.” arXiv:2506.01333, June 2025. https://arxiv.org/abs/2506.01333
[11] Semgrep. “So the first malicious MCP server has been found on npm, what does this mean for MCP security?” Semgrep Blog, 2025. https://semgrep.dev/blog/2025/so-the-first-malicious-mcp-server-has-been-found-on-npm-what-does-this-mean-for-mcp-security/
[12] Prefactor. “MCP Security for Multi-Tenant AI Agents: Explained.” Prefactor Tech Blog, 2026. https://prefactor.tech/blog/mcp-security-multi-tenant-ai-agents-explained
[13] Cloud Security Alliance. “AI Controls Matrix (AICM): A Framework for Trustworthy AI.” CSA, July 2025. https://cloudsecurityalliance.org/artifacts/ai-controls-matrix
[14] MITRE. “MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems.” Updated October 2025. https://atlas.mitre.org/
[15] Cloud Security Alliance. “Cloud Security Alliance Launches CSAI Foundation With Mission of Securing the Agentic Control Plane.” CSA Press Release, March 23, 2026. https://cloudsecurityalliance.org/press-releases/2026/03/23/csa-securing-the-agentic-control-plane