VerdifaX

FedRAMP

FedRAMP is the U.S. federal program for authorizing cloud services used by federal agencies. It assesses a cloud service offering against baselines built from the controls in NIST SP 800-53. This page describes which controls Verdifax records can support and which they do not.

Verdifax is not FedRAMP certified, has no FedRAMP authorization or Marketplace listing, and the hosted Verdifax service is not a FedRAMP-authorized cloud service. Verdifax also does not currently hold a SOC 2 report or an ISO/IEC 27001 certificate. The controls below belong to the cloud service provider or agency seeking authorization, and Verdifax records can serve as evidence for that party's own implementation.

Maturity note. Several pipeline values, including the zero-knowledge transcript and its state-prover binding, are still scaffold values rather than real cryptographic proofs. Hardware attestation depends on the deployment: runs on the hosted service carry the hardware-attestation scaffold flag, because the hosted service runs without an attestation agent; deployments with an AMD SEV-SNP attestation agent bind a verified SEV-SNP quote into each run's execution record (demonstrated 2026-10-03). Every audit bundle flags scaffold values with a scaffold field; the open-source verifier surfaces them in its report. See /concepts/scaffold-gaps/ for the full disclosure list and what activates each. Control claims on this page that depend on scaffold layers are flagged inline below.

Quick orientation

FedRAMP comes in three baselines:

  • Low, limited adverse impact (e.g., open public information)
  • Moderate, serious adverse impact (most AI systems serving federal customers land here)
  • High, severe / catastrophic adverse impact (intelligence, defense)

Each baseline is a defined subset of the ~1,000 NIST 800-53 controls. Verdifax records are relevant mainly to the audit and accountability (AU) family, the controls that govern logging, integrity of audit records, and event review.

AU controls Verdifax records can support

ControlWhat it requiresVerdifax contribution
AU-2 Event LoggingIdentify which events to log; document the rationaleEvery AI inference is a logged event with full sealed manifest
AU-3 Content of Audit RecordsRecords must contain sufficient information for forensic reviewThe sealed manifest (every field the manifest hash covers) plus payload hash, route, program id, timestamp
AU-9 Protection of Audit InformationAudit records must be protected from unauthorized modificationA change to anything the run anchors no longer matches its public-log entry: every section on records sealed from run 239 on, the 33 pre-anchor values on leaf v5 records sealed before run 238. Run 238 also carries the complete-record entry, but deleting it only lowers the verdict to partial coverage. On records sealed before run 238, descriptive sections (request substance, authorization chain, real-world effects, system provenance) are sealed only by hashes inside the bundle. Since verifier 0.12.0, a public-log 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. From run 240 on, each record seals a 600-second anchoring window, so a later re-log, even by Verdifax, fails or must carry a new sealed date; earlier records show their authenticated anchoring time but cannot fail on it.
AU-10 Non-RepudiationIdentity of actors performing logged actions cannot be deniedAPI key is bound to runs; revocation is auditable. Verdifax's server generates each API key's Ed25519 signing key pair and holds the private key in its database, so a run's actor signature shows that Verdifax's server signed with the key assigned to that API key, not that the customer's own system did
AU-11 Audit Record RetentionRecords retained per organization-defined periodSQLite store ships with the orchestrator; on a self-run deployment, retention is operator policy. The hosted Verdifax service currently has no deletion jobs and keeps records indefinitely
AU-12 Audit GenerationSystem generates audit records for defined eventsEvery /execute call writes a record

Verdifax records are also relevant to:

  • SI-7 Software, Firmware, and Information Integrity, via hardware measurement: on deployments with a SEV-SNP agent configured, each run binds a verified AMD SEV-SNP report, including the guest launch measurement, inside its execution record. The hosted service runs without an agent today and discloses a per-run scaffold; TPM2 remains roadmap. See scaffold-gaps.
  • SC-13 Cryptographic Protection, sealing uses SHA-256, a NIST-approved hash function. The CRES key-encryption key is held in AWS KMS, but the CRES encryption path is not yet wired into /execute, so no stored field is currently encrypted under a CRES key. Customer Ed25519 signing keys and the public-log signing key are not held in KMS.
  • CM-3 Configuration Change Control, manifest hashes provide change-evidence (see SOX § 404 for the same logic in commercial framing)

What Verdifax does not address

Most of the FedRAMP control catalog. Verdifax is one component of a much larger authorization package. It does not provide:

  • Personnel security (PS family)
  • Physical and environmental protection (PE)
  • Most access control (AC)
  • Identification and authentication (IA, beyond the API-key plumbing)
  • Incident response (IR), other than producing forensic-quality records
  • Risk assessment (RA), that's your governance team

A reasonable analogy: Verdifax is to AU what database encryption is to SC, useful evidence for the relevant controls, sufficient for none of them, and unrelated to most of the catalog.

Where Verdifax helps most

Federal AI deployments where the auditor needs to confirm specific decisions later, benefits eligibility determinations, security-clearance adjudication assistance, threat triage, denial-of-claim recommendations. Anything where "show me how this AI made that determination" is a question the system has to answer.

Continue