MCP Security Testing Guide

Use these techniques only on systems you own or are explicitly authorized to test. Run high-impact checks in an isolated environment with synthetic data, test credentials, controlled callback services, and rollback procedures.

Inventory the MCP environment

• List every configured server, command, argument, environment variable, package source, version, transport, listening address, owner, and credential scope.
• Enumerate tools, resources, prompts, schemas, descriptions, defaults, and change notifications exactly as the client receives them.
• Mark which servers process untrusted data and which can write files, execute code, access cloud APIs, send messages, or change production systems.

Test transport and authentication

• Verify remote servers require authentication and TLS, reject anonymous requests, validate token audience, and scope access per user and tenant.
• Confirm local servers bind only where intended. A development HTTP server listening on all interfaces may expose tools to the network.
• Test session identifiers, reconnect behavior, cross-user state, replay, request size, timeouts, and rate limits.
• For STDIO servers, ensure clients invoke a fixed executable and argument array without shell wrappers or user-controlled command fragments.

Test tools and authorization

• Mutate every argument outside its schema: extra properties, wrong types, oversized values, traversal paths, internal URLs, another tenant’s IDs, and encoded alternatives.
• Verify the server authorizes the caller, resource, and action. A valid JSON schema does not provide object-level authorization.
• Replay and race mutating calls, test idempotency, and confirm destructive actions require a clear approval.
• Inspect resource and tool output for instructions that could influence the model or trigger another server.

Practical test examples

Configuration review

# Review commands manually. Do not print secret values.
rg -n '"command"|"args"|"url"|"env"' ~/.cursor/mcp.json

# Flag shell wrappers and floating package versions.
rg -n 'sh -c|bash -c|cmd /c|@latest|npx -y|uvx' ~/.cursor/mcp.json

Argument mutation checklist

{
  "expected": "project-a/file.txt",
  "tests": [
    "../project-b/secret.txt",
    "/etc/passwd",
    "project-a/%2e%2e/project-b/secret.txt",
    "very-long-value...",
    {"unexpected": "object"},
    null
  ]
}

Useful tools

• MCP Inspector – enumerate resources, prompts, tools, schemas, and server responses during authorized testing.
• mcp-scan – inspect MCP configurations and servers for tool poisoning and related risks.
• A JSON schema validator and an intercepting proxy – mutate tool arguments, reject unknown fields, and verify server-side authorization.
• Burp Suite or Caido – intercept chat requests, alter hidden parameters, replay conversations, and compare authorization behavior.
• curl, HTTPie, or Postman – replay API calls with different users, model IDs, tool settings, and conversation identifiers.
• mitmproxy – inspect streaming APIs, WebSocket traffic, agent callbacks, and model-provider requests in a controlled test.
• Semgrep or CodeQL – trace untrusted prompts and model output into shell, SQL, HTML, file, URL, and deserialization sinks.
• Gitleaks or detect-secrets – find model-provider keys, MCP tokens, and credentials in repositories and logs.
• Syft plus Grype, Trivy, or another SCA scanner – inventory and scan agent frameworks, MCP servers, plugins, containers, and transitive dependencies.

How to fix and retest

1. Pin server packages and tool definitions, review changes, and run each server with minimal filesystem, network, and credential access.
2. Validate tool arguments and authorize every request server-side. Namespace tools and separate trust between servers.
3. Require authentication and TLS remotely, safe direct process invocation locally, strict limits, auditable approvals, and complete traces.

Retest checklist

• Repeat the original proof with the same identity, state, model version, and input source.
• Try equivalent variants through every other input channel and fallback model.
• Confirm the control is enforced by the backend or runtime, not only by prompt wording.
• Check logs and alerts, then add the case to a versioned regression suite.

Conclusion

AI security issues are easiest to manage when every piece of content is treated according to its real trust level and every consequential action is controlled outside the model. Keep the test evidence reproducible, limit blast radius, and rerun the suite whenever the model, prompt, retrieval pipeline, tool, server, or policy changes.