NSA MCP Guidance: Inventory Agent Tools Before They Drift

The AI agent security story this week is not a single exploit. It is the moment the operational guidance caught up with the risk.

On May 20, the NSA’s Artificial Intelligence Security Center published security design considerations for Model Context Protocol deployments. The timing matters: in the days since, security vendors have been repeating 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 fresh Reddit thread on the NSA guidance focused on unauthenticated servers, MCP CVEs, and the fact that the protocol cannot enforce safety by itself. A current 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?

That is why this is the story to watch. 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.

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 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 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. Hidden or manipulated tool metadata can steer an agent in ways the user never intended. 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.

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.

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.

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.

Those recommendations map cleanly to the same controls teams already use for software supply chains: inventory, provenance, least privilege, review gates, runtime monitoring, and vulnerability response.

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 that your agents can reach. Include local developer machines, CI runners, cloud workloads, and 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.

Then 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.

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 can 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.

Finally, 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.

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.

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.