The NSA Just Published MCP Hardening Guidelines — Here's Why Every AI Agent User Should Be Worried
The NSA issued official MCP hardening guidance. Amazon Q had a CVSS 8.5 MCP auto-execution flaw. ShareLock achieves >90% attack success by splitting malicious payloads across tool descriptions. And only 11% of production agents pass basic security checks.
The NSA just published an official Cybersecurity Information Sheet on MCP Hardening. That’s right — the same agency that deals with nation-state threat actors is now telling developers how to configure their AI agent tools safely. And honestly, it reads less like guidance and more like a post-mortem for an incident that hasn’t finished happening yet.
MCP — the Model Context Protocol — has become the universal plumbing for AI agents. Every agent uses it to talk to tools, databases, and APIs. And as Adversa AI’s July 2026 roundup makes clear, it’s “rapidly becoming a primary vector for AI agent hijacking.”
The inverted client-server model nobody asked for
Here’s the problem MCP can’t escape: the client (your agent) connects to servers (tools) and says “here, run this.” But the server can push arbitrary code execution back into the agent’s runtime.
The NSA calls this out directly: “inverted client-server pattern” leading to “unverified task propagation” and “arbitrary-code-execution exposure.” In plain English: every MCP tool you plug in is a potential remote code execution hole. Your agent chains tools automatically, so a single bad tool description cascades into full compromise.
We’ve been building client-server systems for forty years and we know better. Trust flows from client to server, not the other way. MCP inverts this deliberately — then acts surprised when people abuse it.
Amazon Q: CVSS 8.5, buried in a patch note
Amazon’s own Q VS Code Extension had an MCP auto-execution vulnerability that scored CVSS 8.5 this year. The mechanism was painfully simple: the extension automatically loaded MCP configurations from .vscode/mcp.json files inside workspace directories. No user consent. No prompt. Just open a repo and the agent auto-loads whatever tool definitions the author left there.
The attack chain writes itself: fork a popular project, add a malicious mcp.json, submit a PR. When the maintainer opens your branch, their VS Code agent dutifully loads your MCP configs — and your run_setup.sh tool description just exfiltrated their AWS credentials.
Amazon patched it in June 2026. But the structural issue — that workspace files can inject tool definitions into the agent’s trust boundary — is still there. The NSA guidelines specifically warn against auto-loading MCP configs from untrusted directories. We needed a near-critical CVE on Amazon’s own product to learn that lesson.
ShareLock: 10 innocent tool descriptions, one devastating payload
If you think single-tool prompt injection is already bad, meet ShareLock. Recent research demonstrates how attackers use Shamir’s threshold secret-sharing to split a malicious payload across multiple MCP tool descriptions — each one individually innocent.
The agent loads ten tools. Each description looks fine to every scanner, context filter, and safety guard out there. But when the agent combines them during a task, the payload reconstructs. The paper reports >90% attack success against state-of-the-art agents.
Because the split is cryptographic, automated detectors can’t fingerprint it. No single tool description contains enough information to flag. The NSA’s “verified task propagation” guideline is nice, but when every individual task is benign, verification is useless. We need structural changes — tool-combination sandboxing that detects threshold reconstructions.
MCPPrivacyDetector: 10% of servers leak your credentials
One more data point from the MCPPrivacyDetector project: researchers scanned over 10,000 real-world MCP servers — the APIs that power your agent’s “check email” or “query database” tools. More than 10% leaked credentials, API keys, or PII.
These aren’t edge cases. MCP servers commonly embed secrets in tool descriptions, error responses, and JSON-RPC return values. Many of these servers are community-contributed — someone published a “Slack integration” MCP server to a registry, and now your agent is passing tokens to a random endpoint in a log message.
The NSA says “minimize data exposure” in MCP server responses. But the servers leaking credentials don’t know they’re leaking them. That’s the whole problem.
WebMCP session hijacking: XSS for AI agents
Even locked-down MCP configs aren’t safe during active sessions. The WebMCP Tool Surface Poisoning paper (MSTI — Mid-Session Tool Injection) shows attackers hijacking an agent’s tools while it’s running, by injecting malicious third-party scripts into the web content the agent is processing.
Since MCP allows dynamic tool resolution, the agent can be tricked into swapping “look up weather” for “run arbitrary Python” mid-task. No tool identity nonces. No session-level integrity checks. The swap goes unnoticed. Success rates are, in the paper’s words, “exceptionally high.”
This is XSS for MCP. Your agent browses a page, a script modifies the tool manifest, and now your agent is executing attacker commands. The NSA guideline to “verify tool provenance” sounds reasonable — until you realize verification needs to happen continuously during execution, not just at load time.
The state of production: 11% pass rate
All of this lands in an ecosystem that is structurally unprepared. According to Adversa AI’s AIRQ evaluation, only ~11% of 100 assessed production agents pass basic security evaluation.
Meanwhile, the Cloud Security Alliance found that 98% of production agents combine what they call the “Lethal Trifecta”: private data access + untrusted content exposure + outbound actions. An agent that reads your email, processes web content, and can send messages? Congratulations, you’ve built a perfect attack surface.
The NSA can publish all the guidance it wants. But when 89% of agents fail basic checks and 98% are architecturally designed to be exploitable, the guidance is describing a burning building, not a renovation plan.
What actually needs to happen
The NSA guidelines are a good start — mandatory user consent for workspace configs, strict tool provenance verification, minimal data exposure in responses, verified task propagation chains. But they’re fighting the last war.
The structural problems — inverted trust, cryptographic payload splitting, session-level hijacking — require structural solutions. Tool-combination sandboxes that detect reconstituted payloads. Session-level integrity checks that survive dynamic tool resolution. Ephemeral capability handles that can’t be reused or replayed.
Until then, MCP servers cannot be treated as trusted infrastructure. Every tool your agent connects to is an attack surface. Every tool description is a potential payload. And every session is a live-fire exercise.
The bottom line: If your production agent uses MCP tools — and it does — assume every tool description is adversarially crafted until proven otherwise. The NSA is telling you what you already suspected: the protocol wasn’t designed for security, and the attackers figured that out first.
Adversa AI July 2026 MCP Security Roundup • NSA MCP Hardening Guidelines • ShareLock @ arXiv • MCPPrivacyDetector • WebMCP MSTI • Amazon Q Security Bulletin
Is your AI-built app ready for real users?
We audit, harden, and ship AI-built apps. From security review to production deployment.
Get an audit