Security & trust

Last updated: April 30, 2026

Threat model

Verdifax is built to defend against operators and infrastructure providers (including Verdifax itself) tampering with execution after the fact. 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) uses a formally-verified prover whose status field must equal the literal string VERIFIED_SOUND_COMPLETE_ZK for the run to seal. Anything else aborts the manifest. We do not invent cryptography; we compose audited primitives.

Hardware root of trust

Stage 5 of the pipeline incorporates a hardware attestation measurement. Production runs are bound to either a TPM 2.0 quote or an AMD SEV-SNP attestation report. The Decentralized Root of Trust (DEROT) requires a 3-of-5 quorum so that no single hardware vendor or operator can forge a manifest.

Determinism guarantees

Identical inputs produce identical manifest hashes byte-for-byte across languages and architectures. This is a primitive of the system, not an aspiration — it is enforced by the §0 specification and tested by the cross-architecture determinism audit.

Independent verification

Every Verdifax manifest can be re-derived by a verifier that does not trust Verdifax. The DCAE Verification Service and the VFA Independent Verifier run outside the Verdifax runtime, recompute every hash, and return either independent_verified = true or a specific failure reason. There is no privileged path that bypasses verification — not even for the Verdifax operator.

Data handling

Verdifax never stores the raw input bytes you attest. Payloads are canonicalized, hashed, sealed into an envelope, and discarded. The only payload-derived value retained on disk is the envelope hash. Model weights, IAM tokens, and customer records do not enter the Verdifax substrate and cannot be exfiltrated through it.

Access controls

Production access is gated by hardware-backed multi-factor authentication, role-based authorization, just-in-time credentials, and per-action audit logging. Engineers cannot access customer payloads in production. Administrative actions are themselves attested and emit their own VFA artifacts.

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 acting in good faith and within the scope of our responsible-disclosure policy.

Compliance posture

Verdifax is designed to satisfy the evidence-of-execution requirements of:

• EU AI Act, Article 13 — logging and traceability
• HIPAA 45 CFR § 164.312(b) — audit controls
• SOX § 404 — IT change controls
• FedRAMP — attestation and continuous monitoring

Compliance certifications are issued at the operator level, against specific deployments. See the Compliance section for guidance on producing audit-ready 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. Please use PGP for sensitive disclosures; the public key is on the security page at verdifax.com/security.