The NSA published 17 pages on MCP security. Here it is as a checklist you can run today

For years, government AI guidance stayed at the level of “secure your AI systems” which is about as actionable as “drive carefully”. In May that changed. The NSA Artificial Intelligence Security Center published a Cybersecurity Information Sheet on the Model Context Protocol specifically. Seventeen pages, public, aimed at people wiring agents to tools.

That tells you something about where incidents are actually happening. Not in the model. In the plumbing between the model and your tools.

I went through the public summaries and the sheet itself and pulled out the themes. Here is each one translated into a check you can run today.

1. Inventory every MCP server you actually run

Most people cannot list their MCP servers without opening three config files. Check now:

• Search your projects for .mcp.json, claude_desktop_config.json, and similar config files
• For each server, note: what it does, where it came from, what credentials it holds

If the list surprises you, that is the finding.

2. Pin versions, stop floating

Servers pulled with a floating tag change under you. When an MCP supply chain incident hits, pinned versions let you answer “am I affected” in seconds instead of guessing.

• Pin to an exact version
• Subscribe to the release feed of each server you depend on

3. Treat tool descriptions as untrusted input

This is the one Microsoft warned about in June: poisoned tool descriptions steering agents into leaking data through perfectly approved tool calls. The description field is text that influences your model. Your model reads it. So it is an input.

• Read the description of every tool you install, before install
• Diff descriptions when you update a server, not just the code

4. Session hygiene

The NSA sheet calls out message replay and unauthorized reuse of valid sessions. Practical version:

• Rotate tokens on a schedule you can actually keep
• Bind sessions where the protocol allows it
• If your client supports session timeouts, turn them on

5. Least privilege per tool

A search tool does not need write access. A filesystem reader does not need the whole disk.

• For each server, list what it can touch and cut it to what it needs
• Prefer read-only grants wherever the server offers them

6. Egress allowlists

An MCP server that can reach the entire internet can exfiltrate the entire context. Whitelist the domains it genuinely needs. If the server refuses to work behind an allowlist, ask yourself why.

7. Log tool calls with arguments and results

The sheet’s guidance lands on auditability. Without a log of which tool ran with which arguments, every incident investigation starts with “we are not sure what the agent did”.

• Route tool call logs somewhere a human looks
• Include arguments, results, and the session identifier

The honest part

None of these are exotic. That is the point. The sheet exists because the boring layer is where the losses are. A scanner like the one I maintain catches a subset of this automatically. The rest is habits, and habits are what the checklist is for.

I keep a 12 point preflight version of this for MCP setups. Drop a comment and I will send it over, free, no signup.

Sources

• NSA sheet: https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf
• Independent summary of scope: https://innovatecybersecurity.com/news/mcp-security-control-surface/
• Microsoft on poisoned tool descriptions: https://www.microsoft.com/en-us/security/blog/2026/06/30/securing-ai-agents-ai-tools-move-from-reading-acting/

---

If you want to run checks like these on an MCP server or a .claude/ directory before you install it, I maintain mcpscan, an open-source scanner for tool poisoning, risky permissions and leaked secrets. Issues and false-positive reports are welcome.

Originally published on DEV. Discussion happens there.