The harness decides

Kosken whitepaper, draft 1. 15 November 2026.

Summary

Kosken is a service that watches Linux servers and responds to incidents. A model reads the evidence and writes a diagnosis. Code, not the model, decides what runs on a machine.

We built Kosken on one belief: the harness around a model matters more than the model. The harness is the set of rules, checks, and limits that surround the model. A better model gives a better diagnosis. It does not make an unsafe action safe.

This paper explains the principles, the architecture, and the limits of our claims. It also states what is not true yet. Today Kosken runs on three machines that belong to its authors. It has no customers.

The problem

A server fails at night. An engineer wakes up, reads logs, finds the cause, and applies a fix. A model can do the first three steps faster. The fourth step is where the risk is.

A model can write a wrong command with full confidence. If the model can run commands, one wrong answer changes a production machine. A prompt that says "be careful" is a request. It is not a control.

The question for an on-call tool is therefore not "how smart is the model?" The question is "what can the model cause, if it is wrong?"

Principles

1. Decide in code. Propose with models.

A model writes text: a severity, a cause, a report. Code decides whether an incident opens, closes, or needs approval, and whether a recipe runs. The model has no tool that closes an incident. Its diagnosis can end with conclude, which takes no action.

2. A closed catalog of signed recipes.

A recipe is a signed JSON document. Each step is a fixed list of arguments. No step is a shell string. Parameters have types and allowed values. A model selects a recipe and fills parameters. It cannot add a step.

3. Separate who thinks from who acts.

The process that talks to the server over the network does not run commands. A second process runs them. That process has no network access and verifies each order against keys built into its binary.

4. Start by watching.

Every machine starts in audit mode. Audit mode reads and reports. It changes nothing. You move a machine to shadow, then to live, when you trust what you saw.

5. Evidence, or no claim.

A report cites evidence IDs. A check flags each claim that has no evidence. A report that says "no action ran" must be true, and the audit log can prove it.

Architecture

The path of an incident

1. An agent on the machine reports signals. A rule in the server opens an incident when a signal fails.
2. Triage: a model proposes a severity and a class. A safety classifier checks the output.
3. Diagnosis: a model reads evidence through read-only tools and writes a cause. A specialist can help. A specialist never executes or approves, and delegation goes one level deep.
4. Report: a model writes the report. A check compares each claim with the cited evidence. Text that repeats the prompt is blocked.
5. Execution: code selects a recipe. The machine mode and the approval rules decide the next step.

The executor

The executor is a separate process that runs as root. Its unit sets PrivateNetwork=yes and RestrictAddressFamilies=AF_UNIX. It receives an order on a local socket. It verifies the signature of the order and of the recipe. It runs the dry run, the steps, and the verify step. It reports the result.

A compromised agent cannot make the executor run an unsigned recipe. The agent does not hold the signing keys.

Modes and approval

Each machine has a mode: audit, shadow, or live. The effective mode is the lowest of the machine setting and the limits above it. A recipe has a risk level and a trust level. A person approves each run when the trust level requires it.

Tenants and keys

Row-level security in the database separates workspaces. Each workspace has its own keys, derived with HKDF and sealed. You can bring your own model key. Kosken does not issue model keys. The endpoints for model calls are fixed in code, and context is redacted before it leaves.

Audit

Each audit entry includes the hash of the previous entry. A signed anchor is written each day. If someone edits an old entry, verification fails. This detects tampering. It does not prevent a person with full database access from deleting the whole log and its anchors. Anchors stored outside the database reduce that risk.

Lessons from earlier projects

The author of Kosken built two earlier projects: OpenRemedy and NanoInfra. Kosken takes ideas from both. It shares no code with either.

OpenRemedy

OpenRemedy is the author's earlier incident-response project. Its public whitepaper, version 1.2 (July 2026), is titled "The moat is the harness, not the model." Kosken takes that thesis.

We changed these things:

• Kosken starts every machine in audit mode. OpenRemedy let an operator start in live mode.
• Kosken has a closed catalog of signed recipes. We found that recipes written by a tenant, or drafted by a model, were the hardest part of the earlier design to trust.
• Kosken has a separate executor with no network. In the earlier design, the central service held the access that ran commands.
• Kosken gives the model no way to close an incident. An earlier attempt to let a model close incidents was reversed after it closed incidents that were still open.

We also learned three general lessons. First, arguments that a model fills can carry shell syntax, so a tool must pass arguments as a list and never build a string. Second, an approval that resumes a paused run needs a stored state, or the run can loop. Third, a safety check that blocks too much teaches people to turn it off.

OpenRemedy is stronger in one area: it has been in use longer, so its operational experience is larger than ours.

NanoInfra

NanoInfra is an open-source project (MIT licence, github.com/nanoinfraorg/nanoinfra, version 2.3.2 released 9 September 2026). It splits the part that reasons from the part that executes, and it uses Landlock to limit what the executor can reach. Kosken takes the split.

Kosken limits its executor with systemd settings, not with Landlock. We did not test the two approaches against each other. Landlock limits file access in ways that our unit settings do not, and we may add it.

What we do not claim

• We do not claim that Kosken is safer than another product. We did not test other products.
• We do not claim a rate of correct diagnoses. We have no measurement that would support one.
• We do not claim that a signed recipe is a correct recipe. A signature shows who approved the text. It does not show that the text does what you want.
• We do not claim that audit mode proves the future. A fix that looks right in audit mode can still fail in live mode.
• We do not claim protection from a person who controls the server host. That person holds the keys.

Status

As of 15 November 2026:

• Kosken runs on three machines that belong to its authors.
• It has no customers.
• We have not yet seen Kosken fix a real fault by itself in live mode.
• Email delivery, Stripe billing, and single sign-on are built but not configured on the hosted service.
• The service is free for up to 5 machines. Paid blocks of 5 machines come later. The price is not published.
• The Terms of Service and the Privacy Policy are drafts. A lawyer has not reviewed them.

Comparison

This table lists only facts that we can source. "Not checked" means we did not look. We list OpenRemedy and NanoInfra because they are the projects that Kosken learns from.