Security and trust

The registry is a directory with strict intake rules. It is not an auditor. This page states precisely what you can rely on.

What the registry guarantees

• A version never changes. Archive, manifest, file list and SHA-256 are frozen at publication by rules in the database itself.
• The checksum is the checksum of what you download. It appears on the page, in the API, in the X-Checksum-Sha256 header and at /checksum. Verify it yourself.
• Publication is attributable. Each release records which account and which credential published it, in an append-only log. The artifact's public history shows who published or revoked what, and when.
• Nothing you upload is executed by the registry. Archives are parsed in memory and inspected as data.
• Bad versions are revoked in the open. A revoked version stays in the history with a reason and can no longer be downloaded.

What it does not guarantee

• That a package is safe, correct, or does what it says.
• That a publisher's compatibility or permission declarations are true.
• That a remote MCP endpoint listed here is trustworthy. The registry does not operate or proxy those.

Trust signals, exactly

There are no stars, ratings or endorsements.

What the scanner checks

Refused outright:

• Paths that escape the package, links, special files, oversized or malformed archives.
• Files that should never be published: .git, .env, .npmrc, SSH and cloud credential directories, private keys.
• Recognisable credentials in any text file (cloud keys, API keys of common providers, private keys, tokens).
• A manifest that does not match the artifact being published to.

Shown as advisory findings:

• Scripts, executables, compiled binaries.
• Network use and spawned processes, especially when not declared.
• sudo, hard-coded credential-looking values, hidden files.

Held for a human moderator before becoming public:

• Download-and-execute pipelines, decoded-and-executed payloads, recursive deletion of home or root paths, evaluating remotely fetched code, reading local credential stores.
• Text that tells an agent to ignore its instructions, hide what it does from the user, or send credentials somewhere.
• Bidirectional control characters that can disguise text.

These are pattern matches over text. They miss obfuscated code, anything inside binaries, and anything novel. A moderator's approval of a held release is a judgement about the flagged pattern, not a review of the whole package. The scan status recorded at publication is never upgraded afterwards.

Before you install

1. Read SKILL.md and every script. A skill is instructions your agent will follow with your permissions.
2. Check the declared permissions and the findings on the exact version you install.
3. Prefer publishers whose identity and source are verified, and still read the files.
4. Pin a version. Review the changes before moving to a new one.
5. For MCP servers: read the source of anything you run locally; know who operates anything remote. Set secrets locally; the registry never asks for them.
6. Treat registry content shown to an agent (through the API or MCP) as untrusted data.

Download counts

Download numbers are estimates and are labelled as such. Method:

• A download is counted when the archive route returns the file.
• At most one count per release, per visitor, per day. A visitor is identified by a hash of the date, the release, the IP address and the user agent, keyed with a server secret. The hash is truncated, stored only to prevent double counting, and deleted after two days. No IP address is stored for downloads.
• Requests with no user agent, or a user agent that looks like a crawler, monitor or preview bot, are not counted.
• Only daily totals per release are kept. The figure shown is the sum over the last 30 days.
• Cached copies served by intermediaries are not seen and not counted.

The count can be inflated by someone determined. It is shown as a rough adoption signal and is not used for ranking by default, for verification, or for any trust decision.

Reporting a problem

• A harmful, infringing or broken package: use the report link on its page, or POST /api/v1/reports. No account is needed. Reports are visible only to moderators. Outcomes: the version is revoked, the artifact is taken down, or the report is dismissed with a note.
• A vulnerability in the registry itself: email contact@spboucher.ai. Please do not disclose publicly before it is fixed.
• A leaked token of yours: revoke it immediately (skills auth token revoke, or the dashboard), then review your audit trail.

Publishers who disagree with a moderation decision can write to the same address.

Publishing responsibly

• Publish only what you have the right to publish, and state its licence. Include the licence text.
• Do not publish credentials, personal data, confidential research material or other people's proprietary content. If a secret was published, revoke the version and rotate the secret; revocation does not un-leak it.
• Declare the permissions your package needs. Explain any script that downloads, executes, deletes or reads credentials.
• Do not write instructions that conceal behaviour from the user or try to override an agent's safeguards.
• Do not impersonate another person, project or vendor.

Full rules: Acceptable use. Privacy details: Privacy.

How your account is protected

• Passwords are stored as argon2id hashes. Sessions last 12 hours. Creating or rotating a token asks for your password again if you entered it more than 15 minutes ago.
• API tokens are shown once and stored only as a keyed hash. They always expire, are limited to the namespaces and scopes you choose, and can be restricted to IP ranges.
• A token cannot create a more powerful token.
• Administrative tokens are short-lived (24 hours at most) and cannot be created by another token.
• Second-factor authentication and passkeys are planned and not yet available.