MCP Server Security Audit: How to Check a Server Before You Connect It

An MCP server security audit is becoming a standard step before any team connects a new server to its agents. The reason is structural: the Model Context Protocol lets the model, not the developer, decide which tools to invoke, when, and with what parameters, and the LLM sees every tool description from every connected server in its context. OWASP's MCP Security Cheat Sheet describes the result as a fundamentally new attack surface combining prompt injection, supply chain attacks, and confused deputy problems. This post is a practical audit sequence built from the OWASP guidance, Invariant Labs' tool poisoning research, and a 2026 academic auditing toolkit. Source

What an audit is defending against

The OWASP cheat sheet names the core risks. Tool poisoning hides malicious instructions in tool descriptions, parameter schemas, or return values. Rug pull attacks change a server's tool definitions after initial approval, turning a trusted tool malicious. Tool shadowing lets one malicious server manipulate how the agent behaves with tools from other trusted servers. The confused deputy problem means the MCP server executes actions with its own, often broad, privileges rather than the requesting user's. Add data exfiltration through legitimate channels, over-scoped OAuth tokens, supply chain attacks on public registries, message tampering, and sandbox escapes from local servers running with full host access. Source

Invariant Labs demonstrated tool poisoning in April 2025, calling it a specialized form of indirect prompt injection. Their example was an innocent-looking add tool whose description, visible to the model but not to the user in a simplified UI, instructed the agent to read the user's MCP config file and pass its contents as a parameter, while reasoning aloud about arithmetic to conceal the file read. Their experiments showed a malicious server could exfiltrate sensitive data and override instructions from other trusted servers, compromising the agent even against trusted infrastructure. They reported that major providers and MCP clients were susceptible at the time. Source

Step 1: Verify the source and the supply chain

Only install MCP servers from trusted, verified sources, review the server's source code and tool definitions before installation, verify package integrity with checksums or code signing, and scan dependencies for known vulnerabilities. OWASP calls out typosquatting specifically: a package named mcp-server-filesytem instead of mcp-server-filesystem is a common attack vector, so verify names character by character. Never allow web content or untrusted data to trigger an MCP server installation. Source

Step 2: Read every tool description like it is a payload

This is the step most teams skip. Inspect all tool descriptions, parameter names, types, and return schemas before approval, and treat the entire tool schema as a potential injection surface, not just the description field. Then pin the reviewed definitions using cryptographic hashes over the complete definition, including inputSchema, outputSchema, and annotations, and require review when they change. OWASP notes why the full hash matters: a flipped readOnlyHint or destructiveHint can change client approval behavior without any visible description change, though a hash detects metadata changes only, not behavior changes behind an unchanged definition, and annotations are hints rather than enforcement. Source

Automated scanning helps here. Invariant released mcp-scan after their disclosure to detect poisoned descriptions and cross-server shadowing, and OWASP recommends mcp-scan or equivalent tooling for detecting poisoned tools and monitoring installed servers for changes. On the schema side, use strict JSON Schema for tool parameters: set additionalProperties to false and apply pattern constraints on string fields so only declared parameters and valid formats are accepted. Source

Step 3: Audit permissions and credentials

Grant each MCP server the minimum permissions needed for its function. Use scoped, per-server credentials and never share tokens across servers. Request narrow OAuth scopes, mail.readonly rather than mail.modify, and prefer ephemeral short-lived tokens over long-lived personal access tokens. For remote servers, validate that each access token was issued for this MCP server as its intended audience, reject invalid tokens, and never pass an MCP access token to an upstream API. Store OAuth tokens in OS-native secure storage such as macOS Keychain or Linux Secret Service, never in plaintext MCP config files. The over-privilege question is not hypothetical: a March 2026 arXiv paper introducing the mcp-sec-audit toolkit notes that MCP servers often expose privileged capabilities like file system access, network requests, and command execution that can be exploited if not properly secured. Source

Step 4: Check the sandbox and the transport

Run local MCP servers in a real sandbox that enforces minimal privileges, restrict file system access to required directories, and disable network access unless explicitly needed. OWASP is specific that a bare chroot is not a process sandbox, and that stdio transport avoids a listening endpoint but does not restrict the server process's file system, network, or credential access. Separate sensitive servers handling payment, auth, or PII from general-purpose ones. Source

For remote Streamable HTTP connections, use TLS, verify server identity, require authentication for non-public tools, and validate the Origin header on incoming requests, rejecting an invalid one with HTTP 403 while not rejecting non-browser clients that send none. Validate the Host header too, and bind local servers to localhost unless network access is explicitly needed. Apply rate limits, quotas, and timeouts per session or tenant. Source

Step 5: Test behavior, then keep watching

Static review is not the whole audit. The mcp-sec-audit toolkit from the 2026 arXiv paper combines static pattern matching for Python-based MCP servers with dynamic sandboxed fuzzing and monitoring via Docker and eBPF, detecting risky capabilities through configurable rule-based analysis and offering mitigation recommendations. That pairing, read the code, then watch what it does in a container, is the shape a serious audit should have. Source

After installation, log all MCP tool invocations with full parameters, user context, and timestamps, feed the logs into your SIEM, and alert on unusual patterns like new tools being called or abnormal call frequency, while redacting secrets and PII from logs. Re-prompt for consent when tool definitions change, since a tool approved yesterday may not be the same tool today. Require explicit user confirmation for destructive, financial, or data-sharing operations, display full tool call parameters rather than a summary, and never auto-approve tool calls in multi-server setups. And treat every tool response as untrusted data, including from approved servers: enforce authorization on subsequent calls in trusted application code, independently of the model's interpretation. Source

Our read

This section is our assessment, not the sources' claims. Most MCP incidents we have read about trace back to step 2: nobody read the tool descriptions as adversarial text. If your team does only one thing from this list, pin hashed tool definitions and re-review on change; it converts the rug pull from a silent failure into a visible diff. The permission work in step 3 maps directly onto the least-privilege for AI agents discipline, and the OAuth audience and scope rules overlap with what we covered in MCP OAuth security. For the broader hardening picture beyond the audit itself, our MCP server security best practices post covers the deployment side. Bottom line: an MCP server is third-party code plus a prompt injection channel, so audit it like both.