The NSA says MCP proliferation has outpaced security

Every decade or so, a federal agency publishes a document that redraws the boundary between “early adopter” and “production.” NIST SP 800-63 addressed it in the context of digital identity. The CISA SBOM guidance did it for the software supply chain. The NSA’s Artificial Intelligence Security Center has now done the same for agentic AI by releasing its new Cybersecurity Information Sheet on the Model Context Protocol.

The headline here is that MCP is secure, but the Information Sheet emphasizes that MCP, as a specification, was never going to be secure on its own. The NSA’s framing is precise: “MCP’s rapid proliferation has outpaced the development of its security model. Much like early web protocols, MCP was released with a flexible and underspecified design, allowing implementers freedom of design but also introducing ambiguity for safe usage.”

Anyone who lived through the SOAP-to-REST transition, the early days of OAuth, or the first wave of Kubernetes recognizes the pattern. A useful protocol ships, then vendors implement it poorly. A standard execution layer later emerges to clean up the mess. That layer becomes the category.

The need for an actions runtime

Securing MCP cannot be patched at the endpoint, the protocol, or the model. It requires a single enforcement point that sits architecturally separate from the MCP servers and the LLM: a layer that brokers identity, mediates every tool call, codifies approval, and produces a single audit trail. That layer is what the industry has been missing. It is what we call an actions runtime.

Arcade.dev has been building that runtime for the last two years to deliver secure authorization and policy enforcement, reliable tool execution, and centralized governance for multi-user AI agents.

Translating the NSA’s 10 claims

Strip away the agency formalities, and the report makes 10 claims. They are worth reading in the NSA’s own language, with a simpler translation on each.

Access control is undefined. “Associating a session to an identity is not defined by the protocol… MCP currently lacks support for exchanging Role-Based Access Control (RBAC) permissions at instantiation.” Translation: every MCP server picks its own answer to “who is allowed to do what,” and most of them don’t pick anything at all.

Serialization is dangerous. Structured objects are passed through mechanisms that “often lack strict validation or schema enforcement,” echoing the OWASP A8:2017 Insecure Deserialization class of risk. Translation: the protocol passes blobs that the LLM may interpret as instructions, with no required schema check between them and the execution environment.

Approval workflows are weak. “A change in capability or data access… often can be made without approval. End users are often kept unaware of these changes, whether malicious or benevolent.” Translation: consent at install, drift in production.

Token and session lifecycle is the implementer’s problem. The spec relies on OAuth 2.1 bearer tokens “without specifying protocol-level token lifecycle management (i.e., refresh, revocation, and reuse control).” Translation: every MCP server author is writing identity infrastructure, and most of them shouldn’t be.

Misconfiguration is the default. Open-source frameworks let developers “rapidly deploy MCP servers without fully understanding the security implications.” Translation: the median community server ships without auth, validation, or audit, and gets repurposed against sensitive data anyway. See the Arcade State of MCP Report.

Behavior is non-deterministic. Two MCP-enabled agents can interpret the same prompt differently based on prior context, and “this divergence… can be exploited by a malicious actor who preconditions the agent to arrive at a specific or unsafe outcome.” Translation: probabilistic interpretation is now a vulnerability class.

Audit logging is minimal or absent. “Many implementations either omit logging entirely or record only minimal operational metadata.” Translation: when something goes wrong, you can’t answer “which agent did what on whose behalf?”

DoS and fatigue techniques work. Prompt storms, recursive task requests, and “lethargy” exploitation are hard to distinguish from valid high load. Translation: agents make resource exhaustion easier, not harder.

Real exploits already exist. The report cites a long list of named, demonstrated attacks, including:

Translation: this is no longer hypothetical.

This cannot be patched at the endpoint. “Securing MCP systems requires treating the agentic environment as a continuum, where misaligned assumptions or subtle inconsistencies at any stage can propagate and compound into exploitable conditions.” Translation: you need a runtime.

Authorization, reliable execution, and governance

Arcade has organized its product around the three simultaneous requirements that the NSA report makes the case for, one section at a time: authorization at runtime, reliable execution, and a centralized control plane for governance and observability.

Authorization at runtime: the NSA’s access control, token lifecycle, and approval workflow gaps

The NSA’s first three concerns (undefined access control, ungoverned token lifecycle, and weak approval workflows) collapse into one architectural question: where does the user’s identity meet the agent’s action? In raw MCP, the answer is “nowhere consistent.” In Arcade, the answer is the runtime.

Arcade provides just-in-time delegated OAuth. The user authenticates first, authorization happens at the moment of action, and the scope is exactly what the action requires. No blanket consent that accumulates drift over time. Credentials are isolated from the LLM. Tokens are brokered, refreshed, rotated, and revoked by Arcade, not by the MCP server author. Every tool call enforces the intersection of what the agent is allowed to do and what the user is allowed to do. That is runtime RBAC, exactly the property the NSA says MCP cannot provide at the protocol level.

The deeper point is what this means for the customer’s engineering organization. Nobody on the customer side rewrites identity infrastructure per tool. No DIY token refresh, per-server OAuth client, or bespoke session handling. Arcade handles the entire identity surface once, across every tool. Engineering teams ship agents instead of rebuilding Okta inside thirty different MCP servers.

This directly addresses the GitHub MCP exemplar that the NSA cites. In the unrestricted server, a user grants blanket repo access; a compromised tool then reads private code and writes it to public repos. Arcade’s delegated model scopes every action to the specific operation requested, gated by the user’s existing entitlements in Okta, Ping, Entra, SailPoint, or Saviynt. The blanket-scope abuse pattern goes away by construction.

Reliable tools: the NSA’s misconfiguration, serialization, parameter injection, and path-confusion gaps

The NSA’s “misconfigurations and poor implementation” section is, when read closely, an indictment of community MCP server quality. The exploited examples reinforce it: tool parameter injection in open agents, tool invocation path confusion through name collisions, and the MCP Inspector RCE.

Arcade ships 7,500+ managed tools across 81 toolkits, each hardened, validated, retry-aware, and tested against evals. Tools are built around intent, not API structure. When the LLM is asked to “make the intro paragraph friendlier,” the tool resolves the segment ID, index, and updated text deterministically. The agent never gets the chance to construct a malformed parameter that downstream serialization will mishandle, because the agent never touches the parameters that matter.

The NSA flags tool-name collisions as path confusion. Arcade eliminates it with a private registry and strict, namespaced resolution. There is no “lookup by name from an ambient registry and load whatever shows up.” For customers building proprietary tools via Arcade’s open-source MCP framework, the same hardening, eval framework, and auth flow apply.

Centralized control plane: the NSA’s approval drift, audit, and inventory gaps

The NSA’s recommendations on logging, vulnerability tracking, and inventory describe a control plane. “Maintain a clear inventory of all deployed MCP agents and tools, along with versioning, patch history, and known security concerns. A well-maintained registry enables faster triage and coordinated mitigation efforts when a vulnerability is disclosed.” That is the Arcade control plane, almost verbatim.

Arcade gives a single place to manage tools and servers (Arcade-built, customer-built, or BYO), with version control for safe upgrades, project and org-level segregation, visibility filtering so agents only see tools the user is permitted to invoke, and pre- and post-tool-call enforcement. Approval workflows are codified rather than implicit, which addresses the “consent at install, drift in production” failure that the NSA highlights: capability changes route through Arcade’s policy layer, not silently into a long-running session.

The audit trail answers the question every CISO will ask their first agentic AI vendor: which agent took which action on behalf of which user against which system, and under whose authority? Every tool call, every credential exchange, every policy decision is captured, OTel-formatted, exported to SIEM.

For the regulated buyer, deployment matters as much as the controls. Arcade runs cloud, self-hosted in cloud or on-prem, or fully air-gapped. The NSA recommends always preferring a local instance of MCP server for private data. In Arcade’s self-hosted profile, that posture is the default: no connection back to Arcade, no shared tenancy, no vendor access to customer data.

Aligned with the policy floor

Arcade is SOC 2 Type II certified. Beneath that certification sits Arcade’s own security policy framework: fifteen formal policies managed in Vanta, AES-256 at rest, NIST SP 800-57-aligned encryption, vulnerability remediation SLAs of 30 days for critical and high severity, quarterly access reviews, MFA on all privileged production access, segregation of duties across dev/test/deploy, and 60-day customer-data deletion on contract termination. The runtime gives the customer the controls. The policy framework gives the customer the evidence.

Protocol or operating system-layer problems that remain to be solved

Several of the NSA’s recommendations sit at the protocol or operating-system layer, below where any runtime can reach. An honest reading of the CSI must acknowledge them.

Per-message cryptographic signing. The NSA recommends signed JSON-RPC payloads with expiration and replay-protection metadata, aligned to OWASP ASVS V7. The MCP specification today relies on TLS at the transport layer; the protocol itself does not bind requests to time and context. This is a protocol-level gap, not a runtime gap.

Semantic output filtering against indirect prompt injection. Hidden instructions embedded in tool outputs and semantic manipulation of tool metadata are a class of attack that no auth or governance layer fully eliminates. The state of the art is immature across the industry, as the NSA itself acknowledges.

OS-level sandboxing of tool execution. The NSA recommends seccomp, AppArmor, SELinux, and AppContainer-class isolation. Arcade isolates credentials and validates parameters; the operating-system isolation of tool processes is the customer’s responsibility, particularly in self-hosted and air-gapped deployments.

Shadow MCP discovery. Arcade is the inventory system of record for what it manages, but the broader shadow AI problem: unauthenticated or unauthorized MCP servers running elsewhere on the customer network requires network scanning tools (MCP Scanner, Ramparts, CyberMCP, Proximity) that currently operate outside the runtime.

Non-deterministic LLM behavior. Probabilistic interpretation of context is a model-layer problem. Arcade enforces deterministic execution at the tool layer, but two agents reading the same prompt may still interpret intent differently.

Helping to advance the MCP spec

Arcade is helping to shape the protocol from the inside. Our lead architect co-authored the MCP authorization specification and chairs the MCP identity working group. We are active contributors on the working groups governing MCP and agent interoperability, and we are helping to close some of the gaps that currently exist in the spec to ensure it meets the needs of the enterprise.

What enterprise buyers should take away

CISOs, CIOs, and chief data officers will read this CSI and use it as the requirements document for their next agentic procurement. The questions on the RFP write themselves: delegated auth, token lifecycle, RBAC at runtime, codified approval, audit to SIEM, signed messages, sandboxed execution, vendor-maintained inventory.

We’ve seen this movie before. Identity required a runtime, and Okta became the answer. Application platforms required a runtime, and JBoss became the answer. Cloud and mobile required a new data model, and MongoDB became the answer. Agents require a runtime, and the NSA just published the spec.

The “should we adopt MCP?” conversation is already over. The one worth having now is, “what is the right runtime to support it?” Reach out to have that conversation.

Arcade is the actions runtime for enterprise AI agents: enforcing your security policies on every action, executing reliably across any system, and governing agents centrally in production. Deployable as cloud, self-hosted, or fully air-gapped.

Sources