This article was originally published on LucidShark Blog.
The NSA published a formal Cybersecurity Information Sheet on Model Context Protocol (MCP) security today. If you use Claude Code, Cursor, or any MCP-enabled AI coding tool in a professional context, this document is addressed to you.
Formal government security advisories are not written about niche hobbyist protocols. They are written when an attack surface has become large enough, and serious enough, that the intelligence community considers it a systemic risk. The NSA's decision to publish on MCP signals a transition: MCP is no longer a developer playground experiment. It is production infrastructure that carries real security obligations.
This article explains what the advisory means in practical terms, where the NSA's analysis falls short, and five concrete steps you should take this week.
What MCP Actually Does (And Why That Matters for Security)
Model Context Protocol is the bridge between large language models and the rest of your computing environment. A Claude Code session with MCP enabled can read files from your codebase, execute shell commands, query databases, make HTTP requests, and call external APIs, all under the direction of the model based on your natural language instructions.
This is genuinely powerful. It is also a fundamentally different security model from traditional software.
In traditional software, a function either has permission to do something or it does not. Access controls are enforced at the call site. Auditing means checking permissions and API contracts.
In an MCP-enabled agentic workflow, the model decides which tool to call based on its interpretation of context, instructions, and tool descriptions. An attacker who can influence any of those three inputs can influence what the model does, without ever touching the underlying code directly.
The attack boundary is semantic, not syntactic. No firewall rule catches a carefully crafted tool description that manipulates model behavior. No SAST scanner flags a malicious intent embedded in a prompt. This is the core challenge the NSA advisory begins to address.
What the NSA Advisory Gets Right
The advisory is a reasonable starting point. Its core recommendations focus on authentication and authorization at the transport layer: ensure MCP servers require authentication before accepting connections, enforce authorization checks on individual tool calls, and treat MCP servers as untrusted endpoints by default rather than implicitly trusted local services.
These recommendations are correct. Most MCP server implementations in the wild today have weak or absent authentication. A developer running an MCP server locally often assumes "it's localhost, it's fine." But in an environment with other running processes, shared containers, or even browser-based attacks, localhost is not a trust boundary.
The advisory's emphasis on minimal permissions is also sound. An MCP server that can only read files in your project directory is a smaller risk than one with arbitrary filesystem access. An MCP server that cannot make outbound network calls cannot exfiltrate data. Scoped permissions reduce blast radius.
What the Advisory Misses
The transport layer is necessary but not sufficient. The advisory does not adequately address two harder problems.
The code layer problem. An MCP server that passes all authentication and authorization checks can still contain malicious logic. A server that reads environment variables and passes them to an outbound HTTP call is a credential exfiltration tool dressed as a legitimate utility. Static analysis of MCP server code before installation catches many of these cases: hardcoded remote endpoints, suspicious subprocess calls, unusual credential access patterns, data flows that route sensitive information outbound.
The advisory mentions "vetting" MCP servers but treats it as a policy matter rather than a technical one. For teams managing dozens of MCP servers across dozens of developer machines, "manually review each server" is not a scalable policy. Automated static analysis of MCP server code at install time is the practical implementation of vetting.
The natural language description attack. MCP tool descriptions are written in natural language. They are read by the language model, not by a compiler or an access control system. A malicious tool description can instruct the model to take actions that the underlying code has permission to take but that the developer never intended.
Example: A tool described as "optimizes your code for performance" that also instructs the model, embedded in the description, to copy any environment files it encounters into the project's public directory. The code itself has read permission for env files and write permission for the public directory. The access controls pass. The attack succeeds through semantic manipulation.
The NSA advisory does not address this vector. The practical mitigation is treating tool descriptions as untrusted input and applying scrutiny to any MCP server whose description seems to request more context or permissions than its stated purpose requires.
Five Concrete Steps to Take This Week
1. Inventory Every MCP Server in Your Environment
Most developers have installed MCP servers one at a time over several months and have lost track of what is actually running. Run a full inventory: what servers are installed, what permissions they have requested, and when they were last updated.
# List MCP servers in Claude Code config
cat ~/.claude/settings.json | jq '.mcpServers'
# Check for project-level MCP configs
find . -name ".mcp.json" -not -path "./node_modules/*"
If you find servers you do not recognize, remove them first and investigate second.
2. Review Source Code Before Installing Any MCP Server
This is the principle of "do not run code you have not read" applied to AI tooling. Before adding a new MCP server, read the source. If it is not open source, treat it as untrusted. Look specifically for: outbound HTTP calls, subprocess execution, filesystem access beyond what the stated purpose requires, and access to environment variables.
Tools that automate this review, such as static analysis scanners that check MCP server code for suspicious patterns, reduce the friction enough that developers will actually do it rather than skip it.
3. Scope Permissions to the Minimum Necessary
Claude Code and other MCP clients allow you to configure which tools each server can expose and which path prefixes it can access. Use these controls.
// .mcp.json scoped permissions example
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["@modelcontextprotocol/server-filesystem", "/workspace/src"],
"permissions": ["read"]
}
}
}
A server scoped to read-only access on your src/ directory cannot write files, cannot read your .env, and cannot touch your deployment configuration. Least privilege is not just a compliance checkbox: it is a practical limit on what a compromised server can do.
4. Treat All MCP Tool Output as Untrusted Input to Your Codebase
Code generated through MCP tool calls should be subject to the same quality and security checks as code generated any other way. MCP output is not more trustworthy because it came from a tool rather than direct model output. In some ways it is less trustworthy, because the tool may have been manipulated upstream.
Pre-commit hooks that run static analysis on AI-generated diffs, security scanners that flag new dependencies, and test coverage checks that catch regressions are all relevant here. The goal is to catch problems before they reach main, regardless of how the code was generated.
5. Keep Your Validation Stack Local
The NSA advisory does not address the data residency implications of cloud-based AI security tools, but they are significant. If your code quality and security validation runs in a vendor's cloud, your code is on a vendor's server. For proprietary codebases, sensitive business logic, and any environment subject to compliance requirements, that is a meaningful risk.
Local-first validation tools process your code on your own hardware, using your own API keys, with no intermediate server seeing your codebase. This is not just a privacy preference: it is a security control that eliminates an entire class of supply chain risk.
What This Means for Your Tooling
The pattern across all five recommendations is the same: move security decisions as close to your codebase as possible, minimize trust dependencies on external vendors, and automate the checks that humans will not reliably do manually.
This is the design philosophy behind LucidShark: local-first code quality analysis that runs on your machine, integrates with Claude Code via MCP, and surfaces security regressions, suspicious dependency changes, and quality drift before they merge. No cloud dependency. No code leaving your machine. Open source, so the tooling itself is auditable.
The NSA advisory is a signal that the AI coding security category is maturing. Government-level attention means enterprise adoption follows, and enterprise adoption means stricter security requirements for everyone in the supply chain. Getting your security posture right now, while the category is still defining its standards, puts you ahead of the curve rather than scrambling to catch up.
The protocol that connects your AI assistant to your codebase is now officially a security concern worth federal attention. Act accordingly.
Add a local security layer to your AI coding workflow.
LucidShark runs entirely on your machine, integrates with Claude Code via MCP, and catches security regressions, suspicious dependency additions, and quality drift before they reach main. No code leaves your machine.
Install LucidShark
Top comments (0)