NIST AI Risk Management Framework (AI RMF 1.0) Crosswalk
How Verdifax's cryptographic-attestation infrastructure maps onto the subcategories of the NIST AI Risk Management Framework version 1.0 (NIST AI 100-1), the Generative AI Profile (NIST AI 600-1), and the seven Trustworthy AI characteristics. This is a self-published mapping document. NIST does not certify products; the framework is voluntary and outcome-based. The companion PDF in the Verdifax data room covers the same material.
Verdifax is policy-as-code, not policy-as-document
The NIST AI RMF defines outcomes; Verdifax compiles those outcomes into cryptographic enforcement at the gateway. A NIST subcategory such as MEASURE 2.7 (security and resilience) becomes a runtime check executed on every governed run, not a periodic written attestation produced after the fact. This is the architectural shift the industry calls the move from policy-as-document to policy-as-code, and it is the same category as the Microsoft Agent Governance Toolkit (governing digital agents), the SINT Protocol (governing physical robotics), and the AI-SAFE2 Framework (the GRC operating-system layer). Verdifax sits inside this category as the cryptographic-attestation primitive for AI inference, which any of the above can plug into when they need third-party-verifiable evidence of what was submitted and recorded for a model run.
What this document is, and is not
Is: a mapping showing where Verdifax materially supports each RMF subcategory.
Is not: a NIST validation. NIST does not certify products. Real third-party validation comes from accredited certifications (ISO/IEC 42001 via BSI, Schellman, etc.) or independent security audits (Trail of Bits, NCC Group). Those are separate exercises tracked outside this document. Verdifax does not currently hold an ISO/IEC 42001 certificate.
The framework, briefly
NIST AI RMF 1.0 (NIST AI 100-1, January 2023) is voluntary, rights-preserving, and sector-agnostic. It defines:
- Four core functions: GOVERN, MAP, MEASURE, MANAGE
- Subcategories under each function (e.g. GOVERN 1.1, MEASURE 2.7) naming specific outcomes
- Seven Trustworthy AI characteristics (Section 3): valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed
- A separate Generative AI Profile (NIST AI 600-1, July 2024) overlaying twelve GAI-specific risk categories
The framework is a vocabulary and an architecture, not a certification, and NIST states that its actions "do not constitute a checklist." There is nothing in it for a product to satisfy. Verdifax records can support organizations in achieving outcomes described in AI RMF 1.0 subcategories, most directly MEASURE 2.8, MEASURE 3.1, MANAGE 4.1 and MANAGE 4.3. How those outcomes are achieved is determined by each organization.
GOVERN function
| Subcategory | What Verdifax provides |
|---|---|
| GOVERN 1.1 (legal & regulatory understanding) | The audit PDF of an OK run carries a structured LegalEvidenceArtifact, compiled when the PDF is rendered and not part of the sealed record, that names the laws and frameworks the record is offered as relevant to; whether any legal requirement is met is for the organization, its counsel and its regulators |
| GOVERN 1.2 (trustworthy AI integrated) | Verdifax is the technical integration layer; the seven characteristics map to Verdifax outputs (see Trustworthy AI section below) |
| GOVERN 1.3 and 1.4 (risk tolerance, transparent policies) | The hosted API runs one built-in PEPG policy, baseline-permit, for every caller, which admits every request unless Malicious Code Defense matches a threat signature; customer-specific policy files (VERDIFAX_POLICY_PATH) are planned, not available. Every run records the hash of the policy in effect at decision time |
| GOVERN 1.6 (inventory AI systems) | Sigstore Rekor anchoring creates a continuous public inventory: every successful run, and every deny or halt receipt issued from run 241 on, is a timestamped public log entry; receipts sealed before run 241 carry no log entry |
| GOVERN 2.1, 2.3 (accountability, executive responsibility) | NREP (Non-Repudiation Engine Protocol) binds every signature to an actor identity via the API key; signatures made under different API keys carry different public keys. Verdifax's server generates and holds each API key's Ed25519 private key in its database, so a signature shows that Verdifax's server signed with the key assigned to that API key, not that the customer's own system did |
| GOVERN 4.2 (document risks and impacts) | The audit PDF per run is the documentation; human-readable, references regulatory clauses, lists real-backend vs development-mode adapters |
| GOVERN 4.3 (testing, incidents, information sharing) | Sigstore Rekor is the public information-sharing layer; CCV halt receipts, MACC budget breach receipts, PEPG deny receipts are sealed incident records |
| GOVERN 6.1, 6.2 (third-party risks and contingency) | AIVP-T4 governs the AI output the caller declares; the hash of that vendor output and the governance seal (PIA hash) are bound into the manifest, immune to retroactive vendor changes; record persists even if vendor disappears |
MAP function
| Subcategory | What Verdifax provides |
|---|---|
| MAP 1.1 (intended purposes documented) | AttestedContext is a fixed set of caller-declared fields (actor, model, prompt hash, decision kind, result and note) that flows through the audit bundle; it has no intended-purpose or regulatory-framework field, so intended purpose can be recorded only in those free-text fields, such as decision_note. The optional regulatory_scaffolding block can name frameworks |
| MAP 1.4 (business value/context) | AttestedContext is not extensible: fields outside its fixed set are dropped, not sealed. Business context can be recorded in decision_kind and decision_note, or in the optional authorization_chain risk assessment |
| MAP 1.5 (risk tolerances determined) | CCV per-run and MACC cross-run token budgets set by the deployment; the hosted API applies the same built-in PEPG policy and budgets to every caller, so tolerances are not configured per customer |
| MAP 2.1 (specific tasks defined) | DKEC (Deterministic Kernel Execution Controller) names the computational kernel per run; kernel identifier embedded in the audit bundle |
| MAP 2.3 (TEVV considerations) | The AER (Attestation Execution Record) is the TEVV evidence object; per-stage attestations capture cryptographic state with hash chains |
| MAP 4.1 (third-party data/software risks) | Model provider, name, version, temperature and prompt hash are recorded per run as caller-declared attested_context; AIVP-T4 seals its own adapter id and the hash of the AI output it reviewed |
| MAP 5.1 (impact magnitude documented) | The optional regulatory_scaffolding and causal_graph blocks record caller-declared data classifications and affected entities, so impact documentation can reference sealed runs |
MEASURE function
The function with Verdifax's strongest material fit.
| Subcategory | What Verdifax provides |
|---|---|
| MEASURE 1.1 (measurement approaches) | The manifest hash (SHA-256 over a dot-joined preimage of the sealed manifest fields) is the measurement primitive: a single recomputable value uniquely identifying the run, anchored to a public timestamp via Sigstore Rekor |
| MEASURE 2.1 (TEVV documentation) | Every Verdifax run is itself a TEVV record; AER per-stage attestations document which stages executed with what inputs producing what cryptographic outputs |
| MEASURE 2.3 (performance/assurance criteria) | Audit PDF includes assurance criteria values (latency, token counts, cost) per run |
| MEASURE 2.4 (production monitoring) | Every governed run is monitored end-to-end; production-time monitoring is not an add-on, it is the substrate |
| MEASURE 2.5 (valid and reliable) | Deterministic pipeline: pinned-clock replay reproduces the manifest hash (POST /execute/verify-determinism); production records verify by recomputation from their recorded fields; 200+ test suite; production track record |
| MEASURE 2.6 (safety risks) | CCV per-run budgets, MACC cross-run cumulative budgets, PEPG admission control; budget breaches produce sealed halt receipts |
| MEASURE 2.7 (security and resilience) | CRES key-encryption key held in AWS KMS (us-east-1); Ed25519 actor signatures, with the private keys held in Verdifax's database. The per-record AES-256-GCM encryption path is not yet wired into /execute, so no stored field is currently encrypted under it |
| MEASURE 2.8 (transparency and accountability) | Open-source verdifax-verify CLI on GitHub; transparency independent of Verdifax cooperation |
| MEASURE 2.9 (model explained, output interpreted in context) | AIVP-bound PIA hash inseparably binds model output to model identifier, prompt, and AttestedContext |
| MEASURE 2.10 (privacy risk) | Raw payloads and AI output text are kept as hashes. CRES (Cryptographic Record Erasure System) is an admin-only endpoint that destroys a per-field data-encryption key and issues a sealed deletion receipt, but that key encrypts no stored field, so it does not remove any content from a sealed bundle. CRES does not currently provide erasure for GDPR Article 17 or any HIPAA purpose |
| MEASURE 3.1 (regularly identify and track risks) | Sigstore Rekor log is a continuous append-only public record; emergent risks become trackable via Rekor query |
| MEASURE 4.1 (measurement approaches connected to context) | The verifier is the connection-back-to-context primitive; domain experts can recompute and validate independent of Verdifax |
MANAGE function
| Subcategory | What Verdifax provides |
|---|---|
| MANAGE 1.4 (residual risks disclosed) | Every audit PDF discloses real-backend vs development-mode adapters for that specific run; no silent fallback; residual risks surfaced per run, not hidden in aggregate metrics |
| MANAGE 2.2 (sustain deployed AI value) | Cryptographic record sustains evidentiary value over the asset lifecycle; runs sealed today remain verifiable years later as long as Rekor is operational |
| MANAGE 2.3 (respond to new risks) | Every run records the hash of the PEPG policy in effect, so auditors can group runs by policy; there is no hash chain of policy revisions, and the hosted API currently runs a single built-in policy |
| MANAGE 2.4 (supersede, disengage, deactivate) | CCV and MACC halts are the mechanical disengage; halt receipts are auditable |
| MANAGE 3.1, 3.2 (third-party monitoring) | AIVP-T4 reviews the AI output text the caller supplies (Verdifax never wraps the caller's own model call); cross-run statistics on the reviewed outputs are derivable from the audit bundle archive |
| MANAGE 4.1 (post-deployment monitoring) | Sealed run records can support an organization's post-deployment monitoring, appeal, override and incident-response plans; the plans themselves are the organization's |
| MANAGE 4.3 (incidents communicated) | Halt receipts and PEPG deny receipts are structured, sealed, regulatory-mappable incident records |
NIST AI 600-1 Generative AI Profile
The Generative AI Profile (July 2024) overlays twelve GAI-specific risks onto the same four-function structure. Verdifax has material fit on:
| GAI risk | What Verdifax provides |
|---|---|
| Information Integrity | Core value proposition: manifest hash + Sigstore Rekor anchor make a later change to what the run anchors detectable: every section on records sealed from run 239 on (run 238 also carries the complete-record entry, but deleting it only lowers the verdict to partial coverage); on leaf v5 records sealed before run 238 the anchored values (including the payload hash, the attested decision and the AIVP governance result), with descriptive sections sealed inside the bundle only |
| Confabulation | When a run includes AI output text, AIVP seals a hash of that text with the PIA hash of its governance review, so on leaf v5 and later records, where that hash is one of the anchored values, a confabulated output, once sealed, cannot be edited without the change being detectable; Verdifax does not judge whether an output is true |
| Data Privacy | Raw payloads and AI output text are kept as hashes; caller-supplied metadata is stored as sent. CRES erasure does not yet remove content from sealed bundles (see MEASURE 2.10) |
| Information Security | Ed25519 signatures, SHA-256 sealing, TLS 1.2 or higher in transit; MCD (Malicious Code Defense) scans request payloads for prompt-injection, dangerous-API, supply-chain and filesystem-escape signatures |
| Human-AI Configuration | NREP actor signing + PEPG policy regime + AttestedContext orchestration context; attributable to the API key that submitted the run |
| Intellectual Property | Caller-declared model provider and version recorded per run; AI-Assisted Development Methodology document covers Verdifax's own IP integrity |
| Value Chain and Component Integration | The execution record (AER) plus system provenance: orchestrator version, git commit, and kernel versions recorded per run |
Out of scope: Dangerous, Violent, or Hateful Content and Obscene, Degrading, or Abusive Content. MCD scans request payloads for malicious-code signatures; it does not classify violent, hateful, or obscene content.
Out of scope for Verdifax v1 (handled elsewhere):
- CBRN information: model-vendor or specialized-policy concern
- Environmental impact at training time: on the Verdifax roadmap
- Harmful bias and homogenization: bias detection requires statistical evaluation orthogonal to cryptographic attestation; Verdifax records the inference so downstream bias tools can operate on a sealed record whose anchored content is bound to a public log
Trustworthy AI characteristics
| Characteristic | How Verdifax supports |
|---|---|
| Valid and Reliable | Deterministic pipeline: pinned-clock replay reproduces the manifest hash (POST /execute/verify-determinism); production records verify by recomputation; 200+ test suite |
| Safe | CCV per-run budgets, MACC cross-run budgets, PEPG admission control, MCD content scanning |
| Secure and Resilient | KMS-held CRES key-encryption key, Ed25519 signatures, Sigstore Rekor anchoring |
| Accountable and Transparent | NREP actor signing, public Rekor log, open-source verifier |
| Explainable and Interpretable | AER per-stage attestations document the computational pathway; note Verdifax does not produce model-internal explanations (attention maps, etc.) |
| Privacy-Enhanced | Raw payloads and AI output text are kept as hashes only. CRES erasure does not yet remove content from sealed bundles, and the hosted service keeps records indefinitely |
| Fair, Harmful Bias Managed | Verdifax does not produce fairness evaluations; it records the inference so a later change to what the record anchors no longer matches its public-log entry, giving downstream fairness tooling a stable, verifiable base |
What Verdifax does NOT provide
Honest scope. The following RMF subcategories are not materially addressed by Verdifax. Organizations adopting Verdifax should plan separate controls for these.
- GOVERN 2.2, GOVERN 3: workforce training, diversity, equity, inclusion. Organizational concerns.
- GOVERN 5: external AI actor engagement. Process concern.
- MAP 1.2: interdisciplinary diversity in AI actors. Organizational.
- MAP 3: capability benchmarking. Verdifax records outcomes; it does not benchmark them. Specialized benchmark suites (HELM, MLPerf AILuminate, vendor-internal evals) fill this gap.
- MEASURE 2.2: evaluations involving human subjects. IRB-equivalent organizational concern.
- MEASURE 2.11: fairness and bias evaluation. Orthogonal layer.
- MEASURE 2.12: environmental impact at training time. On the Verdifax roadmap; not in v1.
- MEASURE 3.3: end-user feedback and appeal processes. Process concern. Verdifax records the audit bundle that supports the appeal, but the appeal workflow itself is organizational.
- MANAGE 1.1: go-no-go deployment decisions. Verdifax records the technical state; the deployment decision is a human and organizational judgment.
These are not weaknesses. They are the boundary between cryptographic-attestation infrastructure and broader AI governance practice. The NIST AI RMF is intentionally a multi-layer framework, and Verdifax is intentionally a substrate within it, not a replacement for it.
Verifying the claims
Every technical claim above is independently verifiable.
- The verifier is open source: github.com/Verdifax/verdifax-verify.
- The Sigstore Rekor log is public; manifest hashes are looked up directly.
- The orchestrator runs at api.verdifax.com/health. A read-only API credential can be issued under NDA for hands-on diligence.
- A USPTO Track One patent application has been filed. The application number and filing receipt are available under NDA.
If any claim does not survive verification, please email robert@verdifax.com. Verdifax's value proposition depends on every claim being recomputable from primary sources.
Related work, the policy-as-code peer ecosystem
Verdifax sits inside a recognizable emerging category. Cited as context, not competitors, because each addresses a different layer of the same problem.
| Project | Layer | Verdifax relationship |
|---|---|---|
| Microsoft Agent Governance Toolkit | Digital AI agents (policy engines, circuit breakers, OpenTelemetry) | Verdifax is the cryptographic-attestation primitive AGT's evidence collection can call into for MEASURE-function output whose anchored content is bound to a public log. 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. |
| SINT Protocol | Physical robotics (Ed25519 capability tokens, ROS 2, Policy Gateway, Evidence Ledger) | Where AGT targets digital agents, SINT targets robots and actuators. Verdifax sits at a different stack layer: cryptographic substrate for AI inference itself |
| AI-SAFE2 Framework | GRC operating system (agentic AI, non-human identities, swarm governance) | Maps to ISO 42001, NIST AI RMF, SOC 2 + 10 other frameworks. Verdifax-emitted artifacts can serve as evidence inputs to AI-SAFE2's Ledger pillar |
Verdifax's category position: cryptographic-attestation infrastructure for AI inference, designed to plug underneath any of the above when those systems need third-party-verifiable evidence of what was submitted and recorded for each inference.
References
- NIST AI 100-1, AI Risk Management Framework v1.0
- NIST AI 600-1, Generative AI Profile
- Sigstore Rekor transparency log
- RFC 8785, JSON Canonicalization Scheme
- Federal Reserve SR 26-2, which replaced SR 11-7 on 17 April 2026 and excludes generative and agentic AI models from its scope
- Verdifax executive summary on verdifax.com with downloadable 12-page PDF