# Threat Model
Assets are service viability, data integrity, authority history, signing keys,
decision integrity, and audit evidence.
Adversaries may control one declared authority principal, replay signed history, equivocate,
forge observations through an adapter, delay messages, trigger partitions, exploit
parser differences, or exhaust hypothesis computation. They may be an insider with
a valid signing key.
Initial exclusions are simultaneous compromise beyond the declared budget,
hardware/OS compromise of the checker, cryptographic breaks, arbitrary side
effects outside the simulator, correlated viability-principal semantics, and a
malicious viability specification signed by all trusted principals.
Controls include canonical encoding, domain-separated signatures, key rotation,
freshness/lineage checks, resource bounds, independent implementations,
transactional simulation, least privilege, append-only evidence, and fail-closed
timeouts.
The post-M3 fault model authenticates distinct viability issuers and excludes one
issuer per bounded hypothesis. Distinct keys establish principal identity, not
organizational or implementation independence.
Certificate v3 groups viability issuers by declared fault domain. Correlated
failure inside one domain is covered; shared failure across every surviving
domain produced a retained unsafe approval in the v3 experiment.
Certificate v4 adds a viability-independent stable-key continuity kernel:
transitions cannot delete keys present on every authenticated current replica.
This removes the reproduced cross-domain unsafe approvals. It does not cover a
key omitted by every malicious phenotype replica, combined goal/phenotype
corruption beyond the declared bound, or an authorized-deletion use case.
Certificate v5 authenticates multiple goal issuers and excludes declared goal
fault domains. Goal values must agree exactly before planning; disagreement is
fail-closed. Separate keys and domain labels do not establish independent policy
authorship, custody, implementation, or deployment.
Certificate v6 authenticates separate deletion issuers and binds their exact key
set to the goal digest and phenotype tip. Cross-context replay, divergent
authorization, missing domains, and authorization overbreadth fail closed.
Certificate v7 derives an identifier from the exact signed deletion-envelope set
and consumes it atomically with the history anchor in the anchored path.
Stateless replay, organizational independence, and production side effects
remain outside scope.
Authenticated phenotype history rejects chain and anchor rollback within a
64-record bound. The trusted anchor is configuration in this harness; compromise
or rollback of that trust root remains outside the demonstrated protection.
The durable-anchor prototype detects store-level sequence rollback and conflict
under a trusted local filesystem. Filesystem compromise, malicious lock recovery,
disk firmware rollback, and multi-host split brain remain outside its protection.
The consumption ledger is bounded at 4,096 validated identifiers and its state
file at 512 KiB; either limit fails closed. Evidence failure after durable
consumption can burn an authorization; this is a deliberate availability loss
rather than permitting an uncertain replay.
The certificate-v8 local actuator prevents stale or concurrent evaluation from
committing by rechecking authenticated observed state and the transition
precondition under its lock. Its service state, history anchor, and deletion
ledger are one atomic file replacement. Local operator compromise, filesystem or
firmware rollback, unauthorized file access, and non-transactional external
adapters remain outside the demonstrated protection.
The schema-v2 recovery witness detects accidental stale primary-state restore and
resolves process termination before or after atomic replacement. It does not
resist rollback of both state and witness, witness deletion, forged local files,
or violated filesystem `fsync`/rename semantics. Exact-latest restore fails
closed if the co-located witness is lost.
Operational issuer keys may be rotated, expired, or revoked through bounded
recovery-root-signed chains. A compromised operational key cannot sign its own
recovery because roots must be distinct and are never operational. Recovery-root
compromise remains critical: it can authorize arbitrary future keys. Lifecycle
roots, trusted tips, evaluation time, and the bounded trusted-time assertion are
scenario configuration. Local rollback, forward-jump, and maximum-window checks
do not provide an independent clock; coordinated rollback of that configuration
remains outside the detected boundary.
The recovery-root ceremony model binds a strict-majority quorum to exact request
and evidence digests, retains the original quorum after exclusion, and treats
any veto as an abort. Its participant names and votes are unsigned local data.
It therefore demonstrates deterministic protocol behavior but not participant
identity, organizational independence, protected root-key custody, coercion
resistance, or a real authorization act.
The certificate compatibility boundary prevents unknown future versions,
unknown top-level fields, oversized inputs, and cross-version extension
relabelling from being treated as supported evidence. It does not authenticate
certificates, infer unknown future semantics, or protect a downstream consumer
that bypasses the boundary and deserializes the public structure directly.
Validate-then-regenerate avoids mutating historical evidence but cannot recover
missing authoritative inputs.
The Python reader reduces common-parser risk for version and top-level shape
decisions. Both implementations still follow one project-owned specification
and run on the same host, and the Python reader deliberately does not reproduce
all nested Rust types. A malicious certificate may therefore pass the envelope
reader yet fail later semantic processing. Neither reader authenticates who
created a certificate.
Detached Ed25519 attestation detects exact-byte tampering, certificate
substitution, cross-context replay, unknown signers, invalid signing windows,
and expiry. Key identifiers permit bounded rotation without rewriting historical
certificates. Compromise of a trusted private key remains critical: without an
external trusted timestamp or append-only witness, an attacker can backdate a
forged attestation inside that key’s declared window. Trust configuration,
evaluation time, signer identity, key custody, and revocation distribution
remain external.
The Python Ed25519 verifier is independently implemented for differential
qualification but is project-controlled and unaudited. Rust `ed25519-dalek`
strict verification remains the primary research implementation; neither
constitutes production HSM or organizational assurance.
The Post-M22 witness prototype bounds backdating after revocation by requiring a
separate signed timestamp observed before the inclusive revocation boundary.
Exact timestamp and revocation digests detect rollback and equivocation relative
to independently retained tips. Joint authority/tip compromise, malicious
clocks, unavailable distribution, and non-durable local tip configuration remain.
Post-M23 detects local tip rollback, same-sequence conflict, interrupted
replacement, stale/tampered restore, and copied-state inconsistency. It bounds
distribution attempts and refuses unavailable or equivocal artifacts. A hostile
disk, lock-owner impersonation, joint primary/witness rollback, power-loss
semantics outside the tested filesystems, endpoint compromise, and denial of
service remain outside the protection.
The isolated HTTP harness detects wrong credentials, delay beyond the request
deadline, dropped connections, oversized bodies, complete outage, stale
revocation, and equivocal bytes before verification can succeed. Because it uses
loopback fixture tokens and project-controlled processes, it does not defend
against TLS/DNS compromise, credential theft, hostile networks, endpoint load,
or organizational collusion.
The operator-return validator rejects request substitution, project-control
disclosures, same-origin authorities, non-HTTPS origins, incomplete outcomes,
hosted-CI claims, stale records, unknown fields, attachment traversal, oversize,
and digest mismatch. It does not authenticate names, organizations, signatures,
DNS ownership, endpoint behavior, or narrative truth; an independently trusted
assessor must verify those facts outside the repository.
The evaluation configuration boundary rejects unknown fields, future schemas,
mutation modes, oversized files, control/overlong paths, and configuration
output aliasing before target inputs are evaluated. It does not make
configuration trustworthy, protect output confidentiality, collect a coherent
live snapshot, or make certificate and ledger writes one transaction. Operators
must protect evidence directories, enforce a single writer per output pair, and
investigate partial persistence failures.
The Kubernetes shadow adapter has no client or cluster credentials. It rejects
resource-version/UID drift, partial or stale controller observations, oversized
exports, and output/input aliasing. A malicious or incoherent exporter that
fabricates a self-consistent snapshot remains outside the boundary; exact
agreement with signed Telosieve authorities is required but does not prove live
cluster truth.
The OpenTofu adapter has no backend, provider, state, credential, or apply
capability. It rejects unsupported format versions, non-update or non-built-in
resources, sensitive/unknown inputs, structural excess, exact authority
disagreement, producer byte disagreement, and invalid producer attestations. A
set of producers sharing the same plan-generation, provider, state, backend, or
custody fault can still corroborate a consistent lie. Provider behavior after
evaluation is outside the boundary; operators must retain and verify the
digest-bound saved plan and separately control any apply step.
The reference OpenTofu producer refuses symlinked/non-regular tools, saved
plans, and keys; single-link and size bounds apply before rendering. Renderer
and signing subprocesses have fixed deadlines and output limits. The configured
OpenTofu and Telosieve executables, host, filesystem, environment, saved binary
plan, and administrators remain trusted; process separation alone does not
isolate those faults or prevent plan contents from reaching producer memory.
The Redis Contract v1 adapter accepts only loopback endpoints, owner-only
single-link credential files, bounded RESP2 shapes and an atomic read-only
`MULTI`/`EXEC` collection over one configured namespace. The real Redis
qualification proves three distinct ACL
users cannot execute `SET`, and detects oversized topology, producer
disagreement and outage without evidence. All readers share one server, host,
administrator and harness; server compromise, consistent false replies,
credential theft, TLS/remote transport, cluster failover and independently
administered custody remain outside this local evidence.
The PostgreSQL adapter executes fixed SQL inside one repeatable-read, read-only
transaction with row, payload, statement, lock and process bounds. Credential
files are owner-only and passwords enter `psql` only through a temporary
owner-only pgpass file. The real qualification denies mutation, DDL and secret-
schema reads, and refuses racing disagreement, revoked credentials, excess
topology, stale producers, lock timeout and outage. All readers still share one
database administrator, server and host; consistent server lies, custody,
remote transport, failover and production topology remain outside this evidence.
The optional Linux producer relay separates evaluator and producer filesystem
identities through per-producer systemd users, client groups, tokens, sockets,
and hardening. Compromise of the evaluator can request observations but should
not expose signing keys or platform credentials. Compromise of one producer can
emit false observations and consume its own resources, but unique groups/tokens
limit direct access to peer relays. Root, kernel, systemd, shared host storage,
token provisioning, configuration authors, and common platform truth remain
correlated trust boundaries. The local qualification validates the relay under
one UID and therefore is not OS-identity or privilege-separation evidence.
The lifecycle manager rejects relative or symlinked roots and inputs, concurrent
operations, unexpected release content, backup symlinks, inventory or digest
tampering, and incorrectly confirmed uninstall. Atomic activation prevents a
mixed binary/configuration pair. Root-owner compromise, process termination
during filesystem operations, local-filesystem durability failure, malicious
administrators, network filesystems, and evidence changes by a concurrent
evaluator during backup remain outside this qualification; operators must stop
writers and protect the root and backup storage.
Diagnostics rejects symlinks, hard links, unsafe permissions, installation
manifest drift, evidence changes during hashing, resource-bound excess, and
output collision. Its allowlist omits contents, paths, names, environment, and
command output. SHA-256 and exact sizes can still correlate known or
low-entropy evidence, and a privileged local actor can change files between
separate entries; operators must stop writers and treat the export as sensitive.
Incident drills validate deterministic software responses, not operator timing,
hardware failure, hostile administrators, or multi-host disaster recovery.
Deterministic parser corpora bound test-case count and input bytes while
exercising malformed structures across four trust boundaries. They do not
replace coverage-guided fuzzing, sanitizers, arbitrary-input proofs, dependency
audits, or independent parser implementations.
The assessor handoff detects manifest drift, missing Git objects, artifact
digest changes, hosted workflow presence, dirty clean-checkout state, local-CI
failure, and operational-result divergence. It does not establish independence:
the repository, machine, dependency cache, and verifier are still controlled by
the project.
Locked dependency inventory detects package, source, checksum, and declared
license drift. RustSec matching detects only published advisories in the retained
database snapshot; it cannot detect unknown vulnerabilities, compromised
upstream releases or registries, malicious build scripts, license-text mismatch,
or toolchain compromise.
Private-bundle signatures bind exact bytes, context, signer identity, key ID,
and a maximum 30-day validity interval. Verification refuses unknown fields,
non-canonical encodings, ambiguous keys, invalid time windows, and oversized
inputs. Compromised signer hosts, memory disclosure, rollback of independently
supplied trust/time, key ceremony, revocation distribution, hardware custody,
and assessor independence remain outside the implemented boundary.
Commit binding prevents silent reuse of one bundle under a different declared
source identity. It does not prove that the binary was built from that commit;
reproducible-build provenance, compiler trust, custodian collusion, and ceremony
execution remain separate controls and assessment targets.
Isolated same-host rebuild comparison detects nondeterminism visible across two
clean target directories and later binary substitution. It shares the source
tree, host, compiler, dependency cache, environment, and build script, so a
common compromise or deterministic malicious toolchain remains undetected.
Bundle v3 additionally binds the supplied binary's capability output to the
packaged contract, configurations, and assessor test plan under bounded process
time/output and source-file sizes. This detects stale or substituted capability
surfaces during assembly. A binary can still lie consistently about its behavior;
real Kubernetes/OpenTofu execution and independent assessment remain necessary,
and the embedded unsigned profile is not authenticity evidence.
The real-cluster harness verifies actual namespace RBAC denial and read-only
target behavior with a short-lived token. A compromised host, Docker daemon,
kind image, kubectl binary, cluster administrator, admission chain, or shared
control plane can still falsify or alter observations; managed and independent
environments remain required.
The sustained-load qualification bounds 48 concurrent-process oversized-input
refusals and eight concurrent real-cluster evaluations without target mutation.
It does not establish production capacity, denial-of-service resistance,
host-wide resource isolation, hostile scheduling, or managed control-plane
behavior.
The PKI Prometheus publisher rejects unsafe, malformed, inconsistent, stale and
future monitor status and replaces prior metrics atomically with fixed-cardinality
fail-closed gauges. It does not authenticate Prometheus, secure the scrape path,
deliver alerts, prove retention, or establish independent operational response.
The observation-quorum primitive can detect one false producer only when a
separately trusted producer in a distinct configured domain signs different
exact bytes. It is not yet mandatory in evaluation, and labels do not prove
organizational independence. Colluding domains, compromised trust distribution,
key theft, and consistently false agreement remain outside its protection.
The HTTP/JSON adapter issues only GET to a bounded loopback path, refuses
redirects and lengthless or non-JSON responses, and keeps bearer tokens in
owner-only files. The loopback restriction deliberately avoids pretending that
the current implementation secures DNS, TLS, proxies or public networks.
Post-M52 pins a configured CA, requires TLS 1.3, hostname/IP verification and
distinct client certificates, and refuses plaintext downgrade. Ephemeral
project-generated certificates do not establish operational PKI, revocation,
custody, rotation or independent endpoint administration.
Post-M53 requires a CRL and enables leaf checks on both sides of the mTLS
connection. Local issuance, rotation and revocation prove enforcement mechanics,
not CRL distribution freshness, CA compromise resistance or protected custody.