The package you approved isn’t the one running tomorrow

You installed an MCP server three weeks ago. You read what it did, you decided it was reasonable, and your agent has been calling it since.

Version 1.7 shipped last Tuesday. Same package, same name, same install command. You did not read it, because nobody reads the diff of a patch release, and your lockfile updated the way lockfiles do.

That release is the one that matters. Not because it is usually malicious — it almost never is — but because it is the only moment where what your agent will do changes without anyone deciding that it should.

An MCP server is not an ordinary dependency. Its tool descriptions are read by a model as instructions and acted on without a human in the loop. A rewritten description is a rewritten instruction. A widened input schema accepts arguments the approved version refused. A new install script runs before anything else happens at all.

Registries make versions discoverable. They do not tell you what changed inside one.

What we built

Sentinel unpacks an exact published npm artifact, reads it without executing any of it, and writes down what that artifact declares. Then it does the same for a later version and tells you what moved.

npx magus-mcpsentinel analyze npm @scope/[email protected] --evidence-dir ./ev --output before.json
npx magus-mcpsentinel analyze npm @scope/[email protected] --evidence-dir ./ev --output after.json
npx magus-mcpsentinel diff before.json after.json

That is the whole thing. It is Apache-2.0, there is no account, no key, no telemetry, and the only network access is to the registry you name.

What comes out is a schema-validated report: artifact digest, file inventory with per-file digests, dependencies, install scripts, entrypoints, and the tool surface it could recover. A diff between two reports names what changed and stops there.

What it deliberately will not tell you

It will not tell you whether a package is safe.

That is not because we can't or because of any kind of modesty. It's because a tool that says "safe" has made a promise it cannot keep, and the first time it's wrong it takes every other right statement, prior and post, down with it. So any credibility or trust gained is rightfully lost.

So, Sentinel produces the evidence — you set the policy. The analyzer assigns no severity at all, and that is enforced in CI rather than merely intended: a test fails if it starts to. The ranking you see on our watch page is a separate layer applying our policy to the same evidence, and you can apply your own instead. Ranking a change is a judgement, and the judgement belongs to whoever has to act on it.

It also cannot see everything, and this is the part worth reading carefully.

Tool surfaces are recovered by parsing shipped JavaScript. Across a pinned corpus of 50 real published MCP servers, 37 yield a usable tool inventory and 12 can be resolved completely. Those are two different numbers because they license two different conclusions: only the second permits saying that a tool was removed, because only the second means we know we saw everything.

An inventory without complete: true is a lower bound. Treating a short list as a complete one is the most likely way to misread one of our reports, so it says so, in the report.

The corpus is checked into the repository with exact versions and artifact digests. You can re-run the figure rather than take it on trust, and a weekly job re-runs it against us.

We published a number we could not reproduce

The figure above used to be "about a third."

It came from 25 packages that were never checked in. The corpus did not exist as an artifact — it existed as a thing someone had once run. When we went to reproduce it, we could not, so we retired it and measured again properly.

The new number is better than the old one — 37 of 50 rather than roughly a third — which is the detail that makes this worth telling. We were not hiding a bad result. We were quoting a good-enough result that had no source, and a number with no source is a claim, not a measurement.

It stayed on our own website for a week after we retired it in the repository, on the page headed why this is trustworthy, understating our real coverage by half. We found it because a sentence next to it read badly.

We had someone try to break it

An adversarial review spent three days trying to make Sentinel's claims outrun its behaviour. It found one real flaw, and it is a good one, and we aren't going to hide it from you. So here it is...

A tar archive can contain two entries at the same path. Our reader took the first. npm takes the last. So a package could carry a harmless package/package.json, then a second one with an install script. Sentinel would report a clean, benign artifact with its integrity verified, while installing it ran the script.

Worse, the tool disagreed with itself: one part of the report described the first entry, another listed both, and the diff collapsed them to the last. Three answers to one question, inside a tool whose entire job is to answer that question.

It is closed. Sentinel now refuses any archive with a duplicate path rather than picking a winner, because a package with two files at one path is ambiguous by construction and no legitimate package in the corpus ships one. The fix has a test built from the original attack.

We are telling you this because a security tool that has never been attacked is not a security tool that has no flaws. The three days also found that the parts we had hardened deliberately — the path-traversal handling, the decompression bounds, the query plans, the refusal to ever execute package code — held.

What this is for

If you run MCP servers your agents depend on, Sentinel tells you when one of them changes, with the evidence attached, before you upgrade.

It is free and complete, permanently. There is no paid tier holding anything back. Everything above is in the repository, including the limitations, including the attack.

• Repository: github.com/vahive-tobias/magus-mcpsentinel
• On npm: magus-mcpsentinel, published from CI with a provenance attestation you can verify with npm audit signatures
• Live evidence: aivare.ai/watch — real packages, real reports, downloadable