Security model

The registry is built around a specific failure: a marketplace where publishing was pure trust, nothing declared what a package would touch, and a malicious package reached thousands of agents within minutes. Every control below exists because of one part of that.

What is enforced

• Immutable versions. name@version always means the same bytes.

Removal tombstones rows rather than deleting them, so a version number can never be reissued.

• Server-computed checksums. The SHA-512 is produced by streaming the stored

object, not copied from the upload request. A publisher cannot declare a digest that does not match what they sent.

• Content-addressed storage. Blobs are keyed by their own hash, so a retried

upload is a no-op rather than a second copy that might differ.

• Signatures. The registry signs each artifact; the client verifies against a

pinned public key before writing anything to disk.

• No install scripts. Nothing runs at install time, for any kind. There is no

flag to disable this, because there is nothing to disable.

• Account age at signup. Trust signals are captured when an account is

created, not when it publishes — an attacker controls when they publish, not when they signed up.

• Sessions die on ban. A ban that lets someone keep browsing for 30 days on

an existing cookie is not a ban.

• Downloads of unsigned executables require sign-in. See

Installing for why.

What is declared, not enforced

Permissions. SenClaw is not the agent's sandbox and does not pretend to be one. What the declaration gives you is a diff on upgrade and a triage signal for moderators — a package declaring no network whose scan found a request to a paste site is lying, and a lie is more legible than the behaviour it hides.

What is not promised

That a package is safe.

Automated checks find known patterns, not intent. A listing is not an endorsement. The verified checkmark means SenClaw confirmed a publisher's identity and says nothing whatsoever about their code. Read the permissions, read the source repository, and treat a package the way you would treat any code you are about to run.

Reporting a vulnerability

For a vulnerability in SenClaw itself, use contact, or the address in security.txt. Please do not open a public issue first.

For a malicious or infringing package, use the Report button on its page — see Reporting and moderation.