The MCP security landscape.

The MCP ecosystem is six months old and growing exponentially. The npm and pip ecosystems took roughly twenty years to develop the social and tooling infrastructure for trust — registries, signing, CVE feeds, security advisories, audit programs. MCP has none of that yet.

This essay is an attempt to draw the threat map. Five categories, ranked by how much new tooling each one needs. Two categories are well-served by existing scanners. Three are not.

The agent will install whatever you let it. The first major MCP supply-chain incident is a question of when, not if. The argument for an "MCP TÜV" is that infrastructure-of-trust takes years to build, and we do not have years.— Manifesto, About page

Five threats, ranked by tooling gap.

01 · Dependency CVEs

Boring, well-understood, well-tooled. Three independent scanners (Trivy, Grype, OSV) cover this category with high confidence. Multi-engine scanning helps mainly because the underlying CVE databases differ slightly. This is solved.

02 · Hardcoded secrets

Also boring, also well-tooled. The interesting tension is recall vs precision: detect-secrets is high-recall and high false-positive (entropy-based); Gitleaks is the opposite. Run both, accept that the union has noise, and weight accordingly. Mostly solved.

03 · Supply-chain provenance

Knowable but rarely known. Most MCP servers have no SBOM, no signature, no clear chain from source to artifact. Syft can generate the SBOM after the fact. The gap is cultural — maintainers don't ship them.

04 · Tool-shadowing & prompt injection

This is where it gets MCP-specific. A tool description is, mechanically, instructions to the agent. A malicious tool can include language that nudges the agent's next decision. There are no mature scanners for this. Our custom YARA rules are a first pass; they catch obvious cases but are pattern-based.

05 · Permission overreach

An MCP server declares the surface it needs — filesystem, network, environment variables. Almost nothing checks whether the server's actual code stays inside that surface. This is the largest blind spot. Building a scanner for it is on the roadmap.

What MCP looks like compared to npm circa 2014.

The parallel is uncomfortable but instructive. npm in 2014 had similar dynamics: rapid growth, no signing, no SBOM, registry-as-trust-substitute, and an emerging awareness that "popular" did not mean "safe". The first major npm supply-chain incidents (left-pad, event-stream) followed within four years.

The honest read is that MCP has the same shape, on a faster clock. Agents install packages without human review. An npm developer in 2014 at least had to type the install command. An agent today reads a recommendation and runs the install — sometimes typo-squatted, sometimes from a registry the user has never visited.

What an MCPAmpel-grade posture looks like.

Concrete recommendations, in priority order:

1. Run a multi-engine scan before connecting any MCP server. One scanner is a liability. Free options exist; use them.
2. Pin tool versions. If the agent asks to "install latest", say no. Pin a digest and update it on a schedule you control.
3. Quarantine credentials. Do not let the agent run an MCP server with the same credentials your CI uses. Scope.
4. Read the tool descriptions. Once. Just once. Most agents will read them every time, and the descriptions are instructions to them.
5. Set a minimum trust score in CI. Whatever scanner you use, fail the build below the threshold.

# GitHub Action — fail PRs below trust score 7.0
- uses: mcpampel/action@v1
  with:
    repo: ${{ github.repository }}
    min-score: 7.0
    fail-on: red,yellow

The boring conclusion.

MCP security is mostly hygiene. The dramatic threats — prompt injection, tool-shadowing — exist and are real, but they account for a minority of the findings in our dataset. The bulk of the risk is the same risk every package ecosystem has always faced: old dependencies, leaked secrets, broad permissions.

The new shape of MCP changes one thing materially: the agent is the install path. That collapses the human review step that npm and pip rely on. Either we add scanners back into that path, or we accept whatever the model recommends. Camp two is not a security model.