You're Not Installing What You Think You Are

Run pip install litellm right now. You'll get a package with 122 million weekly downloads. You can read every line of the source code on GitHub. Everything looks legitimate.

But here's what you can't do: prove that the package you just installed was actually built from that source code.

There is no cryptographic attestation, no build provenance, no SLSA signature — nothing that links the binary on PyPI to the commit on GitHub. The install probably matches. But "probably" is doing a lot of heavy lifting when the thing you're installing can execute shell commands, call APIs, and access your files.

Downloads are not trust

This is the part most people get wrong. They see "122M weekly downloads" and think that's a safety signal. It's not. Downloads tell you how popular something is. They tell you absolutely nothing about whether the package on the registry was built from the source you're reading.

Here are the most-downloaded AI agent packages that ship with zero provenance:

Combined: over 280 million weekly installs with no way to verify the build.

The ones who actually do it

31 out of 178 agents we track publish build provenance. And here's the pattern that's hard to ignore: they dominate the top of our trust rankings.

The top 7 agents on HVTracker all have verified provenance. That's not a coincidence — it's a signal. Projects that bother with build attestations also tend to sign commits, run OSSF Scorecard, and maintain security policies. Trust signals cluster.

What's actually in the gap

When a package ships without provenance, here's what sits between the source code and your machine — unverified:

The maintainer's local machine or CI pipeline → their registry credentials → the registry's build storage → your pip install.

At any of those steps, the package could be modified. A compromised CI secret. A hijacked npm/PyPI token. A supply chain attack on a build dependency. Without provenance attestation, you have no way to detect any of these after the fact.

With provenance, you can run npm audit signatures or check pip inspect attestations and get a cryptographic chain: this package was built at this commit, by this CI workflow, from this repo. If anything doesn't match, you know.

Why AI agents are different

When someone compromises a date-formatting library, the worst case is data exfiltration through a dependency. Bad, but bounded.

When someone compromises an AI agent, the worst case is whatever that agent was authorized to do:

• Coding agents can read and write files, execute terminal commands
• Browser agents can navigate, click, fill forms, extract data
• Workflow agents can call external APIs, move data between services
• Research agents can scrape, summarize, and exfiltrate content

The blast radius of a compromised AI agent is categorically larger than a compromised utility library. And yet 83% of them ship with the same level of supply chain verification as a left-pad clone: none.

It's not hard to fix

Both npm and PyPI support provenance attestation today. If your project uses GitHub Actions (and most do), enabling it is a configuration change — not a rewrite:

• npm: Add --provenance to your publish command. Done.
• PyPI: Use the pypa/gh-action-pypi-publish action with attestations enabled.

CopilotKit added provenance and their trust score jumped from the 60s to 75. It's one of the highest-leverage trust improvements a maintainer can make.

Data from HVTracker signals as of June 2, 2026. Provenance is checked via npm registry attestations and PyPI PEP 740 metadata. Download counts from npm and PyPI APIs. Full methodology.