MCP Package Supply Chains: Separate Locks, Artifacts, and Provenance
A familiar package name and valid provenance do not establish an unchanged artifact, dependency tree, or build. Adoption evidence should separately bind the version, digest, publisher identity, and reviewed change.
Read in JapaneseAn MCP server launched through a package manager does not necessarily keep running the same code merely because its configuration retains the same package name. A version range, distribution artifact, transitive dependency, registry, or build workflow can change the code exercising permissions on the host. A lock, an artifact digest, and provenance answer different questions. None of them alone establishes the safety of the complete supply path.
Four evidence types with different limits
| Evidence | What it can establish | What it cannot establish alone |
|---|---|---|
| Exact version and lock | Resolved direct and transitive dependencies | Whether the distributed artifact matches an approved build |
| Artifact digest | Downloaded bytes match the recorded bytes | Whether those bytes contain safe code |
| Provenance or attestation | Link to source, workflow, and publisher identity | Whether source or build instructions are benign and correct |
| Source and release review | Intended changes and permission differences | Whether the deployed bytes match the reviewed source |
npm documents that it uses exact versions from a lockfile when they satisfy the ranges in package.json. A separate project lock does not fix an MCP launch command that resolves a moving tag or version range directly from a registry on every run. For example, an approval may cover @example/search-mcp 1.4.2, while resolving ^1.4 later can select 1.4.3. The name is familiar, but the accepted artifact has changed.
Python package installation has a similar distinction between version selection and file identity. A pinned version narrows resolution; hashes bind the allowed distribution files. Platform-specific wheels can also mean that two systems install different files for the same release. The acceptance record therefore needs the distribution filename and digest, not only a version string.
The identity established by provenance
npm provenance links a package to source code and build instructions. A PyPI attestation can show that a release file was published by a particular Trusted Publisher identity. A GitHub artifact attestation can bind an artifact to repository, workflow, commit, and build context.
These signals help detect tampering and unexpected publisher changes. They do not prove that the identity owner introduced only safe changes. npm, PyPI, and GitHub each warn against treating an attestation as a security guarantee. A newly attested release still needs review for dependency additions, install scripts, network destinations, file access, and changes in tool authority.
Acceptance conditions before connection
The current MCP Security Best Practices describe local servers as binaries running on the client's machine, potentially reaching local files, credentials, and the network. MCP does not prescribe a package-manager lockfile or provenance record format. The following acceptance evidence is an MCP Guard operational recommendation:
- registry, package name, exact version, distribution filename, and artifact digest;
- a lock or hash-bound resolution covering direct and transitive dependencies;
- verified provenance source repository, workflow, commit, and publisher identity;
- changes in dependencies, install hooks, permissions, and external connections since the accepted artifact; and
- equality between the artifact tested and the artifact retrieved by the production launch path.
Valid provenance from the expected source identity should not automatically approve an artifact whose digest or change set is unknown. A moving tag, unrestricted range, or launch-time re-resolution needs an environment that can pin the artifact before connection. After an artifact changes, do not carry the previous decision forward without a review proportionate to the changed surface.
Scope and sources
This design analysis uses public MCP 2026-07-28 Security Best Practices and current npm, PyPI, and GitHub attestation documentation reviewed on September 22, 2026. It does not report malware, tampering, a product CVE, or an MCP Guard inspection of a named package. The table and acceptance conditions are MCP Guard recommendations derived from the documented limits.