Answers · MCP security
How do I verify an MCP server package was built from its repo (npm provenance, PyPI attestations)?
Last updated
TL;DR: Check the signed provenance that links the package to its source. For npm, a published-with-provenance version shows a green check on its npm page, with links to the source commit, the build workflow and a public transparency log entry, and npm audit signatures (npm CLI 9.5.0 or later, after npm install or npm ci) verifies registry signatures and provenance attestations for everything installed. For PyPI, the pypi-attestations CLI checks a file's attestations against the repository you expect. For release binaries and container images, gh attestation verify checks GitHub artifact attestations against a repository. Then compare the repository in the attestation with the one the server's docs name. Provenance proves where and how a package was built, not that it's safe: npm says provenance doesn't guarantee a package has no malicious code, and in May 2026 the Mini Shai-Hulud worm published malicious npm and PyPI versions that carried valid provenance attestations because it ran inside the projects' own build pipelines.
What should I check, step by step?
1. Find how the server is distributed: an npm package (npx), a PyPI package (uvx or pip), a release binary or a container image. Each has its own check.
- npm: open the exact version on npmjs.com and look for the provenance check mark, then click through to the source commit, build file and transparency log entry.
- npm: after installing, run npm audit signatures with a current npm CLI. It reports how many packages have verified registry signatures and verified attestations, and errors on missing or invalid ones.
- PyPI: run pypi-attestations verify pypi --repository https://github.com/OWNER/REPO with the file's URL. It checks that the Trusted Publisher matches the repository you passed and verifies the file against its attestations.
- Binaries and images: run gh attestation verify PATH_OR_oci://IMAGE -R OWNER/REPO.
- Confirm the repository in the attestation is the one the vendor documents, not a fork or a look-alike name. A valid attestation from the wrong repository is still the wrong package.
- Treat missing provenance as a reason to look harder, not proof of malice, and valid provenance as one signal, not a safety verdict: still pin the exact version, read install scripts (npm ci --ignore-scripts in CI where it works), and run the server with narrow credentials.
- Re-check on every upgrade. Provenance applies to one version; the next release can come from a different workflow or a compromised one.
What each check proves (checked Oct 31, 2026)
npm provenance has two parts. The provenance attestation, made in a supported cloud CI/CD build (GitHub Actions or GitLab CI/CD with cloud-hosted runners), links the package to its source repository and build instructions. The publish attestation is made by the registry when an authorized user publishes. Both are signed through Sigstore and logged in a public transparency log.
- Before accepting a publish with provenance, npm checks among other things that the build ran on a cloud-hosted runner, that the package name, version and tarball digest match the signed statement, and that the repository in package.json matches the repository in the signing certificate.
- PyPI serves attestations through its Integrity API, grouped by the Trusted Publisher identity that signed them. GitHub artifact attestations record where and how a binary or image was built and are verified with the GitHub CLI.
- npm's own docs are explicit: provenance doesn't guarantee a package has no malicious code. It gives you a verifiable link to the source and build, which you can then audit.
Why valid provenance isn't enough
The Cloud Security Alliance's research note on Mini Shai-Hulud (May 15, 2026) reports that between May 10 and 12, 2026, attackers published malicious versions of npm and PyPI packages, including TanStack packages and the Mistral AI SDK, that carried valid SLSA Build Level 3 provenance. The attackers poisoned a shared GitHub Actions cache, read short-lived OIDC tokens from the runner's memory and published through the projects' real trusted-publishing setup.
- The attestations were accurate: the packages really were built in those projects' pipelines. What provenance can't show is whether the code that ran in the pipeline was what the maintainers intended.
- So use provenance to rule out a package built somewhere else or altered after the build, and keep the other controls (version pinning, install-script review, sandboxing, narrow credentials, watching for tool-list changes) for the cases provenance can't catch.
How do I ask Rightshold about this (free, no key)?
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “Before I connect this MCP server, what's on record about it: registry entry, its tool definitions now versus the recorded fingerprint, and any security flags?”
{
"tool": "precall_check",
"arguments": {
"url": "<the MCP server's https URL>"
}
}- Free. It returns evidence to decide from, never a finding that a server is safe. For a server registered on Rightshold, check_tool_integrity compares the tools it serves now with the recorded fingerprint after you upgrade.
- For the server's GitHub repository, GET /v1/safety-ratings/{owner}/{repo} shows Rightshold's public-signal checks, including whether signed releases or build provenance were found (SLSA generator, GitHub artifact attestations, Sigstore/cosign, npm --provenance or PyPI trusted publishing in workflows, or signature or attestation assets on recent releases), each with its source. Maintainers can ask for a free re-check with POST /v1/safety-ratings/{owner}/{repo}/recheck.
- Each rating is sealed on the public ledger with its date, so you can show what the signals were when you decided.
Rightshold doesn't download or verify npm, PyPI or container signatures for you, and a rating isn't an audit or a statement that a package is safe. Run npm audit signatures, pypi-attestations or gh attestation verify yourself.
What are the sources?
- npm Docs: Generating provenance statements (provenance and publish attestations, limitations)
- npm Docs: Viewing package provenance (npm audit signatures)
- npm/provenance: server-side verification and npm audit signatures
- PyPI Docs: Consuming attestations (pypi-attestations verify)
- GitHub Docs: Using artifact attestations (gh attestation verify)
- Cloud Security Alliance: Mini Shai-Hulud: When Signed Provenance Certified a Supply Chain Worm (May 15, 2026)
Related
- How to vet an MCP server before installing it
- How to pin MCP server versions and review changes before upgrading
- How to detect MCP tool description changes (rug pulls)
- Rightshold Safety Ratings
Not legal advice. JSON · Markdown · All answers
Get a free API key in one call
No card and no email needed. 100 free credits; the license and policy checks stay free without a key.
curl -s -X POST https://www.rightshold.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export RIGHTSHOLD_API_KEY=rs_... # the api_key from the reply (shown once)
curl -s https://www.rightshold.com/v1/licenses/check -H "Authorization: Bearer $RIGHTSHOLD_API_KEY" \
-H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'