Skip to content

MCP security

Teams wire AI agents to MCP servers faster than anyone reviews them. Every .mcp.json entry is third-party code (or a third-party endpoint) running with the agent’s privileges: typosquatted packages one transposition away from the official server, live secrets committed in server env config, filesystem roots that hand every session the whole home directory, unpinned versions that re-resolve latest on each launch, and remote endpoints nobody put through review.

RingZero treats the MCP config as a first-class security surface.

Scan

ringzero-mcp scan discovers every MCP server configured across your repos — Claude Code, OpenCode, VS Code, Cursor, Claude Desktop — and runs the canonical security checks against each one.

Policy & allowlist

A reviewable org allowlist in .ringzero/mcp-policy.json: propose → review → allow. Warn first, enforce when you’re ready.

MCP Registry

An org-controlled catalog that auto-configures approved MCP servers in every harness — pinned versions, no inline secrets, dev contributions via PR, drift caught in CI.

Usage auditing

Harness hooks record every MCP tool call to an append-only local audit log — who called which tool on which server, and what the policy decided.

Harness guards

A Claude Code hook and an OpenCode plugin evaluate each call against your policy live — denying dangerous commands and unapproved servers in enforce mode.

HarnessConfig discoveryUsage recordingBlockingIntegration
Claude Code.mcp.json, ~/.claude.json✅ PreToolUse / PostToolUse hooksBest-effort (see caveat)ringzero-mcp hook
OpenCodeopencode.json[c]tool.execute.before/afterEnforce mode, primary session@ringzero/opencode-mcp-guard
VS Code.vscode/mcp.jsonScan-onlydiscovery only
Cursor.cursor/mcp.json, ~/.cursor/mcp.jsonScan-onlydiscovery only
Claude Desktopclaude_desktop_config.jsonScan-onlydiscovery only

All five harnesses are also MCP Registry sync targets — the org catalog auto-configures approved servers in each one’s config format.

Trust is derived from open findings, never stored — a server’s status can never disagree with its finding list:

StatusMeaning
FlaggedAny open critical or high finding
UnverifiedOnly medium/low findings open
VerifiedNothing open

The org-wide fleet trust score is max(0, 100 − Σ weights) over all open findings, with weights critical 25 · high 15 · medium 5 · low 2 — deterministic and explainable from the current finding set alone, and it visibly recovers as you remediate.

CategorySeverityWhat it looks forEvaluated by the CLI
TyposquatcriticalPackage-name distance vs registry-official servers
Secrets in configcriticalCredentials inline in server env, args, or URLs
Excessive scopehighCapability broader than the project needs (e.g. filesystem root at $HOME)
Prompt injectionhighHidden instructions in tool descriptions, aimed at the calling agentComing soon (platform)
Unpinned versionmediumServer re-resolves latest on every session launch
Unapproved servermediumNot on the org allowlist✅ (needs a policy)
Unsigned packagelowResolved version published without npm provenance attestationComing soon (platform)

The two platform checks need live registry/server data the local CLI does not fetch; scan output always lists them in its checks manifest with evaluated: false and the reason — never silently missing.