The NSA Just Flagged MCP Security — Here's What It Means

The National Security Agency published a detailed cybersecurity advisory this month on Model Context Protocol (MCP), the de facto standard for connecting AI agents to tools, data, and services. The report, MCP: Security Design Considerations for AI-Driven Automation, is required reading for anyone deploying agentic AI in production — especially in regulated, high-stakes, or sovereign environments.

The headline finding is blunt: MCP’s rapid adoption has outpaced its security model. The NSA compares it to the early web protocols — flexible and underspecified, with security left as an afterthought for implementers.

What the NSA Actually Found

Access control is largely absent

MCP does not define how a session maps to a verifiable identity. Authentication is optional, role-based access control (RBAC) is not part of the protocol, and many implementations ship without any controls at all. The result: ambiguous, untraceable access to data and context.

Even the official MCP documentation acknowledges this reality. Its dedicated tutorial on authorization states that authorization is “optional but strongly recommended” and explicitly notes that MCP itself does not implement the identity provider or token issuance. Implementers must wire up an external OAuth 2.1 authorization server (e.g., Keycloak), handle Protected Resource Metadata (PRM), dynamic client registration, token introspection, audience validation, and scope enforcement — all on their own.

Approval workflows are broken by design

The MCP spec itself states that “MCP itself cannot enforce these security principles at the protocol level.” Even when user consent is added, a trusted server can silently expand its capabilities. No re-approval. No notification. A previously benign agent can suddenly reach sensitive resources.

Token and session security is inconsistent

MCP uses OAuth-style bearer tokens, but token lifecycle (refresh, revocation, reuse protection) is left entirely to implementers. Session hijacking becomes trivial.

Audit logging is missing or minimal

The specification offers only basic guidance. Most deployments log little more than minimal metadata. In a multi-agent or multi-tenant environment, forensic investigation becomes guesswork.

Real exploits, not just theory

The NSA documents concrete, exploitable issues that have already appeared in the wild:

• Tool parameter injection — unsanitised parameters leading to arbitrary command execution.
• Tool invocation path confusion — naming collisions allowing attacker-controlled tools to be loaded.
• Unrestricted repository access — blanket read/write on private repos.
• Downstream output poisoning — hidden instructions propagating silently through multi-agent chains.
• Remote code execution — CVE-2025-49596 in MCP Inspector (fixed in 0.14.1).

What the NSA Recommends

The guidance is exactly what enterprise security teams expect — and what most MCP implementations still lack:

• Explicit trust boundaries between agents, plugins, models, and users
• Schema-level validation of every parameter
• Sandboxed tool execution (AppArmor, seccomp, SELinux)
• Cryptographic signing and replay protection of MCP messages
• Output filtering before any downstream consumption
• Comprehensive, tamper-evident logging fed into SIEM
• Regular network scans for rogue MCP servers

What This Means in Practice

The NSA advisory — combined with MCP’s own authorization tutorial — is institutional confirmation of what many architects have been saying quietly: MCP governance cannot remain an “implementation detail.”

Even when you follow the official tutorial to the letter, you end up manually wiring together external OAuth servers, PRM documents, consent flows, and token validation logic — all while hoping your custom code doesn’t introduce the very vulnerabilities the NSA just documented. In regulated industries — defence, government, finance, healthcare — treating security as a post-deployment exercise is no longer acceptable.

The structural gap is clear: there is no built-in enforcement layer that checks intent, brokers credentials, assigns verifiable identity, and produces a tamper-evident audit trail. Standard MCP trusts the client by default. That assumption does not survive contact with real enterprise data.

How Scrydon’s Cognitive Enterprise Platform Closes the Gap

At Scrydon we took a fundamentally different approach. Our Human + AI Orchestrator and AI Agents are not built on top of MCP — they are designed from the ground up to make the NSA’s recommendations native, not optional.

When you define an agentic workflow in Scrydon, you are not writing prompts. You are encoding policy directly into the Cognitive Enterprise ontology — the unified semantic model built from four compounding layers: Data, Processes, Knowledge, and Expertise.

• Every step of the process is modelled explicitly.
• Every tool call, data access, or external integration is declared with its required identity, required approvals, and exact trust boundaries.
• Only tools and data explicitly declared in the workflow are accessible to the agents. No hidden capabilities. No surprise expansions.
• The Human + AI Orchestrator becomes the runtime enforcement point. It schedules, routes, and governs every task — whether executed by an AI agent, an existing system (CRM, ERP, C2), or a human.
• Credentials are brokered just-in-time and scoped to the exact step. Long-lived tokens are never exposed.
• Every action is assigned a verifiable identity, executed within the defined boundaries, and logged immutably back into the ontology.

Because the workflow definition is the policy, the system is deterministic by design. Agents cannot drift. Parameter injection, path confusion, output poisoning, and silent capability expansion are prevented at the architectural level — not by hoping the next prompt guard will catch them. The ontology provides the semantic context that makes validation possible; the orchestrator provides the enforcement layer that MCP itself lacks.

This is not “bolt-on security.” It is security by design, delivered through a sovereign, European-controlled stack that runs from air-gapped on-prem to hyperscale cloud without ever surrendering data or compute control.

Ready for Agentic AI That Actually Meets Regulatory Standards?

The NSA report — and MCP’s own authorization tutorial — is a wake-up call. Most organisations will respond by adding more wrappers, more OAuth plumbing, and more custom code around MCP.

The smarter move is to adopt a platform purpose-built for regulated environments — one where the ontology, the orchestrator, and the agents are already aligned with the security and sovereignty requirements the NSA is now demanding.

If you are deploying (or planning to deploy) agentic AI in a high-stakes environment and want to move beyond reactive fixes, let’s talk.

---

NSA advisory: MCP Security Design Considerations
MCP Authorization Tutorial: Understanding Authorization in MCP