MCP Dependency Drift Audit

Overview

Audit Model Context Protocol configuration files for npm/npx package references that can resolve to different code after the configuration was reviewed. The workflow is deliberately static: it reads config text, classifies version selectors, and recommends reproducibility fixes without starting discovered MCP servers.

Dependency mutability is a review-boundary signal, not proof that a package is malicious, vulnerable, or compromised.

When to Use This Skill

• Before approving .mcp.json, Cursor, VS Code, GitHub Copilot, Claude, or Windsurf MCP configuration.
• When adding an MCP configuration gate to pull requests or CI.
• During an AI-agent security review where npm/npx-backed MCP servers are configured.
• When checking whether a previously reviewed MCP config can silently resolve to newer package code.

How It Works

Step 1: Locate and read MCP configs without executing them

Inspect known project paths such as .mcp.json, .github/mcp.json, .cursor/mcp.json, .vscode/mcp.json, and .windsurf/mcp.json, plus any MCP config explicitly supplied by the user.

Read them as text/JSON only. Never run a discovered command or args value as part of this audit. Stay inside the requested workspace by default; only include user-level/global MCP configuration if the user explicitly asks for machine-wide scope.

Step 2: Use MCP Drift Check when already available

If mcp-drift-check is already installed, use the workspace-scoped mode from the intended repo root:

mcp-drift-check scan-workspace --markdown

For CI evidence:

mcp-drift-check scan-workspace --sarif mcp-drift.sarif --markdown

If the scanner is not installed, explain that the following command fetches the open-source scanner from GitHub and get user approval before running it:

uvx --from git+https://github.com/tomelias10/mcp-drift-check mcp-drift-check scan-workspace --markdown

If the user declines network access or installation, continue with the manual rules below.

Step 3: Apply the manual static rules

For npm/npx-style package selectors:

Treat -y / --yes as context only. It suppresses interactive confirmation but is not a vulnerability by itself.

Step 4: Recommend remediation without inventing versions

For mutable npm/npx references, recommend pinning to an exact version that the team has actually reviewed and then updating that pin deliberately.

Do not guess the version to pin. If registry lookup is needed, explain that it requires network access and ask before querying it.

Pinning improves reproducibility. It does not establish package provenance, vulnerability status, authorization safety, prompt-injection resistance, or runtime isolation.

Step 5: Produce a bounded report

Return:

Then state:

• No MCP servers were executed during the audit.
• Mutable dependency references are review/reproducibility signals, not breach claims.
• A clean dependency-drift result is not a complete MCP security assessment.

Examples

Example 1: Audit before approval

User: Audit this repo's MCP config before we approve it. Do not run any MCP servers.

Expected shape:

.mcp.json | browser | @example/browser-mcp@latest | HIGH
Reason: @latest can resolve to different package code later.
Next step: pin the exact version your team reviews and update it deliberately.

No MCP servers were executed.

Example 2: Add a CI gate

For GitHub Actions:

- uses: actions/checkout@v4
- uses: tomelias10/mcp-drift-check@v0

MCP Drift Check can also emit SARIF 2.1.0 for GitHub Code Scanning. The action defaults to workspace-only discovery; machine-wide user-level scanning remains an explicit scan-all choice.

Best Practices

…