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.

More precisely, Etch proves the integrity, sequence, and attribution of what was recorded. Completeness of the record and legitimacy of the underlying authority are separate organizational properties, not chain guarantees. The distinction matters when an auditor evaluates the evidence against a specific standard: the chain establishes that the record has not been altered and that its entries are attributed to the signing party; the organization must still establish that the required events were captured and that the authority under which each action was taken was itself legitimate.

• 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. As of 2026-09-26 Etch ships a per-project per-pattern-class secret-leak policy so operators can flag, redact, or refuse ingest for detected SSN, credit card, JWT, and common API-key patterns; defaults preserve compat (no behavior change) so opting in is explicit. Full policy semantics and preset shapes are in the admin API.
• 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.
• Not guaranteed today (KMS in progress): defense against Etch itself. The Ed25519 signing key currently lives on the same server as the audit database, so an attacker with access to Etch's servers could rewrite past entries and re-sign them without being caught by a signature check. Detection still holds for anyone WITHOUT that access: an external verifier who holds pinned public-key fingerprints catches every content or signature mutation performed by a non-privileged party. Moving the signing key to KMS so the server never holds plaintext is on the roadmap; until then, an auditor relying on Etch for defense against Etch should also pin previously-observed (log-index, head-hash) pairs from the transparency log so a re-sign is caught as a log-head divergence.

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.

The ratio speaks to legibility, not to evidentiary completeness or organizational sufficiency. A technically substantive record with a high weight-bearing ratio may still omit the specific event or condition that matters to a later decision. Whether the required events were captured in the first place is an organizational property outside the chain's scope.

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.