Security & trust

Last updated: October 17, 2026

Threat model

Verdifax is designed so that a later change to a run's record no longer matches its entry on a public log that Verdifax does not operate. Since verifier 0.12.0, an entry counts only if it is signed with a published Verdifax log-signing key and the timestamp the log signs for it verifies, so a rewritten record that anyone else logs as a new entry fails. Verdifax holds that key, so that check alone does not catch a change made by Verdifax itself. From run 240 on, each record seals a 600-second anchoring window: a re-log by Verdifax after that window fails, and moving the record's sealed clock to fit changes the record's own date. Earlier records show their authenticated anchoring time but cannot fail on it. Nothing here shows that Verdifax sealed true inputs in the first place. Two layers are checked separately. Recomputing the execution record and its proof from the disclosed fields needs no key, no public log and no Verdifax service. The public-log checks are a second layer, which relies on the log's key and on Verdifax's published log-signing keys. What the design covers is what the record binds to the public log, which depends on when it was sealed. Successful runs sealed from run 239 (2026-10-16, 18:27 UTC) on carry a complete-record anchor, a second public-log entry over a digest of every section that the first entry states is required, so a rewritten section no longer matches that entry and deleting the entry fails verification. Run 238 carries the same second entry, but deleting it only lowers the verdict to partial coverage. On records sealed before run 238 it covers the run's identity and, on leaf v5 records (runs 236 and 237), its 33 pre-anchor values, which include the attested decision, the AIVP governance result, the payload hash, the actor and the scaffold flags; their descriptive sections (outcome summary, request substance, authorization and approval chain, real-world effects, system provenance) are sealed by hashes inside the bundle but are not bound to the public log, so they show the bundle is internally consistent, not that a party able to rewrite the whole bundle has not changed them. The platform is not designed to prevent the user's own program from being incorrect, malicious, or biased, those are evaluation problems upstream of the attestation pipeline. See What the Manifest Hash proves for the precise scope of the cryptographic claim.

Cryptographic primitives

All hashing uses SHA-256. Canonicalization uses RFC 8785 (JSON Canonicalization Scheme). The zero-knowledge layer (ZKSP) is a disclosed scaffold: it emits a deterministic hash facade in place of a real zero-knowledge proof, and its status field must equal the expected literal token (SCAFFOLD_R1CS_HASH_FACADE) for the run to seal. Anything else aborts the manifest. The Lean 4 development referenced in each new audit bundle verifies theorems about a model of the pipeline; it does not verify the prover or the production Go binary. See Scaffold gaps. We do not invent cryptography; we compose standard primitives.

Hardware attestation

Runs sealed with a SEV-SNP attestation agent carry a genuine AMD SEV-SNP attestation report taken before the run's execution record is built: the report's guest-controlled field is computed from the record's other fields, the report's hash becomes the record's hardware field, and the orchestrator verifies the report's certificate chain against AMD's Milan root of trust (pinned by fingerprint) plus its signature before sealing. A configured agent that fails halts the run rather than sealing it without the hardware. The report and certificate chain are embedded in the audit bundle so any third party can re-verify them offline. The hosted service runs without a hardware agent today; those runs disclose that honestly with a per-run scaffold flag, which reports what each individual run actually carried. Additional platforms (TPM 2.0, Nitro Enclaves) and a multi-vendor quorum root of trust are disclosed roadmap items, not current capabilities.

Determinism guarantees

Every Verdifax hash is SHA-256 over a canonical preimage defined by the §0 specification, so the same canonical field set always produces the same hash, byte-for-byte. Shared canonical test vectors lock the Go and Python implementations of the DSE, DCAE and CRES kernel formulas to identical output. The pipeline's computation is deterministic as well: replaying the same inputs under a pinned clock and nonce, with the public-log anchoring stage held fixed, reproduces the same manifest hash byte-for-byte, and POST /execute/verify-determinism runs exactly that check. This is a primitive of the system, not an aspiration.

Determinism does not mean that resubmitting the same inputs reproduces an earlier hash. Every /execute call mints a fresh admission clock and per-run nonce, and both enter the manifest hash and the anchored public-log leaf, so two separate submissions of identical inputs are distinct records with different hashes, by design. A production record's hash also binds its own unique public-log entry, so a production record is verified by recomputing its seals from its recorded fields, not by re-running it.

Independent verification

Every Verdifax audit bundle can be checked by a verifier that does not trust Verdifax. The open-source verifier, verdifax-verify, runs on your own machine and, offline, recomputes every section hash, the bundle hash and the anchored public-log leaves from the bundle's own fields, confirms every section is bound to the same manifest hash, and checks each Sigstore Rekor inclusion proof against a public key embedded in the binary.

Use verifier v0.14.5 or later. v0.12.0 also accepts a bundle whose JSON carries a value twice under keys that differ only in letter case, which other readers such as jq, Python and browsers read differently; since v0.12.1 the verifier refuses it. Releases through v0.11.0 accept a record whose public-log entries were logged by any key, and report records from run 240 on as failed because they do not recognize leaf v7. Releases v0.1.4 through v0.9.0 also did not check that an anchor's recorded leaf hash matches the public-log entry its inclusion proof covers; since v0.10.0 the verifier binds every anchor to its log entry. From run 239 on, a record's first public-log entry states that a complete-record anchor is required, and a missing or altered one is a failure (exit code 1). The published log-signing keys, their fingerprints and custody are listed in the verifier's README: key 1, the production key, is a file on the API server's volume, not in a hardware module, and has never been rotated. For run 238, which predates that requirement, require the verdict VERIFIED AND ANCHORED, COMPLETE RECORD ANCHORED, because deleting its complete-record anchor yields PARTIAL COVERAGE with exit code 0. The verifier does not re-derive the manifest hash itself, which takes the full stored manifest; GET /runs/{id}/verify performs that check server-side. There is no privileged path that bypasses verification, not even for the Verdifax operator.

Data handling

Verdifax does not store the raw payload bytes you attest. Payloads are canonicalized, hashed, sealed into an envelope, and discarded; the payload-derived values retained on disk are hashes. If you include AI output text, Verdifax sends it to Anthropic's Claude API for the governance review and stores only its hash. Metadata you include, such as actor identifiers, approver names and comments, and any optional inline prompt, output or entity fields, is stored exactly as sent inside the sealed record. Each sealed record also contains hashes of the connecting IP address and user agent: from run 245 on, keyed HMAC-SHA256 hashes under a secret only the server holds (prefix hmac-sha256:), which nobody without that secret can reverse, though Verdifax could by trying every possible address; up to run 244, unsalted SHA-256 hashes, from which anyone can recover an IP address that way. From run 247 on the server refuses a request that supplies its own values for these two hashes; before then a caller's values were sealed in place of the server's. The API does not ask for model weights, IAM tokens, or customer records; do not put them in payloads or metadata.

Retention. The hosted service currently has no deletion jobs. Sealed records, account records and access requests are kept indefinitely unless they are deleted manually, and entries in the public Sigstore Rekor log cannot be removed.

Erasure. POST /admin/erase is admin-only. It destroys a per-field data-encryption key and issues a sealed deletion receipt, but the encryption path is not yet wired into /execute, so the destroyed key encrypts no stored field and the sealed bundle's content is unchanged. For runs anchored in the Rekor log, there is currently no product function that removes or edits the content of a sealed record.

Public demo bundles. Apart from the 44 earlier bundles described below, a sealed bundle is publicly readable, without an API key, only after a Verdifax admin key publishes it with POST /admin/runs/{id}/publish, and an admin key can publish only runs it created itself. Customer API keys cannot make a bundle public, and a route_id that begins with buyer-demo- no longer does. The 44 bundles published under that earlier prefix rule remain readable at the sequential address /runs/{id}/bundle.json. Bundles published since are readable only at /public/runs/{token}/bundle.json, where the token is 32 hexadecimal characters from a cryptographic random source, so they cannot be found by counting run ids. A public bundle may still be served from cache for up to one hour after it is unpublished.

Key custody. Verdifax's server generates each API key's Ed25519 signing key pair and holds the private key in its database. An actor signature on a run therefore shows that Verdifax's server signed with the key assigned to that API key, not that the customer's own device or system signed. API key secrets are stored only as SHA-256 hashes.

Access controls

Multi-factor authentication is enabled on every account that controls production: Fly.io, Cloudflare, GitHub, AWS and Google Workspace. Within the API, the administrative endpoints (/admin/*) require an admin-scoped API key and refuse customer-scoped keys. Raw payload bytes are not stored (see Data handling above), so they cannot be read from production storage.

Vulnerability disclosure

Security researchers may report suspected vulnerabilities to security@verdifax.com. We acknowledge reports within forty-eight (48) hours and aim to triage within five (5) business days. We do not take legal action against researchers who act in good faith and report vulnerabilities to us at security@verdifax.com.

Compliance posture

Verdifax produces cryptographically sealed records of AI decisions, with hashes published in a public transparency log. Organizations subject to the following can use these records as evidence for their own record-keeping, audit, integrity and monitoring controls:

• EU AI Act, Articles 12, 19 and 26(6), record-keeping and log retention, which are duties of the provider and deployer of a high-risk AI system
• HIPAA 45 CFR § 164.312(b), audit controls (customer-assessed)
• SOX § 404, IT general controls within the issuer's internal control over financial reporting (customer-assessed)
• NIST SP 800-53 audit and accountability (AU) controls, as used in FedRAMP authorizations (customer-assessed)

Whether that evidence is sufficient is for the organization and its auditors or regulators. Verdifax does not make any organization compliant. Verdifax currently holds no SOC 2 report, ISO/IEC 27001 certificate or FedRAMP certification, and does not sign Business Associate Agreements, so do not send protected health information to Verdifax-hosted services. See the Compliance section for guidance on producing evidence packs from Verdifax artifacts.

What Verdifax does not protect against

To keep the security promise narrow and auditable, we list the out-of-scope items explicitly:

• Verdifax does not certify that a model's output is correct
• Verdifax does not certify training-data licensing or representativeness
• Verdifax does not authenticate the human user, wire your IAM into the inputs you attest
• Verdifax does not prove that the values inside a payload describe reality (input authenticity is upstream of the pipeline)

The narrow scope is the source of the cryptographic strength. See What the Manifest Hash proves for the full list.

Contact

Security questions can be sent to security@verdifax.com.