NSA MCP guidance warns about GitHub scope, WhatsApp leaks, and agent runtime risk

AI 요약

• What happened: NSA's AISC published MCP security design guidance on May 20, 2026.
  • The 17-page sheet treats MCP as a fast-spreading automation standard whose security model has not kept pace with adoption.
• Risk examples: NSA cites GitHub MCP permission scope, WhatsApp MCP data exposure, and the MCP Inspector RCE.
  • It also groups tool parameter injection, tool-name collisions, and downstream output poisoning into the same operational risk class.
• Operational impact: An MCP server is no longer just an endpoint; it is an agent runtime that needs permissions, logs, sandboxing, and DLP.
• Watch: Official MCP guidance is only a baseline. Production teams still need registries, egress controls, SIEM events, and repeat approval for changed capabilities.

The U.S. National Security Agency's Artificial Intelligence Security Center published a Cybersecurity Information Sheet on May 20, 2026 titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. The document is version 1.0, carries the identifiers U/OO/6030316-26 and PP-26-1834, and runs 17 pages.

The news is not that NSA discovered MCP. The news is that NSA now treats MCP as security infrastructure for AI automation rather than a developer convenience layer. The sheet says MCP has become a de facto standard for communication between AI-driven services, and that deployments already touch business, finance, legal, and software development workflows. It names AutoGen Studio, Harvey AI, Agentverse, and Copilot as examples of products in the broader ecosystem.

MCP has moved quickly since Anthropic introduced it in November 2024. Claude Desktop, IDEs, agent frameworks, SaaS connectors, and internal automation projects now use it to connect models with APIs, databases, GitHub, Slack, browsers, file systems, and local tools. For engineering teams, the appeal is obvious: one protocol can expose many capabilities to an agent. NSA's warning is that the same convenience shifts the security boundary around identity, authorization, context sharing, tool execution, and audit logging.

NSA's central claim is short and uncomfortable for teams already deploying MCP: adoption has outrun security-model development. The sheet compares MCP's flexible and underspecified design to early web protocols. That flexibility gives implementers room to move, but it also leaves ambiguity around safe usage. In production, "adding an MCP server" is not a small connector task. It is a deployment that can delegate privileged actions to an agent.

MCP reverses a familiar client-server assumption

In a traditional web service, the client asks a server for data or asks it to perform a fairly bounded API operation. NSA describes MCP as a pattern that can reverse that familiar shape. An MCP server can query or act on data and actions available through the connected client. The user expresses intent, an agent interprets it, an MCP client library turns it into protocol messages, and MCP servers expose tools and capabilities that can be selected at runtime.

The travel-planning example is benign. A user asks an assistant to arrange an overseas business trip, and the agent collects location, dates, airport options, visa requirements, flights, and calendar data from multiple tools. The same architecture is more sensitive when those tools reach electronic health records, private repositories, accounting systems, legal workspaces, or customer-support logs. One tool result becomes the input for another tool call. Previous context enters the next agent decision. A UI that shows a single Allow button can hide a wide action surface the user has not fully inspected.

NSA says traditional cybersecurity principles still apply: authentication, authorization, and input validation remain necessary. The difference is that agentic systems create dynamic tool invocation, implicit trust relationships, and context sharing. Patching a single server endpoint does not cover the lifecycle of an agent that reads from one system, transforms context in a model, and writes to another system minutes later.

Access control is the first failure mode

The access-control section targets the most common MCP adoption mistake. NSA says the protocol does not define a binding between a session and identity; implementers make those choices. Some MCP components process data without authentication. Others authenticate a user but do not enforce role-based controls at the CRUD or operation level.

The GitHub MCP example makes that concrete. When a user authorizes a GitHub MCP tool, the tool may receive broad repository-level read and write access across both private and public repositories. If permissions are not narrowed by repository and operation, a compromised or confused tool can read private code and write to a public repository. That is not only a prompt-injection problem. It is a permission-design problem.

For development teams, the important check is not whether an OAuth consent screen exists. The useful questions are more specific. Does the MCP client log user identity and server identity separately? Are tool permissions split into read, write, delete, and publish classes? If a previously trusted MCP server changes its capability list or expands its data access, does the user or administrator have to approve the change again? NSA treats silent capability drift after initial approval as a separate risk.

Tokens and sessions need lifecycle rules

NSA also focuses on bearer tokens and session IDs. MCP implementations often depend on OAuth-style tokens, but protocol-level lifecycle rules are not enough by themselves. Refresh, revocation, reuse prevention, expiration, and rotation can remain implementation-specific. When those controls are weak, message replay and unauthorized session reuse become realistic attacks. If a session is hijacked, the attacker may be able to interact with the MCP server as if they were the legitimate client.

The official MCP Security Best Practices document calls token passthrough an anti-pattern. An MCP server should not accept a token that was not issued specifically for that server and then forward it to a downstream API. Doing so breaks token audience checks and weakens the audit trail. NSA's guidance pushes that idea into production concerns: token lifecycle, replay protection, session expiration, and idempotency all have to be designed explicitly.

Idempotency can look like a minor distributed-systems detail until an agent starts performing mutations. MCP runs through JSON-RPC and, in some environments, message queues or resumable calls. A request can be retried, replayed, or resumed. For payments, repository writes, ticket-status changes, customer-data exports, and deployment operations, a missing idempotency key can turn one visible approval into two backend mutations.

NSA's real-world examples are already familiar to agent teams

The middle of the NSA sheet collects real-world MCP security issues. One case is tool parameter injection in an open source MCP agent. A malformed MCP message used unsanitized tool parameters and exposed sensitive MCP server data. The tool interface still looked like the normal path; the failure was insufficient contextual validation and logging.

Another case is tool invocation path confusion. Some MCP orchestrators resolve tool names automatically from public registries or local modules. If an attacker can create a name collision or manipulate configuration, attacker-controlled code can be loaded instead of the intended tool. NSA describes this as a risk when MCP clients cannot require unique tool identifiers or strict resolution policy.

NSA also cites a WhatsApp MCP extension scenario. A trusted third-party MCP agent and a malicious MCP server were connected to the same client. The malicious server used tool descriptions to manipulate client behavior and expose WhatsApp message data. The evasive part matters for defenders: the malicious server could present benign instructions at install time, then change its instructions on later use.

Downstream automation poisoning is the multi-agent version of the same problem. One agent's output becomes another agent's input. Tool metadata, hidden instructions, and prompt injections can travel through the pipeline. NSA treats this as a systemic class, not an isolated bug. If a workflow assumes that previous agent output is trustworthy, control-flow hijacking or data exfiltration may happen several steps after the original malicious content entered the system.

The final named example is the MCP Inspector CVE-2025-49596 remote code execution issue, fixed in 0.14.1. A developer tool used for testing MCP servers allowed crafted messages to reach code execution. That example expands the attack surface beyond the production agent runtime. Inspectors, debuggers, registries, local launchers, and test harnesses are also part of MCP security.

Trust boundaries should be drawn around tools

NSA's first recommendation is to choose supported MCP projects. The sheet notes that some popular MCP servers are no longer actively maintained. That is not a paperwork issue. A file-system server, browser-automation server, development-tool server, or productivity-service connector can become supply-chain risk when an archived demo enters production.

The second recommendation is boundary design. NSA says agents, plugins, models, and end users should sit in distinct trust zones. Data from a user-facing plugin should not be trusted automatically by a privileged backend model. Public tools should stay tied to public datasets. Tools that access health records, financial information, controlled unclassified information, or other sensitive data should run in separate zones.

MCP's dynamic tool discovery creates the matching security requirement. If an agent can discover and attach tools at runtime, the organization needs origin verification and authorization checks at the same point. A private MCP registry is a practical starting point. Servers outside the registry can be blocked or at least warned on, including in development environments. NSA recommends local MCP server instances when private data is involved.

Parameter validation beats prompt filtering

MCP security discussions often collapse into prompt-injection filtering. NSA includes prompt injection, but it demands broader parameter validation. Every tool invocation and model-execution request should match a defined schema, expected range, and intended context. Malformed input, missing fields, excessive size, and strange parameters can be used for injection and denial of service.

Consider a math-interpreter agent. The expression itself may look harmless. If a context parameter can alter file I/O behavior, however, the tool can stop behaving like a calculator and start touching local files. NSA's validation requirement is less about checking whether a string contains bad words and more about checking whether this tool should run with this parameter under this permission and context.

Parameter forwarding also needs limits. If user-supplied input enters one component and is forwarded automatically into another component, the downstream tool may interpret it as a system instruction, execution option, URL, path, or tool metadata. Agent chains make this convenient in normal operation and painful during incident response, because the meaning of the same value can change as it crosses components.

Sandboxing and egress control are runtime requirements

NSA recommends treating tool actions through MCP as high-risk actions. Shell commands, database queries, and external API calls should run inside strict resource boundaries. The sheet names Windows AppContainers, seccomp, AppArmor, and SELinux as examples of operating-system isolation. Agent processes should follow least privilege, and unnecessary file-system, model-file, and internal-network access should be blocked at runtime.

Outbound control is part of the same design. NSA recommends filtering outgoing proxies or enterprise DLP for connections to external entities. The sheet names proxy examples such as Squid and tinyproxy. The reason is direct: an MCP server may interact with external URLs, APIs, registries, and OAuth discovery endpoints. Data exfiltration and server-side request forgery can travel through the same path.

The official MCP security documentation also calls out SSRF. A malicious MCP server can manipulate OAuth metadata discovery so a client requests internal IP ranges, cloud metadata endpoints, localhost services, or other protected resources. A production MCP client needs checks for private IP ranges, link-local addresses, redirect chains, and DNS rebinding. This is not a place for a hand-written URL parser if the platform already provides a hardened networking policy layer.

Message integrity and logs determine whether incidents can be reconstructed

NSA says MCP may rely on transport-layer encryption such as TLS while still lacking protocol-level message integrity. For sensitive data or security-critical decisions, the sheet recommends considering cryptographic signatures inside JSON payloads, plus expiration timestamps and replay-protection metadata. The goal is to reduce distributed-system failures where delayed or duplicated messages trigger unintended execution.

Logging guidance is equally concrete. Every tool and model invocation should record exact parameters, involved identities, and, where possible, a cryptographic hash of the result or output. That telemetry should feed SIEM, threat detection, and compliance dashboards. NSA names unexpected tool invocation, anomalous message flow, authorization failure, and RBAC violation as patterns worth monitoring.

Many agent products hide or compress logs to improve user experience. MCP incidents need the opposite forensic backbone. Investigators need to know what the agent read, which tool it called, which parameters it used, and which downstream step consumed the result. If the log contains only the prompt and final answer, permission escalation or data leakage between tool calls can be impossible to reconstruct.

Organizations need to scan for MCP servers

One of NSA's most operational recommendations is local network scanning. Organizations should regularly find unauthenticated MCP servers, outdated MCP servers, unauthorized deployments, and unregulated internet connectivity. The sheet names MCP Scanner, Ramparts, CyberMCP, and Proximity as example tools.

That recommendation will collide with normal developer behavior. MCP servers often start as local experiments: a filesystem server attached to an IDE agent, a browser-automation server left running after a demo, or a small wrapper around an internal API. If that server remains on localhost, exposes a container port, or runs on a shared development host, it becomes an agent integration outside the security team's inventory.

A production readiness checklist should therefore include MCP inventory. The minimum record should include server name, version, owner, repository, capability list, and data classification. Outbound domains, credential storage, patch history, approval workflow, and logging destination belong in the same registry. NSA says a registry with versioning and patch history makes vulnerability triage faster.

The response is not simply to ban MCP

NSA does not frame MCP as something organizations should reject. The conclusion calls MCP a promising foundation for agentic AI orchestration and automation. The caution is that the current security posture is uneven and depends heavily on implementation discipline rather than protocol guarantees. Teams that use MCP need to govern agent runtime with the same seriousness they bring to web APIs and privileged internal services.

The first response is an internal MCP registry. Teams need to know who built each server, which version is deployed, which tools it exposes, and which data zone it touches. Servers outside the registry should default to deny, or at minimum require warnings and approval in development. One-click flows such as running an arbitrary package should show the exact command, arguments, file-system access, and network access before execution.

The second response is tool-level permission design. If read_repo, write_repo, create_issue, and publish_release sit behind the same GitHub access grant, a failed agent action can become a release or supply-chain incident. Sensitive actions need separate approval and idempotency keys. Capability changes should generate reapproval events rather than silent updates.

The third response is an output pipeline filter. Tool output should be treated as untrusted input before it enters the next agent step. Hidden instructions, oversized content, unexpected URLs, code blocks, serialized commands, and tool metadata mutations all deserve inspection. NSA notes that MCP-aware security proxies are still maturing, so teams will need to combine egress proxies, DLP, schema validation, and custom policy engines today.

The fourth response is an incident drill. An MCP incident may not end with one secret rotation. Agent memory, cached tool results, downstream tickets, public repository writes, chat messages, and audit logs may all be affected. A runbook should include server disablement, token revocation, tool-registry quarantine, affected-context purge, and downstream-output invalidation.

MCP security is runtime security

After the NSA sheet was published, security vendors quickly used it to argue for agent firewalls, MCP proxies, and detection layers. PipeLab's May 22, 2026 write-up highlights NSA's references to filtering outgoing proxies, DLP, sandboxing, message integrity, output filtering, and local MCP scans. Those product categories may become useful. The baseline lesson from the NSA document is more fundamental: MCP has to move into the organization's inventory and trust-boundary design.

MCP spread because it standardizes how agents call files, repositories, issue trackers, browsers, databases, and SaaS APIs. That standardization speeds development. It also concentrates permissions and context, then links tool output to future action. NSA's warning is about that connectivity.

AI engineering teams should treat an MCP server less like a plugin and more like a small remote execution environment. Who runs it? Which permissions does it hold? Which network can it reach? Which data can it read? Which logs does it write? Which updates can arrive without approval? Those questions now belong in the deployment review for every serious MCP integration.

The practical message from NSA's MCP guidance is direct. Once a tool is connected to an agent, a tool call becomes a privileged action. Production MCP deployments cannot stop at prompt filters. Registry, sandbox, schema validation, signatures, egress control, DLP, SIEM events, and scanner coverage need to appear in the same design document. Without those controls, MCP is not just convenient automation. It is hard-to-trace delegated authority.

Sources