MCP Supply Chain Security: Auditing Servers, Extensions, and Skills Before They Compromise Your Agent

The problem: your agent's attack surface just got a lot bigger

Six months ago, securing an AI agent meant thinking about prompt injection and tool permissions. Today, a typical production agent pulls in a dozen MCP servers, a handful of editor extensions, and increasingly, third-party "skills" — bundles of instructions and helper scripts that get loaded into context and sometimes executed directly.

Each of these is unaudited code from someone you don't work with, running with whatever permissions you granted the agent. An MCP server is a Node or Python package like any other — it can have a malicious postinstall script, a compromised maintainer account, or a dependency three levels deep that got typosquatted. A skill is a markdown file plus scripts that an agent will read and, in many harnesses, execute without a human reviewing every line first.

This is a classic software supply chain problem wearing a new hat. The npm and PyPI ecosystems have dealt with malicious packages for a decade. What's new is that agents now auto-discover and load these packages based on a config file, often without the human in the loop reading the code — and the blast radius includes whatever credentials, file system access, or API keys the agent's process holds.

In September 2026, this stopped being theoretical. Perplexity shipped Bumblebee, a read-only scanner purpose-built to check MCP servers, dependencies, and editor extensions for suspicious packages before you install them — and it started trending on GitHub within days. That's a signal worth paying attention to: the tooling market is telling you this risk is real enough to build dedicated infrastructure for.

Why this is different from normal dependency scanning

You already run npm audit or pip-audit in CI. Why isn't that enough?

MCP servers run with elevated trust by design. The whole point of an MCP server is to give the model access to something — a database, your filesystem, a browser, your email. A compromised MCP server isn't a library with a bug; it's a live conduit between an LLM and your systems.
Discovery is often manual and undocumented. Someone found an MCP server in a Discord, a tweet, or an awesome-list, and added it to .mcp.json or claude_desktop_config.json. It never went through the PR review your other dependencies get.
Skills and agent instructions are executable prose. A SKILL.md file can contain both social-engineering-style instructions aimed at the model and actual shell scripts. Standard SCA (software composition analysis) tools don't parse either.
The agent is the thing running the audit. If you ask the agent itself to "check if this MCP server is safe," you're trusting the same reasoning loop that a malicious server is trying to manipulate.

A practical audit workflow

Here's a checklist you can run before adding any MCP server, skill, or extension to a project — whether you're doing it by hand or scripting it.

1. Provenance check

Is the source repo verifiable (official org, not a fork with a similar name)?
Does the maintainer have a track record, or is this a brand-new account with one repo?
Is there a pinned version/commit hash, or are you pulling latest?

# Quick provenance check for an npm-based MCP server
npm view @scope/mcp-server-name --json | \
  jq '{name, version, maintainers, repository, time}'

2. Static scan of the package and its dependency tree

Run standard SCA tooling first — it's cheap and catches known-bad packages instantly.

# npm ecosystem
npm audit --audit-level=high

# Python ecosystem
pip-audit -r requirements.txt

# Cross-ecosystem, catches typosquats and install-time scripts
osv-scanner --lockfile=package-lock.json

Specifically look for postinstall, preinstall, and prepare scripts — these run automatically on npm install before you've even looked at the code:

grep -r '"\(pre\|post\)install"' node_modules/*/package.json 2>/dev/null | head -20

3. Permission scoping — what can this MCP server actually touch?

Read the server's tool definitions before wiring it in. An MCP server that claims to "search documentation" but registers a write_file or execute_shell tool is a red flag.

# Pseudocode for auditing tool surface before trusting a server
import json

def audit_mcp_tools(server_manifest_path: str):
    with open(server_manifest_path) as f:
        manifest = json.load(f)

    risky_verbs = {"write", "delete", "execute", "exec", "shell", "eval", "spawn"}
    flags = []

    for tool in manifest.get("tools", []):
        name = tool["name"].lower()
        desc = tool.get("description", "").lower()
        if any(v in name or v in desc for v in risky_verbs):
            flags.append((tool["name"], tool.get("description", "")))

    return flags

If a server registers filesystem write or shell-execute tools, run it in a sandboxed environment (a container with no access to real credentials) before granting it production scope. This is the same principle behind sandboxing LLM-generated code — apply it to third-party tool servers too.

4. Runtime allowlisting, not blanket trust

Most agent harnesses let you scope which tools a server is allowed to call without a human approval step. Default to deny, and only allowlist the specific tools you've reviewed:

{
  "mcpServers": {
    "docs-search": {
      "command": "npx",
      "args": ["-y", "@vendor/docs-mcp-server"],
      "allowedTools": ["search_docs", "get_page"]
    }
  }
}

Never allowlist * for a third-party server you haven't fully read.

5. Skill and instruction auditing

For markdown-based skills (Claude Skills, agent "personas," reusable prompt bundles), treat the file the same way you'd treat a shell script from a stranger:

Search for instructions that try to override system-level rules ("ignore previous instructions," "you are now in developer mode")
Check any bundled scripts for network calls to unfamiliar domains
Confirm the skill doesn't request credentials or secrets be echoed into its own logic

# Cheap heuristic scan across a skills directory
grep -riE "ignore (previous|prior) instructions|override|exfiltrate|send.*(api.key|token|password)" \
  ./skills/**/*.md

This won't catch a sophisticated attack, but it catches the lazy ones, and lazy attacks are still the majority.

Tool comparison: what to reach for

Tool	Scope	Best for	Limitation
`npm audit` / `pip-audit`	Known CVEs in dependency tree	Fast, free, CI-friendly baseline	Misses zero-days and logic-based attacks
`osv-scanner`	Cross-ecosystem vuln + lockfile diffing	Catching typosquats, version drift	Still signature-based
Bumblebee (Perplexity)	MCP servers, editor extensions, dependencies	Purpose-built for the agent supply chain	New, read-only, still maturing
Manual tool-surface audit	MCP tool manifests	Catching over-scoped permission requests	Manual, doesn't scale without scripting
Sandboxed trial run	Any new server/skill	Observing real behavior before trusting	Requires sandbox infra (containers, no real creds)

Use them layered: automated scan first (cheap, fast), tool-surface audit second (catches scope creep), sandbox trial third (catches anything that only shows up at runtime), and manual review of instructions/skills as an ongoing habit, not a one-time gate.

Common pitfalls

Trusting a GitHub star count as a security signal. Stars measure popularity, not safety review. A popular repo can still ship a compromised release if a maintainer's account is taken over.
Auditing once and never re-checking on update. MCP servers update like any package. Pin versions and re-run your checklist on every version bump, not just on first install.
Letting the agent decide what's safe. Don't ask the model "is this MCP server safe to install?" and act on its answer alone — that's asking the reasoning system to grade its own exam, and it's exactly the kind of decision a well-crafted prompt injection is designed to manipulate.
Granting shell/filesystem scope "just in case." Every unused permission is unused attack surface. Scope tools to exactly what the agent's task requires and revisit as tasks change.
Ignoring skills because they're "just markdown." A skill file is instructions plus, often, executable scripts. Review both parts.

Next steps

Start small: pick the MCP servers you already have wired into your team's agents and run steps 1–3 above against each one this week. Most teams find at least one server with broader tool scope than anyone intended. Then bake the allowlisting pattern from step 4 into your team's default agent config so new servers start deny-by-default instead of trust-by-default.

If you're building agent systems and want to go deeper on the security model — sandboxing, identity, tool contracts, and the rest of the OWASP Agentic AI Top 10 — that's exactly the kind of production-readiness gap our AI Engineering cohort is built to close.