What do security teams get wrong about MCP supply-chain risk?

Why Security Teams Misread MCP Supply-Chain Risk

MCP supply-chain risk is often underestimated because teams treat it like a conventional software vulnerability problem. That framing misses the real attack surface: registries, package metadata, manifests, build outputs, and the trust paths that deliver an MCP server into production. A malicious package can redirect tool behavior long before static code review notices anything suspicious, which is why identity and provenance matter as much as code quality.

This pattern is visible across the broader NHI landscape. NHIMG’s The State of Non-Human Identity Security shows that visibility and control gaps remain common, while the LiteLLM PyPI package breach demonstrates how package delivery can become the compromise path. In MCP environments, the risk is not just what the server does, but what was published, signed, mirrored, and trusted on the way in. Current guidance suggests that security teams should evaluate the package lifecycle, not only the server binary.

In practice, many security teams encounter MCP compromise only after a poisoned dependency or manifest has already altered downstream trust decisions, rather than through intentional supply-chain verification.

What a Practical MCP Supply-Chain Control Model Looks Like

Effective MCP defense starts with provenance. Security teams should require cryptographic integrity for artifacts, verify publisher identity, and treat metadata as security-relevant input. That means reviewing package source, version history, checksum consistency, build pipeline trust, and manifest changes with the same seriousness as application code.

For teams using registries or internal package mirrors, the control objective is to prevent an attacker from substituting a malicious server, extension, or tool definition without detection. The OWASP Non-Human Identity Top 10 is useful here because it frames secrets, identity, and lifecycle issues as first-class attack paths. For broader delivery-chain guidance, NIST Cybersecurity Framework 2.0 supports governance, protect, detect, and recover functions that map well to MCP publishing workflows.

• Pin trusted publishers and verify package signatures where available.
• Scan manifests, not just code, for tool endpoints, credential references, and unexpected privilege requests.
• Separate build-time trust from runtime trust so a compromised CI job cannot silently alter release artifacts.
• Use allowlists for approved registries and require review for new MCP server sources.

NHIMG research on the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack reinforces a practical lesson: once trust in a distribution path is broken, downstream code scanning arrives too late. These controls tend to break down in fast-moving CI/CD environments because teams prioritize release velocity over package-level provenance checks.

Where the Standard Answer Breaks Down

Tighter supply-chain control often increases release friction, so organisations must balance provenance assurance against developer throughput. That tradeoff becomes sharper when MCP components are sourced from multiple registries or patched quickly to support new tools. Best practice is evolving, and there is no universal standard for MCP registry governance yet, but the direction is clear: trust should be explicit, short-lived, and continuously revalidated.

One common mistake is assuming that a signed package is automatically safe. Signature validation only proves origin, not intent. If the maintainer account, build pipeline, or metadata store is compromised, a valid signature can still wrap malicious behavior. Another gap appears when teams harden server code but ignore the “last mile” where manifests map tool permissions, endpoints, and environment variables into runtime behavior. The emerging lesson from OWASP Agentic AI Top 10 is that autonomous systems expand the blast radius of a poisoned dependency because they can invoke tools, chain actions, and persist trust decisions faster than human reviewers can intervene.

Security teams should therefore test MCP supply-chain assumptions with adversarial scenarios: compromised maintainer, tampered manifest, stale mirror, and poisoned internal package. The blind spot is usually not the server itself, but the path that convinces the platform to trust it.

Related resources from NHI Mgmt Group

• What do security teams get wrong about agentic supply chain risk?
• What do security and risk teams get wrong about friendly fraud?
• What do security teams get wrong about bonus abuse and account farming?
• What do security teams get wrong about data visibility and NHI risk?