The TL;DR
Three government security documents and a new MCP specification arrived within weeks of each other in 2026. Teams running MCP in production now have a clear security checklist that external auditors, customers, and regulators can hold them to.
-
• No Reason to Wait
Closing the security gap does not depend on waiting for the July 28 MCP specification. Most NSA recommendations are established security practices, including strong authentication, least-privilege access, secure credential handling, detailed logging, and continuous monitoring.
-
• The Trigger
The NSA advisory, CISA’s joint agentic AI guidance, and the MCP specification’s largest security rewrite arrived within days of one another. Each addresses the same long-standing weakness: authentication and authorization have often been treated as optional parts of MCP deployments.
-
• Not Hypothetical
Researchers had already demonstrated exploitable security weaknesses in production MCP tools months before the new documents were published. The guidance responds to risks already observed in real deployments, not merely theoretical attack scenarios.
MCP has never required authentication. For nearly eighteen months, many production teams left it off because the protocol did not force them to add it.
That changed when a joint advisory from six cyber agencies, an NSA technical assessment, and a major MCP spec update arrived within weeks of each other. Together, they set a clearer baseline for identity, OAuth, sessions, authorization, logging, and tool access.
The guidance followed real incidents. Researchers had already shown that weak MCP controls could expose private repository data, leak WhatsApp history through a malicious server, and enable remote code execution through an MCP debugging tool.
The practical takeaway is simple: MCP security is now more than an implementation choice. Customers, auditors, insurers, and security teams can ask whether your deployment authenticates clients, limits tool access, protects tokens, logs actions, and isolates compromised servers.
Teams should not wait for the next spec release. The priority is to replace trust-by-default with enforceable controls now.
Three Security Releases That Changed MCP in 2026
Three separate publications, three different authors, one closing window. Here’s how they line up.
Timeline of the 2026 MCP Security Updates
CISA, the NSA, and cyber agencies from Australia, Canada, New Zealand, and the UK published Careful Adoption of Agentic AI Services on May 1, 2026, the first coordinated multinational guidance aimed specifically at agentic AI systems. Nineteen days later, the NSA’s Artificial Intelligence Security Center followed with a document narrower in scope but sharper in detail: Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation names specific gaps and specific fixes. One day after that, the MCP 2026-07-28 release candidate went public, the largest revision to the protocol since Anthropic open sourced it in November 2024.
Why the Timing Matters
The NSA’s framing explains why three documents in three weeks is more than a coincidence. MCP inverts a pattern security teams have spent two decades hardening. In a typical client-server setup, clients ask servers for data. In MCP, servers often query and execute actions on behalf of connected clients, so the attack paths security teams know how to trace don’t map cleanly onto how MCP actually moves data. The NSA states the consequence plainly: MCP’s proliferation has outpaced the development of its security model.
The Scale Behind the Urgency
According to Anthropic’s own December 2025 ecosystem update, more than 10,000 active public MCP servers were running by the time Anthropic donated the protocol to the Linux Foundation’s Agentic AI Foundation, with over 97 million monthly SDK downloads. This is infrastructure sitting in front of finance, legal, and healthcare workflows now, exactly the deployment pattern the NSA’s advisory calls out by name. Scale is why this stopped being a niche developer concern.
NSA and the Five Eyes coalition agree on the diagnosis. Where they differ is scope, and that split is worth understanding before touching a single config file.
NSA-Identified Security Gaps in MCP
The NSA’s advisory does not treat MCP as broken by accident. It treats the gaps as structural, The NSA’s advisory doesn’t treat MCP as broken by accident. It treats the gaps as structural, meaning they can’t be patched at a single endpoint. Seven problem areas do most of the damage.
- Access control has no floor: Associating a session with an identity is optional, left entirely to whoever implements the server. Many implementations skip authentication outright, and the ones that add it rarely distinguish between read, write, and delete permissions the way a database interface would. MCP also has no built-in way to exchange role-based access control permissions at connection time.
- Token and session security has no lifecycle: MCP servers commonly rely on OAuth-style bearer tokens, but the core specification doesn’t mandate refresh, revocation, or reuse control. A hijacked session can be replayed without the protocol itself noticing.
- Approval workflows can drift silently: A user might approve an MCP server once, then have that server’s capabilities or data access expand later without triggering a new consent prompt. A previously vetted, benign integration can turn into something that reaches sensitive resources on demand, with the end user none the wiser.
- Serialization is wide open: MCP passes structured objects through mechanisms that often skip schema validation, which opens a path for injection whenever the payload includes executable code or embedded model calls.
- Logging is inconsistent to nonexistent: The spec gives basic logging guidance but leaves comprehensive audit requirements to the implementer, so many deployments log little beyond minimal operational metadata. That becomes a real problem the moment an incident needs a forensic trail.
- Misconfiguration compounds fast: Open source MCP frameworks make it trivial to deploy a server without understanding what it’s actually exposed to. NSA’s own example: a weather lookup server later repurposed to touch location-linked user data, because MCP provides no built-in task or data isolation to stop that kind of scope creep.
- Denial of service is an open door: Prompt storms, malformed inputs, and recursive task requests can exhaust an MCP server. These patterns are hard to distinguish from legitimate high load, which slows detection.
Every one of those seven gaps sits inside the protocol itself. The Five Eyes guidance picks up where NSA’s MCP-specific list stops, and looks at what happens once agents built on protocols like this start acting autonomously.
Five AI Security Risks Highlighted by CISA
Where the NSA’s advisory is MCP-specific, the Five Eyes guidance zooms out to agentic AI generally, and MCP sits squarely inside its scope as the connective layer most agents now depend on.
- Privilege risk: Agentic systems tend to aggregate permissions across many tools and environments, so one compromised agent can reach far more than a single compromised service normally would.
- Design and configuration risk: Static access controls that were fine for a fixed integration break down against dynamic, tool-discovering agent workflows, leaving stale permissions an attacker can walk through.
- Behavioral risk: Agents can be manipulated through prompt injection or data poisoning into pursuing goals in ways their designers never intended.
- Structural risk: Networks of interconnected agents can cascade a single failure across the whole system. Most organizations lack the network isolation to contain that blast radius.
- Accountability risk: Autonomous, high-volume decision-making makes it hard to trace who authorized an action or reconstruct what an agent actually did. The same missing audit trail NSA flags for MCP shows up here too.
The guidance’s operating instruction is direct: treat autonomous agents as untrusted until proven otherwise, and prioritize resilience and containment over speed of rollout. It also pushes toward cryptographically anchored agent identity with short-lived, just-in-time credentials, a stronger requirement than most enterprise identity stacks currently support for non-human actors.
The new spec doesn’t make any of this easier. If anything, it gets more explicit about whose job each piece is.
What Changed in the July 2026 MCP Security Spec
The 2026-07-28 release candidate is the biggest MCP has shipped, and part of it directly answers the NSA’s complaints. The rest leaves the same gaps in place, just relocated.
Security Improvements in the New MCP Spec
- Sessions disappear entirely: MCP moves to a fully stateless protocol core. The
initializehandshake and theMcp-Session-Idheader are both gone. That means the class of attack built around hijacking or replaying a pinned session no longer has a session to hijack at the protocol layer. - OAuth gets six SEPs of hardening: Clients must now validate the
issparameter on authorization responses per RFC 9207. OpenID Connectapplication_typegets declared during Dynamic Client Registration, which closes a common redirect URI rejection bug that used to push developers toward workarounds. Registered credentials also bind to the issuing authorization server. Together these move MCP’s OAuth story closer to how OAuth 2.1 and OpenID Connect actually get deployed in production elsewhere, the same direction our breakdown of MCP versus CLI-based tool access flagged as the dividing line between personal automation and anything touching another user’s data.
Security Gaps the New MCP Spec Does Not Address
- State just moves, it doesn’t disappear: Removing the protocol-level session doesn’t remove state, it just makes state explicit. Servers that need to track something across calls now mint a handle, like a
basket_id, and pass it back through ordinary tool arguments. That’s a cleaner pattern architecturally, but it puts scoping and validation of that handle back on the implementer. Same NSA complaint about parameter validation, restated in a new shape. - Message signing and RBAC are still missing: Per the MCP authorization specification itself, “authorization is OPTIONAL for MCP implementations.” Message signing and a standardized RBAC exchange are still absent from the core spec. Nothing in this release adds them.
- Protocol-level logging is going away: Roots, Sampling, and Logging are formally deprecated in favor of tool parameters, direct LLM provider integration, and OpenTelemetry. Protocol-level logging support is disappearing right as the NSA is telling organizations to log everything.
- MCP Apps get sandboxing, but only MCP Apps: The spec also formalizes MCP Apps, server-rendered interfaces that run inside a sandboxed iframe with every UI action routed through the same audit and consent path as a direct tool call. Anthropic and OpenAI’s own MCP Apps announcement confirms the sandboxing is real, but it only covers one extension, not the protocol as a whole.
MCP Spec Release Timeline
The release candidate locked on May 21, 2026, and the final specification ships July 28, a ten-week validation window for implementers to catch breaking changes before the spec locks for good. We’re about six and a half weeks into that window as of this writing, which leaves roughly three weeks to finish testing.
A spec revision reads abstract until you see what it would have stopped. The next three incidents show exactly that.
Real MCP Security Incidents Behind the New Guidance
The NSA’s advisory cites specific, disclosed incidents rather than hypotheticals, and each one maps to one of the gaps above.
GitHub MCP Prompt Injection Incident
In May 2025, Invariant Labs demonstrated that the official GitHub MCP server could be hijacked through a single malicious public GitHub issue. A user asking their agent to check open issues on a public repository was enough to trigger a prompt injection that pulled private repository data into context and leaked it into a public pull request, including salary information and personal relocation plans in the researchers’ test case. GitHub’s server code wasn’t at fault. The architecture that let one agent hold blanket access across public and private repositories was.
WhatsApp MCP Data Exfiltration Incident
About seven weeks earlier, the same team showed that a malicious MCP server connected to the same agent as a trusted WhatsApp MCP server could exfiltrate a user’s entire message history. The attack never called the WhatsApp server directly, and the user never approved anything that looked suspicious. It worked because MCP places no boundary between tool descriptions from different servers once they share an agent’s context.
MCP Inspector Remote Code Execution (CVE-2025-49596)
In June 2025, Oligo Security disclosed CVE-2025-49596, a critical remote code execution flaw (CVSS 9.4) in MCP Inspector, the official tool developers use to debug MCP servers. The proxy server accepted unauthenticated requests by default, so a victim visiting a malicious website could trigger arbitrary code execution on their own machine through a DNS rebinding chain. Anthropic shipped a fix in version 0.14.1, adding session tokens and origin validation that should have been there from the start.
OWASP MCP Top 10 Security Risks
The OWASP MCP Top 10 project has since organized this pattern into a structured framework covering token mismanagement, permission scope creep, tool poisoning, software supply chain attacks, command injection, insufficient authentication, shadow MCP servers running outside governance, and context over-sharing between tasks or users. Every category traces back to one of the same protocol gaps the NSA names directly.
Each entry above was written because something on this list already happened. The checklist below exists to stop the next one.
MCP Security Hardening Checklist
The NSA’s advisory closes with nine recommendations. Every one of them can start now, most through standard software practices rather than protocol changes, with nothing waiting on July 28.
| NSA Recommendation | What It Actually Means |
|---|---|
| Choose supported MCP projects | Confirm that the server is actively maintained before deployment. Audit it at your strictest security tier, just as you would any new production dependency. |
| Design for trust boundaries | Separate MCP components into distinct trust zones. Route external traffic through a filtering proxy, gateway, or DLP system before it reaches a privileged model or internal tool. |
| Validate every parameter | Validate inputs against approved schemas, ranges, formats, and request context, not only data type. Reject any parameter whose source or purpose cannot be verified. |
| Sandbox tool execution | Treat every tool call as potentially high risk. Isolate execution with seccomp, AppArmor, SELinux, containers, or an equivalent control, and deny all access the tool does not explicitly require. |
| Sign and verify messages | Do not rely on TLS alone. Add cryptographic message signatures, expiration timestamps, nonce validation, and replay protection so individual requests can be verified. |
| Treat outputs as untrusted | Inspect and validate tool outputs before they are passed into another model, workflow, or tool. Output from a trusted server is not automatically safe input for the next step. |
| Log everything centrally | Record every tool invocation with the caller identity, parameters, result status, timestamps, and result hashes. Send those records to your existing SIEM rather than keeping isolated local logs. |
| Track and patch continuously | Maintain an inventory of every MCP server and client, including owners, versions, dependencies, and update history. Monitor CVE databases and vendor security feeds for each component. |
| Scan for shadow servers | Regularly scan your network for unauthorized or unmanaged MCP servers. Tools such as MCP Scanner, Ramparts, CyberMCP, and Proximity can help identify unknown deployments. |
How an MCP Gateway Improves Security
A few of these recommendations are architectural decisions as much as configuration changes. Centralizing MCP access through a single gateway, rather than letting every team stand up its own server connections, turns scoped per-tool authentication and centralized audit logging into properties of the gateway itself instead of something every integration has to reimplement. MCP360 runs OAuth 2.0 and API key authentication with audit logs and rate limiting for that reason, and holds SOC 2 Type II, ISO 27001, and GDPR compliance as of this writing. That covers the access control and logging rows above.
A gateway doesn’t replace parameter validation, sandboxing, or the network scanning NSA recommends. Those stay the responsibility of whatever runs on top of it. For an individual developer juggling MCP configs across Claude Desktop, Cursor, and other local clients, an open source tool like mTarsier centralizes that view and cuts down on config drift. It’s worth pairing with an organization-wide inventory process, not substituting for one; mTarsier manages what’s installed on a single machine, which is a different job from tracking every server version across a fleet.
Frequently Asked Questions
What is MCP security?
MCP security covers the authentication, authorization, and monitoring controls that protect Model Context Protocol deployments. MCP itself treats most of these as optional. NSA’s May 2026 advisory and the Five Eyes guidance now treat closing that gap as the baseline, regardless of what the spec requires.
What are the biggest MCP security risks?
The biggest risks are missing authentication, unrestricted tool access, and unvalidated data passing between servers. Since the protocol never requires identity verification, a compromised server can reach whatever data the connected agent touches. Prompt injection, session hijacking, and inconsistent logging round out the list.
Does the new MCP spec fix authentication?
No. The MCP 2026-07-28 spec hardens OAuth 2.1 and removes protocol-level sessions, closing one class of session hijacking risk, but authentication still isn’t mandatory. Message signing and RBAC are also still missing. Closing those gaps stays implementation work, which is what NSA’s checklist addresses.
What does NSA’s MCP advisory actually require organizations to do?
NSA’s advisory closes with nine recommendations, not a mandate. Use maintained MCP projects, define trust boundaries, validate parameters, sandbox execution, sign messages, treat outputs as untrusted, centralize logging, patch known vulnerabilities, and scan for shadow servers. None of it waits on the July 28 spec.
What real MCP security incidents happened before this guidance?
Three disclosed incidents drove this guidance. In 2025, a public GitHub issue hijacked an agent into leaking private repo data, a malicious MCP server exfiltrated someone’s WhatsApp history without touching its encryption, and MCP’s own debugging tool carried an RCE flaw with a 9.4 CVSS score.
How can a gateway help close MCP security gaps?
Centralizing MCP access through a gateway turns per-tool authentication and audit logging into properties of the gateway, not something every team builds separately. MCP360, for example, runs OAuth 2.0 and API key authentication with audit logs, covering NSA’s access control and logging recommendations. It doesn’t replace sandboxing or parameter validation.
Will this MCP security guidance show up in vendor security questionnaires?
Likely yes, and soon. Once an agency names specific CVEs and publishes a detailed checklist, it becomes what security teams check vendors against. A gateway with compliance certifications already in place gives a documented starting point instead of a blank page. MCP360, for instance, already holds SOC 2 Type II, ISO 27001, and GDPR compliance.
How do teams keep an inventory of their MCP servers?
NSA treats server inventory as a baseline control, not an advanced one. Keeping a current list of every MCP server and client, with version history, is what makes patch tracking and shadow server detection possible. mTarsier, an open source manager built by the MCP360 team, handles that inventory across multiple clients.
Conclusion
Every fast-growing protocol eventually reaches a point where adoption moves faster than security. MCP has now reached that stage.
The July 28 specification improves session handling and OAuth, but mandatory authentication, message signing, and standardized RBAC still sit outside the core protocol. Because NSA and CISA have now identified these gaps publicly, customers, auditors, insurers, and security teams have a clear basis for reviewing how production deployments handle them.
Teams should not wait for another specification update. Review every MCP server and client, verify identities, restrict tool permissions, validate inputs and outputs, centralize logs, and isolate tool execution from sensitive systems. Any protection the protocol does not provide must be enforced at the gateway, infrastructure, or application layer.
The real question is not whether your deployment follows the MCP specification. It is whether it meets the security standard now expected in production.
Find the gap before an audit, customer review, insurance assessment, or incident finds it for you.
Article by
MitaliAI & Automation | Content Writer
Mitali is a content writer covering AI agents, automation, and no-code tools. Her writing spans the AI landscape, from support and sales automation to MCP integrations and agent workflows, with a focus on practical business use.
