Skip to content
All tools
betaModel Context Protocol Guard

MCP Guard

Static audit of your MCP server configuration.

In the wild— MCP Guard runs— Issues surfaced— Countries· opt-in only

The problem

MCP gives agents access to tools, files, and APIs — and most configs ship with plaintext tokens, auto-installed remote servers, and a filesystem server rooted at your home directory. One bad config line is a foothold.

What it does

Paste your claude_desktop_config.json or mcp.json and get a scored audit: plaintext secrets, unpinned remote installs (npx -y), shell pipes, and over-broad filesystem roots — each with a concrete fix. The config never leaves the request.

Capabilities

  • Detects plaintext secrets embedded in server env
  • Flags unpinned remote installs (supply-chain risk)
  • Catches shell pipes / destructive command chains
  • Flags filesystem servers rooted at / or $HOME
  • Runs in the browser or as an npm package / CI gate

What MCP Guard flags in an MCP config, and the fix for each

MCP Guard reads your claude_desktop_config.json or mcp.json and flags the configuration lines that most often turn an MCP server into a foothold. Each finding comes with a concrete fix:

  • Plaintext secrets in a server’s env block. API tokens pasted into the config are readable by anything that can read the file, and they leak through backups and screen-shares. Fix: Load them from a secrets manager or the OS keychain, and rotate any token that was ever stored in plain text.
  • Unpinned remote installs (npx -y package). Every launch fetches whatever version is current, so a compromised or swapped release runs without review. Fix: Pin an exact version, and review the changes before you upgrade.
  • Shell pipes and destructive command chains. A server command that pipes into a shell, or chains destructive commands, hands an agent far more power than the tool needs. Fix: Call the binary directly, with fixed arguments.
  • Filesystem servers rooted at / or $HOME. These expose SSH keys, cloud credentials and browser data to any prompt that steers the agent. Fix: Scope the root to the one project directory the task needs.

Each finding carries a severity and feeds a 0–100 risk score, so you can fix the high-severity ones first. Subscribers can also run the same checks as a CI gate that fails the build on any high-severity finding.

How you run it

Paste your config in the browser for a scored audit. Subscribers can install @playciso/mcpguard and fail CI on any high-severity finding.

Roadmap

  • Static config audit + scoring
  • In-browser audit form
  • npm package + CI gate
  • Runtime proxy: allow-lists + redaction
  • Tamper-evident audit log

FAQ

What is MCP governance?

MCP governance is the set of controls that keep AI agents’ use of Model Context Protocol (MCP) servers safe: an allowlist of approved servers, least-privilege scoping of the tools and data each exposes, authentication and secret handling, human approval for high-impact actions, and full logging of every tool call. It matters because an MCP server hands an agent real capability in your environment.

What does MCP Guard check?

MCP Guard statically audits an MCP server configuration for the things that make one risky — over-broad permissions and tool scopes, weak or missing authentication, and unnecessary exposure — and flags where it deviates from least-privilege governance.

Why do MCP servers need governance?

Because an MCP server exposes tools, data or actions an AI agent can call, and an agent processing untrusted content can be steered by prompt injection into misusing that access. Governing the server — least privilege, auth, approval gates, logging — bounds what a hijacked agent can actually do.

Included with any PlayCISO plan

MCP Guard runs inside PlayCISO for subscribers. The source stays private — no public repos, nothing to fork, nothing for attackers to study. Monthly and yearly plans all include every tool.

The tools people use most on PlayCISO.

All tools