Security

Etch is a signed audit chain for AI agent decisions. This page names the security properties Etch does guarantee, the properties Etch does not guarantee, the adversarial tests that prove the guarantees hold, the conformance vectors any independent implementation can verify against, and the coordinated-disclosure channel. Kept on one URL so a buyer-side security team or regulator can walk the whole posture in one pass.

What Etch guarantees, and what Etch does not

Etch is a stay-pure notary. It proves what happened. It does not decide what should happen next. Every guarantee below is a detection property, not a prevention property.

• Guaranteed: any tampering with a recorded event is detectable by an external verifier who holds the Ed25519 and SLH-DSA public-key fingerprints, or a previously-observed (log-index, head-hash) pin. Detection is a code-testable property, not a subjective judgment.
• Guaranteed: post-quantum forgery resistance for every epoch signed today. Each closed epoch carries a hybrid signature: Ed25519 (classical) plus SLH-DSA-SHA2-128f (FIPS 205, hash-based, post-quantum). An adversary who breaks Ed25519 in the future still faces the SLH-DSA signature over the same payload.
• Guaranteed: independent, offline verification. The etch-verify CLI ships in the MIT-licensed world-model-mcp PyPI wheel; an auditor runs it on their laptop against a downloaded manifest without any network access to Etch.
• Not guaranteed: preventing tampering. The operator has root on their storage; Etch cannot stop a delete. Etch guarantees the delete is detectable, not that it never happens.
• Not guaranteed: sub-epoch immutability. Between two epoch closes the underlying database is mutable by the operator. Every event you care about should be recorded via record_event, which forces closure on a fixed cadence so the signed epoch boundary is short.
• Not guaranteed: confidentiality. The audit log is not encrypted at rest by design; auditors need to read it. If events contain secrets, redact before recording.
• Not guaranteed: defense against a colluding auditor. Etch's design assumes at least one honest party in the auditor role. If the operator and the auditor collude, no cryptographic system can help.

Threat model

Etch's threat model assumes an insider adversary: the operator themselves may be malicious, may hold the classical Ed25519 signing key, may modify storage on disk, and may serve different history to different clients (split-view). The threat model assumes the adversary cannot forge SLH-DSA signatures without the SLH-DSA private key (envelope-encrypted in KMS, separate custody from Ed25519), cannot recompute SHA-256 collisions on demand, and cannot access previously-observed client pinned heads.

Full threat-model write-up with per-attack property + defense citations lives in the open-source repository at docs/adversarial_analysis.md. Every claim in that doc is locked by a green test in the same repository under tests/test_adversarial.py.

Adversarial benchmark

Two layered adversarial suites lock the threat-model claims to green tests.

• 13 hosted adversarial tests, all passing. Attacks covered: rewriting past event content (naive + sophisticated with recomputed leaf hash), deleting an entry from the middle, inserting a forged entry, reordering entries, forging a new genesis, rewinding a truncated log, stripping the signature envelope, canonicalization-based attacks, concatenating two valid chains, duplicating an entry in place. Source of truth: tests/test_adversarial.py.
• 14 offline-verifier adversarial tests, all passing. Independent OSS-repo test suite covering chain-tamper attack classes caught by the offline etch-verify verifier alone (no server side involvement). Source of truth: world-model-mcp-adversarial-benchmark. Scope claim; new attack classes may be added later, and this URL is the single source of truth for the current count.

Conformance vectors

The Portable Agent Identity v1.0 specification (Zenodo DOI 10.5281/zenodo.22154537, CC-BY-4.0) ships with 9 published conformance vectors under spec/portable-agent-identity/vectors/ in the hosted-service repository. Any independent implementation can prove conformance by parsing every valid vector and rejecting every invalid vector with the reason named in the sibling .meta.json file.

• 2 valid vectors: valid-minimal.json, valid-with-description.json.
• 7 invalid vectors, each covering one required rejection class: bad salt base64, fingerprint mismatch, missing encrypted material, non-empty bindings on mint, unsupported schema version, unsupported cipher algorithm, unsupported KDF algorithm.

Vector files: spec/portable-agent-identity/vectors. Specification: spec/portable-agent-identity/v1.0.md.

Row-quality report (G3)

Track B v1.1.1 shipped a G3 row-quality report: every verifier run reports the fraction of rows in the chain that carry a weight-bearing field (a field the record's later behavior depends on, not a purely descriptive tag). The report is per-project, computed at verify time from the chain manifest, and surfaced on the auditor-preview page an operator mints for their auditor.

Semantics: ratio = weight_bearing_rows / total_rows. A row is weight-bearing when its stored fields would change a verifier's replay outcome; a row is not weight-bearing when it only decorates the record. The ratio is not a pass/fail metric; it is a legibility metric an auditor uses to decide whether the chain carries enough substance to reconstruct decisions or is mostly descriptive noise. The report freezes to a specific spec version so a chain that verifies today verifies the same way against the same report next year.

Post-quantum stance

Ed25519 will eventually be broken by a sufficiently large quantum computer running Shor's algorithm. Every closed epoch Etch signs today carries a hybrid signature envelope: Ed25519 (classical, fast) alongside SLH-DSA-SHA2-128f (FIPS 205, stateless hash-based, post-quantum). For any epoch signed today, the signature envelope remains valid evidence in a post-quantum world; an adversary who develops quantum capability and steals the operator's Ed25519 key still cannot forge a past head, because the SLH-DSA signature over the same payload would need to be forged too.

This is the "harvest now, decrypt later" defense applied to signatures: sign now with both algorithms, and the historical record survives even if one algorithm is broken later.

Coordinated disclosure

Suspected vulnerabilities: contact channel + PGP fingerprint at /.well-known/security.txt (RFC 9116). Please do not open a public GitHub issue for a vulnerability. Sensitive reports get a private-response acknowledgment within one business day; the policy line and canonical URLs are documented in the same security.txt file. Etch operates a single-maintainer disclosure channel today; scope grows when the team grows.

What Etch is not

Etch does not gate agent actions, sit in the request path, or decide what an agent should do next. Runtime control planes, policy engines, and gateways exist for that. Etch's job is to prove after the fact what did happen, in a form an external auditor, regulator, or insurer can verify without cooperation from the operator.

"We prove, we do not block."

Every URL above resolves to a public artifact anyone can inspect independently. Detection properties, adversarial tests, and conformance vectors are open source; anyone who wants to challenge a claim on this page can rerun the tests against the published sources.