The Registry Policies Live In
A policy is only as useful as the number of people who can start from it. SevorixHub makes policies portable artifacts — versioned, signed, and pullable — instead of a JSON file each team writes from scratch.
The Blank-File Problem
Every runtime enforcement product eventually asks the same thing of a new user: describe, precisely, which actions your agents may take. It is the right question, and it is a genuinely hard first day of work. Written from an empty file, the first policy is either too narrow to let the agent work or too broad to be worth having.
That first draft is not novel work. The commands that destroy a Postgres database, the paths that leak credentials, the outbound hosts a coding agent has no business reaching — these are the same on your machine as on everyone else’s. Writing them again per team is duplicated effort at best, and at worst it is a policy that misses the case someone else already learned about the hard way.
SevorixHub is the answer to that. It is a registry of policy artifacts: publish one under a name and a version, find one by name or tag, pull it onto your machine, adapt it, and push your version back. The enforcement engine does not change — the same local daemon, the same eBPF maps, the same deterministic verdicts. What changes is where the policy came from.
What an Artifact Is
An artifact is a policy document — the same JSON the local daemon already reads — plus the metadata that makes it addressable and checkable: a name, a semantic version, a description, tags, an owner, a visibility level, and a SHA-256 of the content the hub stored.
Name and version together are unique across the registry, so a published version is a fixed point: pushing the same name and version twice is rejected rather than silently replacing what was there. Anything that references sql-destructive 1.2.0 keeps meaning the same bytes tomorrow.
- Artifacts and sets: An artifact is a single policy document; a set is an artifact that composes others. A push can declare dependencies as name@version pairs, and the hub resolves the full transitive list for any artifact on request — so a team can publish one "backend-agent" set that names the database, filesystem, and network policies it is built from instead of copying them into one file.
- Download counts and yanking: The hub counts pulls per artifact, and a publisher can yank a version with a reason when it turns out to be wrong. Yanking does not delete history — the version stays addressable for anything already pinned to it, and it stops being something new users are handed.
- A warning on executable policies: Sevorix policies can call an external checker binary. When you pull an artifact containing an Executable policy type, the CLI says so and refuses to write it out until you pass --allow-executable. Pulling a policy from a stranger should not quietly hand that stranger a command to run.
Four commands, start to finish.
The registry is reached entirely from the CLI you already have. SEVORIX_HUB_URL points the client at a hub — ours by default, your own if you run one — and the token from a login is stored at ~/.sevorix/hub_token with owner-only permissions.
- STEP 01
Find something to start from
Search matches on name and description, filters by tag, and pages with a limit. Anonymous searches return public artifacts; logged in, you also see your own private and draft ones.
sevorix hub search --query postgres sevorix hub search --tag database --limit 10 - STEP 02
Pull it onto the machine
A pull writes the policy document to a file (or stdout) and reports whether the artifact carried a valid signature and which key fingerprint signed it. From there it is an ordinary local policy file — hot-reloaded, no restart.
sevorix hub pull sql-destructive 1.2.0 \ --output ./policies/sql-destructive.json - STEP 03
Adapt it and push your version
Publish under your own name and version, with tags and a description that make it findable, and a visibility that decides who ever sees it. Declare dependencies to publish a set rather than a single document.
sevorix hub push \ --name acme-backend-agent --version 1.0.0 \ --file ./policies/backend.json \ --description "Backend agent baseline" \ --tag database --tag production \ --visibility private - STEP 04
Retire a version that turned out wrong
Yank marks a version as withdrawn with a reason attached, and unyank reverses it. This is the honest path for a policy with a hole in it — better than deleting it out from under a fleet that pinned it.
sevorix hub yank acme-backend-agent 1.0.0 \ --reason "Missed pg_dump to external hosts"
Pulling and searching public artifacts needs no account at all. Publishing does: registration creates an account in a pending state, and an administrator approves it before your first push or endorsement is accepted. We would rather be slow about who can put enforcement policy in front of other people than fast.
Who Can See What
Visibility is set per artifact at push time and is enforced on every read path, not just on the browse surface.
- Public: Readable by anyone, including anonymous clients with no account. This is the shared commons — the artifacts a new user can pull on their first day.
- Private: Readable by the owner and hub admins only. An internal policy that encodes how your company actually operates is not something you want indexed, and it does not have to be public to be versioned and distributed.
- Draft: Owner-only, for a policy that is not ready to be depended on yet. Same storage, same versioning, no audience.
Search respects the same rules: anonymous callers see public artifacts, an authenticated caller additionally sees their own private and draft ones, and a private artifact that does not belong to you is a 404 rather than a 403 — the registry does not confirm the existence of things you cannot read.
Signing: Provenance You Can Check
A registry that hands out enforcement policy is a supply chain, and it is treated as one. Publishers register Ed25519 public keys against their account; each key is stored with a fingerprint and an optional label, and can be revoked without touching the artifacts it signed.
A signed push carries the signature over the SHA-256 of the content together with the fingerprint of the key that made it. The hub looks up that fingerprint against the publisher’s own unrevoked keys and verifies the signature before anything is written — a bad signature is a rejected push, not a stored artifact with a warning on it. Signature and fingerprint are written as a pair, enforced by a database constraint, so "signed" can never mean "we recorded a signature we never checked".
On the way back down, a pull reports the signature state and the fingerprint that signed it, so you can pin the key you trust rather than trusting the registry as a whole.
A hub deployment can set REQUIRE_SIGNED_ARTIFACTS, and unsigned pushes are then rejected outright. On an internal registry that is the setting worth having: every policy that reaches your fleet is attributable to a key your organisation registered.
Endorsements: Trust That Is Someone’s Name
Download counts measure popularity, and popularity is not safety. Endorsements are the second signal: an account can endorse a specific artifact at one of three levels — verified, trusted_author, or official — and an endorsement is attributable to the account that made it, one per account per artifact, removable by its author.
Endorsed accounts are marked as such throughout: search results and pull responses both carry whether the owner is endorsed, and an endorsement from an endorsed account carries correspondingly more weight. The intent is a web of accountable review rather than an anonymous star rating.
Running the Registry Yourself
For most teams the hosted hub is the right answer. For a regulated or air-gapped one it is not, and Enterprise runs the same service inside its own boundary: a single Rust binary shipped as a container, backed by your PostgreSQL and either local filesystem or object storage for artifact contents.
A self-hosted hub is the whole registry, not a mirror — your own accounts and approvals, your own signing keys, your own artifacts, your own endorsements, and REQUIRE_SIGNED_ARTIFACTS on if you want it. The CLI points at it through SEVORIX_HUB_URL, and no artifact, name, or query leaves your network. It is the same mechanism the Enterprise tier’s fleet-wide policy sync is built on: policies compiled from your compliance documents, signed with your enterprise key, distributed from a registry you operate, and verified against a pinned public key by every daemon before they reach the eBPF maps.
What the hosted hub receives, and what it never does, is set out in full in the privacy doctrine.
Registry facts
Start from someone else’s hard-won policy.
Install Sevorix Lite, then pull a policy instead of writing one. Enterprise registries run inside your own boundary — we will walk that deployment with you.