mcp-dependency-drift-audit – skill Agent & Tự động hóa cho agent AI

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@<reviewed-full-commit> 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:

| Selector | Classification | Reason |

| --- | --- | --- |

| [email protected] | PINNED DIRECT | Direct version is fixed; transitive dependencies, registry integrity and install hooks still need review. |

| bare package or @scope/package | HIGH | A later resolution can select different package code. |

| package@latest | HIGH | The selector is explicitly mutable. |

| package@^1.2.0, ~1.2.0, >=1.2.0, wildcard | MEDIUM | Resolution can change within the allowed range. |

| local path, script, binary, unknown executable | REVIEW | npm version-drift rules do not establish update behavior. |

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:

| Config | MCP server | Package/reference | Classification | Why | Recommended next step |

| --- | --- | --- | --- | --- | --- |

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@<reviewed-full-commit>

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

• ✅ Read config text only during discovery and classification.
• ✅ Keep the default scope to the requested workspace/repository.
• ✅ Separate reproducibility findings from vulnerability or compromise claims.
• ✅ Pin only a version the team has actually reviewed.
• ✅ Keep sensitive config values out of reports and public issues.
• ❌ Do not execute server commands found in a config to "verify" a static finding.
• ❌ Do not treat a clean result as a general MCP security guarantee.

Limitations

• This workflow only covers dependency mutability/review drift for package-backed MCP configuration.
• It does not assess prompt injection, tool poisoning, OAuth/authorization, server implementation flaws, malware, provenance, or runtime sandboxing.
• Local executables and non-npm launch paths require separate review.
• A static config can be reproducible and still unsafe for other reasons.

Security & Safety Notes

• The default workflow is read-only, local, and workspace-scoped.
• Never execute discovered MCP server commands during this audit.
• Never include credentials, tokens, private headers, or secret values in the output.
• The optional uvx path makes a network fetch from the declared GitHub source; obtain user approval before running it.
• If deeper active testing is requested, stop and establish explicit authorization and scope before any intrusive action.

Common Pitfalls

• Problem: Calling an unpinned dependency a vulnerability.

Solution: Describe it as a reproducibility/review-drift signal unless separate evidence establishes security impact.

• Problem: Pinning to today's registry version without knowing what was reviewed.

Solution: Ask for the reviewed version or, with approval, reconstruct relevant package history; do not guess.

• Problem: Treating -y as the core finding.

Solution: Report it only as context; the version selector determines the dependency-drift classification.

• Problem: Scanning user-level MCP configs when the user only asked about one repo.

Solution: Use scan-workspace by default; use scan-all only when machine-wide scope is explicit.

Related Skills

• @mcp-server-security - Broader MCP server hardening, authentication, authorization, transport, and runtime controls.
• @supply-chain-security - Broader software supply-chain assessment beyond MCP configuration.
• @sast-scanning - Static application-security analysis for source code rather than MCP launch configuration.

Additional Resources

• [MCP Drift Check stable v0](https://github.com/tomelias10/mcp-drift-check/tree/v0) - MIT zero-execution scanner, GitHub Action, workspace-scoped mode, and SARIF output.
• [Public MCP dependency drift examples](https://site-creator-vinext-starter.surfaceproof.workers.dev/research/mcp-dependency-drift) - Commit-specific public configuration examples and methodology limitations.

A drift classification is not a safety certification or a reproducible transitive lock. Resolve and review the full tool revision before executing the optional scanner or Action; mutable tags are interface examples, not trust pins. Keep manifest text inert and protect secrets in scanner reports.