MCP supply chain security means treating servers as artifacts

At a glance

What this is: This is a governance pattern for MCP supply chain security that treats every MCP server as a controlled production artifact, with version pinning, CI builds, signing, scanning, and reviewed catalog promotion.

Why it matters: It matters because MCP servers can carry secrets, reach corporate systems, and execute code, so IAM, PAM, and NHI teams need catalog-level controls instead of runtime trust.

👉 Read Obot's analysis of MCP supply chain security and catalog governance

Context

MCP supply chain security is the discipline of controlling how Model Context Protocol server artifacts are built, signed, scanned, and promoted before they reach users. The core problem is simple: when a client pulls a server directly from an upstream package at runtime, the code can change without review, pinning, or audit.

That matters for identity governance because MCP servers often sit between AI workflows and external systems, including data sources, file systems, and credentials. Once a server can reach sensitive services, the trust model has to move from convenience to controlled artifact management.

The article’s central claim is that production MCP should behave like any other controlled software supply chain, with catalog approval acting as the enforcement point. That is a typical security need for fast-moving AI tool ecosystems, not an edge case.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create a bigger secrets risk than ordinary package installs?

A: Because the threat is not only code on disk, but code that executes inside a real user context and can read live credentials immediately. A malicious MCP server can preserve expected functionality while harvesting SSH keys, cloud tokens, and configuration files in the background.

Q: What breaks when MCP servers are allowed to run from latest upstream code?

A: The review model breaks first, because the code that runs is no longer the code that was approved. Rollback also becomes unreliable, since the registry can change without notice and there is no stable version to compare against. In practice, latest turns a governed tool into an unmanaged trust decision at runtime.

Q: Who should control promotion of MCP server updates?

A: The team operating the catalog should control promotion, because that is where review, scope, and visibility decisions become enforceable. If promotion happens automatically at runtime, teams lose the ability to track what changed, when it changed, and why. Catalog governance is the point where identity, access, and change management meet.

Technical breakdown

Why runtime package fetching breaks MCP governance

When an MCP client starts a server from npx or uvx, it downloads and executes whatever the upstream registry serves at that moment. That means the running code is not a stable artifact, so review, pinning, rollback, and audit all become unreliable. In identity terms, the server behaves like an NHI that can change its own effective implementation between invocations, which makes the trust boundary unstable. The problem is not just supply chain risk in the abstract. It is that the governance model assumes a fixed object, while the runtime is pulling a moving one.

Practical implication: require version pinning and approved manifests before an MCP server can be used in production.

How signed images and SBOMs turn MCP servers into governed artifacts

Building the final image in CI, signing its digest, and generating an SBOM creates a verifiable chain from source to runtime. A signature proves the artifact came from a trusted workflow, while the SBOM gives teams a dependency inventory when a new CVE lands. This is the same control logic used in broader NHI and workload governance: prove what is running, prove where it came from, and prove what it contains. If the scan happens on the wrong layer, or only on upstream source, the control fails because it does not match the deployable object.

Practical implication: scan and attest the exact image that will be deployed, not the source package or an intermediate build.

Why catalog promotion is the real control plane for MCP

The article treats the catalog as the enforcement point for reviewed versions, scopes, and auth methods. That matters because a promotion gate converts change into an auditable decision instead of a silent runtime update. For IAM and NHI teams, this is the practical boundary where least privilege, review workflows, and tool authorization converge. The same pattern also supports rollback and incident response, because the catalog becomes the source of truth for what should exist. Without that gate, MCP sprawl becomes impossible to govern at scale.

Practical implication: make catalog merge approval the only path by which new MCP servers or versions become visible to users.

Threat narrative

Attacker objective: The objective is to turn a trusted-looking MCP server into a path for credential theft, unauthorized tool execution, or downstream data access.

1. Entry occurs when a client is pointed at an upstream package through npx or uvx and fetches server code directly at runtime without a pinned, reviewed artifact.
2. Credential or tool abuse follows when the server can access secrets, corporate file systems, cloud credentials, or downstream services from the same execution context.
3. Impact is produced when an unreviewed or poisoned server reaches production, enabling unauthorized execution, data exposure, or prompt-driven misuse of connected systems.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• SpotBugs Token GitHub Supply Chain Attack — Leaked SpotBugs personal access token triggers cascading GitHub supply chain attack across thousands of repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP supply chain security is an identity control problem, not just a software build problem. The article correctly frames MCP servers as production artifacts because each server can reach sensitive tools, credentials, and data sources. That makes the catalog, the signed build, and the promotion gate part of the identity governance layer, not just DevOps hygiene. Teams that treat MCP startup as a convenience feature will miss the fact that the server itself is now an access-bearing actor.

Runtime fetches create trust debt that conventional IAM never sees. A server started from the latest upstream package can change after approval, which means the identity of the tool is no longer stable. That breaks the assumption that access review can focus on a known, persistent artifact. The practical consequence is that approved tool identity must be anchored to a pinned, attestable version rather than an ephemeral registry reference.

Server artifact governance: this article exposes the control point that many teams still ignore. The real security boundary is not the package registry, and not even the build job, but the catalog promotion step that decides which artifact becomes visible to clients. That is where least privilege, scoped access, and approval workflow need to meet.

Short-lived runtime trust is the right mental model for MCP, but it only works if the artifact is frozen. MCP servers can be spun up quickly, which tempts teams to equate speed with harmlessness. In practice, fast startup plus broad system access creates a governance gap unless the server is pinned, signed, scanned, and promoted through review. Practitioners should assume that every unpinned server is an ungoverned access path.

Security teams should align MCP controls with OWASP NHI and supply chain governance, not invent a separate exception path. The same patterns that govern service account sprawl, credential handling, and artifact trust also apply here, because MCP servers behave like non-human identities with tool reach. The discipline is to treat them as governed executors with bounded scope, not as temporary developer conveniences.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that makes centralised control harder to sustain.
• That governance gap is why readers should also review The 52 NHI breaches Report for patterns that turn secret exposure into real compromise.

What this signals

The governance signal here is clear: MCP is starting to behave like a non-human identity estate with build-time, runtime, and catalog-time control points. Teams that already struggle with secrets sprawl and review latency will find that the same problems reappear inside AI toolchains unless the catalog becomes the policy boundary.

Server artifact governance: this is the new control concept to watch. Once AI assistants can call tools through MCP, the question is no longer only whether the server is trustworthy, but whether the approved artifact is the same one that actually runs, which means your change process and access process now overlap.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, the operational risk is not theoretical. Practitioners should expect MCP governance to move from engineering preference to identity and platform policy, especially where external services and credentials are in scope.

For practitioners

• Pin every MCP server version before approval Replace latest references with fixed upstream versions in the catalog manifest so reviews, diffs, and rollbacks remain possible.
• Build and scan the deployable image only Package the exact server artifact that will run, then scan that final image and publish the results alongside the build output.
• Require signature checks at admission time Use digest signing and policy enforcement so the runtime accepts only artifacts produced by the trusted CI workflow.
• Make catalog promotion the change gate Allow users to see new MCP servers or versions only after a reviewed catalog update merges and updates the approved reference.
• Scope tool access by server identity Tie each MCP server to granular permissions, short-lived credentials, and logging so tool calls remain attributable and bounded.

Key takeaways

• MCP supply chain security shifts the control point from runtime convenience to governed artifacts, which is the right model once servers can reach sensitive systems.
• The main failure mode is trust drift, where an unpinned upstream package can change after approval and leave teams unable to review, roll back, or attribute what ran.
• Practitioners should treat catalog promotion, image signing, and final-image scanning as the minimum viable governance stack for production MCP.

Key terms

• MCP Supply Chain Poisoning: A supply chain attack that abuses trust in Model Context Protocol distribution channels, registries, or repositories. The attacker replaces or clones a legitimate server with a malicious one, then uses false provenance signals to get it installed into developer or agent environments.
• Catalog Promotion Gate: The review and approval point where a new MCP server version becomes visible to users or clients. It turns change into an auditable decision, which is critical when the server can reach tools, credentials, or sensitive data sources.
• Artifact Ownership: The practice of treating the deployable server image as the security object to be controlled, not the upstream package reference. For MCP, that means proving what code runs, where it came from, and which identity or workflow produced it.
• Claim Trust Drift: Claim trust drift is the gap between where a token was issued and where it is later accepted without enough restriction. It happens when audience, issuer, or lifetime controls are too broad, allowing a valid cryptographic token to create invalid access across systems.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• The reference GitHub Actions workflows that detect upstream version changes and open reviewable pull requests.
• The manifest structure used to pin Node, Python, and container-based MCP servers in a catalog.
• The build, sign, and SBOM generation steps used to turn an MCP server into a deployable artifact.
• The runtime and catalog promotion pattern that links approved images to downstream deployment visibility.

👉 Obot's full post covers the reference workflows, signing steps, and catalog promotion pattern in operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.