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

Verdifax uses industry-standard, publicly documented cryptographic primitives: SHA-256 collision-resistant hashing, RFC 8785 deterministic canonical JSON serialization, ECDSA P-384 signature verification (for hardware attestation reports), and the Sigstore Rekor public transparency log. We do not invent cryptography; we compose audited primitives. Nothing is gated behind an NDA: the verifier is open source, the formal proofs are public at github.com/Verdifax/lean-verdifax, and every audit bundle names the exact algorithms used. Zero-knowledge proof generation is on the public roadmap and is disclosed as a scaffold in every audit bundle until it ships.

Hardware attestation

Runs sealed with the confidential-compute attestation service carry a genuine AMD SEV-SNP attestation report bound to that specific run: the report's guest-controlled field is derived from the run's envelope and result hashes, and the orchestrator verifies the report's certificate chain against AMD's Milan root of trust (pinned by fingerprint) plus its signature before sealing. The report and certificate chain are embedded in the audit bundle so any third party can re-verify them offline. Runs sealed without the attestation service disclose that honestly with a per-run scaffold flag; the flag 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

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 platform's foundational specification and tested by an automated cross-architecture determinism audit.

Independent verification

Every Verdifax manifest can be re-derived by a verifier that does not trust Verdifax. Independent verifier services run outside the Verdifax runtime, recompute every hash, and return either a verified status or a specific failure reason. There is no privileged path that bypasses verification, not even for the Verdifax operator.

Data handling

By default, Verdifax does not store the raw input bytes you attest. Payloads are processed in a stateless way and discarded; only the cryptographic hash of the canonical request is retained for audit purposes. (Callers may explicitly opt in to inline payload retention per request; absent that opt-in, raw bytes are not kept.) 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 multi-factor authentication and role-based authorization. Customer API keys are stored only as salted hashes; administrative surfaces carry an additional identity-verified access gate on top of API-key authentication; every security-relevant action is logged. Deployments are provenance-stamped with the exact source commit they were built from, which every audit bundle records.

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 12, record-keeping (automatic logs over the lifetime of high-risk AI systems)
• EU AI Act, Article 13, transparency and provision of information to deployers
• NIST AI RMF 1.0, Govern and Measure functions (evidence-of-execution records sufficient for Govern.4 and Measure.2)
• ISO/IEC 42001:2023, AI management system, clauses 8 (operational planning) and 9 (performance evaluation)
• HIPAA 45 CFR § 164.312(b), audit controls
• SOX § 404, IT change controls
• SR 11-7, model risk management evidence (sealed inputs, sealed model output, sealed policy gate per decision)
• GDPR Articles 17 and 22, right to erasure (via Cryptographic Record Erasure) and automated-decision record
• FedRAMP / NIST SP 800-53, 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.