Security & trust

Verdifax is a security product. This page describes the controls, the threat model, the assumptions, and the limits of what the platform protects against. Security promises are stated narrowly so they can be audited.

Threat model

Verdifax is built to defend against operators and infrastructure providers (including Verdifax itself) tampering with execution after the fact. The platform is notdesigned to prevent the user's own program from being incorrect, malicious, or biased — those are evaluation problems upstream of the attestation pipeline.

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.

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.

Contact

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