MCP Security: Threats, Vulnerabilities, and How to Secure MCP Servers

Direct answer: Is MCP secure?

For the roles behind these boundaries, start with what an MCP server is, how MCP works, and the matrix of security responsibilities by MCP role.

MCP can be deployed securely, but protocol compliance alone does not make an MCP system secure. The Model Context Protocol defines how a host and client communicate with a server, how capabilities are represented, how supported HTTP deployments perform authorization, and how current requests identify their protocol version and client capabilities. It does not certify the server’s code, make a downloaded package trustworthy, constrain the operating-system permissions of a local process, validate every tool argument, guarantee correct OAuth implementation, prevent prompt injection, or ensure that the underlying API enforces least privilege.

An MCP deployment is therefore only as secure as the complete chain:

User and organization policy
        ↓
Host application and permission interface
        ↓
MCP client and SDK
        ↓
Transport, network and authorization
        ↓
MCP server implementation
        ↓
API, database, filesystem, CLI or SaaS service
        ↓
External data interpreted by the model

The current protocol is also materially different from the version described in many security articles. MCP revisions through 2025-11-25 used an initialization handshake and protocol-level sessions. The 2026-07-28 revision removed initialize, notifications/initialized, and Mcp-Session-Id; every request now carries its protocol version and client capabilities, and servers expose server/discover. It added header-based routing and cacheable results, hardened authorization, replaced server-initiated requests with Multi Round-Trip Requests, and moved Tasks into an extension. (MCP 2026-07-28 key changes [S055])

That revision did not eliminate state or security risk. Applications can retain state in databases, long-running Tasks, upstream services, caches, and explicit server-minted handles. Those identifiers must be unguessable, bound to the correct user and tenant, limited in scope, expired, revoked, and reauthorized whenever they are used.

The safest conclusion is neither “MCP is secure” nor “MCP is insecure.” MCP creates a reusable capability boundary. That boundary can become a valuable enforcement point for identity, approvals, allowlists, audit, data-loss prevention, and network policy. It can also become a route through which malicious packages, poisoned tool descriptions, overprivileged credentials, unsafe server code, and untrusted data reach powerful systems. Security depends on whether every layer treats the others as untrusted by default and verifies authority before effects occur.

---

Executive summary

MCP security is frequently discussed as though it were one technical problem. It is at least nine:

1. Protocol security: correct implementation of message, version, transport, caching, routing, capability, and authorization semantics.
2. SDK security: safe parsing, bounded input, isolated per-client state, secure transport defaults, and timely patching.
3. Host and client security: server approval, project-configuration trust, process launch, tool filtering, meaningful confirmation, and model exposure.
4. Server security: authentication, authorization, input validation, tenant separation, safe tool behavior, and result handling.
5. Supply-chain security: package identity, provenance, dependencies, binaries, images, registries, updates, and maintainer compromise.
6. Deployment security: TLS, DNS, local-network exposure, egress, secret stores, resource limits, routing, caching, and observability.
7. Authorization security: OAuth discovery, PKCE, issuer validation, client identity, scopes, token audience, consent, account linking, and revocation.
8. Model and data security: tool poisoning, indirect prompt injection, malicious resources, poisoned outputs, and cross-server semantic influence.
9. Underlying-system security: native repository, database, filesystem, cloud, and SaaS permissions that remain the final enforcement boundary.

This layered model explains why the phrase “an MCP vulnerability” can mislead. A remote-code-execution defect in MCP Inspector, a DNS-rebinding default in an SDK, a malicious npm package impersonating a server, an OAuth callback error in a framework, a cross-tenant response leak, and command injection in one community server all concern the MCP ecosystem. They do not affect the same component or require the same remedy.

The security history follows MCP’s architectural history. The launch-era 2024-11-05 protocol was oriented toward deliberately configured local processes and contained no later OAuth framework. The 2025-03-26 revision introduced Streamable HTTP and an authorization framework as remote MCP became more important. The 2025-06-18 revision classified protected servers as OAuth resource servers, added protected-resource metadata, and required Resource Indicators to bind tokens to their target. The 2025-11-25 revision expanded OpenID Connect discovery, Client ID Metadata Documents, and incremental consent. The current 2026-07-28 revision removed protocol sessions, preferred Client ID Metadata Documents over Dynamic Client Registration, strengthened issuer and credential binding, and reworked interaction for ordinary HTTP infrastructure. (Authorization, 2026-07-28 [S133])

Local and remote servers now have clearly different threat models. A local stdio server normally has no listening network port, but it is code running with some portion of the user’s authority. Its dominant risks are package compromise, malicious project configuration, broad environment inheritance, filesystem access, command execution, and automatic updates. A remote server moves execution away from the workstation but adds network exposure, OAuth, token handling, multi-tenancy, availability, routing, caches, and delegated access to user-linked services.

Semantic attacks cut across both models. In April 2025, Invariant Labs demonstrated tool poisoning: attacker instructions embedded in tool descriptions seen by the model but poorly exposed to the user. The same work demonstrated tool shadowing, in which one malicious server changes how the agent uses another server, and rug pulls, in which tool definitions change after approval. (Invariant Labs tool-poisoning disclosure [S108]) These attacks are not ordinary parser vulnerabilities. They exploit the host’s decision to place untrusted natural-language metadata in the model’s decision context and then grant the model access to consequential capabilities.

Research published in 2026 indicates that insecure deployment is not merely theoretical, although the numbers require care. One preprint identified 7,973 live remote MCP servers and reported that 40.55% exposed tools without authentication. Its dynamic OAuth analysis covered only 119 testable servers; all had at least one identified flaw, but that selected subset cannot be generalized to every OAuth deployment. (Zhou et al., arXiv:2605.22333 [S196]) Another preprint reported scanning 39,884 server repositories and confirming 106 taint-style vulnerabilities, with 67 CVE identifiers assigned by the time of its revision. Repository counts are not deployment counts, and preprint results are not universal rates, but both studies show a productionization gap between an easy-to-prototype server and a safely operated capability service. (VIPER-MCP, arXiv:2605.21392 [S197])

The practical security program is defense in depth:

• approve and inventory servers before connection;
• verify publisher, package, version, artifact, and update path;
• isolate local processes and pass only necessary environment variables;
• authenticate restricted remote endpoints and authorize every operation;
• bind tokens, state handles, tasks, caches, and upstream credentials to the correct identity and resource;
• validate tool arguments semantically at the server and again at the underlying system;
• expose the minimum tool set and minimum data needed for a task;
• treat tool metadata, resources, prompts, and outputs as untrusted content;
• make consequential confirmation show the real target, arguments, data movement, and expected effects;
• log identity, decision, effect, and outcome without indiscriminately storing secrets;
• patch SDKs, hosts, servers, registries, and dependencies independently;
• design for revocation, cancellation, incident response, and decommissioning.

The central thesis of this research is that MCP security is not a property of the wire format. It is a property of the authority graph built around the protocol.

---

1. What “MCP security” includes

1.1 Protocol, product, package, and deployment are not interchangeable

An MCP specification revision is a set of protocol rules. An SDK is a library that implements some of those rules. A host is an application that coordinates users, models, clients, and servers. A server is a program or network service implementing the server side. A server package is one way to distribute that implementation. A hosted service is one way to operate it. A registry or directory helps people find metadata about servers. These artifacts can be maintained by different organizations and have different vulnerabilities.

A historically and technically useful security report therefore asks five questions before assigning blame:

1. What exact component was affected?
2. Which version and configuration were affected?
3. What authority did the component possess?
4. Was the defect in normative protocol behavior, an SDK default, host behavior, server logic, package distribution, or deployment?
5. Would a conforming independent implementation share the flaw?

Consider four representative cases:

• MCP Inspector versions below 0.14.1 had a remote-code-execution vulnerability involving the relationship between its client and proxy. That was a vulnerability in a developer tool, not a property of every MCP server. (GHSA-7f8r-222p-6f5g [S109])
• The TypeScript SDK before 1.24.0 did not enable DNS-rebinding protection by default for certain unauthenticated localhost HTTP servers. The advisory explicitly said stdio was not affected. (GHSA-w48q-cv73-mx4w [S111])
• A later TypeScript SDK advisory described cross-client response leakage when a single mutable server and transport instance was reused across connections. That was a concurrency and isolation defect affecting specific versions and usage patterns. (GHSA-345p-7cg4-v4c7 [S147])
• FastMCP before 3.2.0 had a confused-deputy vulnerability in an OAuth proxy flow because consent was not correctly bound when a provider could skip a repeat consent screen. That was an authorization implementation flaw, not proof that OAuth or MCP is inherently a confused deputy. (CVE-2026-27124 [S225])

The phrase “MCP security” is appropriate as an ecosystem topic. It becomes inaccurate when used to erase the affected layer.

1.2 The authority graph

Security analysis should begin with authority rather than protocol nouns. For every connection, record:

• who selected or installed the server;
• which user, workload, organization, or service the client represents;
• what code runs and where;
• which credentials the server receives;
• what filesystem, network, database, repository, cloud, or SaaS authority it can exercise;
• which content enters the model context;
• what the user sees before approval;
• which system makes the final authorization decision;
• where state, logs, caches, and results persist;
• who can update the server or its tool definitions.

A server with one read-only documentation-search tool is not equivalent to a server that can run shell commands, modify production infrastructure, retrieve private messages, and send outbound email. The protocol can represent both. Their acceptable controls and assurance levels are different.

1.3 Threat actor categories

At least eight actors matter:

• a malicious server publisher;
• a legitimate publisher whose account or dependency is compromised;
• an attacker controlling a remote MCP endpoint or DNS domain;
• a malicious repository or project opened by a developer;
• an untrusted user supplying tool arguments;
• an attacker controlling content retrieved by a trusted server;
• a tenant attempting to cross into another tenant’s state;
• an insider or compromised identity with legitimate MCP access.

The same incident may involve more than one. Tool poisoning can begin with a malicious publisher or compromised update. Indirect prompt injection can begin in a public issue, document, webpage, or database record consumed by a trusted server. Cross-tenant leakage may arise without a malicious server at all, through a concurrency error in an SDK or cache.

---

2. A security model by layer

Protocol layer

The protocol layer defines messages, methods, transports, versions, capability declarations, authorization requirements, extensions, and error behavior. Security failures here would include ambiguous or unsafe normative behavior shared by correct implementations. The project can address them through specification revisions, SEPs, deprecation, and security guidance.

SDK layer

SDKs implement parsers, transports, helpers, server instances, callbacks, and state. They can choose insecure defaults, mishandle concurrency, omit input limits, leak state, or incorrectly implement authentication. Patching an SDK advisory does not patch every application that embedded a fork or reimplemented the behavior.

Host/client layer

The host controls which servers connect, which tools enter model context, what the user sees, when confirmation is required, and which local process is launched. Hosts also translate MCP tool definitions into model-provider formats. Security depends heavily on whether they display provenance, full consequential arguments, affected data, and target destinations rather than a friendly tool name alone.

Server layer

The server owns its tool logic. It must authenticate when access is restricted, authorize the principal for every object and operation, validate model-generated and user-generated input, safely call upstream systems, and isolate tenants. A model producing schema-valid JSON does not establish that a repository name, SQL statement, shell argument, path, amount, email recipient, or Kubernetes namespace is authorized.

Distribution and supply-chain layer

Local servers are often installed through package managers or launched by package-runner commands. Remote servers still depend on source repositories, containers, build pipelines, domains, certificates, and dependencies. Publisher identity, package name, provenance, signing, lockfiles, SBOMs, and update policy are security controls independent of protocol conformance.

Deployment layer

Deployment determines whether a service is public, private, localhost-only, containerized, multi-tenant, rate-limited, observable, and protected from DNS rebinding, SSRF, and resource exhaustion. The same source code can be low risk over stdio in a disposable sandbox and dangerous when exposed unauthenticated to the public internet.

Authorization layer

Authorization spans the MCP server, authorization server, client registration or identification, user consent, scopes, token audience, upstream delegation, refresh, revocation, and step-up. It also includes non-OAuth systems such as service identities, network authorization, and native API permissions.

Model and data layer

Natural-language metadata and retrieved data can function as instructions to the model. Tool descriptions, prompt templates, resources, webpage text, issue bodies, email messages, database records, and tool results are not trustworthy merely because they arrived in valid MCP messages.

Underlying-system layer

The target API, database, filesystem, repository, cloud control plane, or SaaS service remains the last line of enforcement. Native RBAC, row-level security, object ownership, transactional safeguards, approval workflows, and immutable audit should remain active. MCP should not create a privileged bypass around them.

---

3. MCP security by protocol era

Use the primary-source MCP history, 2026-07-28 release guide, and stateful-to-stateless migration guide to keep security advice pinned to the right protocol era.

Security claims about MCP must identify the specification revision. The protocol’s trust model, transport, authorization, server-to-client behavior, and state model changed substantially between November 2024 and July 2026.

3.1 Late 2024: local-first composition and host-mediated trust

The first released revision, 2024-11-05, described stateful client–server sessions initialized through a handshake. It supported stdio and an HTTP+SSE transport. Servers could expose tools, resources, and prompts; clients could expose features such as roots and sampling. The protocol emphasized user consent and host control, but it did not include the OAuth authorization model introduced later. (MCP specification 2024-11-05 [S024])

The typical early experience was a desktop or developer host launching a local server. That removed the need to operate a public endpoint or build a browser-based authorization flow. It also moved trust into configuration and process execution. The user or host chose a command, the command started with the local user’s authority, and credentials were commonly passed as environment variables.

This model had several attractive security properties:

• no required listening network socket for stdio;
• a clear parent/child process relationship;
• the possibility of terminating the server with the host;
• local access to files and tools without uploading them to a remote vendor;
• host-mediated decisions about which tools the model could use.

But those properties were not isolation. A malicious process could read anything its OS identity could read, inspect inherited environment variables, make network connections, alter files, or invoke other local programs. Early MCP made integrations easy to prototype partly because the server could be a small script with direct access to the developer environment. The same simplicity made secure distribution, installation, and permission scoping essential.

Launch-era server-to-client sampling is another example of responsibility division. A server could ask the client to sample from the model, but the host was expected to preserve control over model access and user consent. The protocol mechanism did not make a server trustworthy merely because the request was routed through the client.

3.2 March 2025: remote MCP makes authorization unavoidable

The 2025-03-26 revision introduced an OAuth-oriented authorization framework and Streamable HTTP, while retaining initialization and protocol sessions. It also added tool annotations such as read-only, destructive, idempotent, and open-world hints. (MCP 2025-03-26 changelog [S036])

This revision marks the historical shift from a convenient local integration protocol toward a remote service protocol. A local child process may trust the host configuration and receive credentials directly. A remote server needs to know which user or workload is connecting, what it may do, and which upstream account it represents. It may serve many users, operate behind proxies, and obtain delegated access to third-party services.

OAuth entered MCP because remote operation requires more than a network connection. It requires:

• a way to challenge unauthorized clients;
• a way for the client to discover the authorization server;
• user consent where access is delegated;
• a code flow suitable for public clients such as desktop applications and CLIs;
• scoped access tokens;
• a clear target resource;
• refresh and revocation behavior;
• separation between client credentials, user identity, MCP-server authority, and upstream-service authority.

The first framework was necessarily immature. The next revisions refined resource-server identity, discovery, audience restriction, registration, issuer validation, and incremental scopes. That history matters because a server that implemented the March profile and never migrated is not equivalent to a server implementing the current profile.

Tool annotations likewise illustrate the difference between metadata and enforcement. An annotation can help a host decide when to request approval or how to present a tool. It cannot prove that the implementation is read-only or idempotent. The current tools specification continues to warn that annotations should be treated as untrusted unless they come from a trusted server. (MCP tools, 2026-07-28 [S123])

3.3 June 2025: token audience and resource-server hardening

The 2025-06-18 revision explicitly classified an MCP server as an OAuth resource server and required protected-resource metadata and Resource Indicators. (MCP 2025-06-18 changelog [S043])

These changes address a classic distributed-systems problem: a valid token is not valid everywhere. A token issued for service A should not be accepted by service B merely because both trust the same authorization server. RFC 8707 Resource Indicators let the client state the intended resource in the authorization and token requests. The MCP server must validate that it is the token’s intended audience. RFC 9728 protected-resource metadata lets the resource server identify the authorization servers and relevant metadata clients need to begin the flow. (RFC 8707 [S005]; RFC 9728 [S006])

This was more than interoperability polish. Without audience restrictions, a stolen or misdirected token can become a bearer credential usable outside its intended boundary. If an MCP server forwards the client’s token to an upstream service, it becomes difficult to distinguish the client’s authority, the server’s authority, and the upstream resource’s expected audience. The project’s security guidance treats token passthrough as an anti-pattern. (MCP Security Best Practices [S134])

The June revision also removed JSON-RPC batching only one release after adding it. That reversal is relevant to security history because complexity creates ambiguous failure and authorization behavior. A protocol that is still maturing can add and remove features quickly; security programs must track the exact revision rather than assume that all SDKs and hosts converge immediately.

3.4 November 2025: open clients, discovery, incremental consent, and Tasks

The 2025-11-25 revision expanded authorization through OpenID Connect discovery, Client ID Metadata Documents, and more explicit incremental consent. It also introduced experimental Tasks and expanded elicitation. (MCP 2025-11-25 changelog [S049])

MCP clients often run in user-controlled environments and cannot safely keep a static client secret. They may connect to servers that have never seen that client before. Traditional manual preregistration does not scale to an open ecosystem, which encouraged Dynamic Client Registration. But open registration creates difficult questions: Who is the client? Which redirect URIs belong to it? How can an authorization server prevent an attacker from registering misleading or dangerous metadata? How should credentials be bound to the issuing authorization server?

Client ID Metadata Documents address part of this by using a verifiable HTTPS URL as the client identifier and metadata location. Current MCP prefers this approach over Dynamic Client Registration, which is now deprecated but retained for backward compatibility. The shift is historically important because a 2026 measurement study found registration-related defects clustered heavily in the OAuth subset it could test. That sequence does not prove the study caused the protocol change, but it shows that the deprecated mechanism was a significant operational pain point. (Zhou et al., arXiv:2605.22333 [S196])

Experimental Tasks introduced another security dimension: work that persists beyond the immediate request. A long-running operation can outlive the access token, user session, role assignment, or policy under which it began. It can produce results after the principal loses access. Task identity, status visibility, cancellation, result authorization, and expiry therefore need explicit treatment.

3.5 July 2026: stateless protocol, explicit state, routing, caching, and extensions

The current 2026-07-28 revision is the largest architectural break in MCP’s history. It removed protocol-level sessions and the initialization handshake. Each request carries protocol version and client capabilities in _meta; clients should identify themselves on each request, and servers should identify themselves in results. Servers implement server/discover. The revision also introduced required routing headers for Streamable HTTP, cache hints and cache scope for list/read results, Multi Round-Trip Requests, and a formal extensions mechanism. (MCP 2026-07-28 key changes [S055])

The infrastructure benefit is clear. A remote server no longer needs sticky routing or a shared protocol-session store solely to remember initialization state. Ordinary reverse proxies and load balancers can route on visible HTTP information. List results can be cached. Statelessness reduces hidden coupling between requests and server processes.

The security consequence is more nuanced.

Protocol sessions disappeared; application state did not

A server that needs cross-call state now returns an explicit handle and expects it as an ordinary argument later. This is easier to see and route but creates a bearer-like identifier unless properly designed. A secure handle should be:

• generated with enough entropy to resist guessing;
• bound to the authenticated user, workload, tenant, and relevant scopes;
• limited to a specific workflow or resource;
• short-lived or explicitly expiring;
• revocable;
• checked on every dereference;
• absent from URLs, broad logs, and model-visible text unless required;
• unusable after account, policy, or authorization changes that invalidate it.

A handle is not an authorization decision. It is an identifier presented to an authorization decision.

Routing headers became visible infrastructure inputs

Mcp-Method and Mcp-Name help gateways and load balancers route or apply policy without parsing the complete body. That is operationally valuable. It also means servers and gateways must validate header/body consistency. An attacker-controlled header must not be allowed to select a less restrictive route while the body requests a different method or tool. Current MCP defines a header-mismatch error and rules for mirrored parameters. (Streamable HTTP, 2026-07-28 [S057])

Cacheability introduced a privacy boundary

Current list and read results include ttlMs and cacheScope. A public result may be stored in shared infrastructure; a private result must remain bound to its authorization context. A correct cache key must include every request parameter and identity or policy dimension that can change the result. A shared cache that keys only on tools/list or resource URI can leak private capabilities, metadata, or content across users.

Cache scope is a protocol signal, not a substitute for correct intermediary configuration. Operators must confirm that proxies, CDNs, SDK caches, application caches, and gateways respect it.

Multi Round-Trip Requests changed server-to-client interaction

Earlier MCP let a server issue requests such as elicitation or sampling through the client during an established connection. The current protocol instead returns an input_required result. The client obtains the required input and retries the original request with input responses and request state.

This preserves a stateless transport pattern, but the host must maintain provenance across rounds. It should show which server and original operation requested information, what data is being supplied, whether the request is a form or external URL flow, and whether the user’s answer changes authorization or causes an effect. An attacker should not be able to splice input from one outer request into another.

Extensions let security-sensitive features evolve separately

MCP Apps and Tasks can now evolve as official extensions rather than continuously expanding the core. That modularity reduces core-protocol pressure but gives hosts another negotiation and trust decision. A host should not treat support for an extension as blanket approval of every server that uses it.

3.6 What did not change

Across the revisions, several principles remained durable:

• the host mediates access between users, models, and servers;
• server capabilities are not the same as user authorization;
• the server implementation remains responsible for safe behavior;
• tools and resources can expose sensitive data or cause effects;
• user consent needs meaningful presentation;
• JSON-RPC conformance is not a code-security guarantee;
• the underlying system must enforce its own permissions;
• untrusted data remains untrusted after it crosses MCP.

The protocol became more suitable for internet-scale deployment. It did not transform external code, credentials, or natural-language data into trusted objects.

---

4. Local MCP security

The MCP transport guide separates stdio from local or remote HTTP; the transport changes which threats apply.

4.1 The stdio process model

In a typical local configuration, the host starts the server process and exchanges JSON-RPC messages over the process’s standard input and output. The server writes protocol messages to stdout and ordinary logs to stderr. No TCP listener is required.

This is often safer than an unauthenticated localhost HTTP service because a browser cannot ordinarily send JSON-RPC messages into another process’s stdin. It also gives the host a direct lifecycle relationship with the child process. But stdio is not a sandbox. The operating system does not automatically know that the child is “only an MCP server.” It is ordinary code with the permissions of its process identity, container, sandbox, or security profile.

The correct question is not “Does stdio have authentication?” It is:

Who is allowed to select the executable, and what authority does that executable inherit?

4.2 The package and command are the trust boundary

Local installation frequently uses commands that fetch or execute a package. A convenient one-line configuration can hide several mutable decisions:

• which package registry is used;
• whether a namespace or package name is authentic;
• which version is resolved;
• whether the version is pinned;
• whether install scripts run;
• which transitive dependencies are fetched;
• whether the binary matches the reviewed source;
• whether the server auto-updates;
• whether the command uses a shell;
• which working directory and files it can see;
• which environment variables it inherits.

The malicious Postmark-impersonating package reported in 2026 illustrates this class. The attack did not require changing MCP messages. It depended on users installing code that appeared to be a legitimate integration and then passing credentials to it. (Snyk report on the malicious Postmark MCP package [S244])

A secure host should display and approve the exact package, version, registry, executable, arguments, environment names, and working directory. Enterprises should distribute local servers through an approved catalog and pin artifact digests or trusted package versions rather than execute a mutable “latest” release.

4.3 Project configuration can become code execution

Coding tools often support repository- or workspace-specific MCP configuration. This is useful when a project needs its own database, documentation, build, or source-control integrations. It is dangerous when opening an untrusted repository silently authorizes the repository to choose a command that runs on the developer’s machine.

Advisories affecting products such as Cursor, Zed, and Claude-related automation have demonstrated variants of this trust-boundary problem. The precise affected behavior and fixed version are product-specific, but the general control is durable:

• project configuration is untrusted content until the user or policy approves it;
• the host should show a normalized command and meaningful diff;
• approval should be per project and per changed configuration;
• repositories should not be able to override global trusted-server definitions invisibly;
• high-risk servers should run in a workspace container or sandbox;
• project trust should be revocable and auditable.

A user opening source code is not the same security event as a user agreeing to execute repository-selected software.

4.4 Environment variables and secret inheritance

Local servers often need API keys or tokens. Passing a narrow credential through the environment can be appropriate. Passing the host’s complete environment is not.

The parent process may contain cloud credentials, database URLs, signing tokens, package-registry tokens, telemetry keys, session cookies, or unrelated service credentials. A server that needs GITHUB_TOKEN should not automatically receive AWS, Stripe, database, and production deployment credentials.

Hosts should construct a new environment from an allowlist rather than inherit and subtract. Better designs use short-lived brokered credentials or OS secret services and release a credential only when the server requests an authorized operation. Secret values should not appear in command-line arguments, model context, tool descriptions, logs, resource URIs, or error messages.

CVE-2026-40159, affecting a PraisonAI integration before its reported fix, is one example of why broad inherited environments matter. The general risk exists even without a vulnerability label: any deliberately launched local process can inspect variables it receives. (CVE-2026-40159 [S238])

4.5 Filesystem, shell, and developer authority

Filesystem and command tools are high-risk because they convert model decisions into local effects. The controls should be structural, not merely prompt-based:

• use a dedicated OS account, container, sandbox, or mandatory-access-control profile;
• mount only approved directories;
• use read-only mounts by default;
• resolve canonical paths and enforce policy after resolution;
• handle symlinks, junctions, case normalization, and alternate paths;
• avoid general shell tools when structured operations suffice;
• use argument arrays rather than shell concatenation;
• allowlist commands and subcommands;
• restrict network egress;
• cap CPU, memory, file size, output size, execution time, and process count;
• separate read, write, execute, and administrative capabilities;
• require explicit confirmation for irreversible operations.

An MCP tool schema may restrict input shape. It does not make a string safe for a shell, SQL engine, path resolver, templating language, or infrastructure CLI.

4.6 Local HTTP is not equivalent to local stdio

A server bound to 127.0.0.1 is not automatically unreachable by hostile web content. DNS rebinding can cause a browser that initially contacted an attacker-controlled domain to send requests to a localhost service after DNS resolution changes. Several official and vendor SDK/server advisories concerned missing default Host validation or related protection for unauthenticated local HTTP deployments.

The TypeScript SDK advisory stated the necessary conditions precisely: an HTTP-based server running on localhost without authentication, using an affected transport and without DNS-rebinding protection. It also stated that stdio was not affected. (CVE-2025-66414 [S111])

The durable recommendations are:

• prefer stdio for a server intended only for one local host;
• if local HTTP is necessary, authenticate it or use a strong unguessable channel binding;
• validate the Host header and expected origin where applicable;
• bind only to intended interfaces;
• do not assume CORS is a complete DNS-rebinding defense;
• patch SDKs and apply protection even when using custom HTTP frameworks;
• test from a browser-origin threat model, not only from a CLI.

4.7 Local-server approval checklist

Before approving a local server, answer:

1. Is the publisher verified through an official vendor or known maintainer channel?
2. Is the version or artifact digest pinned?
3. Are install scripts and dependencies reviewed or scanned?
4. What exact command will run?
5. Can project content change that command?
6. Which environment variables will be passed?
7. Which directories, sockets, devices, and network destinations are accessible?
8. Which tools are exposed, and which can write, execute, transmit, or delete?
9. Does the server run inside a sandbox appropriate to its authority?
10. How will updates, advisories, revocation, logs, and removal be handled?

A local server is software installation plus delegated authority. Treat it accordingly.

---

5. Remote MCP security

Remote MCP changes the unit of trust. Instead of launching a process selected by local configuration, the client communicates with a service selected by URL or directory metadata. The service may be operated by a SaaS vendor, an internal platform team, a third-party integration provider, or an unknown developer. It may serve one user or thousands. It may hold long-lived access to upstream systems or exchange user-delegated tokens on demand.

5.1 Inventory and exposure

The first control is knowing that a server exists and whether it is reachable. Internet-exposed developer services are often created for testing, bound to all interfaces, left unauthenticated, and forgotten. A server can reveal its tool catalog, schemas, software identity, error behavior, and underlying integrations before any destructive tool is invoked.

The 2026 remote-authentication measurement study identified 7,973 live remote MCP servers and reported that 40.55% exposed tools without authentication. Those numbers are not a universal census. The authors used particular discovery and validation methods over a particular time window, and the population largely predates the current 2026-07-28 revision. The result is still operationally important: a large observed class of remote services treated network reachability as sufficient authority. (Zhou et al., arXiv:2605.22333 [S196])

Organizations should continuously inventory:

• public IPs and domains exposing MCP endpoints;
• internal servers reachable from user devices or agent platforms;
• remote URLs in host configuration;
• OAuth protected-resource metadata and authorization-server relationships;
• service owners, purpose, data classification, supported tools, current version, and last review;
• abandoned or duplicate deployments;
• direct endpoints that bypass an approved gateway.

Discovery is not approval. An endpoint appearing in a registry, code repository, browser search result, or host marketplace does not establish that the organization intends to trust it.

5.2 Authentication and authorization are different controls

Authentication establishes an identity or credential relationship. Authorization decides whether that identity may perform the requested operation on the requested object in the requested tenant and context.

A server can authenticate a valid employee and still be insecure if every employee can call an administrative tool. It can validate an OAuth token and still accept a token intended for another resource. It can correctly authorize access to the MCP endpoint but use a shared upstream service account that ignores the user’s native SaaS permissions.

Every tool call should reach an authorization decision that includes:

• authenticated principal or workload;
• tenant and organization;
• client identity where relevant;
• MCP server and tool;
• requested object or resource;
• action type and side effects;
• current scopes and role assignments;
• upstream account or delegated identity;
• policy version and contextual restrictions;
• whether step-up approval is required.

Do not use the presence of a tool in tools/list as proof that the caller may invoke it. Catalog visibility and execution authority are separate.

5.3 Transport and network controls

For restricted remote services, the deployment should include:

• TLS with valid certificate and hostname verification;
• authenticated access to every protected request;
• reverse-proxy and application request-size limits;
• rate limits by identity, tenant, tool, and cost;
• connection, execution, and upstream timeouts;
• request and response body bounds;
• allowed methods and content types;
• Host and origin validation where relevant;
• egress restrictions for metadata fetching and tool execution;
• private networking or service mesh where public access is unnecessary;
• DDoS and abuse controls;
• secure handling of Mcp-Method, Mcp-Name, and mirrored parameter headers;
• isolation between tenants, users, server instances, and caches.

A network firewall is not enough if every internal workload can reach a tool that performs production changes with a shared service account. A bearer token is not enough if the server does not check audience, tenant, object, and operation.

5.4 Multi-tenancy

Multi-tenant MCP services must assume concurrent requests from unrelated users. Avoid process-global current-user variables, mutable singleton server state, shared transports, and caches that omit authorization context.

The TypeScript SDK cross-client leakage advisory is a useful case study. A single server and transport instance reused across clients could deliver response data to the wrong connection in affected versions. (GHSA-345p-7cg4-v4c7 [S147]) The immediate remedy was an SDK patch and correct instance usage. The broader lesson applies to application code:

• carry identity in immutable request context;
• bind state and handles explicitly;
• make caches tenant-aware;
• use per-request authorization rather than connection assumptions;
• test concurrency with adversarial interleavings;
• ensure background jobs preserve the initiating principal;
• avoid shared mutable response channels;
• verify that logs and metrics do not cross tenant boundaries.

The removal of protocol sessions in 2026 helps horizontal routing but does not create tenant separation automatically.

5.5 Availability and economic abuse

MCP tools can trigger expensive database queries, cloud operations, browser sessions, builds, model calls, search requests, or long-running research. A schema-valid request can still be abusive.

Controls should combine:

• message-size, nesting-depth, array-length, and schema-complexity limits;
• pagination limits;
• per-tool concurrency;
• request budgets and cost estimates;
• downstream rate limits;
• cancellation and deadlines;
• output truncation with secure retrieval for larger results;
• bounded queues;
• circuit breakers;
• tenant quotas;
• protection against repeated MRTR retries or task polling;
• isolation between high-cost and low-cost tools.

Several SDK advisories have involved denial-of-service or unbounded processing. Patch them, but also design service-level bounds because valid protocol traffic can exhaust a poorly bounded tool.

---

6. MCP authorization and OAuth security

6.1 Current scope and roles

The current MCP authorization specification applies to HTTP-based transports. Authorization remains optional at the protocol level. When an HTTP implementation supports restricted access, it should conform to the profile. The specification says stdio implementations should not follow the HTTP authorization flow and should instead obtain credentials from the environment. (MCP Authorization, 2026-07-28 [S133])

The roles are:

• the MCP client acts as an OAuth client;
• the protected MCP server acts as an OAuth resource server;
• the resource owner is normally the user or organization granting authority;
• the authorization server authenticates as necessary, obtains consent, and issues access tokens;
• an upstream service may have a separate authorization relationship with the MCP server.

That last relationship is where many implementations become confused. There can be two OAuth boundaries:

User / MCP client
        ↓ authorization for MCP server
MCP server as resource server
        ↓ separate delegated or service authorization
GitHub / Google / Slack / database / cloud API

The token issued for the first boundary should not simply be forwarded into the second.

6.2 Protected-resource metadata

A protected MCP server publishes metadata under the conventions of RFC 9728. The metadata identifies the authorization server or servers and describes relevant resource information. When the client reaches a protected endpoint without sufficient authorization, the server returns a 401 Unauthorized challenge pointing to protected-resource metadata.

Security requirements include:

• use an authenticated HTTPS origin;
• ensure the metadata describes the intended MCP resource;
• validate discovered authorization-server metadata;
• limit redirects;
• prevent metadata URLs from reaching private, loopback, link-local, or cloud-metadata addresses unless explicitly intended;
• re-resolve and validate DNS where the threat model requires it;
• avoid accepting metadata merely because it is well-formed JSON.

The metadata-fetch path is an SSRF surface. A client often runs on a developer workstation or enterprise network with access the remote attacker does not have. An attacker-controlled MCP URL that points discovery toward internal services can turn the client into a network proxy unless URL handling is hardened. Official security guidance explicitly addresses OAuth URL validation and SSRF. (MCP Security Best Practices [S134])

6.3 Client identification and registration

Before an authorization flow, the client needs a client identifier. Current MCP defines three approaches:

1. Client ID Metadata Documents;
2. preregistration;
3. Dynamic Client Registration for compatibility.

Client ID Metadata Documents are preferred. The client identifier is an HTTPS URL from which the authorization server can obtain client metadata. Security depends on validating the document’s origin, redirect URIs, application type, and relationship to the client.

Dynamic Client Registration historically helped arbitrary clients connect without prior coordination. It also allowed an authorization server to accept client-supplied metadata at runtime. The current specification deprecates DCR in favor of CIMD, while retaining it for authorization servers that do not support the preferred mechanism. (MCP 2026-07-28 key changes [S055])

The 2026 measurement study found DCR-related flaws in much of its 119-server testable subset. The correct interpretation is not “DCR always fails” or “all OAuth servers are vulnerable.” It is that open client registration is hard to implement and was a recurring source of defects in the subset the researchers could actively probe.

6.4 PKCE, state, and authorization-code binding

MCP clients include public clients such as desktop applications and CLIs that cannot safely keep a static secret. PKCE creates a one-time verifier/challenge relationship between the authorization request and token redemption. The client should also maintain state sufficient to bind:

• the authorization request;
• expected issuer;
• selected authorization server;
• client identity;
• redirect URI;
• target MCP resource;
• user interaction;
• PKCE verifier;
• requested scopes;
• resulting callback.

A callback is not safe merely because it contains a valid authorization code. The client must know which flow created it and which issuer, resource, and local user it belongs to.

6.5 Issuer validation

The current revision strengthens issuer validation. The client records the issuer from validated authorization-server metadata before redirecting the user. If the authorization response includes an iss parameter, the client compares it with the recorded issuer before sending the code to any token endpoint. Client credentials are also bound to the authorization server that issued them and must not be reused with a different issuer. (MCP Authorization, 2026-07-28 [S133]; RFC 9207 [S192])

These controls address authorization-server mix-up and credential misbinding. Without them, an attacker can try to make a client send a valid code or client credential to the wrong endpoint.

6.6 Resource Indicators and audience validation

Current clients include the target MCP resource in both authorization and token requests using the resource parameter. The server validates that the access token was issued specifically for it. (RFC 8707 [S005])

This requirement should be enforced at runtime, not assumed from token format. A JWT that verifies cryptographically can still be invalid for the current server if its audience is wrong. An opaque token needs introspection or another authorization-server relationship that establishes the intended resource.

The canonical resource identifier must be stable and specific enough to distinguish servers where paths identify separate resources. Proxy rewrites and aliases must not create multiple inconsistent identities that break audience checks or let one service accept another’s token.

6.7 Bearer-token handling

Current MCP requires the Authorization: Bearer header for access tokens and prohibits putting tokens in the URI query string. Authorization must accompany every protected HTTP request. The server validates the token, audience, scopes, expiry, revocation state where available, and any tenant or subject constraints. (MCP Authorization, 2026-07-28 [S133]; RFC 6750 [S193])

Operators should also:

• avoid logging Authorization headers;
• prevent tokens from entering traces, exceptions, URLs, browser history, analytics, or model context;
• use short lifetimes appropriate to risk;
• rotate refresh tokens where supported;
• encrypt stored tokens;
• bind storage to the correct OS user or tenant;
• revoke on server removal, user offboarding, or suspected compromise;
• avoid sharing tokens between local profiles or host installations.

6.8 Scopes and incremental consent

Scopes should express meaningful, enforceable authority rather than merely label a UI. A server can challenge with the scopes needed for the current request. Clients should request the minimum set and add scopes through step-up when a later operation needs more.

Useful scope design separates:

• read from write;
• metadata from content;
• one repository, workspace, tenant, or account from another;
• normal operations from destructive or administrative actions;
• interactive user actions from background or long-running Tasks;
• data retrieval from external transmission.

The server must still authorize the object. A repo:write scope does not prove that the user may modify every repository. Scope checks and resource-level checks are complementary.

6.9 Token passthrough

Token passthrough occurs when the MCP server accepts a token from the client and forwards it to an upstream API. It is attractive because it appears to preserve user identity without another authorization flow. It is unsafe because the upstream API may interpret the token differently, and the token’s audience may not be the upstream resource.

Consequences include:

• bypassing the MCP server’s intended audience restriction;
• losing a clear audit boundary;
• exposing a token to server code or logs that did not need it;
• allowing an upstream API to receive a credential minted for another service;
• confusing whether the MCP server or user authorized the operation;
• preventing correct scope translation and revocation.

Use a separate upstream authorization relationship. The MCP server can exchange, obtain, or store an upstream token specifically intended for that service and user, or use a service identity when the organizational model explicitly permits it. It should never treat the client’s bearer token as a general-purpose credential.

6.10 Confused deputy and account linking

A confused deputy is a component with legitimate authority that is tricked into exercising it for the wrong principal or objective. MCP creates several possible deputies:

• a host that can call multiple servers;
• an OAuth proxy that connects clients to an upstream provider;
• a server with access to a service account;
• a gateway with broad routing privileges;
• an agent with tools for both reading secrets and sending data.

CVE-2026-27124 in FastMCP is an instructive authorization example. The affected OAuth proxy did not correctly validate consent when handling a GitHub authorization code, interacting badly with provider behavior that could skip a repeat consent page. The patch addressed that implementation. The general defense is to bind consent and callback state to the initiating client, user, resource, issuer, provider account, and intended operation. (CVE-2026-27124 [S225])

Account linking deserves separate review. A user signed into the host as Alice may authorize an upstream provider account belonging to Bob, intentionally or accidentally. The system should make that identity relationship visible, prevent a callback initiated for one local account from binding to another, and support unlinking and reauthorization.

6.11 Machine-to-machine authorization

Not every MCP connection represents a human in a browser. Scheduled agents, build systems, internal services, and enterprise gateways may use workload identities and client credentials. The security model should specify:

• which workload identity is authenticated;
• which tenant or environment it belongs to;
• whether it acts as itself or on behalf of a user;
• how scopes and target resources are limited;
• how credentials are rotated and attested;
• how human approval is inserted for consequential operations;
• how activity is attributed and revoked.

Do not simulate a user-delegated flow with a shared static token simply because the client is non-interactive.

---

7. Tool poisoning, shadowing, and rug pulls

The MCP vs function calling comparison explains where model tool choice ends and the MCP client-server boundary begins.

7.1 Why tool metadata is security-sensitive

An MCP tool definition is not merely developer documentation. The host may place its name, description, schema, annotations, and other text into the model’s context so the model can choose and populate the tool. Any attacker who controls that text may gain an instruction channel into the agent’s decision process.

Invariant Labs publicly documented this problem on April 1, 2025. Its proof of concept used an innocent-looking addition tool whose description instructed the model to read sensitive local files, conceal that behavior, and include the contents in a tool argument. The researchers also demonstrated cross-server shadowing and later described a practical exfiltration path involving another connected server. (Invariant Labs tool-poisoning disclosure [S108])

The security issue is not that JSON contains a description field. It is that:

1. an untrusted server controls natural-language content;
2. the host gives that content to a model as decision context;
3. the model can use other high-authority tools or local capabilities;
4. the user may see only a simplified label or partial arguments;
5. the host treats a model-produced call as sufficient evidence of intent.

7.2 Direct tool poisoning

In direct poisoning, the malicious tool’s own metadata instructs the model to perform unauthorized actions. The tool may request an extra argument that acts as an exfiltration channel, or it may tell the model to call a separate file, shell, browser, or network tool first.

Defenses include:

• trust and allowlist servers before their metadata enters model context;
• display the complete tool description and meaningful schema to reviewers;
• analyze all textual schema fields, not only the description;
• restrict which tools can co-reside in the same model context;
• apply dataflow policy preventing secrets from becoming arguments to unrelated servers;
• require consequential confirmation showing actual values and destination;
• use a model-independent policy engine for sensitive files, credentials, and external transmission;
• constrain server permissions so a successful semantic attack cannot reach high-value data.

Static text scanning can catch obvious payloads. It is not complete. Instructions can be obfuscated, split across fields, encoded in examples or enum labels, generated dynamically, or written to look like legitimate operational requirements. A defense paper published in 2026 reported useful precision but incomplete recall across its dataset, reinforcing the need to limit effects after detection fails. (CASCADE, arXiv:2604.17125 [S203])

7.3 Implicit poisoning

A malicious tool does not need to be invoked. Its description can tell the model to use a legitimate high-privilege tool differently. Research on implicit tool poisoning formalizes this pattern: the poisoned metadata influences the agent while the actual malicious capability remains unused. (MCP-ITP, arXiv:2601.07395 [S201])

This defeats controls that monitor only calls to the suspicious tool. Hosts need provenance-aware reasoning about which server supplied each instruction and which data flows between server domains.

7.4 Tool shadowing

In a shadowing attack, one server’s metadata changes how the model uses another server. A low-authority “calculator” server might tell the model that an email tool requires a special recipient, that a repository tool must include private file content in an issue, or that a trusted server’s safety rule is obsolete.

MCP servers do not need to communicate directly for this to work. The model is the shared semantic channel. A host that combines tool descriptions from many servers into one undifferentiated prompt creates an implicit trust domain larger than any single server.

Controls include:

• server-qualified names and visible provenance;
• separate model contexts or subagents for different trust domains;
• explicit policy preventing one server’s metadata from redefining another server’s semantics;
• tool-level input and output labels;
• cross-server dataflow rules;
• minimal server selection for each task;
• postcondition checks at the host or underlying service.

Namespacing helps humans and software identify provenance. It does not guarantee that a model will ignore cross-server natural-language instructions.

7.5 Rug pulls and definition drift

A server may present a benign definition during approval and change it later. A remote server can change immediately. A local server can change through package update, mutable dependency, or compromised maintainer account. Tool lists can also legitimately change as features are added.

Approval should therefore bind to an identifiable definition, not merely a server name. Hosts can fingerprint:

• tool name;
• description;
• input and output schemas;
• annotations;
• server identity and version;
• extension declarations;
• package or artifact digest;
• remote origin and certificate identity.

When a security-relevant field changes, the host should show a diff and require review. Dynamic systems may need a policy allowing additive low-risk changes while blocking new write, execute, credential, or network capabilities until approved. Signed manifests can establish publisher integrity but do not prove benign semantics.

7.6 Meaningful consent

A generic dialog—“Allow tool send_email?”—is inadequate when the security-relevant facts are:

• which server supplied the tool;
• which account will send the message;
• the actual recipient;
• whether attachments or retrieved secrets are included;
• whether the action is externally visible and irreversible;
• whether the call was influenced by untrusted content;
• whether the tool definition changed since approval.

Confirmation should be proportional to consequence. Read-only metadata lookup may need no per-call prompt in a trusted environment. Transferring data between trust domains, modifying production, deleting records, sending money, publishing content, or granting access should expose target and effect clearly and may require step-up identity or a second approver.

7.7 Why model choice is not a security boundary

Some models resist malicious instructions better than others, and reasoning strategies can change attack success. Research comparing clients and models is useful. But model resistance is probabilistic, prompt-dependent, and subject to regression. It should reduce risk, not serve as the final control.

A secure system assumes the model may select a disallowed action and enforces policy outside the model. The policy engine should inspect structured action, principal, target, data classification, provenance, and expected effect.

---

8. Prompt injection through resources, prompts, and tool results

8.1 Data can become instructions

MCP resources can expose documents, files, database content, webpages, messages, and other data. Tools can return text and structured content. Prompts can provide server-authored templates. The model is designed to interpret language, so attacker-controlled language can attempt to redefine the task.

Examples include:

• a public issue telling the agent to upload private repository files;
• a webpage instructing browser automation to reveal cookies;
• a document telling a research agent to ignore the user and call a send tool;
• a database row containing instructions that become a follow-on SQL or admin call;
• a tool result telling the model that authorization succeeded when it did not;
• a prompt template that quietly includes an attacker-controlled destination.

The MCP transport may faithfully carry the content. That is not a guarantee that the content is safe to treat as instruction.

8.2 Instruction and data separation

A host should label provenance and intended role:

• user instruction;
• host policy;
• trusted organizational instruction;
• server tool metadata;
• untrusted external data;
• tool result;
• model-generated plan.

Models may still blur those categories, but explicit structure helps both models and policy systems. The host should never allow external content to grant itself authority. A sentence in a webpage cannot authorize a file read, credential access, tool installation, or external transmission.

8.3 Taint and dataflow controls

For sensitive systems, track the origin and classification of data through the workflow. Examples:

• content from a public webpage is untrusted and public;
• a private repository file is confidential;
• an API token is secret and non-model-visible;
• a customer record is tenant-bound personal data;
• a tool description from an unapproved server is untrusted instruction-like metadata.

Policy can then block flows such as:

• secret → model context;
• confidential repository → unapproved server;
• tenant A data → tenant B task;
• untrusted webpage → shell command;
• model-generated recipient → external email without confirmation;
• tool result → authorization decision without independent verification.

Dataflow controls are difficult but more durable than searching for known hostile phrases.

8.4 Result validation and postconditions

A server result should be treated as a claim until validated. Structured output schemas verify shape, not truth. For consequential operations, verify postconditions through a trusted channel:

• query the repository to confirm the issue was created in the intended project;
• verify the payment amount and recipient through the payment system;
• compare infrastructure plan and applied state;
• confirm that a file write stayed within approved paths;
• verify database row count and tenant;
• ensure an email’s actual recipient matches the approved recipient.

The host should not let a malicious or buggy server’s “success” text override an error from the underlying system.

8.5 Retrieval minimization

Do not place every available resource and tool description into the model context. Select the minimum servers, tools, and resources needed for the current task. This reduces token cost, ambiguity, semantic attack surface, and accidental data exposure.

Dynamic discovery and search can help, but the discovery mechanism must respect trust and authorization. “Find a tool that can do X” is itself a supply-chain and policy decision.

---

9. Server implementation vulnerabilities

For the underlying service boundary, see MCP vs APIs.

9.1 Schema validation is necessary but insufficient

MCP tools use JSON Schema to describe inputs. A server should reject malformed requests and unsupported schema complexity. But schema validity answers whether the input has the expected structure. It does not answer whether the input is authorized or safe for the downstream interpreter.

A value can be:

• a valid string and an unsafe shell fragment;
• a valid path and outside the approved directory;
• a valid repository name and inaccessible to the user;
• a valid SQL string and an injection payload;
• a valid URL and an SSRF destination;
• a valid recipient and an attacker-controlled external address;
• a valid Kubernetes namespace and the wrong production environment.

Validation should combine syntax, semantics, policy, and authorization.

9.2 Command injection

Command injection occurs when untrusted arguments reach a shell or command interpreter with unsafe composition. Model-generated arguments are untrusted. Retrieved data incorporated into arguments is also untrusted.

Strong controls:

• avoid the shell;
• call a library or structured API;
• pass an executable and argument array directly;
• allowlist commands and flags;
• reject unexpected metacharacters as an additional defense, not the primary one;
• isolate the process and filesystem;
• restrict network egress;
• use a nonprivileged account;
• enforce time and output limits;
• require confirmation for effects.

CVE-2026-5059 in an aws-mcp implementation and multiple findings reported by VIPER-MCP are examples of this class. They are server-code vulnerabilities that become particularly dangerous because a model can generate varied natural-language paths to the vulnerable argument. (GHSA-fgmx-xfp3-w28p [S232]; VIPER-MCP [S197])

9.3 SQL injection and database authority

Database servers should use parameterized queries and a database identity limited to the required schema, tenant, tables, and operation. A “read-only” connection should be enforced by the database, not only by a tool description or application flag.

Additional controls include:

• query templates or a safe query builder;
• statement timeout and row limits;
• separate read and write tools;
• prohibit multiple statements;
• tenant predicates enforced below the model;
• explain/plan review for expensive queries;
• transaction rollback or dry-run for changes;
• redact secrets and personal data from model-visible results.

CVE-2026-11529 in one MySQL MCP implementation illustrates that conventional SQL injection remains relevant inside MCP servers. (GHSA-mvq4-39wx-6h5g [S231])

9.4 Path traversal and filesystem boundaries

Path policy must be applied after canonicalization and symlink resolution. Consider:

• .. traversal;
• symlinks and junctions;
• alternate case or Unicode normalization;
• network shares and mounted volumes;
• file URLs and encoded separators;
• race conditions between check and use;
• archive extraction;
• Git repositories with unexpected worktrees or submodules.

The reference Git server path advisory is one ecosystem example. The broader control is to combine server validation with OS-level mount and permission boundaries. (GHSA-5cgr-j3jf-jw3v [S215])

9.5 SSRF in tools and authorization discovery

Any server tool that fetches a URL can become an SSRF primitive. So can OAuth metadata discovery, schema imports, webhooks, image fetches, browser automation, and server-manifest resolution.

Use an egress proxy or library that:

• permits only necessary schemes;
• normalizes and validates before connection;
• blocks loopback, private, link-local, multicast, and cloud metadata ranges unless explicitly needed;
• revalidates after redirects;
• resolves DNS and checks every returned address;
• limits redirects, response size, content type, and time;
• prevents credential forwarding to a different origin;
• logs destinations without recording secret query data.

The official Registry SSRF advisory demonstrates that registry and distribution infrastructure can share the same class of flaw as servers. (GHSA-r48c-v28r-pf6v [S216])

9.6 Denial of service

MCP messages can contain nested schemas, large arrays, binary data, recursive references, long strings, and requests that trigger expensive downstream work. Defensive parsing should apply before allocating large structures or invoking tools.

Set limits for:

• HTTP and stdio message size;
• JSON depth and field count;
• schema $ref depth and composition branches;
• base64 content size;
• result size;
• concurrent requests;
• tool execution time;
• task duration and polling rate;
• pagination size;
• log volume;
• repeated authorization or discovery attempts.

A server should fail closed and predictably when limits are exceeded. It should not include sensitive internal state in errors.

9.7 Error handling

Errors need enough detail for the client and operator to act, but not enough to expose:

• access tokens;
• client secrets;
• filesystem paths beyond what the user already knows;
• SQL queries with sensitive values;
• stack traces and dependency versions to untrusted callers;
• internal URLs or cloud metadata;
• other tenants’ identifiers;
• full model prompts or retrieved content.

Use correlation IDs to join a sanitized client error to protected operational logs.

---

10. SDK and host vulnerabilities

10.1 Secure defaults matter

An SDK can implement the protocol correctly yet expose developers to unsafe default deployment. DNS-rebinding advisories across several language SDKs show the importance of secure localhost HTTP helpers. Input-validation and resource-exhaustion advisories show the importance of bounded parsing. Cross-client leakage shows the importance of safe instance ownership.

Teams should maintain an inventory of:

• SDK language and version;
• enabled transports;
• custom middleware replacing official helpers;
• known security advisories;
• forked or vendored code;
• protocol revisions supported;
• application patterns affected by advisory preconditions.

Patch versions should be verified in the original advisory immediately before publication or deployment. Do not copy an affected range from an undated blog post.

10.2 Inspector and developer-tool authority

Inspectors, test proxies, debuggers, and configuration UIs often run with exceptional local authority. They can launch arbitrary server commands, connect to local and remote endpoints, display tokens, and bridge a browser UI to a backend process. A developer tool intended for localhost can still be reachable through browser-origin attacks or broad interface binding.

CVE-2025-49596 in MCP Inspector demonstrated the severity of that boundary. The fix was product-specific. The durable controls are:

• bind test tools to loopback by default;
• require an unguessable session token or authentication between UI and backend;
• validate origin and Host;
• do not expose arbitrary command launch to unauthenticated web content;
• separate production credentials from test tools;
• stop inspectors when not in use;
• patch them as aggressively as production servers.

10.3 Host configuration and one-click installation

A polished host can make installation feel like selecting a harmless connector. Underneath, the action may download code, add an executable command, pass secrets, grant filesystem access, and expose tools to a model.

A secure installation interface should show:

• publisher and verification method;
• source repository and package registry;
• exact version or digest;
• requested local paths, network destinations, environment variables, and credentials;
• tools and risk categories;
• whether definitions can change dynamically;
• whether the server is local or remote;
• authorization scopes and upstream account;
• update and removal behavior;
• security-review and support status.

The interface should not equate “official-looking icon” or “listed in a directory” with verified provenance.

10.4 Tool filtering and context construction

A host does not need to expose every connected tool to every model request. It can select by task, user, workspace, data classification, server trust, and model capability. Reducing the active set limits both semantic attack surface and accidental selection.

Hosts should preserve server and tool provenance in model-visible names or metadata, detect collisions, and avoid silently truncating security-relevant descriptions or schemas during provider-format translation.

10.5 Confirmation policy

Use a risk model based on effects rather than names:

• Low risk: public documentation lookup; no sensitive input; no persistent effect.
• Moderate risk: private read; bounded object; no external transmission.
• High risk: write, delete, execute, publish, message, transfer, permission change, credential use, cross-domain data movement.
• Critical risk: production infrastructure, financial transaction, security control, identity administration, destructive bulk operation.

High and critical operations should include clear arguments, target, principal, upstream account, data leaving the trust domain, and a preview or plan where possible. Repeated approvals may be reduced through narrowly scoped policy, but not through blanket trust in a mutable server.

---

11. MCP supply-chain security

11.1 Why MCP servers are attractive supply-chain targets

A local MCP server is often installed precisely because it needs access to data and credentials. It may receive a source-control token, database URL, cloud credential, Slack token, browser profile, local directory, or command-execution capability. A malicious package does not need to exploit a protocol parser if the user deliberately runs it and hands it secrets.

Remote servers have a different but equally important supply chain: source repository, build system, container image, hosting account, domain, TLS certificate, dependencies, registry record, and deployment pipeline. A compromised remote server can change tool definitions or behavior without the client installing a new package.

11.2 Provenance controls

For each approved server, record:

• canonical server name and organizational owner;
• official source URL obtained from the vendor, not from a copied directory entry;
• package, container, binary, or remote origin;
• publisher identity and namespace verification;
• source commit, release tag, package version, and artifact digest;
• signature or provenance statement where available;
• SBOM and dependency lockfile;
• build and release process;
• vulnerability-reporting channel;
• maintenance status and support commitment;
• update and rollback procedure;
• current security assurance level.

A server name such as “GitHub,” “Postmark,” “Google Drive,” or “Slack” does not establish that the named company published it. A community wrapper may be useful, but it must be labeled as a community implementation and reviewed accordingly.

11.3 Package pinning and updates

Pinning a version prevents unexpected code changes but creates a patch-management obligation. An organization needs to know when an approved version becomes vulnerable or unsupported. A sound update process includes:

1. monitor project and dependency advisories;
2. fetch a new release through an authenticated source;
3. verify signature, digest, and publisher;
4. compare dependencies, tool definitions, permissions, and network behavior;
5. run automated tests and security scans;
6. test in a constrained environment;
7. reapprove security-relevant capability changes;
8. deploy gradually;
9. retain rollback artifacts;
10. update the catalog and evidence record.

Automatic updates without review enable rug pulls at the code layer. Never updating leaves known vulnerabilities in place. The solution is governed updates, not one extreme.

11.4 Registries and directories

The official MCP Registry launched in preview in September 2025 to standardize metadata and namespace verification. It points to packages or remote endpoints; it is not a substitute for package registries, artifact verification, code review, or operational assessment. (Official MCP Registry preview [S066])

The Registry itself has had separate advisories involving SSRF, OIDC token replay, open redirects, stored XSS, and OCI verification behavior. Those advisories should not be presented as evidence that every listed server was compromised. They demonstrate that discovery infrastructure is software with its own threat model and patch lifecycle.

An enterprise catalog should enrich registry metadata with:

• internal owner and business justification;
• approved version or remote origin;
• data classification;
• permitted users and workspaces;
• requested scopes and upstream identity model;
• risk level and review date;
• known advisories and patch status;
• required gateway, sandbox, or egress policy;
• deprecation date and replacement.

11.5 Signed manifests and their limits

A signed manifest can prove that a particular publisher approved a particular tool definition or artifact. It helps detect tampering and definition drift. It does not prove that the publisher is trustworthy, the implementation is secure, the description is nonmalicious, or the runtime behavior matches the manifest.

Use signatures for integrity and provenance, then apply semantic review, runtime controls, and least privilege.

11.6 Abandoned servers

Server proliferation creates long-tail risk. A server may remain installable after maintainers stop patching dependencies, responding to disclosures, renewing domains, or supporting current MCP revisions.

Catalog policy should define minimum maintenance evidence and remove or quarantine servers that:

• have unresolved critical advisories;
• depend on unsupported SDKs;
• have no accountable owner;
• use an expired or transferred domain;
• no longer build reproducibly;
• expose deprecated insecure transports without a migration plan;
• fail authorization or tenant-isolation tests;
• have not been used for a defined period.

---

12. MCP Apps security

MCP Apps let a server associate a tool with an interactive user interface rendered by a compatible host. The UI can make complex results and workflows more understandable than raw text. It also means the host may render server-provided HTML and accept messages or tool requests from it. (MCP Apps overview [S136])

12.1 The UI is not the host’s trusted chrome

A server-provided app should be visibly distinct from the host’s own identity, authorization, and confirmation interface. Otherwise, a malicious app can imitate:

• a permission dialog;
• an OAuth login;
• an operating-system prompt;
• an organizational approval screen;
• a success or error state;
• a trusted server’s branding.

The host should retain control of consequential confirmation outside the server-provided frame.

12.2 Sandboxing and CSP

The app should run in the required sandbox with a restrictive Content Security Policy. The host should expose only the bridge methods necessary for the negotiated capability. Network access should be denied or narrowly allowed. The UI must not receive host secrets, unrelated conversation context, or credentials merely because it belongs to an MCP server.

12.3 Message and origin validation

Every message crossing the UI/host bridge should be schema-validated, origin-checked, associated with the correct app instance and server, and authorized like any other action. Do not trust a message field claiming that the user clicked “approve.” The host’s own trusted event path must establish consent.

12.4 UI-initiated tools

A UI may request a tool call. The host should apply the same tool filtering, argument validation, approval, dataflow, and auditing used for model-initiated calls. The UI is another caller, not an authorization bypass.

12.5 Privacy

The app should receive the minimum data needed to render. Avoid sending complete tool catalogs, conversation history, tokens, or other servers’ results. Treat telemetry from the app as outbound data subject to disclosure and policy.

---

13. MCP Tasks and long-running work

Tasks represent durable or pollable work outside one immediate request. The current Tasks extension uses task handles and status/result interactions rather than the experimental core shape introduced in 2025. (MCP Tasks overview [S137])

13.1 Task identity is not authorization

A task identifier may behave like a bearer capability if possession is enough to read or modify it. Use high entropy and bind it to:

• authenticated principal;
• tenant;
• MCP server and operation;
• authorized scopes;
• expected client or workload where appropriate;
• creation time and expiry;
• data classification;
• result-access policy.

Check authorization on every status, input, cancellation, and result request.

13.2 Privilege drift

A task may begin while the user has permission and continue after the user is disabled, removed from a project, or loses a scope. Define policy for:

• rechecking before each privileged phase;
• pausing on token expiry or revocation;
• continuing nonprivileged compute but withholding results;
• cancelling on tenant or policy change;
• handling upstream permission changes;
• irreversible effects already completed.

A task should not gain a permanent copy of the initiating privilege by accident.

13.3 Input and MRTR

When a long-running workflow asks for additional input, the host should show the original task, requesting server, current status, data requested, and consequence of answering. Prevent a response intended for one task from being attached to another.

13.4 Result security

Task results may contain more sensitive data than status. Separate permissions for listing or knowing a task exists, viewing status, supplying input, cancelling, and reading results. Redact status messages that would leak data through notifications or logs.

13.5 Cleanup

Tasks need expiration, deletion, retention, and incident-response behavior. Define whether cancellation also deletes intermediate artifacts, revokes credentials, stops upstream work, and removes cached results.

---

14. Current vulnerability record: what it proves and what it does not

The public advisory record now spans SDKs, inspectors, hosts, registries, launchers, frameworks, and individual servers. The included machine-readable timeline in this research package records the affected component, version, fixed version, layer, and primary advisory URL.

14.1 Representative classes

Developer-tool remote code execution

MCP Inspector below 0.14.1 had a critical advisory involving unauthenticated communication between the Inspector UI/client and proxy. It demonstrates that local development bridges can be high-authority network services. It does not mean that the MCP protocol grants arbitrary code execution. (GHSA-7f8r-222p-6f5g [S109])

DNS rebinding

Official SDKs and servers in several languages published DNS-rebinding advisories affecting localhost HTTP modes. The TypeScript advisory fixed the default in 1.24.0 and stated that stdio was unaffected. The repeated class shows how copied transport patterns can spread across ecosystems and why “localhost” is not an authentication mechanism.

Cross-client state leakage

The TypeScript SDK advisory fixed in 1.26.0 showed that improper reuse of server/transport state could leak responses across clients. This is especially relevant to multi-tenant and stateless HTTP services: stateless protocol semantics do not prevent mutable application instances from being shared unsafely.

OAuth and account-linking defects

FastMCP, LibreChat, registry infrastructure, and other components have disclosed OAuth-related defects involving consent, callbacks, token binding, replay, headers, or URL handling. These cases support rigorous implementation testing. They do not establish that a conforming OAuth flow is less secure than static bearer tokens.

Injection in individual servers

Command injection, SQL injection, path traversal, arbitrary file read, and weak authorization have appeared in server advisories. These are conventional software weaknesses amplified by powerful tools and model-generated inputs.

Malicious package distribution

The Postmark impersonator illustrates an incident where the package itself was malicious rather than merely vulnerable. The primary controls are provenance, verified vendor links, package review, secret minimization, and local isolation.

14.2 Do not total CVEs as though they were one product

A raw count can include:

• multiple language SDKs carrying related DNS-rebinding patterns;
• one registry with several independent web and auth issues;
• abandoned community servers with few users;
• host applications with MCP configuration features;
• ordinary dependencies that happen to be used by an MCP component;
• vulnerabilities found in unreleased or unusual configurations;
• duplicate records or revised advisories.

A useful dataset groups by component, layer, weakness, deployment precondition, affected version, fix, and exploit evidence. It should not state “MCP has N vulnerabilities” without defining the population.

14.3 Patch management by layer

Maintain separate inventories and patch channels for:

• specification revision;
• official or community SDK;
• host application;
• Inspector/developer tools;
• local server packages;
• remote server service;
• registry or gateway;
• underlying API clients and dependencies;
• container/base image;
• authorization server.

Upgrading the protocol revision does not automatically upgrade all of those components.

---

15. What empirical security research can and cannot establish

15.1 Remote authentication measurement

The May 2026 preprint “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers” identified 7,973 live servers and classified authentication approaches. It reported 3,233 servers—40.55%—exposing tools without authentication. Among 2,428 OAuth-enabled servers, the researchers narrowed dynamic testing to 119 testable deployments and reported 325 flaws, at least one in every tested server, with nine CVE identifiers obtained through responsible disclosure. (arXiv:2605.22333 [S196])

The responsible interpretation includes four limits:

1. It is a preprint, not a final industry census.
2. The 119-server dynamic subset was filtered for testability and is not a random sample of every OAuth deployment.
3. The scanned ecosystem largely implemented pre-2026-07-28 protocol behavior.
4. A detected flaw can differ in exploitability and impact across configurations.

The study strongly supports the conclusion that remote authentication deployment was immature. It does not support “OAuth is broken on every MCP server.”

15.2 VIPER-MCP

VIPER-MCP reports an automated audit of 39,884 open-source server repositories, 106 confirmed taint-style zero-days, and 67 CVE assignments at the reported revision. Its contribution is not only static detection; the framework attempts to produce end-to-end exploit traces using natural-language prompts. (arXiv:2605.21392 [S197])

Important limits:

• repositories are not equivalent to unique maintained servers;
• repository presence is not deployment or active use;
• the framework focuses on selected taint-style weaknesses rather than every security property;
• confirmation methodology and benchmark composition matter;
• CVE assignment does not prove widespread exposure;
• the disclosure count may change after publication.

The durable conclusion is that ordinary injection and path vulnerabilities can be discovered and reached through model-generated tool inputs at scale.

15.3 Tool-poisoning studies

Research has moved from manual demonstrations to comparative client testing, implicit attacks, multi-tool attacks, and defensive detectors. These studies show that semantic attacks vary by model, client, prompt, tool set, UI, and defense. They do not establish one stable attack-success rate for MCP.

The safest engineering response is to assume semantic defenses can fail and limit the authority available after failure.

15.4 Internet-wide server counts

Studies and security companies have reported different counts of internet-visible MCP services. These cannot be compared without normalizing:

• discovery sources;
• scan date;
• endpoint fingerprints;
• whether legacy SSE and current Streamable HTTP are both included;
• whether one IP hosts many servers;
• whether a responding endpoint actually implements MCP;
• whether authentication prevented validation;
• duplicate domains and ephemeral deployments;
• server versus proxy or gateway.

Use counts as time-stamped measurements, not a universal ecosystem size.

---

16. NSA guidance, OWASP, and security frameworks

16.1 NSA guidance

On May 20, 2026, the NSA Artificial Intelligence Security Center released “Model Context Protocol: Security Design Considerations for AI-Driven Automation.” The accompanying release emphasized MCP use in sensitive environments and argued that security needs to be treated across the full agentic continuum rather than patched only at one endpoint. (NSA press release [S189]; NSA Cybersecurity Information Sheet [S188])

The document is an authoritative institutional contribution. It was published before the final 2026-07-28 specification. Therefore:

• general recommendations about least privilege, trust boundaries, validation, isolation, audit, and governance remain valuable;
• references to protocol sessions or the initialization-era lifecycle must be labeled as applying to earlier revisions;
• current analysis should translate session risks into explicit handle, task, cache, and application-state risks where appropriate;
• it should not be presented as a certification standard.

16.2 OWASP MCP Top 10

As of August 25, 2026, the OWASP MCP Top 10 page described version v0.1 as being in beta release and pilot testing. Its categories include token mismanagement, scope creep, tool poisoning, supply-chain attacks, command injection, intent-flow subversion, insufficient authentication and authorization, lack of audit, shadow servers, and context injection or over-sharing. (OWASP MCP Top 10 [S190])

It is useful as a community checklist. It should not be called a final standard or treated as an exhaustive taxonomy. Some language on the page reflects session-era assumptions and needs current-version qualification. Organizations should map its categories to concrete architecture and controls rather than merely declare “OWASP compliant.”

16.3 MCP-38 and other taxonomies

MCP-38 proposes 38 threat categories and maps them to existing frameworks. Academic and community taxonomies help ensure that semantic, protocol, supply-chain, and operational threats are not omitted. Their category names are not necessarily protocol terminology, and overlapping frameworks should not be combined into inflated counts of unique risks. (MCP-38, arXiv:2603.18063 [S199])

16.4 Use frameworks as maps, not evidence of control

A threat appearing in a checklist does not prove a system is vulnerable. A checkbox marked “implemented” does not prove the control works. Assurance requires design evidence, tests, operational telemetry, and response capability.

---

17. Enterprise MCP security and governance

17.1 Approved-server catalogs

Server proliferation creates an enterprise question that the core protocol cannot answer:

Which servers may this organization’s users and agents trust with which data and authority?

An approved catalog should be an enforcement input rather than a recommendation page. It should bind a stable server identity to:

• accountable business and technical owners;
• source, package, artifact or remote origin;
• supported protocol revision and extensions;
• deployment model;
• approved users, groups, workloads, workspaces, and environments;
• permitted tools and resources;
• upstream identity and credential model;
• data classification and residency;
• network and egress policy;
• security review evidence;
• current version and advisory status;
• required confirmation and step-up rules;
• monitoring, incident, deprecation, and removal procedures.

Hosts should block or clearly quarantine unapproved project configurations rather than allow the catalog to be bypassed through a local JSON file.

17.2 Identity and SSO

Enterprise identity should distinguish:

• human user;
• host installation;
• client application;
• workload or agent;
• MCP server;
• upstream service account;
• organization and tenant.

A single token or username should not ambiguously represent all of them. Central identity can supply SSO and user lifecycle, but the MCP server still needs object- and operation-level authorization. Workload identity may be required when an unattended agent runs outside a user session.

The project’s August 2026 roadmap lists agent identity and enterprise-ready security among the priorities for the next development cycle. That is evidence of active design work, not evidence that one universal agent-identity solution already shipped. (The New MCP Roadmap [S064])

17.3 MCP gateways

A gateway or proxy can centralize:

• authentication;
• approved-server resolution;
• tool and server allowlists;
• scope minimization;
• token brokering;
• routing;
• rate limiting;
• request and result size limits;
• DLP and egress policy;
• logging and tracing;
• schema and definition drift monitoring;
• isolation between networks;
• emergency disablement.

But “gateway” is generally an ecosystem or product role, not a magical security property defined by MCP. A gateway cannot reliably determine that a shell command is safe solely from JSON Schema. It cannot repair SQL injection inside a server, make a malicious publisher honest, or recreate user-level permissions hidden behind a shared service account.

A secure gateway validates identity and body/header consistency, applies policy, and forwards only to authenticated approved servers. Direct paths around it should be blocked. Gateway administrative authority must itself be tightly controlled because it can become a high-value confused deputy.

17.4 Data-loss prevention

MCP creates structured points where DLP can inspect:

• tool arguments;
• resource requests;
• tool results;
• server and tool provenance;
• target origin;
• user and tenant;
• data classification;
• operation type.

DLP should focus on dataflow, not only regex matches. A private key encoded as base64, split across calls, or transformed by the model is still a secret. Controls may include:

• blocking secret values from model context;
• replacing secrets with broker references;
• restricting which servers can receive confidential data;
• limiting external destinations;
• requiring approval for cross-domain transfer;
• scanning structured and text output;
• tagging retrieved data with provenance and policy;
• verifying that the underlying action matches the approved destination.

17.5 Policy enforcement

A policy decision should receive structured facts, not a vague natural-language summary. A useful input includes:

principal: user / workload / tenant
host: product and installation identity
server: verified identity and assurance level
tool: qualified name and definition hash
operation: read / write / execute / transmit / administer
target: repository, account, path, recipient, cluster, database
arguments: normalized values or security-relevant projection
data: classification and provenance
model: provider and policy tier
context: interactive, background, Task, emergency
approval: required status and approver

The decision can allow, deny, require narrower arguments, request step-up authorization, route to a sandbox, or require human review.

17.6 Separation of duties

High-risk deployments should avoid one agent holding every capability needed to read secrets, change policy, disable audit, and transmit data. Separate:

• data retrieval from external transmission;
• plan generation from execution;
• production read from production write;
• normal operation from identity or permission administration;
• server approval from server publishing;
• catalog management from gateway policy administration;
• tool execution from audit-log deletion.

A second identity or approver may be appropriate for critical operations.

---

18. Observability, audit, and incident response

18.1 What to observe

Protocol logging is not the same as application audit. Current MCP deprecated the earlier core logging feature and documents OpenTelemetry propagation conventions. Operators still need service and security telemetry. (MCP 2026-07-28 key changes [S055])

Record, subject to minimization:

• authenticated principal, workload, tenant, and host;
• server identity, origin, version, package or deployment release;
• protocol revision and extensions;
• tool or resource and definition hash;
• policy and authorization decision;
• scopes and upstream account class, not raw token;
• normalized target and security-relevant arguments;
• confirmation or approver;
• result status and verified side effect;
• latency, resource use, retries, task and handle IDs in protected form;
• network destination and egress decision;
• errors and patch/advisory status;
• definition, package, catalog, and policy changes.

18.2 What not to log by default

Avoid full:

• access and refresh tokens;
• private keys and passwords;
• environment variables;
• model prompts containing sensitive context;
• tool results with personal or confidential data;
• file content;
• OAuth authorization codes and PKCE verifiers;
• task results;
• state handles if logs are broadly readable;
• Authorization headers or credential-bearing URLs.

Use hashes, classifications, sizes, field names, redacted projections, and correlation identifiers where possible.

18.3 Detection opportunities

Alert on:

• new or unapproved server origin;
• server definition drift;
• unexpected package or publisher change;
• a read-only workflow calling write or execute tools;
• cross-server movement of sensitive data;
• tokens presented to the wrong audience;
• repeated OAuth callbacks or issuer mismatches;
• metadata fetches to private or link-local addresses;
• unusual tool-list growth;
• large tool arguments or outputs;
• high-rate task creation, polling, or failed authorization;
• one tenant’s identity appearing with another tenant’s handle or cache key;
• tools invoking new network destinations;
• model-selected recipients or targets differing from user-approved values;
• direct endpoint access bypassing the gateway.

18.4 Incident response

An MCP incident plan should support:

1. identify affected host, server, package, SDK, user, tenant, token, task, and underlying system;
2. stop or quarantine the server and block its package/origin;
3. revoke tokens, client registrations, service accounts, task handles, and sessions in upstream systems where applicable;
4. isolate affected workstations or containers;
5. preserve sanitized logs, definitions, package digests, configs, and process/network evidence;
6. determine whether the incident was protocol handling, SDK, host, server logic, supply chain, authorization, deployment, or prompt injection;
7. inspect downstream effects rather than trusting MCP success/error text;
8. notify affected users and service owners;
9. patch or remove the component;
10. reissue credentials and reapprove only after review;
11. update catalog, detections, threat model, and lessons learned.

A malicious server can act through a trusted upstream service. Incident response must investigate that service’s audit logs as well as MCP logs.

---

19. Secure reference patterns

19.1 Personal local development

For a low-risk local server:

Trusted host
  ├─ approved, pinned local package
  ├─ explicit environment allowlist
  ├─ stdio transport
  ├─ workspace-only filesystem mount
  ├─ no general shell
  ├─ outbound network allowlist
  └─ confirmation for write/transmit/delete

Keep production credentials out of the environment. A disposable development token with narrow scope is preferable to a broad personal token.

19.2 Managed enterprise local server

Use an internal package repository or signed artifact catalog, sandbox, OS policy, short-lived credential broker, centralized host policy, and immutable audit. Project-level configuration can request an approved server but cannot replace its executable or expand its environment without review.

19.3 Single-tenant remote server

A single-tenant service can simplify tenant separation but still needs TLS, authentication, audience validation, scopes, object authorization, egress controls, secret management, input limits, and monitoring. Do not use single tenancy as a reason to share one administrative upstream credential with every user.

19.4 Multi-tenant remote service

A robust topology is:

Client
  ↓ TLS + audience-bound token
Ingress / gateway
  ↓ authenticated immutable request context
Stateless MCP worker
  ↓ per-user or tenant-bound upstream credential
Underlying service

External stores:
- tenant-aware task/state database
- authorization-aware cache
- immutable security audit
- managed secret store

Workers can scale horizontally. State handles identify records; they do not authorize access. No process-global mutable user or transport context is shared.

19.5 High-risk infrastructure control

For cloud, Kubernetes, production database, identity, or payment tools:

• separate planning and execution;
• use read-only discovery first;
• show a normalized plan and target;
• require step-up or two-person approval;
• enforce native RBAC and policy-as-code;
• use temporary credentials;
• restrict command and resource types;
• verify postconditions;
• support rapid cancellation and rollback;
• maintain independent audit.

19.6 Untrusted-content research agent

A research or browser agent processes hostile content by design. Separate retrieval from privileged tools. Use a low-authority subagent or model context to parse untrusted documents, produce structured claims, and pass only validated data to a higher-authority workflow. Do not connect the same context directly to secrets, shell, messaging, and production systems.

---

20. MCP security checklist

Before selecting a server

• Establish the business purpose and minimum capabilities.
• Determine whether local or remote deployment is safer for the data and authority involved.
• Verify publisher, source, package, domain, and artifact provenance.
• Identify official, vendor-supported, community, experimental, or abandoned status.
• Review maintenance history, vulnerability policy, dependencies, and current advisories.
• Document the underlying systems and data classifications reachable by the server.

Before connecting a local server

• Pin version or artifact digest.
• Show and approve the exact command and arguments.
• Prevent untrusted projects from silently changing the command.
• Pass only an explicit environment allowlist.
• Use stdio when a network listener is unnecessary.
• Sandbox filesystem, process, device, and network access.
• Separate read, write, execute, transmit, and admin tools.

Before exposing a remote server

• Confirm whether the endpoint is intentionally public or restricted.
• Use TLS and safe proxy configuration.
• Authenticate every restricted request.
• Implement current protected-resource metadata and authorization-server discovery.
• Require PKCE for public clients.
• Prefer Client ID Metadata Documents or controlled preregistration.
• Include and validate Resource Indicators and token audience.
• Bind issuer and client credentials correctly.
• Prohibit token passthrough.
• Apply tenant-, object-, and operation-level authorization.
• Rate-limit and bound messages, tools, Tasks, and outputs.

Before exposing tools to a model

• Limit tools to those needed for the current task.
• Preserve server and tool provenance.
• Review complete descriptions and schemas.
• Treat annotations as hints, not guarantees.
• Fingerprint definitions and require review on security-relevant changes.
• Prevent cross-server secret and confidential-data flows.
• Require meaningful confirmation for consequential actions.
• Verify effects independently.

During operation

• Maintain identity-, tenant-, tool-, and policy-aware audit.
• Redact tokens, secrets, full sensitive prompts, and results.
• Monitor definition, package, origin, and scope drift.
• Patch SDK, host, server, registry, gateway, and dependencies separately.
• Test concurrency and tenant isolation.
• Reauthorize explicit state handles and Tasks.
• Respect private cache scope and authorization-aware keys.
• Maintain revocation, cancellation, rollback, and incident procedures.

On removal

• Stop processes and remote connections.
• Revoke tokens, credentials, registrations, tasks, and handles.
• Remove catalog and project configuration.
• delete or retain cached data and logs according to policy.
• Verify no upstream service account or webhook remains active.
• Record why the server was removed and whether users need notification.

---

21. Myths versus evidence

“MCP is secure because it uses OAuth.”

OAuth supplies an authorization framework. A deployment can still mishandle client registration, callbacks, issuer, token audience, consent, scopes, tenant authorization, or upstream delegation.

“MCP is insecure because it uses OAuth.”

OAuth is not the cause of every implementation failure. PKCE, audience-bound tokens, protected-resource metadata, and issuer validation are important defenses. Static API keys usually provide less context, shorter lifetimes, or user consent—not more.

“Every MCP server requires OAuth.”

Authorization is optional in the protocol. Current HTTP deployments supporting authorization should use the profile. stdio should not implement that browser-oriented flow. A deliberately public read-only server and a private financial server have different requirements.

“stdio is unsafe.”

stdio avoids a listening network endpoint. The danger is running untrusted code or giving it broad local authority. Use package provenance, configuration trust, environment minimization, and sandboxing.

“localhost is safe.”

Unauthenticated localhost HTTP services can be exposed through DNS rebinding and local malware. Use stdio when possible or apply authentication and Host validation.

“A read-only annotation guarantees no side effects.”

Annotations are hints. Enforce read-only behavior through code, upstream credentials, database roles, and policy.

“A confirmation dialog prevents malicious actions.”

A dialog is meaningful only if it shows the real server, account, target, arguments, data leaving the system, and effect. Hidden arguments or misleading metadata defeat superficial consent.

“The official registry certifies security.”

A registry helps with metadata and namespaces. It does not prove that code, dependencies, deployment, permissions, or behavior are secure.

“Open source means safe.”

Open source permits review. It does not prove review occurred, the distributed artifact matches source, dependencies are safe, or the operator deployed it securely.

“Prompt injection is an MCP parser bug.”

It is generally a model/host/data interaction. Valid protocol messages can carry hostile natural language. The defense is provenance, constrained authority, dataflow policy, meaningful approval, and postcondition verification.

“Current MCP is stateful.”

The current core removed protocol sessions and initialization. Earlier revisions were stateful.

“Current MCP cannot retain state.”

Applications retain state through handles, Tasks, databases, upstream jobs, and caches. Those objects need explicit authorization.

“The NSA report describes the current wire protocol exactly.”

It was published before 2026-07-28 final. Its durable security principles remain useful, but session-specific discussion must be labeled historical.

“Forty percent of every MCP server is unauthenticated.”

One study reported 40.55% among its discovered live remote-server population. The result does not describe local servers or every deployment.

“Every OAuth server was vulnerable.”

The same study identified flaws in each of 119 testable servers, not in every OAuth server it discovered.

“A gateway solves MCP security.”

A gateway can enforce identity, routing, allowlists, DLP, limits, and audit. It cannot repair unsafe server code, malicious data, or broad upstream permissions by itself.

The complete 35-item myth register accompanies this article as CSV, JSON, and Markdown.

---

22. Frequently asked questions

These 50 concise answers are visible reader guidance. Their presence does not imply eligibility for search-result enhancements.

23. Conclusion

MCP did not create the underlying risks of executing third-party software, authorizing distributed services, processing hostile content, or exposing APIs to clients. It combined those risks at a reusable boundary intended for AI applications. That boundary can be valuable because it makes capabilities, identities, transports, and calls visible enough to govern. It can be dangerous because one host can compose many servers and let a probabilistic model route data and authority among them.

The history supports three conclusions.

First, MCP security changed as the deployment model changed. Launch-era local subprocesses depended on package and workstation trust. Remote expansion required OAuth, audience restriction, metadata discovery, and tenant separation. The current stateless protocol removes hidden session state but introduces explicit handles, routing headers, cache scopes, MRTR, Apps, and Tasks that need their own controls.

Second, the ecosystem’s incidents belong to different layers. A protocol history that calls every Inspector, SDK, package, server, registry, or OAuth implementation defect “an MCP flaw” is not useful to engineers. Classification determines mitigation.

Third, natural-language capability systems require controls outside the model. Tool descriptions, resources, results, and user content can carry attacker instructions. Detection helps, but least privilege, isolation, provenance, policy, meaningful consent, and independently verified effects remain necessary when the model does the wrong thing.

The most defensible security principle is:

Never let the fact that a capability arrived through MCP substitute for proof that the code is trusted, the caller is authorized, the data flow is permitted, and the effect is intended.

---

Update log

• August 25, 2026: Initial package-backed publication against MCP 2026-07-28; protocol, authorization, major cited advisory, NSA, OWASP, and empirical-study sources were re-opened; two NVD citation targets were normalized to package-manifested GitHub advisories; the vulnerability dataset was sorted chronologically; and incomplete transfer artifacts were disclosed. All affected/fixed versions and live ecosystem facts remain live-check required.

Sources and methodology

Browse the unified evidence library and editorial policy for canonical source IDs, durability labels, correction handling, and update rules.

This article prioritizes versioned MCP specifications and official project guidance, formal OAuth standards, government guidance, original vendor advisories and CVE records, original security disclosures, and peer-reviewed or primary research. Current implementation status, affected versions, fixed versions, registry behavior, roadmap items, and protocol guidance are marked for live verification.

The transferred research package directly supplies the article in Markdown and HTML, a 96-source evidence manifest in CSV and JSON, a source bibliography, a 98-claim CSV, a 48-record vulnerability timeline in CSV and Markdown, a 50-question FAQ, 15 visual briefs, a 71-record content cluster, an SEO package, and a README.

The public integration manifest accounts for all 13 supplied artifacts. It also discloses that the README-referenced methodology, quality-audit, checksum, generation, and additional standalone matrix/register artifacts were not included in the transfer; the site does not present those absent files as recovered or verified.