MCP Security Audit

The Problem Is Configuration, Not Protocol

MCP itself is fine as a protocol. The issue is that MCP server security is an afterthought for most teams. They treat MCP servers like npm packages: install, configure, forget. Nobody audits what they're actually giving these tools access to.

I ran the scanner against my own setup first. Here's what I found on a configuration I built myself, knowing the risks:

• Unpinned versions on third-party MCP servers pulling latest from npm at runtime. A supply chain attack away from arbitrary code execution.
• Broad OAuth scopes where a tool needed read access to one repo but had write access to all of them.
• Environment variables with API keys passed to MCP servers that didn't need them, creating unnecessary blast radius.
• No audit logging on tool invocations. If something went wrong, there'd be no forensic trail.

If someone who builds MCP servers for a living has these issues, most teams are in worse shape.

The 11 Threat Categories

The NSA document organizes MCP security risks into 11 categories. Here's what each one means in practice:

1. Access Control Failures

MCP doesn't require authentication by default. Many implementations ship without it. Multiple MCP servers can see each other's data through shared client context, even without direct connections between them.

2. Insecure Data Serialization

MCP transmits structured objects without strict validation. Tool descriptions can contain executable instructions. Deserialization of untrusted payloads without sandboxing is common.

3. Poor Approval Workflows

You approve a tool once. Then its capabilities silently expand. No re-approval, no diff, no notification. The WhatsApp MCP exploit worked exactly this way: benign at install, malicious on second use.

4. Token / Session Security

Bearer tokens without expiration. No refresh or rotation. No replay protection. Tokens passed in URLs or logs. Session hijacking is trivial when these basics are missing.

5. Tool Parameter Injection

Unsanitized parameters passed to shell commands, SQL queries, or file paths. This is the classic injection family (command, OS, code, eval) applied to MCP tool interfaces. Open source MCP agents have already been exploited this way.

6. Tool Invocation Path Confusion

Tool name squatting. A malicious tool with the same name as a legitimate one gets loaded from a public registry. No namespacing, no integrity verification, no strict resolution policy. Classic supply chain attack vector.

7. Unrestricted Resource Access

GitHub MCP servers with blanket repo scope instead of read-only on specific repos. Tools that can read every private repo and write to every public one. The principle of least privilege, applied nowhere.

8. Output Poisoning

Tool outputs trusted blindly by downstream agents. Hidden prompt injections in responses. In chained workflows, one compromised output infects the entire pipeline.

9. Missing Audit Logs

Most MCP implementations log nothing. No record of which tool was called, with what parameters, by which client. When something goes wrong, you're forensically blind.

10. Denial of Service

No rate limiting. No timeouts. No circuit breakers. "Lethargy" attacks exhaust resources through legitimate-looking but overly complex tasks that are hard to distinguish from valid load.

11. Scope Creep

A server deployed for weather data gets repurposed to access sensitive records. Same interface, same permissions, completely different risk profile. The permissions granted for the benign use case persist silently.

What an Audit Covers

The scanner runs 35+ checks across three layers:

Configuration-Level

• Authentication and authorization on server endpoints
• Token and secret management (hardcoded vs. environment variables)
• OAuth scope analysis (actual vs. necessary permissions)
• Version pinning and integrity verification
• Cross-server isolation and context leakage
• Logging and audit trail configuration
• Command and argument injection surface

Code-Level (If Source Available)

• Tool parameter injection paths (shell, SQL, file, eval)
• Input validation and schema enforcement
• Deserialization safety
• Output filtering between pipeline stages
• Privilege escalation through tool execution context
• Error handling that could leak internal state

Cross-Cutting

• Multi-server output flow validation
• Dynamic tool discovery without origin verification
• Known CVE checks against installed server versions
• NSA recommendations checklist (17 items)

What You Get

A findings report. Every finding includes:

• Severity -- CRITICAL, HIGH, MEDIUM, LOW, or INFO
• Evidence -- the specific config line or code path that triggered the finding
• Risk -- what could actually happen if this is exploited
• Remediation -- the specific fix, not a generic recommendation
• CWE mapping -- ties to the Common Weakness Enumeration for compliance reporting

Plus a risk summary with your top 3 exposures and an NSA checklist scorecard (X of 17 recommendations met).

The whole thing runs in 1-2 hours for a configuration audit. Half a day if you want source code review included.

Who Needs This

If your team uses Claude Code, Cursor, Windsurf, Claude Desktop, or any MCP-compatible client with third-party servers connected, you have an MCP server security surface that probably hasn't been audited.

Specifically:

• Engineering teams with MCP servers in their development workflow (GitHub, database, deployment tools)
• Revenue teams with MCP servers connected to CRMs, enrichment providers, and outbound tools
• Security teams trying to get visibility into what MCP tools can actually access across the org
• Companies evaluating MCP adoption who want a security baseline before rolling it out