No shipped credentials
No API keys, tokens or passwords in shipped files or in repository history.
- Applies to
- agents, MCP servers, apps, templates
- Standard references
- CWE-798 · CWE-540
A finding here is not a failure
Software of any size carries something. A listing that raises findings on this check is still sold, with the findings published and their severity and reachability stated. A badge that only ever said pass would teach people to stop reading it.
Explainer · 2026-09-30
Shipped credentials: how keys end up in published packages, and why most matches are not leaks
A working key in a published package belongs to everyone who installs it. Most strings that look like keys are nothing of the kind, and telling the two apart takes reading each one.
What this row checks
That no API key, token or password ships in the files a package publishes. Many providers issue keys in a recognisable shape: AWS access key IDs begin AKIA, classic GitHub tokens begin ghp_, Slack tokens begin xox, Stripe live secret keys begin sk_live_. A string in one of those shapes is worth looking at wherever it appears.
The other half is a guess: a line that assigns a long, random-looking value to something called token, secret or password. That guess is worth making in source code and wrong by construction in documentation, which exists to show people where to put their own value.
Why a real one is serious
A published package is copied to mirrors and caches within minutes, and earlier versions stay downloadable. Removing a key from the next version does not remove it from the world. The only fix is to revoke it at the provider and issue a new one.
Keys arrive in packages the ordinary way: pasted into a configuration file for a test, a debugging certificate kept beside the code, an environment file nobody excluded from the publish.
What we found when we read every match
The automated scan printed a credential warning on 31 listings. Every one was read by hand, at the version the scan read, with the value itself never printed. 29 were false: test values, documentation examples such as the example key in AWS's own documentation, the detection rules of other secret scanners, and minified parser code in which the word token happens to come before a long string. Two were real: a Google API key repeated in examples and tutorials, and a complete private key in a package's source.
The 29 are withdrawn from their listings, each with the reason printed where the warning used to be. A check that makes this accusation has to be right, and a count of shapes is not the same as a count of leaks.
How the result is shown
As a count, with the location withheld, so a listing page is never a map to a live key. A match is read by hand before it is called a leak, and the reading is published.
How apps and templates are read for this row
On an app or a template, this row is also answered every night by a reading of the package's published files, never by running it. The rules are app check set v1.0, each with its mapping, an example, the nearest writing it leaves alone, a hand count across every app and template listing, and what a reading of files does not cover.
In the glossary: Shipped credential, False positive.
What this check has found
2 listings in the catalogue raise a finding here. Every one is still sold, with the finding printed on its page.
- Neo Mjs
The scan matched 5 credential-shaped strings in the published files. Location withheld pending disclosure to the maker.
- Oh My Pi Pi Coding Agent
The scan matched 1 credential-shaped string in the published files. Location withheld pending disclosure to the maker.
Every listing in the catalogue shows its result on this check, with the findings summarised in public and the full report to whoever bought it. Open the catalogue.