Remit
remit · rɪˈmɪt · n. the scope of someone's authority.
least privilege for agent skills
Every skill declares its scope, is observed in a sandbox when available, and can be blocked at load if it drifts.
npx @remitlabs/cli@latest startfree public beta · Node 22.5+ · no account · runs locally
A skill vouches for itself. Nothing checks the maths.
Today, a skill's trust story is prose: a description, some stars, maybe a README skim. Nothing runs it in a box before your agent loads it. Nothing watches what it does after. Nothing revokes it when a maintainer turns hostile at 2am — so you read SKILL.md twice and install anyway, hoping. The same "summarize notes" skill can ship "curl … | sh" or quietly read ~/.ssh: our detection corpus keeps specimens of exactly that, and they fool a human skim.
The loop, sources to kill-switch
shipped static scan, canary receipts, signed feed + daily sync, MCP router, hook-guard (observe), lockfile rug-pull alerts, fleet dashboard — open boundaries canary containment is observer-first (egress enforcement only with an allowlist), and team identity is not built. A receipt is one observed run, not a safety guarantee.
How existing skills are handled
Point skillctl audit at the skill dirs your agents already use — Claude Code, Codex, Cursor and friends. Every skill gets static findings; when Docker or Podman is available, a canary diff too. 123 skills, 4 agent dirs, 114 duplicate registrations found, measured on the machine this was built on.
Marketplace search (skills.sh + GitHub) funnels installs through one gate: clone, scan, policy, digest — before files ever land. CLI and marketplace installs share the same decision.
A lockfile pins every skill's sha256. If a maintainer re-publishes a skill you installed, update time runs a semantic diff — changed behaviour is flagged, never silently adopted.
The MCP router loads skills on demand (~150 tokens vs 15,238 of eager context, measured). hook-guard watches live sessions against network allow-lists, and the Ed25519 feed syncs daily: revoked digests are blocked by the router and feed. Remit-home copies are removed; hand-installed files get parked with a removal note, never silently touched.
Why a store of scanners isn't this
Not a marketplace with inventory to protect, not an agent selling you its own skills. Remit is the evidence layer under whatever supply chain your agent already uses.
Every verdict ships with its evidence: the rule hits, the canary diff when it ran, the pinned digest, and the signed-feed status. You can re-run the proof yourself — trust here is verifiable, not asked for.
Security without a kill switch is theater. The signed feed gives every install a clock: a revoked digest is blocked at load time, herd-wide, on the next daily sync.
Index, scanner and sandbox detonations run on your machine; the fleet API self-hosts or embeds. No cloud round-trip needed for a trust decision, and the core works offline.
What this does not prove
A finding is a rule match, not proof of intent. A canary receipt is one observed run in a container, not a guarantee that a skill is safe. Static coverage can be partial; compiled or encrypted files are blind spots. The canary is observer-first by default — it enforces egress only when you pass an allowlist. Remit is defense in depth, not a clean bill of health.
Run npx @remitlabs/cli@latest start and judge the evidence yourself. The output tells you which layers ran and what they could not see.