NSA MCP Guidance: Inventory Agent Tools Before They Drift
The NSA's May 2026 MCP guidance treats agent tooling as infrastructure: inventory every server, verify tool changes, and scan before trust drifts.
On May 20, 2026 the NSA’s Artificial Intelligence Security Center published security design considerations for Model Context Protocol deployments. Its message is operational, not theoretical: inventory every MCP server, define trust boundaries, sandbox tool execution, sign and verify messages, and re-review when a tool surface drifts after approval.
Updated September 2026: the guidance itself is unchanged. What changed around it is the ecosystem’s response — Microsoft published an NSA MCP alignment crosswalk on May 22 that rates 8 of the publication’s 11 themes fully covered by its toolkit and 3 only partial, and OWASP shipped an MCP Security Cheat Sheet covering the same ground for implementers.
Key figures
| Figure | What it measures | Source |
|---|---|---|
| May 20, 2026 | publication date of the NSA AISC MCP guidance | NSA CSI (PDF) |
| 8 | problem categories the guidance names, from access control to remote code execution | NSA AISC |
| 9 | recommendations it makes, from choosing supported projects to scanning for open servers | NSA AISC |
| 11 | NSA MCP themes in Microsoft’s crosswalk | Agent Governance Toolkit |
| 8 covered / 3 partial | how one production governance stack rates itself against those themes | Agent Governance Toolkit |
| 3 | attack classes the MCP spec’s own security document treats as normative: confused deputy, token passthrough, session hijacking | modelcontextprotocol.io |
| 1,467 of 3,984 | published agent skills carrying at least one security flaw (36.82%) | Snyk ToxicSkills |
The timing matters. In the days after publication, security vendors repeated the same theme, including Palo Alto Networks’ June 4 post arguing that MCP servers are the new unmanaged API surface. Microsoft is also rolling out dynamic tool discovery for MCP-based Copilot agents and connectors, which makes tool surfaces more flexible and more important to govern.
The public discussion is moving in the same direction. A Reddit thread on the NSA guidance focused on unauthenticated servers, MCP CVEs, and the fact that the protocol cannot enforce safety by itself. A Hacker News discussion about dynamic MCP tool registration is asking the other side of the same question: if agents can load, unload, or even create tools at runtime, how do users and security teams know what they have approved?
MCP has moved from “interesting developer integration pattern” to “agent supply-chain surface with government guidance.” The practical question is no longer whether agent tools are useful. It is how to keep useful tools from becoming invisible infrastructure. Our MCP security guide is the working version of that checklist, and the 12 checks it comes down to — before install, at the call, in flight, and continuously are where the NSA’s 9 recommendations land in practice.
What the NSA Guidance Changes
The NSA’s report is careful, but its message is blunt: MCP adoption has outpaced the maturity of its security model. The document calls out 8 problem categories — access control gaps, insecure serialization, weak approval workflows, token and session handling, poor audit logging, tool invocation path confusion, poisoned outputs, and remote code execution in MCP tooling.
None of those categories are exotic. They are familiar software security problems, but MCP changes the shape of the blast radius.
An MCP server is not just an API client. It is an integration layer that receives instructions from an AI model and acts with whatever credentials it was given. If that server has a GitHub token, database credentials, Slack access, cloud permissions, or filesystem reach, then a compromised tool call is not just a bad model response. It is an action inside the user’s environment.
The protocol’s own maintainers agree on the mechanism. The MCP specification’s security best practices document treats 3 attack classes as normative concerns rather than implementation trivia — the confused deputy problem in proxy servers, token passthrough, and session hijacking — and requires per-client consent before a proxy forwards an authorization request.
The NSA guidance also highlights an uncomfortable dynamic: MCP components can sit in different trust zones while still sharing context. A malicious or compromised server does not always need direct access to sensitive data. It may only need to influence the agent into calling another trusted server that does.
That is the same core problem we covered in MCP tool poisoning, and the class Invariant Labs named when it showed that a single poisoned tool description is enough to make an agent read files the user never mentioned. The difference here is that the NSA is treating the issue as an infrastructure lifecycle problem, not just a prompt-injection trick.
Dynamic Tools Make Approval Harder
Microsoft’s dynamic tool discovery rollout is useful for understanding why static approval is not enough.
In the old model, an MCP server’s tools were captured when an agent or connector was packaged. If the server added a tool, removed one, or changed a schema, the consuming agent needed to be republished before users saw the change.
Dynamic discovery changes that. The agent resolves available tools at runtime from the MCP server. That can reduce maintenance burden and keep agents current, but it also means the tool surface can change after trust was established.
Figure: 22 days, 1 approval, 0 re-reviews. Nothing in this chain is a protocol bug; every step is the system working as designed.
Microsoft’s admin note says Copilot admins will be able to identify dynamic discovery usage, scope or disable affected agents and connectors, and audit interactions in Purview. It also says changed tools are screened at runtime before activation.
Those are the right categories of control. They are also a reminder that the hard part is not “does this tool exist?” The hard part is “was this exact capability, with this exact schema and description, from this exact source, approved for this user and this task?”
That question matters for skills too. A skill can look like documentation while quietly changing agent intent. A plugin can look like a connector while quietly expanding agent capability. An MCP server can look unchanged while its tool descriptions or exposed operations drift underneath the user.
In each case, the security problem is not only malicious installation. It is post-install drift. Microsoft’s own crosswalk concedes the point: of the 11 NSA themes it maps, “shadow MCP servers” and “token and secret exposure” are both rated partial, not covered.
The Supply Chain Lens Fits
The best framing from the Palo Alto post is that MCP servers are becoming unmanaged APIs. Developers deploy them because they make agents useful. Security teams often do not see them because they appear as part of an agent workflow, not as a formal infrastructure change.
That sounds familiar because every supply-chain incident starts with a trust assumption:
- This package is maintained.
- This extension only does what it says.
- This CI token is scoped enough.
- This registry entry still points to the thing we reviewed.
- This plugin cannot change meaningfully after approval.
MCP adds one more assumption:
- This agent tool surface is the same one we intended to expose.
That assumption is fragile. Snyk’s audit of the adjacent skill ecosystem put a number on how fragile: 1,467 of 3,984 published skills — 36.82% — carried at least one security flaw, which we broke down in the first skill-ecosystem audit.
The NSA recommends choosing supported MCP projects, defining trust boundaries, validating parameters, sandboxing tool execution, signing and verifying MCP messages, filtering chained outputs, instrumenting logs, tracking MCP vulnerabilities, and scanning networks for open or vulnerable servers — 9 recommendations that group cleanly into 4 layers.
Figure: The same controls teams already use for software supply chains, applied to a tool surface that can change after approval. Layer 1 is the one most teams skip.
The agent-specific part is that the artifact is not always a package tarball. It may be a skill file, a plugin manifest, a live MCP server, a tool description, a schema, a connector permission set, or a runtime-discovered tool list.
If the agent can read it and act on it, it belongs in the supply chain.
What Teams Should Do Now
- Start with inventory. List every MCP server, connector, plugin, and skill your agents can reach — local developer machines, CI runners, cloud workloads, desktop agent configs. If a tool can touch code, credentials, customer data, tickets, messages, or production systems, it belongs on the list.
- Record the publisher and source for each capability. For code-distributed servers and skills, capture the repository, version, commit, hash, and scan result. For hosted servers, capture the URL, operator, authentication model, exposed tools, and expected data paths.
- Separate static approval from runtime approval. A one-time install approval should not silently cover new tools, broader schemas, changed descriptions, or new credential scopes. When the tool surface changes, require re-review or at least a logged policy decision. Microsoft’s Agent Control Specification is one attempt to make that decision a runtime primitive.
- Keep high-risk tools behind explicit boundaries. Filesystem write access, shell execution, cloud APIs, production databases, messaging systems, deployment actions, and credential-bearing integrations need stricter treatment than documentation lookup or weather data. Human approval still has a place around actions with real blast radius.
- Scan before install, and keep scanning after install. Static scanners catch suspicious skill instructions, malicious subprocess calls, credential access patterns, obfuscation, and poisoned metadata in code-distributed artifacts. Network and runtime scanners are needed for open MCP ports, unexpected tool changes, suspicious tool-call chains, and servers that drift after approval. Anything from a public repo can go through the SkillSafe scanner first.
- Log the agent path, not just the API call. A normal-looking API request can still be unsafe if the agent was steered into making it by poisoned context. Useful logs need to show which agent acted, which tool it selected, what parameters it used, what output came back, and whether any policy blocked an attempted chain.
Where SkillSafe Fits
SkillSafe is focused on the first mile of this problem: verifying the AI skills and plugin-like artifacts developers install before agents consume them. Browse what is already scanned in the skill registry.
That does not replace MCP gateways, cloud runtime monitoring, or enterprise DLP. It complements them. The NSA guidance is valuable because it makes the layered model explicit: choose supported projects, verify origins, constrain execution, monitor outputs, track vulnerabilities, and scan for unauthorized services.
The same logic applies to AI skills. Before a skill changes how an agent behaves, teams should know who published it, what it asks the agent to do, whether it touches sensitive files, whether it contains prompt-injection patterns, and whether the artifact installed by the user matches the artifact that was reviewed.
That is why dual-side verification matters. Publisher-side scanning catches problems before sharing. Consumer-side re-scanning checks what actually arrives before install. Cryptographic verification detects tampering between those two points.
MCP servers, connectors, plugins, and skills are different layers, but they all feed the same agent. Attackers do not care which layer gives them leverage. They care whether the agent has access and whether the user trusts the capability enough to let it run.
Frequently Asked Questions
Is MCP a security risk?
The protocol is not the risk; the deployment is. An MCP server acts with whatever credentials it holds, so a compromised tool call is an action inside your environment rather than a bad model response. The NSA’s May 20, 2026 guidance names 8 problem categories, and the protocol’s own security document treats confused-deputy and token-passthrough attacks as normative concerns.
How do you secure an MCP deployment?
Group the NSA’s 9 recommendations into 4 layers: verify the source before install (supported projects, publisher, version, hash, passing scan), constrain execution at the call (trust boundaries, parameter validation, sandboxing, scoped tokens), verify the stream in flight (signed messages, filtered chained outputs, full-path logs), and respond to drift continuously (CVE tracking, open-server scanning, re-review on change).
Are unauthenticated MCP servers a real problem?
Yes, and they are the hardest to find because an MCP server arrives as a config line, not as a formal infrastructure change. The NSA explicitly recommends scanning networks for open or vulnerable servers. Microsoft’s own crosswalk rates “shadow MCP servers” as only partially covered by a purpose-built governance stack, which is a fair measure of the difficulty.
What is the difference between MCP tool poisoning and post-install drift?
Tool poisoning is malicious metadata present at review time — hidden instructions inside a description that steer the agent. Post-install drift is legitimate metadata that changes after approval: a server adds a write tool on day 14, rewrites its description on day 21, and the agent uses it on day 22 under the original scope. Inventory catches the second; scanning catches the first.
Does the NSA guidance apply to AI skills as well as MCP servers?
It is written for MCP, but the controls transfer directly. A skill file, a plugin manifest, a tool description, a schema and a connector permission set are all artifacts the agent reads and acts on. Snyk found a security flaw in 1,467 of 3,984 published skills, so the population is comparable in both size and risk.
The NSA guidance is a useful line in the sand: agent tooling is infrastructure now. It needs inventory, verification, permission boundaries, and monitoring. The teams that treat it that way will move faster, not slower, because they will know which tools are safe enough to trust.