Your servers are headless. So how does anything run?

The first question every integrator asks. The answer below is what the kernel code does, and every verdict in the simulator is computed by the same model of that code as the main page — including the cases that go through when you might wish they did not.

“Our customers run fleets nobody logs into. Cron jobs, systemd units, backup agents, CI runners. If a resource needs a human action as its causal ancestor, then on those machines nothing can touch anything — which means either your model breaks them, or there is an exception you have not told me about.” — the objection, as it is usually put (paraphrased)

There is an exception, and here it is. On a machine with DCC Ring 0 loaded, a write, a connection, a send or an exec gets through in exactly one of three ways.

The three doors

1 · The binary is whitelisted, within an effect-scope

The operator names trusted executables when loading the layer. The kernel records which executable file each process runs (inode and device, written at exec time), so renaming a process does not borrow that trust (D-15). Each whitelist entry carries an op-class scope — write, network, exec, read, or any — and the binary is exempt (no token needed) only for the effect classes in its scope; any other effect falls to the token path and is refused without one. A backup binary scoped to write cannot open the network; a daemon scoped to net cannot write. This is measured (D-21). Two caveats: a file marked OP_BLOCK overrides even an in-scope write; and the scope is by effect class, not yet by destination or path — a write-scoped binary may still write any non-OP_BLOCK file (that tightening is below). An entry given any scope is the old blanket exemption.

2 · The process holds a token from the authority

A job that is not whitelisted can ask the authority for a token over an authenticated channel — signed, replay-protected, bound to the caller's identity, rate-limited (D-07). The authority decides by its own policy and issues the token through a program only a privileged caller can run; the application cannot issue one to itself (D-06). The token lives 500 ms from issue. Its first write consumes it and binds the job to that one file; connections, sends and execs inside the window do not consume it. A child forked before that first write inherits it, at most three generations deep.

3 · Everything else

Refused with EPERM: the miner in /tmp, the build step past its window, the process that renamed itself.

Simulator

Configured as the proof runs were: write path blocking, network and exec guards blocking, read guard at its default (off), identity by executable file. Green titles are expected to go through, red ones to be refused, blue ones follow a token, amber ones show a weak edge.

No scenario run yet0 lines

The policy the simulator runs

Whitelisted executableIdentityUsed for
Axiom key (first 15 characters)RuleMeaning

Illustrative entries chosen for the scenarios — not the configuration of any deployed host.

“So it is just allowlisting.”

For unattended work — yes, and an integrator who says so is right. On a whitelisted binary the layer adds nothing but the OP_BLOCK files: no destination check, no per-file rule. We would rather say that plainly than dress it up.

What an allowlist alone does not give you is everything the allowlist does not name. A binary that is not on it — the dropped miner, a compromised build step, an agent's freshly written tool — can act only inside a 500 ms window that an authority opened on request, can write only the one file its first write chose, and cannot open that window itself. The claim is about the pair: a short, reviewable list for the enumerable unattended work, and a causal window for the rest.

That makes the list the part to keep small. Every entry is a program trusted with everything, forever.

Weak edges

Still open

Long human-initiated work

The window is 500 ms from issue, and an inherited token keeps its parent's timestamp. A build that runs for four minutes cannot be carried by inheritance. How long-running work that a person started should be authorised — a fresh request to the authority per step, or an attested session — is not decided.

Remote administration

For a machine nobody stands next to, the authority is the answer, and it exists and is measured (D-05 – D-07). What it does not yet have is a hardware-bound credential for the person asking: today the request is authenticated with a shared secret (O-D4), not a FIDO2 or TPM-backed key.

Measurement

Fork inheritance, the TOCTOU pivot, op_class and the OP_BLOCK case were measured on a live kernel with a real token on 2026-09-11 (D-16 – D-20); what that run captured is the effect, not the kernel's verdict names, which are still owed. The fork depth limit and content binding are not yet measured — see Evidence.

Two questions this page used to leave open

Does a consumed token pass to children?

No. A child inherits only a live, unconsumed token; exec, connect and send never consume it; only the parent's first write does. A build that forks before it writes keeps its chain, one that writes first does not — the CI scenario shows both.

Is an axiom per program or per file?

Per file name — coarser than either, as described under Weak edges.

Kernel model: dcc_core.bpf.c, build 2026-08-07; every verdict on this page is computed by it — see how it is checked. The implementation, measurement protocols and deployment notes are in the technical dossier, shared under NDA: admin@metaspace.bio.