mcp-sec-audit: MCP Security Toolkit
- mcp-sec-audit is a pre-deployment auditing toolkit that identifies over-privileged tool capabilities in MCP servers by analyzing both code and metadata.
- It integrates protocol-aware static analysis with dynamic testing using Docker and eBPF to evaluate risk based on exposed capabilities.
- Empirical evaluations demonstrate effective detection and risk scoring, enabling actionable mitigation recommendations for server hardening.
mcp-sec-audit is a pre-deployment security auditing toolkit for Model Context Protocol (MCP) servers, introduced as an extensible framework for identifying when a server exposes more powerful tool capabilities than it needs and for translating those findings into deployment hardening guidance (Huang et al., 23 Mar 2026). In the MCP setting, where servers frequently expose file-system access, network requests, command execution, environment-variable access, and related privileged operations to agent-driven invocation, over-privileged tool surfaces create a high-impact attack boundary. The toolkit is therefore situated within a broader MCP security literature that treats servers, tool metadata, registry provenance, authorization boundaries, and runtime traces as security-critical components rather than mere integration plumbing (Errico et al., 25 Nov 2025).
1. Scope and security rationale
The core premise of mcp-sec-audit is that MCP shifts the trust boundary from the model to the tool server: if a server offers file access, shell execution, network access, environment-variable access, or other privileged operations, then a compromised or poorly designed tool definition can become a high-impact attack surface (Huang et al., 23 Mar 2026). Existing static application security testing tools can identify generic risky code patterns, but the toolkit is motivated by the claim that they do not understand MCP-specific tool metadata or the notion of capability exposure through tool definitions. Its purpose is therefore not merely to find syntactically dangerous code, but to determine what privileged tool capabilities an MCP server actually exposes and how risky those exposures are for deployment (Huang et al., 23 Mar 2026).
This focus aligns with a wider research view that MCP security is structurally different from conventional API security. MCP has been described as replacing static, developer-controlled integrations with dynamic, user-driven agent systems, thereby expanding the attack surface through content-driven exfiltration, tool poisoning, and cross-system privilege escalation (Errico et al., 25 Nov 2025). Other studies similarly frame MCP servers as privileged endpoints whose capabilities can be exploited through prompt injection, parasitic toolchain attacks, caller-identity confusion, or unsafe authorization reuse (Zhao et al., 8 Sep 2025, Huang et al., 8 Mar 2026). Within that landscape, mcp-sec-audit addresses a specific question: whether a server is over-privileged before deployment, either as evidenced in code and metadata or observed dynamically under sandboxed execution (Huang et al., 23 Mar 2026).
2. System architecture and workflow
The toolkit is organized into four conceptual planes. The control plane or knowledge base is centered on an Orchestration Core that manages a DetectionSession, coordinates plugins through a DetectorRegistry, and routes data through the pipelines. Its knowledge base is a TOML-based rulebook, exemplified by files such as detection/rules/keywords.toml, where rules define capability families, indicators for each family, high-risk keywords or regular-expression patterns, and severity weights (Huang et al., 23 Mar 2026).
The core analysis plane contains two engines. The Static Analysis Engine inspects source files and metadata or configuration files using regex and keyword pattern matching, while the Dynamic Analysis Engine runs the server in an isolated Docker sandbox, fuzzes the tool interface, and collects kernel telemetry through eBPF. The output synthesis plane then combines findings through Risk Scoring, a Mitigation Generator, and a Report Builder that emits Markdown or JSON. A separate web detection portal exposes results, statistics, and imported detections through a front end and REST API, including POST /api/detect, GET /api/results, GET /api/stats, and POST /api/import/detection (Huang et al., 23 Mar 2026).
Operationally, the workflow is linear. A user points the CLI at a target server directory; static analysis scans code and metadata to produce initial findings; optional dynamic analysis launches the server in Docker, fuzzes it, and monitors behavior with eBPF; logs are normalized into CEF format and merged with static findings; a weighted risk score is computed; mitigations are generated; and a report is produced (Huang et al., 23 Mar 2026). This makes the toolkit a protocol-aware auditor rather than a generic scanner, because its pipeline is explicitly designed around MCP tool exposure and runtime tool behavior.
3. Static inspection and dynamic verification
The static component is protocol-aware rather than purely generic SAST. It analyzes both Python source code and MCP tool metadata or descriptions in JSON, using efficient regular-expression and keyword matching over these artifacts. Explicit examples of risky patterns include subprocess.run, treated as indicative of command execution, and open(..., 'w'), treated as indicative of file-write capability (Huang et al., 23 Mar 2026). The implementation and evaluation mention capability categories such as file_access, network, and execution, and benchmark results further show detections for file_write, file_read, command_exec, network_outbound, network_inbound, env_access, prompt_injection, tool_sequence_hijack, and param_override (Huang et al., 23 Mar 2026).
A distinctive aspect of the static analysis is that it inspects MCP tool descriptions and metadata for indicators of exposed capabilities, not just dangerous APIs in code. This matters because tool descriptions are part of the MCP security boundary: they can advertise or imply dangerous functionality even when the implementation is indirect (Huang et al., 23 Mar 2026). That design choice is consistent with a broader literature showing that tool descriptions, schemas, and other natural-language metadata are security-relevant because agents rely on them during planning and invocation (Li et al., 3 Feb 2026, Zhang et al., 14 Oct 2025).
The dynamic pipeline is optional but central. Servers are executed inside an isolated Docker container, and a kernel-level eBPF monitor attaches to the container to observe system calls, file I/O, and network connections. These events are serialized into CEF logs, which the Dynamic Behavior Analyzer parses to reconstruct behavior. Dynamic probing is not passive: a protocol-aware MCP fuzzer handles the MCP handshake and stimulates tool endpoints with malicious payloads, including shell injection payloads, path traversal payloads, command injection patterns, and payloads injected into tool arguments (Huang et al., 23 Mar 2026). Because the dynamic analyzer reasons from runtime behavior rather than source syntax, it is language-agnostic in effect and can detect capability evidence even on JavaScript servers that the static analyzer cannot currently parse (Huang et al., 23 Mar 2026).
4. Capability families, scoring, and mitigation output
At the reporting layer, mcp-sec-audit maps implementation cues to capability families such as file_read, file_write, command_exec, and network_*, scores the risk of those capabilities, and generates mitigation recommendations (Huang et al., 23 Mar 2026). The rules are configurable in TOML and specify the capability family, the indicators, and a severity weight. Static and dynamic findings are merged, and the Risk Scoring stage computes a total risk score as a weighted sum of capability confidences. That score is mapped to one of four discrete risk levels: low, medium, high, or critical (Huang et al., 23 Mar 2026).
The report includes identified capabilities, evidence, risk score, and mitigation guidance. Output formats include Markdown and JSON, while the web dashboard can display sortable and filterable tables with severity, result type, and matched keywords (Huang et al., 23 Mar 2026). The mitigation engine is one of the toolkit’s main contributions. For file access, it recommends measures such as “Mount only required directories, preferably read-only” and restricting mount paths. For command execution, it recommends “Run with no-new-privileges” and Docker isolation. More generally, it recommends container isolation, read-only mounts, and restricted network access (Huang et al., 23 Mar 2026).
These recommendations are generic and hardcoded in the current implementation, and the paper explicitly notes that the toolkit does not yet generate fine-grained policies such as per-capability seccomp profiles or deployment-ready Docker or Kubernetes manifests (Huang et al., 23 Mar 2026). This suggests a deployment model in which mcp-sec-audit functions as a capability-discovery and hardening assistant rather than a full policy compiler.
5. Empirical evaluation and measured behavior
The evaluation is reported in three settings. On a synthesized malicious Python server containing command execution, file I/O, and network operations, static analysis detected all three capability categories, produced confidence scores ranging from 0.65 to 0.85, assigned an overall risk of MEDIUM with a total score of 42.5/100, generated 5 mitigation recommendations, and completed analysis in under 2 seconds without Docker (Huang et al., 23 Mar 2026).
On the MCPTox benchmark, the toolkit was evaluated on 45 real-world MCP servers with 491 samples total. It detected 663 capability instances and achieved a 100% detection rate across 491 samples when capability indicators were present. At the sample level, detection was 367/491 = 74.7%, while 124 samples, or 25.3%, had no explicit capability indicators in metadata. The average number of capabilities per sample was 1.35. The most frequent detections were file_write (179), tool_sequence_hijack (136), prompt_injection (87), param_override (60), network_outbound (47), command_exec (46), file_read (43), network_inbound (41), and env_access (24). The resulting risk distribution was 92.3% LOW and 7.7% MEDIUM, with an average score of 9.96 and a maximum score of 49.05 (Huang et al., 23 Mar 2026).
In the Vulnerable MCP Servers Lab, which contained 9 intentionally vulnerable implementations spanning attack vectors including RCE via eval(), path traversal, prompt injection, typosquatting, secrets exposure, and dependency vulnerabilities, static analysis achieved 100% detection on Python servers (2/2) but 0% on JavaScript servers (0/7) because of language limitations. Dynamic analysis, however, achieved 100% coverage on all 9/9 servers. The JavaScript servers averaged 61.4/100 and were classified as HIGH, the malicious-code-exec server scored 65.3, and dynamic scoring was on average +36.2 points higher than static because it incorporated behavior evidence (Huang et al., 23 Mar 2026).
A concise summary of the reported evaluation settings is as follows:
| Setting | Corpus | Reported result |
|---|---|---|
| Synthesized malicious server | 1 Python server | 42.5/100, MEDIUM, under 2 seconds |
| MCPTox benchmark | 45 servers, 491 samples | 663 capability instances; 74.7% sample-level detection |
| Vulnerable MCP Servers Lab | 9 vulnerable implementations | Dynamic coverage 100% on 9/9 |
The paper is explicit about limitations. Static analysis currently supports Python source and JSON metadata and does not yet support JavaScript or TypeScript AST parsing. Pattern-based matching can yield false positives and false negatives, may miss obfuscated or indirect invocations, and does not fully validate semantic runtime constraints such as parameter manipulation or tool-sequence hijacking. Dynamic analysis requires Linux, eBPF support, privileged Docker containers, and manual image builds (Huang et al., 23 Mar 2026).
6. Relation to the broader MCP auditing literature
Within the MCP security literature, mcp-sec-audit occupies the niche of pre-deployment capability auditing for over-privileged servers. Adjacent work audits different but complementary layers. MCPSafetyScanner frames MCP server security around exploit scenario generation from exposed tools, resources, and prompts, demonstrating malicious code execution, remote access control, credential theft, and retrieval-agent deception attacks while using a multi-agent workflow to produce remediation reports (Radosevich et al., 2 Apr 2025). VIPER-MCP combines static taint analysis with dynamic exploit confirmation via proof-of-concept prompts and reports 106 0-day vulnerabilities confirmed through end-to-end exploit traces across 39,884 open-source MCP repositories (Sun et al., 20 May 2026). Agent Audit emphasizes static analysis of Python agent code and deployment artifacts, including structured parsing of MCP configurations and explicit rules for overly broad filesystem access, unverified server sources, missing sandboxing, missing authentication, cross-server tool shadowing, and tool description poisoning (Zhang et al., 24 Mar 2026).
Other audits target ecosystem-scale or protocol-scale weaknesses rather than individual capability exposure. MCPDiFF studies description–code inconsistency across 10,240 real-world MCP servers and reports that approximately 13% exhibit substantial mismatches that can hide undocumented privileged operations, hidden state mutations, or unauthorized financial actions (Li et al., 3 Feb 2026). MICRYSCOPE examines cryptographic misuse across 9,403 MCP servers, identifying 720 with cryptographic logic and a 19.7% misuse rate among those servers (Yan et al., 3 Dec 2025). A measurement study of remote MCP authentication finds 7,973 live remote servers, of which 40.55% expose tools without authentication, and identifies 325 confirmed OAuth-related flaws across 119 testable OAuth-enabled servers (Zhou et al., 21 May 2026). A separate analysis of caller identity confusion reports that 2,846 of 6,137 servers, or 46.4%, exhibit insecure authorization behavior due to missing caller binding or persistent authorization reuse (Huang et al., 8 Mar 2026).
Research on auditing also extends beyond server code. Vision-specific protocol auditing has analyzed 91 publicly registered vision-centric MCP servers, finding schema-format misalignments in 78.0% of systems, coordinate convention errors in 24.6%, and privilege escalation or data leakage risks in 41.0% of audited systems (Tiwari et al., 26 Sep 2025). Trace-grounded evaluation in MCP Pitfall Lab argues that MCP traces and validators should be treated as the source of truth rather than agent self-report, reporting divergence between agent narratives and trace evidence in 63.2% of runs and in 100% of sink-action runs within a preliminary email-system corpus (Hao et al., 23 Apr 2026). Privacy-preserving audit has also emerged as a separate line: zk-MCP combines zero-knowledge proofs with bidirectional MCP communication to let an auditor verify message format, general message types, and usage statistics without learning message contents, with verification overhead reported below 4.14% of total communication costs (Jing et al., 11 Dec 2025).
Taken together, these results indicate that “audit” in the MCP literature encompasses several layers: capability exposure, code-level weakness detection, description fidelity, cryptographic correctness, authorization boundaries, protocol conformance, runtime traces, and privacy-preserving verification. A plausible implication is that mcp-sec-audit is best understood not as a complete MCP security solution, but as one specialized component in a larger auditing stack: it identifies over-privileged tool capabilities and recommends hardening before deployment, while complementary mechanisms such as deny-by-default per-server tool allowlists and attested server admission can bound which servers and tools may be driven at runtime (Metere, 22 May 2026).