The work already exists. Access is the problem.
The payments worker stops processing jobs. Your team already has scripts/restart-worker, and the fix takes seconds.
But the script can reach production. Only two people have the required credential, so everybody else must choose between waiting for them or receiving far more access than this task requires.
- Put another reusable production credential on a developer laptop.
- Teach every caller how the provider, host and credential work.
- Remember every copy when somebody leaves or the key must rotate.
- Repeat the same access setup for CI, workflows and agents.
The caller needed one result. The available credential opened an entire system.
Give the caller the operation.
restart_worker("payments")Kimen checks that this caller may restart this known worker in this environment. A trusted implementation performs the existing operation with the required credential. The caller receives the result, not the credential.
The same operation can be used by a developer, CI job, workflow or coding agent. None of them needs to know where the script runs or how production authentication works.
Kimen Operations is planned. The operation syntax shown here is illustrative.
The project names it. The environment makes it real.
The operation contract travels with the code. It describes the name and permitted inputs, but carries no production address, implementation or credential.
restart_worker(queue)
- implementation
- pinned restart script, fixed API or workflow
- allowed queues
- payments, email
- environment
- production
- credential
- Kimen vault, 1Password, Vault or cloud identity
For local Kimen, the binding lives in Kimen's application data directory outside the repository. Installing or changing it requires explicit owner authorization. For a team, an administrator publishes a signed binding and access policy. Local Kimen or a trusted runner syncs and verifies it before accepting a call.
The operation contract belongs to the project. Its implementation and authority belong to the environment.
Use it where routine production work is still awkward.
run_backfill("invoices", "2026-09") lets an authorized caller run one known backfill without receiving database administration credentials.
inspect_logs("api", since="30m") returns a bounded log window without distributing a general observability key.
restart_worker("payments") restarts one known service without giving the caller SSH or cloud administration access.
Deployments can use the same model when they are still run from local scripts. Teams which already use protected CI deployments and short-lived identity may not need Kimen for that job.
Keep the automation you already have.
Kimen does not become your runbook or workflow platform. Your scripts can stay in the repository. Your workflows can stay in CI. Your credentials can stay in 1Password, Vault or a cloud secret manager.
Kimen provides the narrow contract between a caller and the trusted implementation which already performs the work.
Change the binding once for the whole team.
An administrator can update which implementation is trusted, which parameters are allowed and who may call the operation. Kimen Teams distributes the signed binding and policy to local Kimen runtimes or trusted runners.
The credential does not need to be synchronized through Kimen Teams. It can remain in the organization's existing secret store. The developer may have permission to call restart_worker("payments") without having permission to read the credential behind it.
Approvals, revocation and audit can then describe the real job: who ran which operation, in which environment and with which approved binding version.
Shared bindings. Access rules. Approvals. Revocation. Audit.
Kimen Core remains local and open source. Kimen Teams is the planned coordination layer for organizations which need the same operations across people and systems.