How verification worksIntermediate· 5 min read

Why a badge expires, and what happens when a maker ships

The one thing to remember

A change to what software is allowed to do is treated as a new product, not as an update.

The question

Know what happens to a listing you have bought when its maker publishes a new version.

Figure

The same argument as the text, as a chain. Each step is what makes the next one possible.

1
Ordinary updates drop the badge to pending
A new version means the tested artefact no longer matches the shipped one, so the badge stops applying. The listing shows the previous result with the version it applied to, and the new version is queued for testing.
You keep the version you bought. Nothing is taken away from you because a maker shipped.
2
Permission changes are treated as a different product
If a new version declares a tool it did not declare before, asks for a scope it did not ask for, or adds a destination it may send data to, the listing does not simply go pending. It is flagged, everyone who bought it is notified, and it cannot be sold again until it has been re-tested.
This exists because of a specific attack. The tool-poisoning vulnerabilities disclosed in 2025 worked by changing what a server told the model it did, after the point at which a person had approved it. Pinning the manifest per version and alarming on any change is the direct answer.
If you get one of these notifications, read what changed before you update. That is the whole point of sending it.
3
Badges expire even without an update
Dependency advisories are published continuously, so a clean result from six months ago is a statement about six months ago. Every badge carries an expiry, after which the listing shows as needing re-verification.
Re-verification of an unchanged artefact is cheap and mostly automatic. The expiry is there so the date on the badge always means something.

You have got it when

You can explain why a permission change is treated more seriously than a code change.

1
Ordinary updates drop the badge to pending
A new version means the tested artefact no longer matches the shipped one, so the badge stops applying. The listing shows the previous result with the version it applied to, and the new version is queued for testing.
You keep the version you bought. Nothing is taken away from you because a maker shipped.
2
Permission changes are treated as a different product
If a new version declares a tool it did not declare before, asks for a scope it did not ask for, or adds a destination it may send data to, the listing does not simply go pending. It is flagged, everyone who bought it is notified, and it cannot be sold again until it has been re-tested.
This exists because of a specific attack. The tool-poisoning vulnerabilities disclosed in 2025 worked by changing what a server told the model it did, after the point at which a person had approved it. Pinning the manifest per version and alarming on any change is the direct answer.
If you get one of these notifications, read what changed before you update. That is the whole point of sending it.
3
Badges expire even without an update
Dependency advisories are published continuously, so a clean result from six months ago is a statement about six months ago. Every badge carries an expiry, after which the listing shows as needing re-verification.
Re-verification of an unchanged artefact is cheap and mostly automatic. The expiry is there so the date on the badge always means something.

You have got it when

You can explain why a permission change is treated more seriously than a code change.

Read next