Process attestation

One signed file from a stopped process host shows a reviewer that a run, or one call inside it, happened under the authority it claims. The host signs an observation of its own retained state with its kernel key, and the reviewer checks that observation offline against pins held apart from the host.

The pins are the kernel public key, the runtime ID, and, for native tools, each server's launch-policy signer. The attest-run, attest-call, and attest-outcomes commands read the host's state and run only on Linux; verify-run, verify-call, and verify-outcomes read only the artifact and the pins, so they run on any Unix host, macOS included.

1. Choose the artifact that covers the work under review

Pick the scope from the question before collecting anything. The reference run below fans out to reader-1 and reader-2, which read one file each through one confined launch of a repository reader.

Use attest-run for a completed fan-out whose workers all returned allow, attest-call for one allowed, denied, or uncertain call, and attest-outcomes for every worker, interrupted ones included. A completed-run view of an incident with a worker that never returned would drop the uncertainty you need to investigate.

An attestation makes retained work inspectable and leaves judgment of the result to the application: a correctly attributed worker can still write an incorrect report.

2. Collect the pins from your provisioning records

Set STATE to the existing host state directory, and take every pin from your retained provisioning records before you open any artifact. None of them comes from the artifact under test.

STATE=/absolute/path/to/the/existing/host

TRUSTED_KERNEL_PUBKEY is the public-key file authority.db.kernel.pub in the initialized state directory, and TRUSTED_RUNTIME_ID comes from the same initialization. Each native server's TRUSTED_SERVER_ID and TRUSTED_LAUNCH_SIGNER come from the operator-owned host configuration, passed as SERVER=PUBLIC_KEY once per server; a host with only built-in mailbox tools needs none.

3. Export from the stopped Linux host

Stop the serving process, then export the run with the runner plan the workers ran under, or one call with its request and context frozen before invocation and its response exactly as received.

chio process attest-run \
  --state "$STATE" \
  --plan "$STATE/reference-run-plan.json" \
  --out run.json

chio process attest-call \
  --state "$STATE" \
  --request request.json \
  --context context.json \
  --response response.json \
  --out call.json

You should see attest-run print the artifact path, its receipt ID, the runtime ID, and the worker count. Export takes the state directory's lease, so it refuses while a host is serving, and it requires the runner's completion journal with every worker in the plan completed and no container or socket cleanup outstanding.

Export reads each worker's retained request, response, and continuation custody, the captured invocation count from the family budget store, and, for a native tool, the launch and terminal receipts its call references. It signs a join receipt over the workers' tool receipts and a terminal graph receipt over the digest of their results, both only inside the artifact. It dispatches no tool call, creates no admission authority, and leaves the host's retained authority unchanged.

With execution_nonces: true in the host configuration, export first checkpoints the receipt log, adds each call's original execution-nonce custody and its receipt's inclusion proof, and writes chio.process.completed-fanout.v3; otherwise it writes chio.process.completed-fanout.v2. It verifies its own artifact before writing it to a new private file. An export failure never calls for replaying the effect: reconcile the original operation in recovery first.

4. Verify the run under your pins

Give the verifier the artifact and the pins from step 2. The recorded invocation below ran on Linux 6.17.0-1020-oracle x86_64 with a chio built for x86_64-unknown-linux-gnu, against the reference run.

chio process verify-run --artifact run.json --trusted-kernel-pubkey kernel.pub --runtime-id d8320379-e3f5-4eed-a80b-d526f2609aae --trusted-launch-policy-signer reference-reader=94dcfb118ae7b3321c8430d1bbaf1514c7df38addda1726422a0de61c0e28acb

{
  "schema": "chio.process.run-verification.v1",
  "runtime_id": "d8320379-e3f5-4eed-a80b-d526f2609aae",
  "verified_workers": [
    "reader-1",
    "reader-2"
  ],
  "captured_invocations": 2,
  "verified_native_launches": 1,
  "checks": [
    "signer_pin",
    "runtime_pin",
    "issued_capabilities",
    "worker_responses",
    "task_authority",
    "actual_join_parents",
    "terminal_result",
    "runner_completion",
    "aggregate_usage",
    "continuation_custody",
    "confinement_receipt_chain",
    "execution_nonces",
    "receipt_log_inclusion"
  ],
  "artifact_schema": "chio.process.completed-fanout.v3",
  "unchecked": [
    "scenario_matrix"
  ]
}

You should see two verified workers, two captured invocations, and one verified native launch: both calls went through one confined launch of the reader, and the host ran with execution_nonces: true, so the artifact is version 3. The verifier prints a report only when every check passes, and any failed check is a refusal instead. Standard error was empty and the command exited 0.

chio process verify-run \
  --artifact run.json \
  --trusted-kernel-pubkey "$TRUSTED_KERNEL_PUBKEY" \
  --runtime-id "$TRUSTED_RUNTIME_ID" \
  --trusted-launch-policy-signer "$TRUSTED_SERVER_ID=$TRUSTED_LAUNCH_SIGNER"

5. Verify one call against its frozen request

Retain request.json and context.json from the call you sent, and give the verifier those files. It requires the artifact's request and context to equal yours, and never takes their values from the observation.

chio process verify-call --artifact call.json --request request.json --context context.json --trusted-kernel-pubkey kernel.pub --runtime-id d8320379-e3f5-4eed-a80b-d526f2609aae

{
  "schema": "chio.process.call-verification.v1",
  "runtime_id": "d8320379-e3f5-4eed-a80b-d526f2609aae",
  "process_id": "reader-1",
  "request_id": "process:8e8d938e5acfe9f2e4ebe25fbcbda6da1c2eb1ba7ffccece07d026ac80b589c3",
  "observed_operation_state": "completed",
  "custody_binding": "original_call_commitment_and_signed_store_readback",
  "artifact_schema": "chio.process.call-observation.v2",
  "checks": [
    "signer_pin",
    "runtime_pin",
    "original_request",
    "issued_capability",
    "worker_response",
    "retained_operation",
    "continuation_custody",
    "execution_nonces",
    "receipt_log_inclusion"
  ],
  "unchecked": [
    "task_authority",
    "aggregate_usage",
    "confinement",
    "physical_effects",
    "graph_completion",
    "scenario_matrix",
    "witnessed_parent_authority"
  ]
}

You should see reader-1 bound to its original retained operation, captured on the same host for the first worker of the same run. The unchecked list is longer than the run's: one call says nothing about task authority, family usage, physical effects, graph completion, or the scenario matrix, and a call made without the credential broker carries no evidence of its confinement or of witnessed parent authority.

custody_binding names where the custody claim came from. A denied call with no retained operation reports no_custody_claim, and that observation leaves open whether an effect occurred. To observe every worker at once, run attest-outcomes and verify-outcomes with the same state, plan, and pins as the run pair; for a version 3 artifact the report lists each worker's observed operation state and each referenced native launch, and names physical_effects, scenario_matrix, original_interrupted_launch, and target_death_without_terminal as unchecked.

chio process attest-call --state "$STATE" --request request.json \
  --context context.json --response response.json --out call.json

chio process verify-call --artifact call.json \
  --request request.json --context context.json \
  --trusted-kernel-pubkey "$TRUSTED_KERNEL_PUBKEY" \
  --runtime-id "$TRUSTED_RUNTIME_ID"

Artifacts and verification checks