MCP Is How Your AI Controls Your Systems. The NSA Just Published the Manual for Locking It Down.

In May 2026, the National Security Agency’s AI Security Center, working with Carnegie Mellon’s Software Engineering Institute, published a Cybersecurity Information Sheet on MCP security. The Model Context Protocol (MCP) is the plumbing connecting AI agents to real systems: databases, CRMs, accounting software, exchanges, payment rails. The sheet opens with a line every company rolling out agents should sit with: “MCP’s rapid proliferation has outpaced the development of its security model.”

Here is what the guidance says, and how its recommendations map onto work a mid-market team can run this quarter.

What MCP is

Model Context Protocol is an open, application-level protocol that gives AI models a standard way to discover and call external tools, data, and services. Anthropic popularized it as an open source framework in November 2024, and it has spread fast enough that the NSA calls it the de facto standard for communication across AI-driven services. The sheet counts it “in both experimental and production AI deployments across multiple industries, such as business, finance, legal, and software development”, and names AutoGen Studio, Harvey AI, Agentverse, and Copilot as examples.

What matters for risk is what a connection lets an agent do. MCP sessions can run the other direction: the sheet describes servers that “query and sometimes execute actions for the connected clients.” An agent wired into your ERP through MCP can act on whatever the server exposes, not just read rows.

The inversion that breaks old assumptions

Most controls assume clients initiate and servers respond, with a human approving what leaves; firewalls, API gateways, and OAuth consent screens all lean on that pattern. The sheet’s core observation is that MCP “reverses a familiar interaction pattern”, and the attack paths that follow are “not merely hypothetical but demonstrable.”

The GitHub example is the clearest for a software team. A user grants the GitHub MCP server blanket access to act on their behalf; researchers then showed this “enabled malicious or compromised tools to read sensitive content from private repositories and write or publish it into public repositories without the user’s explicit awareness or intent.” No exploit chain, no zero-day: one broad approval, then drift. In the messaging example, a malicious server sharing the system with a trusted WhatsApp agent coerced the client into exposing message history, and “advertised a benign instruction at the time of installation and switched to a malicious instruction after the MCP server’s second usage.”

The failure behind both is treating approval as if it were permanent. The sheet warns that “a previously benign and approved AI service could later access sensitive resources on demand, without triggering any review.” The approval you granted in March is not necessarily the approval you have in October. If your risk register still files AI assistants under read-only research tools, that assumption is the finding.

The protocol will not protect you

The protocol does not enforce security, and its own documentation concedes the point: “MCP itself cannot enforce these security principles at the protocol level.” The protocol docs also state that “Authorization in MCP is optional (not every implementation uses it)”. Binding a session to an identity and exchanging role-based permissions at instantiation are left to implementers, per the sheet. Serialized payloads “can include executable code or embedded model calls”, the deserialization risk your team knows from OWASP A08. Transport encryption is real, but the protocol “is unaware of message integrity as well.”

The MCP project publishes its own Security Best Practices document (docs revision 2026-07-28), which reads like web application security rather than a protocol standard: confused deputy attacks against OAuth proxies, mix-up attacks, token passthrough, which the spec defines as “an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued” before forwarding them downstream. That document is written for implementers; the NSA sheet is written for organizations deciding whether to adopt.

The vulnerability record is not theoretical

Queried on October 14, 2026, the National Vulnerability Database keyword search for model context protocol returns 144 CVEs. CVE-2025-6514 is OS command injection in the mcp-remote helper, triggerable when connecting to untrusted MCP servers, scored 9.6 on CVSS. CVE-2025-49596 is remote code execution in MCP Inspector, a tool for testing servers under development; the sheet describes it as having “accepted unverified inputs, allowing malicious actors to trigger remote code execution via crafted messages”, fixed in version 0.14.1. The stream runs into 2026: CVE-2026-27735, published in February against mcp-server-git, is the fourth CVE in that one reference server, after three in 2025 scored 8.8, 7.1, and 9.1.

Notice where these land: helpers, developer tooling, reference implementations. The testing utility most integrators use carried remote code execution. Treat every MCP component as unproven until inventoried and patched.

The nine recommendations, translated for a mid-market team

The sheet’s recommendations cover nine areas, and almost every item is a control your team already runs somewhere else. The work is mapping, not invention.

1. Inventory first. Keep a registry of every deployed MCP agent and tool with versions, patch history, and known concerns, the way you track SaaS through your identity provider. The MCP project itself warns that “many popular servers are no longer actively maintained”, so maintenance status belongs on the record and on every vendor checklist. An MCP server you didn’t build is a vendor.

2. Draw trust boundaries by data classification. Keep agents, plugins, models, and end users in separate trust zones. Public tools handle public data; regulated information, with “financial information” among the sheet’s examples, sits behind explicitly controlled, segregated access. Prefer a locally hosted MCP server for anything touching private data.

3. Filter egress. For outbound agent connections, the sheet directs organizations to “use a filtering outgoing proxy (e.g., Squid, tinyproxy) or an enterprise data loss prevention (DLP) solution”. Agents are a new egress point, and most mid-market teams have not extended DLP policy to them.

4. Validate parameters, not just inputs. Check every tool invocation against schemas, expected ranges, and intended execution context, and block parameter forwarding whenever the source is ambiguous or user-supplied.

5. Sandbox every execution. Isolate tool invocation as a high-risk action with AppContainers on Windows, seccomp, AppArmor, or SELinux, apply least privilege, and explicitly deny access paths a server does not need.

6. Sign and verify messages where it matters. TLS protects the pipe, not the payload; the protocol is “unaware of message integrity as well.” For high-value flows, add payload signatures, expiration timestamps, and replay protection. OWASP ASVS session management requirements are the reference.

7. Treat every output as untrusted input. Filter for indirect prompt injection and hidden instructions before one agent’s output becomes another agent’s input. The sheet notes MCP-aware security proxies “remain limited and are still maturing,” so buying a proxy is not a program.

8. Log invocations into the SIEM. Capture parameters, identities, and output hashes for every tool and model call, and feed the stream into existing monitoring; without it, incident response on an agent stack is guesswork.

9. Track MCP CVEs and scan the network. Add MCP to formal vulnerability monitoring, then scan periodically for unauthenticated, vulnerable, or unauthorized servers with tools like MCP Scanner, Ramparts, CyberMCP, or Proximity. Servers “may dynamically change ports,” so a single scan is a snapshot; differential reports are the control.

Two of these rarely exist in a mid-market toolkit yet: the inventory and the scan cadence. The other seven are translation exercises into controls you already operate.

Where this lands in your audit

An MCP connection that writes to accounting software is in scope for a SOC 2 audit whether or not anyone filed it under AI. The inventory, trust boundaries, logging, and change control around agents produce exactly the evidence auditors already request; our analysis of the SOC 2 gap around AI controls covers where that evidence falls short. Building toward ISO 42001 or mapping to NIST’s AI framework? The same inventory and risk assessment become core documentation, and our NIST SP 1353 quick-start guide shows how to structure it.

This is not one agency’s enthusiasm. The sheet follows months after the six-agency guidance on careful adoption of agentic AI services, released late April 2026 by the Australian Signals Directorate’s Cyber Security Centre alongside CISA, the NSA, Canada’s Cyber Centre, NCSC New Zealand, and the UK NCSC, and it cross-references that guidance directly. When that many governments converge on one integration risk, audit and examination expectations follow. Teams that can show inventory, boundaries, and logging for agents will answer from existing artifacts; teams that cannot will build under deadline. The work fits the risk and compliance program you should be running anyway.

What management should do next

Name an owner: whoever holds systems and vendor risk, working with a platform lead or, for companies without one, a fractional CISO. In thirty days: build the inventory (teams usually find more servers than expected), run the first scan, wire invocation logs into the SIEM, and add a line about MCP to change control and vendor review. Those four steps turn a government document into operating evidence.

Our AI Governance Policy Template is the scaffold an agent-integration review slots into, and you can contact NTD Consulting for a second set of eyes on how agents reach your systems. We build this into AI governance and fintech cybersecurity engagements for mid-market teams.

Ron Moore runs NTD Consulting, which provides fractional CISO and cybersecurity advisory services to mid-market SaaS, fintech, and digital-asset companies.