What is a kit publisher?

A kit publisher is whoever authored and published a worker kit to the directory, and whose page carries every kit they maintain.

Every kit in the directory has a publisher, and every publisher has a page listing what they maintain. The relationship is worth understanding before you install anything, because it decides what you are trusting and what you are not.

What you are trusting, and what you are not

This is the load-bearing distinction. Taking a kit **mints a worker in your own account**, with its own key and only the access you granted. The publisher wrote a recipe; you cook it in your kitchen with your ingredients. A kit cannot reach an account you have not connected.

So what you are trusting a publisher for is judgement, not access: that the instruction is well written, that the access it requests is the minimum the job needs, and that the grades are honest.

Reading a kit's access request

The one thing genuinely worth scrutinising is the loadout, because that is where a careless publisher shows up. Every kit states the apps it uses and the exact access each needs, in plain words, before you take it.

Compare two real kits:

The pattern to look for is a kit asking for an app its job sentence does not mention. A triage kit requesting calendar access should prompt the question of why, and the app firewall lets you refuse it and see whether the worker still does the job.

That check is yours to make and it takes about ten seconds, which is a better use of scepticism than worrying about the publisher generally.

Anyone can publish

The Kit Creator Studio is a no-code builder: describe the job, pin the apps and the access each one gets, write the instruction, validate and publish.

Publishing gives a kit its own page and a permanent address for life, which has a specific consequence: an update lands on the same URL rather than a new one, so every link to it keeps working and the page accumulates history rather than being replaced. Each kit page shows when it was first published and when it was last updated.

You can also keep a kit private instead, on every plan including Free.

Why grades carry provenance

A publisher declares things about their own kit, which is exactly the situation where a reader should know the difference between a claim and a measurement.

So every per-model grade is marked: measured from real runs, or declared by the publisher. Both are useful, and they are not equivalent. A declared grade tells you what the author expects; a measured one tells you what happened.

Publishing that distinction rather than presenting one number is the mechanism that makes an open publishing model workable. See model grade for how to read them.

The failure mode: a kit that stops being maintained

The realistic risk is not a malicious publisher. It is a stale one.

An app changes its behaviour, a model's characteristics shift, an assumption in the instruction quietly stops holding. The kit still installs, still runs, and starts producing slightly worse output. Nothing announces it, because there is no error: this is the same plausible-failure shape that makes receipts matter throughout.

Two things help. A kit page shows its last-updated date, which is a signal worth reading. And your worker is yours: you can edit its instruction after installing, so a good-but-dated kit is a starting point rather than a dependency you are stuck with.

The reasonable objection

"Installing an instruction written by a stranger, which then acts in my inbox, is a supply chain risk."

It is a fair frame, and the honest answer is that the mitigation is structural rather than reputational. You are not running the publisher's code; you are running your own worker under permissions you granted, inside an app firewall you control, with contact rules and redaction applied by the platform rather than by the kit. The worst a badly written kit can do is bounded by access you approved and can revoke, and every run is on the receipt.

That is a materially different risk profile from installing a package that executes arbitrary code. It is not zero, and the ten seconds spent reading the loadout is where you spend your scepticism.

When to publish rather than keep it private

• The job generalises. If it only makes sense with your CRM field names, it is a private kit.
• You want the address to be permanent and citable. A published kit keeps its URL for life.
• You are willing to maintain it. A published kit with a two-year-old last-updated date is worse for your reputation than no kit.

FAQ

Does a kit publisher get access to my accounts?

No. Taking a kit mints a worker in your own account with its own key and only the access you granted. The publisher supplied the instruction and the access requirements; they gain no access to your data, no visibility into your runs and no ability to change your worker afterwards.

Can anyone publish a kit to the WorkerKit directory?

Yes. The Kit Creator Studio is a no-code builder, and a published kit gets its own page and a permanent address for life. Kits can also stay private on every plan including Free.

How do I know whether to trust a kit?

Read its loadout, which every kit states before you take it: the apps it uses and the exact access each needs. A kit requesting an app its job does not mention is the signal worth acting on. Also check the last-updated date and whether its per-model grades are measured or declared.

What happens when a publisher updates a kit I installed?

A kit keeps its address for life, so updates land on the same page. Your existing worker is yours: it runs on the instruction you installed, and you can edit that instruction yourself at any time.

Can I edit a kit's instruction after installing it?

Yes. Taking a kit creates your worker, and the instruction is then yours to adjust. That is what makes a dated but well-built kit a useful starting point rather than a dependency.