SAIHM × NIST AI RMF 1.0 crosswalk
NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023) organises AI risk management into four functions: GOVERN, MAP, MEASURE, MANAGE. The Generative AI Profile (NIST AI 600-1, July 2024) adds GenAI-specific actions across twelve risk categories. The tables below map SAIHM — the memory layer for AI agents — to the AI RMF outcomes that an enterprise risk owner is most likely to be asked about.
Outcome statements below are quoted verbatim from NIST AI 100-1 Core (via airc.nist.gov). Sources: NIST AI 100-1 (PDF); NIST AI 600-1 (PDF).
GOVERN — policies, accountability, oversight
| Sub-category | NIST outcome (verbatim) | SAIHM mechanism (evidence) |
|---|---|---|
| GOVERN 1.1 | “Legal and regulatory requirements involving AI are understood, managed, and documented.” | Six public crosswalks (this set) map SAIHM to GDPR Art.17, EU AI Act 2024/1689, ISO/IEC 27001:2022, ISO/IEC 42001:2023, NIST AI RMF, MCP. Each crosswalk is a paste-ready RFP artefact. |
| GOVERN 1.2 | “The characteristics of trustworthy AI are integrated into organizational policies, processes, and procedures.” | Eight MCP tools at the protocol invariant cap; cell shape, identity, encryption envelope, audit, sharing, erasure are protocol-level commitments (not implementation-policy commitments). |
| GOVERN 1.3 | “Processes, procedures, and practices are in place to determine the needed level of risk management activities based on the organization’s risk tolerance.” | SAIHM offers a uniform high-assurance erasure mechanism (cryptographic erase per NIST SP 800-88 Rev. 2) regardless of organizational risk tier. Operators tune the policy layer (sharing scope, retention) without altering the underlying assurance level. |
| GOVERN 1.4 | “The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities.” | Every operation (remember, recall, forget, share, revoke_share) emits a signed receipt anchored on the COTI V2 public chain. The audit trail is independently verifiable by any auditor. |
| GOVERN 1.5 | “Ongoing monitoring and periodic review of the risk management process and its outcomes are planned and organizational roles and responsibilities clearly defined, including determining the frequency of periodic review.” | saihm_status surfaces continuous holder-side metrics (PRS, BFSI with bfsi_R/bfsi_M/bfsi_window_start_ts inputs per protocol Internet-Draft §3.4); operators publish review cadence as part of their deployment documentation. |
| GOVERN 1.6 | “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” | saihm_status returns holder-side inventory (cells by tier, sharing contracts, governance state, PRS/BFSI scores). |
| GOVERN 1.7 | “Processes and procedures are in place for decommissioning and phasing out AI systems safely and in a manner that does not increase risks or decrease the organization’s trustworthiness.” | saihm_forget is the decommissioning primitive at the memory layer: it destroys the per-cell DEK, publishes a tombstone, blacklists the content identifier (CID), and anchors a signed audit receipt. Decommissioning a single memory does not affect any other memory or shared substrate. |
| GOVERN 2.1 | “Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization.” | Wallet-bound holder identity allocates the read-and-erase authority unambiguously. Operators see ciphertext only. Sharing-contract grants are explicit, signed, and revocable. |
| GOVERN 4.1 | “Organizational policies and practices are in place to foster a critical thinking and safety-first mindset in the design, development, deployment, and uses of AI systems to minimize potential negative impacts.” | Safety-by-design protocol features: cryptographic erasure default, revocable sharing, public governance, post-quantum signatures, KEK rotation. |
| GOVERN 4.2 | “Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate, and use, and they communicate about the impacts more broadly.” | SAIHM’s threat model and risk register are public artefacts: the protocol Internet-Draft documents the operator-honest-but-curious model and security considerations; this crosswalk set documents control-mapping; the Apache-2.0 reference implementation in @saihm/mcp-server is openly inspectable. |
| GOVERN 5.1 | “Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks.” | External feedback channels: the on-protocol governance pair (saihm_governance_propose + saihm_governance_vote) for soul-bound-token holders; the public W3C Community Group, AAIF, and IETF Independent Submission Stream tracks for the standards process; Apache-2.0 PRs and issues for the reference implementation. |
| GOVERN 6.1 | “Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third-party’s intellectual property or other rights.” | SAIHM’s operator-honest-but-curious threat model frames every operator as a third party that the holder does not trust with plaintext. Encryption-before-egress; wallet-bound DEK derivation; no plaintext at operator side; the holder can saihm_forget regardless of operator cooperation. |
| GOVERN 6.2 | “Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk.” | The on-chain audit anchor on COTI V2 mainnet (chain ID 2632500) survives operator failure, vendor change, or chain-operator turnover. A holder retains the ability to attest past operations and to migrate to a different operator without losing receipt history. |
MAP — context, requirements, risks
| Sub-category | NIST outcome (verbatim) | SAIHM mechanism (evidence) |
|---|---|---|
| MAP 1.1 | “Intended purposes, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented.” | SAIHM is a memory layer for AI agents (not an AI agent itself; not a vector DB). Reference deployment chain disclosed: COTI V2 mainnet (chain ID 2632500). Context-specific laws covered by the six crosswalks. |
| MAP 1.6 | “System requirements (e.g., “the system shall respect the privacy of its users”) are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks.” | Ten consensus requirements derived from GDPR Art.17, EU AI Act, ISO/IEC 27001:2022, MCP, and operational reality. Each requirement maps to a SAIHM mechanism. See the consensus-requirements article. |
| MAP 2.1 | “The specific tasks and methods used to implement the tasks that the AI system will support are defined (e.g., classifiers, generative models, recommenders).” | SAIHM is explicitly NOT a classifier, generative model, or recommender. The task and method are memory persistence: sealed, signed, recallable, erasable cells held under wallet-bound identity. The protocol layers below an AI system that performs classification/generation/recommendation; mapping the host AI’s task per MAP 2.1 is the operator’s responsibility. |
| MAP 2.2 | “Information about the AI system’s knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making decisions and taking subsequent actions.” | The protocol Internet-Draft, this crosswalk set, and the threat-model documentation describe SAIHM’s knowledge limits (it is a memory layer; it does not interpret, summarise, or reason about cell content). Every operation emits a signed receipt anchored on chain so human operators can audit the memory-substrate behaviour separately from any host-AI behaviour. |
| MAP 2.3 | “Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection.” | Cryptographic claims are reproducible: ML-DSA-65 signatures (FIPS-204) verifiable from public keys; HKDF chain documented; receipts reproducible from the public chain. |
| MAP 4.1 | “Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third party’s intellectual property or other rights.” | Operator-honest-but-curious threat model documented in the protocol Internet-Draft draft-saihm-memory-protocol §6.4. Third-party-storage exposure mitigated by encryption-before-egress. Third-party intellectual-property risk: the reference implementation is Apache-2.0; dependency licenses are tracked in the npm package manifest and the GitHub repository; SAIHM does not embed third-party model weights or copyrighted training data at the protocol layer. |
| MAP 5.2 | “Practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented.” | Public governance: saihm_governance_propose + saihm_governance_vote. Apache-2.0 reference implementation accepts PRs. Public W3C Community Group + AAIF + IETF tracks under way. |
MEASURE — analyse, assess, benchmark
| Sub-category | NIST outcome (verbatim) | SAIHM mechanism (evidence) |
|---|---|---|
| MEASURE 1.1 | “Approaches and metrics for measurement of AI risks enumerated during the map function are selected for implementation starting with the most significant AI risks. The risks or trustworthiness characteristics that will not – or cannot – be measured are properly documented.” | PRS (Process Reliability Score) and BFSI (Byzantine Fault Score Index) surfaced through saihm_status. Storage-tier shard counts, sharing-contract counts, and governance state are also reported. |
| MEASURE 1.2 | “Appropriateness of AI metrics and effectiveness of existing controls are regularly assessed and updated, including reports of errors and potential impacts on affected communities.” | BFSI definition and inputs are surfaced verbatim in saihm_status: bfsi = 1 − (M / R) with bfsi_R, bfsi_M, and bfsi_window_start_ts all returned so any holder or auditor can reproduce the metric (per protocol Internet-Draft §3.4). Metric appropriateness can be assessed externally without operator cooperation. |
| MEASURE 1.3 | “Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organizational risk tolerance.” | Every audit receipt is anchored on the COTI V2 public chain (chain ID 2632500). Any independent assessor — internal expert, external auditor, regulator, or affected-community advocate — can verify operations against the chain without contacting either the holder or the operator. |
| MEASURE 2.3 | “AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented.” | saihm_status reports performance criteria (PRS, BFSI) computed over a 30-day rolling window against deployment-similar conditions; the inputs (R, M, window start) are exposed for external verification. Reference deployment is COTI V2 mainnet (chain ID 2632500). |
| MEASURE 2.4 | “The functionality and behavior of the AI system and its components – as identified in the map function – are monitored when in production.” | Every SAIHM operation emits a signed audit receipt anchored on chain. saihm_status reports aggregate functional behaviour: tier distribution, sharing-contract activity, governance activity. |
| MEASURE 2.7 | “AI system security and resilience – as identified in the map function – are evaluated and documented.” | ML-DSA-65 post-quantum signatures (FIPS-204); HKDF-derived per-cell DEK; KEK rotation versioned; tombstone + CID blacklist on erasure. Cipher implementation in @saihm/mcp-server. |
| MEASURE 2.8 | “Risks associated with transparency and accountability – as identified in the map function – are examined and documented.” | Public-chain audit anchors make every memory operation publicly accountable. Holder-driven cryptographic erasure (saihm_forget) makes the erasure event itself transparent: a signed tombstone receipt is emitted whose absence would itself be evidence of a non-conformant operator. |
| MEASURE 3.1 | “Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts.” | PRS / BFSI are continuous-monitoring metrics; their definitions (and the input fields needed to reproduce them) are part of the public protocol. A BFSI value below the operator’s published integrity threshold (the reference deployment publishes 0.99) signals operator integrity degradation and is grounds to migrate to another operator. |
| MEASURE 3.3 | “Feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metrics.” | End users (holders) have a built-in feedback channel: the on-protocol governance pair (saihm_governance_propose + saihm_governance_vote). Affected communities and impacted parties can also engage through the open W3C Community Group, the IETF Independent Submission Stream, and Apache-2.0 issues on the reference implementation. |
| MEASURE 4.1 | “Measurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain experts and other end users. Approaches are documented.” | The measurement approach (PRS, BFSI, with public inputs) was developed through the open IETF Independent Submission Stream process, exposing the approach to domain-expert review before adoption. The protocol Internet-Draft is the documented form. |
MANAGE — act, treat, monitor
| Sub-category | NIST outcome (verbatim) | SAIHM mechanism (evidence) |
|---|---|---|
| MANAGE 1.2 | “Treatment of documented AI risks is prioritized based on impact, likelihood, and available resources or methods.” | Cryptographic erasure (saihm_forget) is the highest-impact risk treatment available: DEK destruction + tombstone + CID blacklist + on-chain receipt. The operator cannot revive the data. |
| MANAGE 1.3 | “Responses to the AI risks deemed high priority, as identified by the map function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting.” | SAIHM provides one canonical response option for confidentiality-disclosure risk at the memory layer: mitigation by cryptographic erasure. saihm_forget mitigates the residual-data-disclosure risk by destroying the DEK so the residual ciphertext is computationally infeasible to decrypt. Holders may also accept (no saihm_forget) or transfer (saihm_share to a new holder) at the memory-layer policy surface. |
| MANAGE 2.2 | “Mechanisms are in place and applied to sustain the value of deployed AI systems.” | Wallet-bound sovereignty: the holder’s key never leaves the machine. Operator changes, vendor changes, and chain operator changes do not erase the holder’s access to their cells. |
| MANAGE 3.1 | “AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.” | Operator-honest-but-curious threat model. Cell ciphertext is opaque to the operator; per-receipt audit is publicly verifiable; sharing contracts are revocable. |
| MANAGE 4.1 | “Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.” | Decommissioning: saihm_forget with cryptographic finality. Change management: KEK rotation versioned. User input: public governance pair (saihm_governance_propose + saihm_governance_vote). Recovery: receipts on chain are durable across operator change. |
| MANAGE 4.3 | “Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented.” | Every operation result — success or failure — is a signed receipt anchored on chain. Incident state is public: affected holders, third-party auditors, and regulatory bodies can each verify the same record. A failure to anchor a receipt is itself a publicly detectable incident. |
GenAI Profile (NIST AI 600-1, July 2024) — 12 risk categories
The Generative AI Profile identifies twelve risk categories unique to or amplified by generative AI. SAIHM directly addresses the memory-relevant ones:
- Confabulation. Cells are signed at write; signature verification at read prevents silent tampering by an operator.
- Data Privacy. Encryption-before-egress; wallet-bound DEK derivation; no plaintext at operator side.
- Information Security. Post-quantum identity binding (ML-DSA-65, FIPS-204); KEK rotation; tombstone + CID blacklist on erasure.
- Information Integrity. Receipts anchored on a public chain; cell history reproducible from chain.
- Value Chain and Component Integration. MCP-native: SAIHM cells are reachable from any MCP-capable agent (Claude, Cursor, Continue, Goose, custom). The protocol is the integration point.
- Intellectual Property. Apache-2.0 license on the reference implementation; LF IP-transfer ready.
The other six risk categories (CBRN; Dangerous/Violent/Hateful Content; Environmental Impacts; Harmful Bias or Homogenization; Human-AI Configuration; Obscene/Degrading/Abusive Content) are out of scope for a memory protocol — they are addressed at the agent and model layers.
How to cite SAIHM in an AI RMF assessment
- Cite this crosswalk URL:
https://saihm.coti.global/standards/nist-ai-rmf-crosswalk - Reference the reference implementation:
npx @saihm/mcp-server(Apache 2.0). - Reference the chain audit anchor: COTI V2 mainnet, chain ID 2632500, explorer mainnet.cotiscan.io.
- For NIST AI Resource Center submission: email
AIframework@nist.govwith this URL as a use-case reference.