AI Security Best Practices for MCP Deployments

A REST API waits. It takes a request, checks it, hands back data, and the conversation ends there; the threat model behind that pattern is decades old and the tooling that defends it is mature. MCP doesn't work that way. An MCP server acts on the client's behalf: it fetches context, invokes tools, and feeds new instructions back into the model's next decision, all without a human reviewing each step. NSA's May 2026 security guidance calls this inversion out directly, and it warns that it creates attack paths which remain largely untraced compared to conventional API threat models. The protocol trusts the server to act on its own and trusts the client to accept whatever comes back, and nearly every major attack class documented in 2026 traces back to that single design default.

That inversion plays out differently depending on where the server lives. Local STDIO servers execute operating system commands directly on the machine they run on, but remote HTTP servers run on infrastructure the operator doesn't control. Red Hat's Principal Product Security Architect Florencio Cano Gabarda draws that line sharply: many of the risks common to local servers simply don't apply to remote ones, and vice versa. The controls a team applies have to differ by transport type. If a security posture only checks requests at the door, it misses this. That gap is the starting point for everything that follows.

The 2026 threat taxonomy: six attack classes that define the MCP risk surface

The inversion above produces a specific, documented set of attack classes, and none of them map cleanly onto the threat taxonomies security teams already use for APIs or for LLMs on their own. Matching a control to a threat requires understanding the mechanics of each one first.

Tool poisoning works by exploiting the trust an agent places in a tool's own description. The agent reads that description with the same confidence it gives its own system prompt, so a malicious server can hide commands inside the text, prompting the model to read files or leak secrets while still returning an answer that looks completely normal to the user. Invariant Labs first documented the technique in April 2025, and it now sits as MCP03 on the OWASP MCP Top 10. Microsoft's Incident Response and Defender research teams disclosed a case in mid-2026 that shows how this plays out inside a real enterprise: a finance agent was connected to a third-party invoice enrichment tool that had been approved but never given a genuine security review. An attacker altered the tool's hidden description to exfiltrate unpaid invoices, and because MCP picks up description changes automatically, the poisoned version went live with no re-approval trigger at all.

Unauthenticated servers make up a second class, and the scale is large. Scans run by Wiz, Bloomberry, and Censys in 2026 found a substantial share of MCP servers operating with no authentication at all, and Trend Micro counted 492 such servers exposed directly to the open internet. Two CVEs illustrate the consequence. CVE-2026-32211, carrying a CVSS score of 9.1, let an unauthenticated attacker disclose information over a network with no valid credentials. CVE-2026-33032, scored 9.8, hit nginx-ui: the MCP message endpoint failed to authenticate command execution requests, handing attackers complete takeover of the nginx service, with more than 2,600 publicly exposed instances potentially at risk.

A third class lives inside the SDKs themselves, not in any individual deployment. OX Security's research, titled "The Mother of All AI Supply Chains," found a command execution flaw built into Anthropic's official MCP SDKs for Python, TypeScript, Java, and Rust. The STDIO transport passes configuration parameters straight to the host operating system's shell without sanitizing or validating them, so any process command handed to the interface runs on the host machine, whether or not it actually initializes a valid MCP server. This isn't a bug introduced by careless configuration. It ships as a design default in every project that imports the SDK, and Anthropic confirmed the behavior is intentional: the company declined to change the protocol architecture and left remediation to individual developers. An attacker who can influence a configuration file, whether through a compromised repository, a poisoned package registry entry, or straightforward social engineering, gets arbitrary code execution out of it. Check Point Research demonstrated exactly this in Claude Code, using poisoned .claude/settings.json hooks and .mcp.json repository config files, bypassing MCP consent through settings parameters like enableAllProjectMcpServers and enabledMcpjsonServers that could auto-approve every MCP server on launch.

Session hijacking forms a fourth class, occurring at the SDK level. Two separate CVEs disclosed in 2026 trace back to the same root cause: a session identifier that is never bound to the identity that actually owns it. Because the flaw sits in the SDK itself, it ships automatically into every project that imports the vulnerable version, turning what used to be a deployment mistake into a supply-chain problem.

Prompt injection, ranked MCP06 on the OWASP MCP Top 10, makes up a fifth class: instructions hidden inside external content execute as though the user had typed them directly. Tenet Security's research on "agentjacking," a technique that exploits Sentry's MCP architecture, found it bypassed explicit anti-injection instructions in the large majority of cases tested. HackerOne recorded a large surge in prompt-injection reports over 2025.

The sixth class covers the supply chain more broadly: rug pulls, typosquatting, and cross-server cascade. A rug pull happens when a tool's description or behavior changes silently after it has already been approved, exploiting the fact that tool definitions get reviewed once at connection time while tool responses flow continuously into the agent's context with no equivalent ongoing scrutiny. With typosquatting and tool name collisions, attackers register servers with names close enough to legitimate ones that the LLM picks the wrong tool. Antiy CERT confirmed thousands of malicious skills circulating across ClawHub, the marketplace built around the OpenClaw AI agent framework. Practical DevSecOps reports a high cascade rate once one MCP server in a connected set is compromised, so a single breach rarely stays contained to a single server. These are not theoretical categories: the compromises researchers have tracked in environments like Amazon Q and across ClawHub's marketplace are production incidents, not lab demonstrations.

The governance gap and its danger alongside the technical vulnerabilities

The vulnerabilities above are well documented, yet most organizations remain exposed to them, and the reason has little to do with the availability of controls. The most dangerous condition in MCP deployments right now is the combination of fast deployment and near-absent governance: organizations are shipping agents into production without the visibility or accountability structures needed to detect a compromise, let alone contain one.

The numbers make the gap concrete. Only roughly 23% of organizations have a formal AI-agent identity strategy in place, and only a small fraction of agents that reach production do so with full security approval. That gap appears operationally as shadow MCP. A developer can stand up an MCP server against a production database in an afternoon, and once an agent discovers that server, its tools become part of the agent's available action surface with no security team ever seeing it happen. It's the MCP equivalent of shadow IT, except it scales faster, because an agent can discover and adopt new tools automatically in a way a human IT department never could.

Regulatory and compliance frameworks are catching up to this gap faster than most security teams are closing it. Teams treating MCP governance as something to "add later" are already behind both curves at once: the regulatory one and the incident one. The technical controls described in the rest of this piece only work if an organization also knows which servers exist, who approved them, and who is watching what they do once they're running. Without that structure, patching a CVE in one server does nothing to stop the next unreviewed server from opening the same hole somewhere else.

Authentication controls: closing the largest single gap in MCP deployments

Enforcing OAuth 2.1 correctly, including the hardening introduced in the July 2026 spec revision, closes the authentication gap that a large share of live MCP servers currently leave wide open, though doing it right takes deliberate configuration choices that the spec itself doesn't make automatically. The modern MCP specification treats MCP servers as OAuth 2.1 resource servers and MCP hosts as OAuth clients acting on behalf of the user, and it calls for a valid OAuth access token on any request made over HTTP-based transports. STDIO transports work differently: they're not meant to follow the OAuth spec at all, and should instead pull credentials straight from the environment they run in.

The trouble is that authorization remains optional under current MCP implementations, and that optionality is the actual problem, not a minor footnote to it. Independent research found that only 8.5% of MCP servers use OAuth. Most of the unauthenticated servers Trend Micro, Wiz, Bloomberry, and Censys found sitting exposed on the open internet exist because teams treated OAuth as something to bolt on eventually rather than a baseline requirement from day one.

The July 28, 2026 spec revision, labeled MCP 2026-07-28, closes several of the gaps that made earlier OAuth implementations easier to exploit, and teams running MCP servers should apply these changes immediately. Authorization responses now carry a validated issuer claim under RFC 9207. The client has to compare the returned iss parameter against the issuer it recorded before the redirect happened, and refuse to proceed if the two don't match. That single check closes an entire class of token-injection attacks. Client ID Metadata Documents, known as CIMD, replace Dynamic Client Registration entirely: a client's client_id becomes an HTTPS URL that the authorization server fetches and validates on its own, with no pre-registration step required and no way for an attacker to impersonate a client simply by registering a lookalike name.

The spec is also explicit about where tokens are allowed to travel. MCP clients must not send tokens to an MCP server other than the ones issued by that server's own authorization server, and MCP servers must only accept tokens valid for their own resources. Token passthrough to a different service is an anti-pattern the spec forbids outright, because it's exactly the kind of shortcut that turns one compromised token into access across an entire chain of connected servers. For autonomous agents operating without a human in the loop, the specification now supports signed JWT assertions under RFC 7523: the client signs a short-lived JWT using its own private key, naming itself in the iss and sub fields and naming the token endpoint in aud, and the authorization server checks that signature against the public key it has on file. The private key never leaves the client, and the assertion itself expires within minutes, so it doesn't sit around indefinitely in a configuration file waiting to be stolen. PKCE, Proof Key for Code Exchange, is mandatory across these flows, and it closes off the interception attacks that plain authorization-code exchanges have long been vulnerable to.

None of this happens automatically just because a team upgrades to the latest spec version. Every one of these protections, the issuer check, the CIMD validation, the token scope restriction, the JWT assertion flow, has to be configured deliberately by the team running the server, and the spec revision only works as a floor, not a guarantee. Only 8.5% of MCP servers currently use OAuth at all, so the gap between what the spec now makes possible and what most deployments actually enforce remains the single largest opening in the MCP threat surface.