The runner boundary, protocol by protocol

Legacy collection and Runner v2 do not have the same authority. This page names what remains runner-side, what can cross for governed custody, and what the released verify-only package cannot execute.

Back to the trust center Where inference happens

Reviewed 2026-08-28

What each side receives

Protocol custody mapTwo protocols. Two different authorities.

Published register · reviewed 2026-08-28

The customer runner boundary appears first, the ControlFrame control plane second, and each permitted crossing is named between them. The table following this visual contains the same facts as authoritative detail.

Runner-held material

Target access: Target credentials, session material, API keys, mTLS material, and the request-signing private key remain in the runner environment.
Runner identity: The bearer token, request-signing private key, and raw appliance fingerprint are protected as service-identity-only inputs.

Scoped control-plane records

Target access: The control plane stores scoped job and target metadata. It does not receive target credentials through the runner protocol.
Runner identity: Signed requests present the token and raw fingerprint over TLS. The registry retains the token digest, public-key fingerprint, appliance-fingerprint hash, runner identity, and release binding—not the raw private key or fingerprint.

Legacy collectionRunner-side state

Artifacts that are not selected for submission, or exceed protocol limits, remain outside the control-plane evidence record.

Bounded artifact path

Legacy artifact transferControl-plane outcome

Legacy completion may submit bounded raw artifact bytes or immutable references. Accepted bytes enter custody, scanning, redaction, human review, and release gates; this is not a hash-only or local-only protocol.

Runner v2Runner-side state

Root-owned release files, service inputs, signing keys, and the durable replay ledger remain on the appliance.

Signed verify request only

Runner v2 verify-onlyControl-plane outcome

The signed handshake records an immutable verified or refused terminal receipt. It grants no target contact, credentials, browser process, artifact transfer, evidence creation, or CMS execution.

Evidence release

Withheld or locally retained material does not become a ControlFrame evidence object.

Submitted legacy artifacts become eligible for release only after separate custody, scanner, redaction, reviewer, and package gates succeed.

Runner protocol and data boundary
Category	Runner side	Control-plane side
Target access	Target credentials, session material, API keys, mTLS material, and the request-signing private key remain in the runner environment.	The control plane stores scoped job and target metadata. It does not receive target credentials through the runner protocol.
Runner identity	The bearer token, request-signing private key, and raw appliance fingerprint are protected as service-identity-only inputs.	Signed requests present the token and raw fingerprint over TLS. The registry retains the token digest, public-key fingerprint, appliance-fingerprint hash, runner identity, and release binding—not the raw private key or fingerprint.
Legacy artifact transfer	Artifacts that are not selected for submission, or exceed protocol limits, remain outside the control-plane evidence record.	Legacy completion may submit bounded raw artifact bytes or immutable references. Accepted bytes enter custody, scanning, redaction, human review, and release gates; this is not a hash-only or local-only protocol.
Runner v2 verify-only	Root-owned release files, service inputs, signing keys, and the durable replay ledger remain on the appliance.	The signed handshake records an immutable verified or refused terminal receipt. It grants no target contact, credentials, browser process, artifact transfer, evidence creation, or CMS execution.
Evidence release	Withheld or locally retained material does not become a ControlFrame evidence object.	Submitted legacy artifacts become eligible for release only after separate custody, scanner, redaction, reviewer, and package gates succeed.

Customer operation does not imply that every artifact is local-only. The protocol controls what crosses: legacy collection can submit bounded evidence for governed custody, while Runner v2 currently proves binding and release integrity only and cannot execute collection.

Implemented

The controls that exist today

These controls are implemented in their named protocol. A legacy lifecycle control is not presented as Runner v2 execution authority, and a verify-only receipt is not presented as evidence collection.

Project- and appliance-bound credentials: Runner tokens are stored as digests and bound to the organization, project, runner identity, appliance fingerprint, and request-signing public key. Production rejects an unregistered or mismatched runner.
Proof of possession and replay refusal: Runner requests are signed with an Ed25519 key held by the runner. The control plane verifies the method, exact path, bounded body, timestamp, and nonce before issuing project context, and consumes each nonce once.
Fenced legacy job lifecycle: Claims, heartbeats, completion, and failure are bound to the job, attempt, and lease. Stale or mismatched lifecycle requests fail rather than settling another attempt.
Release-bound Runner v2 verification: The approved verify-only release has an exact source-controlled manifest, package digest, executable-bundle digest, root-owned prelauncher and service unit, and a retained install receipt before token use.
Immutable verify-only outcome: A successful or refused verification is recorded as an append-only terminal event. The worker uses a durable replay ledger and cannot convert the verification receipt into execution authority.
Legacy CMS UI-001 refusal: Generic queue routes, the legacy worker, workflow wrappers, and the collector entrypoint refuse selectors resolving CMS EDE UI-001. Its scope intent and activation remain held and nonclaimable.
Separate artifact promotion: A runner completion does not make an artifact releasable. Custody, scanning, redaction, human review, and package authorization remain independent gates.

Not implemented

The release boundary

The verify-only package establishes a reproducible appliance binding. It does not authorize collection. Execution, target access, artifact intake, and evidence promotion remain a separate release boundary and stay listed here until shipped.

Packaging reality, as of 2026-08-28

ControlFrame ships a reproducible, root-owned Runner v2 verify-only package and installation contract. It is not an execution-capable collector appliance. The separate execution, lease, artifact-intake, and evidence-custody protocol remains unreleased; legacy collection remains a distinct protocol.

Runner v2 execution and custody: No Runner v2 execution lease, browser authority, credential profile, artifact-intake contract, or evidence-promotion authority is released. Those require a separate manager authorization and custody tranche.
Legacy local-only guarantee: The legacy protocol can transfer bounded raw artifact bytes. Buyers requiring evidence to remain entirely inside their network need a future execution-and-custody mode that makes that boundary enforceable, not a reinterpretation of the current protocol.
Managed appliance distribution: The verify-only install is a reviewed, source-controlled, out-of-band procedure. It is not a remotely attested managed image, signed update channel, or execution-capable installer.
Transport-level client certificates: Application-layer Ed25519 proof of possession is implemented. Transport-level client-certificate mTLS is not available through the current hosted ingress and is not claimed as equivalent terminology.

How tenants are isolated in the control plane · Back to the trust center