SDOS Runtime Governance Framework — NIST CSF 2.0 Alignment¶
Informative Reference Name: SDOS-RuntimeGov-to-CSF-2.0-v1.0
Reference Version: 1.7
Focal Document: NIST Cybersecurity Framework 2.0 (NIST CSWP 29, February 26, 2024)
Authoring Organization: AAM Cyber (aamcyber.com)
Inventor: Pharns Genece
Submission Date: 2026-05-15 (initial), 2026-05-19 (corrected resubmission addressing SoR finding)
Cataloged: 2026-05-21 as NIST OLIR Reference ID 215
Status: Final — public review concluded 2026-06-22 with zero comments
Trifecta Companions: Ref 220 — AI RMF 1.0 · Ref 217 — SP 800-53 Rev 5.2.0
Change Log: View full version history
Key Facts¶
- What: Concept Crosswalk mapping SDOS Runtime Governance Framework controls to NIST Cybersecurity Framework 2.0 (NIST CSWP 29).
- Who: AAM Cyber, authoring organization. Pharns Genece, inventor.
- Scope: 76 of 106 CSF 2.0 subcategories mapped using 24 canonical SDOS reference elements.
- Coverage: GOVERN (16 of 32), IDENTIFY (17 of 21), PROTECT (16 of 22), DETECT (10 of 11), RESPOND (12 of 13), RECOVER (5 of 7).
- Relationship type: Supportive — SDOS provides structural enforcement at the AI agent dispatch layer.
- Status: Cataloged with the NIST OLIR Program 2026-05-21 as Reference ID 215; Final Informative Reference as of 2026-06-22 (public review concluded with zero comments). Trifecta companion to Reference ID 220 (AI RMF 1.0) and Reference ID 217 (SP 800-53 Rev 5.2.0).
- Strength of Relationship: 7 of 76 subcategories explicitly characterized as
intersects with; remaining mappings supportive without explicit characterization. - Patent status: Aspects of SDOS are the subject of U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620.
Purpose¶
The Security Decision Operating System (SDOS) is a runtime governance framework that enforces structured policy controls over AI agent operations at the point of dispatch. It provides a structural layer of enforcement independent of the underlying model's internal alignment or safety tuning, binding AI model selection, tool invocation, outbound execution, and audit logging to verifiable governance rules.
This page documents the Concept Crosswalk between SDOS controls and NIST Cybersecurity Framework 2.0. The full SDOS control catalog with detailed per-control descriptions, evidence types, and patent references is available at /sdos/reference/v1/.
This document is intended for use by CISOs, GRC auditors, AI risk assessors, procurement reviewers, and federal agencies evaluating AI governance frameworks for alignment with NIST CSF 2.0.
How to Use This Document¶
Control ID Schema¶
Control identifiers follow the pattern SDOS-[DOMAIN]-[NN], where:
SDOSidentifies the framework[DOMAIN]is the two-letter governance function code (see table below)[NN]is a zero-padded sequential number within that domain
| Code | Governance Function |
|---|---|
| GV | Governance |
| RM | Risk Management |
| EN | Enforcement |
| IA | Identity and Attestation |
| AU | Audit |
| IN | Integrity |
| DE | Deliberation |
| AD | Admission |
| RS | Risk Measurement |
IP Notice¶
Aspects of the SDOS Runtime Governance Framework are the subject of pending U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620. The scope of pending claims is defined by the as-filed specifications and is not coextensive with the descriptions in this crosswalk or the linked control catalog. Per-control patent notices are omitted to avoid repetition.
Evidence Types¶
Each SDOS control is supported by one or more evidence types that demonstrate the control is implemented and operational:
- Audit Log Record — a structured log entry generated at runtime capturing the relevant governance event
- Configuration File — a versioned, human-readable policy configuration that governs control behavior
- Test Suite Result — a passing automated test that verifies the control's behavior under defined conditions
- Module Manifest — a cryptographically signed declaration of module identity and authorized capabilities
- System Behavior — an observable runtime response to a defined stimulus (e.g., halt on integrity failure, block on admission failure)
Specific field schemas, log formats, and configuration structures for each control are documented in the SDOS operational documentation available to licensed implementers.
Glossary of Key Terms¶
| Term | Definition |
|---|---|
| Point of Dispatch | The moment a task is assigned to an agent and before any tool execution occurs; the primary governance enforcement boundary |
| Governed Egress | The class of outbound operations subject to pre-execution policy enforcement |
| Model-Alignment-Independent | Enforcement that operates through structural separation from model inference, without reliance on the model's internal safety tuning or alignment claims |
| Admission | The explicit process by which an agent is granted access to governed operations; a precondition for runtime governance evaluation |
| Governance Baseline | The authorized configuration state against which SDOS verifies integrity at startup and on demand |
| Module Manifest | A cryptographically signed artifact that declares a module's identity and authorized capabilities |
| Deliberation Panel | A structured multi-agent evaluation process in which each participating agent operates within a policy-defined role |
| Structural Independence | The property by which policy evaluation occurs in a runtime layer that receives model outputs as data inputs but does not execute model-generated instructions as governance decisions |
| Governance Decision | A policy evaluation performed by SDOS that produces a permit, modify, or block outcome for a given agent operation; recorded in the audit trail and distinct from model-generated recommendations or actions |
Applicability¶
SDOS is applicable to autonomous and semi-autonomous agentic AI workflows in which AI agents invoke tools, make decisions, or produce outputs on behalf of an operator. It is not designed for static LLM-chat interfaces in which no tool invocation or autonomous action occurs.
For NIST CSF 2.0 alignment, SDOS provides runtime enforcement at the dispatch layer that supports CSF 2.0 subcategories in the GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER functions where AI-agent operations are in scope. Organizational, physical, and personnel subcategories outside the dispatch-time enforcement boundary are intentionally not mapped.
SDOS Control Catalog Summary¶
The full control catalog with per-control descriptions, evidence types, and related control dependencies is published at /sdos/reference/v1/. The 24 SDOS controls referenced in this CSF 2.0 crosswalk are:
| Control ID | Title |
|---|---|
| SDOS-GV-01 | Configuration-Governed Module Activation |
| SDOS-GV-02 | Governance-Tiered Model Selection |
| SDOS-GV-03 | Default-Deny Pre-Admission Policy |
| SDOS-GV-04 | Cross-Module Governance Continuity |
| SDOS-GV-05 | Model-Alignment-Independent Policy Enforcement |
| SDOS-RM-01 | Dispatch-Time Risk Classification |
| SDOS-RM-02 | Complexity-Tiered Resource Allocation |
| SDOS-RM-03 | Risk-Floor Model Binding |
| SDOS-AD-01 | Default-Deny Agent Pre-Admission |
| SDOS-IA-01 | Attested Agent Identity |
| SDOS-IA-02 | Attested Module Identity |
| SDOS-IN-01 | Governance Baseline Integrity Verification |
| SDOS-IN-02 | Baseline Drift Detection and System Halt |
| SDOS-IN-03 | Module Manifest Integrity |
| SDOS-EN-01 | Pre-Egress Policy Enforcement |
| SDOS-EN-02 | Subordinate-Side Enforcement Gate |
| SDOS-EN-03 | Fail-Closed Degradation |
| SDOS-EN-04 | Governed Egress with Tamper-Evident Audit |
| SDOS-AU-01 | Per-Invocation Audit Record |
| SDOS-AU-02 | Append-Only Audit Log Integrity |
| SDOS-AU-03 | Dual Audit Trail |
| SDOS-DE-01 | Governed Multi-Agent Deliberation |
| SDOS-DE-02 | Convergence-Based Decision Record |
| SDOS-RS-01 | Governed Return on Safety Investment (ROSI) Evaluation |
Concept Crosswalk Overview¶
This Concept Crosswalk maps the SDOS Runtime Governance Framework — Control Catalog and Reference Document (v1.7) to the NIST Cybersecurity Framework 2.0. SDOS binds AI model selection, tool invocation, outbound execution, and audit logging to governance rules through the 24 controls listed above.
This Informative Reference identifies, for each mapped CSF 2.0 subcategory, the SDOS control(s) that support the subcategory's intent at the dispatch and enforcement layer.
Coverage Summary
| CSF 2.0 Function | Subcategories Mapped | Out of |
|---|---|---|
| GOVERN (GV) | 16 | 32 |
| IDENTIFY (ID) | 17 | 21 |
| PROTECT (PR) | 16 | 22 |
| DETECT (DE) | 10 | 11 |
| RESPOND (RS) | 12 | 13 |
| RECOVER (RC) | 5 | 7 |
| Total | 76 | 106 |
Relationship Type: Supportive. The SDOS framework operates at the dispatch and enforcement layer below model alignment, providing structural controls that support CSF 2.0 subcategory intent without claiming equivalence. Subcategories outside the runtime AI governance scope (e.g., physical security, personnel training, public communications, supplier contract lifecycle, hardware lifecycle) are intentionally not mapped.
Strength of Relationship. 7 subcategories are marked intersects with where the relationship is unambiguous; the remaining mappings leave the optional Strength column blank, consistent with the SDOS-to-AI-RMF-1.0 reference (v1.8) accepted into the NIST OLIR Catalog as Reference ID 220.
How to Read This Page¶
Each mapping table below shows, for one CSF 2.0 Function:
- CSF 2.0 Subcategory — the focal element identifier (e.g.,
GV.OC-03) - Description — the CSF 2.0 subcategory text
- SDOS Controls — the SDOS reference element(s) that support the subcategory at the dispatch and enforcement layer
- Strength —
intersects withwhere the mapping has been explicitly characterized; blank where the mapping is supportive without explicit characterization
The complete control catalog with all 24 SDOS controls and their detailed descriptions is available at /sdos/reference/v1/.
The complete Concept Crosswalk file (mapping rationale per row) is the artifact submitted to the NIST OLIR Program.
GOVERN (GV) — 16 Subcategories Mapped¶
The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.
| CSF 2.0 Subcategory | Description | SDOS Controls | Strength |
|---|---|---|---|
| GV.OC-03 | Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed | SDOS-GV-01, SDOS-GV-03, SDOS-GV-05 | intersects with |
| GV.OV-01 | Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction | SDOS-AU-01, SDOS-RS-01 | |
| GV.OV-02 | The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks | SDOS-AU-01, SDOS-RS-01 | |
| GV.OV-03 | Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed | SDOS-AU-01, SDOS-AU-02, SDOS-RS-01 | |
| GV.PO-01 | Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced | SDOS-GV-01, SDOS-GV-03, SDOS-GV-04, SDOS-GV-05 | |
| GV.PO-02 | Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission | SDOS-AU-01, SDOS-GV-01, SDOS-GV-04, SDOS-GV-05 | |
| GV.RM-02 | Risk appetite and risk tolerance statements are established, communicated, and maintained | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03 | |
| GV.RM-04 | Strategic direction that describes appropriate risk response options is established and communicated | SDOS-GV-02, SDOS-RM-01 | |
| GV.RM-06 | A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated | SDOS-AU-01, SDOS-RM-01, SDOS-RM-02 | |
| GV.RM-07 | Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions | SDOS-GV-02, SDOS-RM-01 | |
| GV.RR-02 | Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced | SDOS-AD-01, SDOS-EN-02, SDOS-GV-01 | |
| GV.SC-04 | Suppliers are known and prioritized by criticality | SDOS-IA-02, SDOS-IN-03 | |
| GV.SC-05 | Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties | SDOS-IA-02, SDOS-IN-03 | |
| GV.SC-07 | The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship | SDOS-AU-02, SDOS-IA-02, SDOS-IN-03 | |
| GV.SC-08 | Relevant suppliers and other third parties are included in incident planning, response, and recovery activities | SDOS-AU-02, SDOS-IA-02, SDOS-IN-03 | |
| GV.SC-09 | Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle | SDOS-AU-02, SDOS-IA-02, SDOS-IN-03 |
IDENTIFY (ID) — 17 Subcategories Mapped¶
The organization's current cybersecurity risks are understood.
| CSF 2.0 Subcategory | Description | SDOS Controls | Strength |
|---|---|---|---|
| ID.AM-02 | Inventories of software, services, and systems managed by the organization are maintained | SDOS-IA-02, SDOS-IN-03 | |
| ID.AM-03 | Representations of the organization's authorized network communication and internal and external network data flows are maintained | SDOS-AU-01, SDOS-EN-04, SDOS-GV-04 | |
| ID.AM-04 | Inventories of services provided by suppliers are maintained | SDOS-AU-02, SDOS-IA-02, SDOS-IN-03 | |
| ID.AM-08 | Systems, hardware, software, services, and data are managed throughout their life cycles | SDOS-GV-01, SDOS-IA-02 | |
| ID.IM-01 | Improvements are identified from evaluations | SDOS-AU-01, SDOS-RS-01 | |
| ID.IM-02 | Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties | SDOS-AU-01, SDOS-RS-01 | |
| ID.IM-03 | Improvements are identified from execution of operational processes, procedures, and activities | SDOS-AU-01, SDOS-AU-02, SDOS-RS-01 | |
| ID.RA-01 | Vulnerabilities in assets are identified, validated, and recorded | SDOS-AU-02, SDOS-IN-01 | |
| ID.RA-02 | Cyber threat intelligence is received from information sharing forums and sources | SDOS-DE-01 | |
| ID.RA-03 | Internal and external threats to the organization are identified and recorded | SDOS-AD-01, SDOS-AU-02 | |
| ID.RA-04 | Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded | SDOS-RM-01, SDOS-RM-02 | |
| ID.RA-05 | Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization | SDOS-RM-01, SDOS-RM-03 | |
| ID.RA-06 | Risk responses are chosen, prioritized, planned, tracked, and communicated | SDOS-GV-02, SDOS-RM-01 | |
| ID.RA-07 | Changes and exceptions are managed, assessed for risk impact, recorded, and tracked | SDOS-AU-01, SDOS-GV-01, SDOS-GV-04, SDOS-IN-01 | |
| ID.RA-08 | Processes for receiving, analyzing, and responding to vulnerability disclosures are established | SDOS-GV-01 | |
| ID.RA-09 | The authenticity and integrity of hardware and software are assessed prior to acquisition and use | SDOS-IA-02, SDOS-IN-03 | |
| ID.RA-10 | Critical suppliers are assessed prior to acquisition | SDOS-IA-02, SDOS-IN-03 |
PROTECT (PR) — 16 Subcategories Mapped¶
Safeguards to manage the organization's cybersecurity risks are used.
| CSF 2.0 Subcategory | Description | SDOS Controls | Strength |
|---|---|---|---|
| PR.AA-01 | Identities and credentials for authorized users, services, and hardware are managed by the organization | SDOS-IA-01, SDOS-IA-02 | |
| PR.AA-02 | Identities are proofed and bound to credentials based on the context of interactions | SDOS-IA-01, SDOS-IA-02 | |
| PR.AA-03 | Users, services, and hardware are authenticated | SDOS-AD-01, SDOS-IA-01 | intersects with |
| PR.AA-04 | Identity assertions are protected, conveyed, and verified | SDOS-AU-01, SDOS-IA-01 | |
| PR.AA-05 | Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties | SDOS-AD-01, SDOS-EN-02, SDOS-GV-01, SDOS-GV-05 | |
| PR.DS-01 | The confidentiality, integrity, and availability of data-at-rest are protected | SDOS-IN-01, SDOS-IN-02 | |
| PR.DS-02 | The confidentiality, integrity, and availability of data-in-transit are protected | SDOS-EN-01, SDOS-EN-04 | |
| PR.DS-10 | The confidentiality, integrity, and availability of data-in-use are protected | SDOS-EN-01, SDOS-EN-04, SDOS-GV-05 | |
| PR.DS-11 | Backups of data are created, protected, maintained, and tested | SDOS-IN-01, SDOS-IN-02 | |
| PR.IR-01 | Networks and environments are protected from unauthorized logical access and usage | SDOS-AD-01, SDOS-EN-02 | intersects with |
| PR.IR-03 | Mechanisms are implemented to achieve resilience requirements in normal and adverse situations | SDOS-EN-03, SDOS-IN-01, SDOS-IN-02 | |
| PR.IR-04 | Adequate resource capacity to ensure availability is maintained | SDOS-EN-03, SDOS-RM-02, SDOS-RM-03 | |
| PR.PS-01 | Configuration management practices are established and applied | SDOS-GV-01, SDOS-GV-04, SDOS-IN-01 | |
| PR.PS-02 | Software is maintained, replaced, and removed commensurate with risk | SDOS-IA-02, SDOS-IN-03 | |
| PR.PS-04 | Log records are generated and made available for continuous monitoring | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03, SDOS-EN-04 | |
| PR.PS-05 | Installation and execution of unauthorized software are prevented | SDOS-AD-01, SDOS-GV-01, SDOS-GV-05, SDOS-IN-03 | intersects with |
DETECT (DE) — 10 Subcategories Mapped¶
Possible cybersecurity attacks and compromises are found and analyzed.
| CSF 2.0 Subcategory | Description | SDOS Controls | Strength |
|---|---|---|---|
| DE.AE-02 | Potentially adverse events are analyzed to better understand associated activities | SDOS-DE-01, SDOS-DE-02 | |
| DE.AE-03 | Information is correlated from multiple sources | SDOS-AU-01, SDOS-AU-02 | intersects with |
| DE.AE-04 | The estimated impact and scope of adverse events are understood | SDOS-AU-01, SDOS-RM-01 | |
| DE.AE-06 | Information on adverse events is provided to authorized staff and tools | SDOS-AU-01, SDOS-AU-03 | |
| DE.AE-07 | Cyber threat intelligence and other contextual information are integrated into the analysis | SDOS-DE-01, SDOS-RM-03 | |
| DE.AE-08 | Incidents are declared when adverse events meet the defined incident criteria | SDOS-AU-02, SDOS-RS-01 | |
| DE.CM-01 | Networks and network services are monitored to find potentially adverse events | SDOS-AU-01, SDOS-AU-02, SDOS-EN-04 | |
| DE.CM-03 | Personnel activity and technology usage are monitored to find potentially adverse events | SDOS-AU-01, SDOS-AU-03 | |
| DE.CM-06 | External service provider activities and services are monitored to find potentially adverse events | SDOS-AU-02, SDOS-EN-04 | |
| DE.CM-09 | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events | SDOS-AU-02, SDOS-IN-01, SDOS-IN-03 |
RESPOND (RS) — 12 Subcategories Mapped¶
Actions regarding a detected cybersecurity incident are taken.
| CSF 2.0 Subcategory | Description | SDOS Controls | Strength |
|---|---|---|---|
| RS.AN-03 | Analysis is performed to establish what has taken place during an incident and the root cause of the incident | SDOS-AU-01, SDOS-AU-02, SDOS-DE-02, SDOS-RS-01 | |
| RS.AN-06 | Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved | SDOS-AU-01, SDOS-AU-03 | intersects with |
| RS.AN-07 | Incident data and metadata are collected, and their integrity and provenance are preserved | SDOS-AU-01, SDOS-AU-03 | intersects with |
| RS.AN-08 | An incident's magnitude is estimated and validated | SDOS-AU-01, SDOS-RM-01 | |
| RS.CO-02 | Internal and external stakeholders are notified of incidents | SDOS-AU-03 | |
| RS.CO-03 | Information is shared with designated internal and external stakeholders | SDOS-AU-03 | |
| RS.MA-02 | Incident reports are triaged and validated | SDOS-AU-01, SDOS-RS-01 | |
| RS.MA-03 | Incidents are categorized and prioritized | SDOS-AU-01, SDOS-RM-01 | |
| RS.MA-04 | Incidents are escalated or elevated as needed | SDOS-DE-01, SDOS-RM-01 | |
| RS.MA-05 | The criteria for initiating incident recovery are applied | SDOS-AU-01, SDOS-RM-01, SDOS-RS-01 | |
| RS.MI-01 | Incidents are contained | SDOS-EN-01, SDOS-EN-03, SDOS-IN-02 | |
| RS.MI-02 | Incidents are eradicated | SDOS-GV-01, SDOS-IA-02 |
RECOVER (RC) — 5 Subcategories Mapped¶
Assets and operations affected by a cybersecurity incident are restored.
| CSF 2.0 Subcategory | Description | SDOS Controls | Strength |
|---|---|---|---|
| RC.CO-03 | Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders | SDOS-AU-01, SDOS-AU-03 | |
| RC.RP-02 | Recovery actions are selected, scoped, prioritized, and performed | SDOS-AU-01, SDOS-RM-01 | |
| RC.RP-03 | The integrity of backups and other restoration assets is verified before using them for restoration | SDOS-IN-01, SDOS-IN-02 | |
| RC.RP-05 | The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed | SDOS-IA-02, SDOS-IN-01, SDOS-IN-03 | |
| RC.RP-06 | The end of incident recovery is declared based on criteria, and incident-related documentation is completed | SDOS-AU-01, SDOS-IN-01, SDOS-IN-03 |
Subcategories Not Mapped¶
30 of 106 CSF 2.0 subcategories are intentionally not mapped to SDOS controls. These subcategories address organizational, personnel, physical, or public-communications outcomes that fall outside the SDOS runtime governance scope:
GOVERN (16 not mapped): GV.OC-01, GV.OC-02, GV.OC-04, GV.OC-05 (organizational mission and stakeholder context); GV.RM-01, GV.RM-03, GV.RM-05 (organizational risk management process); GV.RR-01, GV.RR-03, GV.RR-04 (leadership accountability and HR practices); GV.SC-01, GV.SC-02, GV.SC-03, GV.SC-06, GV.SC-10 (supply chain program lifecycle and contractual coordination).
IDENTIFY (4 not mapped): ID.AM-01, ID.AM-05, ID.AM-07 (hardware and data inventory beyond governed module scope); ID.IM-04 (incident response plan establishment).
PROTECT (6 not mapped): PR.AA-06 (physical access); PR.AT-01, PR.AT-02 (personnel training and awareness); PR.IR-02 (environmental threat protection); PR.PS-03 (hardware lifecycle); PR.PS-06 (secure software development life cycle).
DETECT (1 not mapped): DE.CM-02 (physical environment monitoring).
RESPOND (1 not mapped): RS.MA-01 (incident response plan execution with third parties — coordinated organizationally, not at dispatch).
RECOVER (2 not mapped): RC.RP-01, RC.RP-04 (incident response plan execution and post-incident normalization); RC.CO-04 (public updates on incident recovery).
SDOS Control Catalog¶
The 24 SDOS controls referenced in this crosswalk are catalogued at /sdos/reference/v1/, grouped by governance domain:
- GV — Governance Policy (5 controls): SDOS-GV-01 through SDOS-GV-05
- RM — Risk Management (3 controls): SDOS-RM-01 through SDOS-RM-03
- AD — Admission (1 control): SDOS-AD-01
- IA — Identity Attestation (2 controls): SDOS-IA-01, SDOS-IA-02
- IN — Integrity (3 controls): SDOS-IN-01 through SDOS-IN-03
- EN — Egress Enforcement (4 controls): SDOS-EN-01 through SDOS-EN-04
- AU — Audit (3 controls): SDOS-AU-01 through SDOS-AU-03
- DE — Deliberation (2 controls): SDOS-DE-01, SDOS-DE-02
- RS — Response and ROSI (1 control): SDOS-RS-01
Companion Reference and OLIR Catalog Status¶
This Concept Crosswalk is cataloged as NIST OLIR Reference ID 215 (Final, 2026-06-22), a companion to SDOS-RuntimeGov-to-AI-RMF-v1.0 (Reference ID 220, Final 2026-06-15) and SDOS-RuntimeGov-to-SP-800-53-Rev-5.2.0-v1.0 (Reference ID 217, Final 2026-06-22). All three reached Final status with zero public comments.
Authoritative sources:
- NIST Cybersecurity Framework 2.0 (focal document) — NIST CSWP 29, February 26, 2024
- NIST OLIR Catalog Reference ID 220 (companion submission) — View in NIST OLIR Catalog
- NIST OLIR Program — csrc.nist.gov/projects/olir
- NIST IR 8278 (OLIR submission guidelines) — csrc.nist.gov/pubs/ir/8278/r1/final
This CSF 2.0 crosswalk is cataloged with the NIST OLIR Program as Reference ID 215 and reached Final status on 2026-06-22, with zero comments received during the public review period.
Architectural Positioning¶
SDOS operates at the dispatch-time enforcement layer — the moment immediately before an AI agent invokes a tool, makes a decision, or produces an output. CSF 2.0 alignment focuses on the operational and technical subcategories that govern how AI-driven cyber operations are deployed, monitored, and audited.
The SDOS framework does not replace organizational, physical, or personnel cybersecurity controls. It provides a runtime layer that enforces governance policy at the boundary where AI agents act — adding an architectural layer of cybersecurity assurance for AI-augmented operations.
Frequently Asked Questions¶
What is the SDOS Runtime Governance Framework?¶
SDOS (Security Decision Operating System) is a runtime governance framework that enforces structured policy controls over AI agent operations at the point of dispatch. It binds AI model selection, tool invocation, outbound execution, and audit logging to verifiable governance rules through 24 controls across 9 governance domains. SDOS is model-alignment-independent: it does not rely on the model's internal safety tuning or alignment claims for enforcement.
What is a NIST OLIR Concept Crosswalk?¶
A NIST OLIR (Online Informative References) Concept Crosswalk is a structured mapping between a reference document (such as a control catalog) and a NIST focal document (such as NIST CSF 2.0). The crosswalk identifies, for each subcategory of the focal document, which reference document elements support that subcategory. OLIR submissions are reviewed by NIST and, when accepted, are cataloged as Informative References that practitioners can use for framework alignment.
How many CSF 2.0 subcategories does SDOS map to?¶
76 of 106 CSF 2.0 subcategories are mapped: GOVERN (16 of 32), IDENTIFY (17 of 21), PROTECT (16 of 22), DETECT (10 of 11), RESPOND (12 of 13), and RECOVER (5 of 7). The 30 unmapped subcategories address organizational, physical, personnel, public-communications, or supplier-contract-lifecycle outcomes that fall outside the SDOS runtime governance scope.
What is the relationship type between SDOS and NIST CSF 2.0?¶
Supportive. SDOS provides structural enforcement at the AI agent dispatch layer that supports the operational and technical CSF 2.0 subcategory intent. SDOS does not claim equivalence with the full CSF 2.0; it provides a runtime governance layer that complements, rather than replaces, organizational and physical controls in the focal framework.
What does "intersects with" mean in the Strength of Relationship column?¶
intersects with is one of the standard NIST OLIR strength-of-relationship values defined in NIST IR 8278. It indicates the reference document element and the focal document subcategory share common scope and intent but are not strict subsets of each other. On this crosswalk, 7 of 76 subcategories are explicitly characterized as intersects with; remaining mappings leave the optional Strength column blank.
Is the full SDOS Control Catalog public?¶
Yes. The complete SDOS Control Catalog and Reference Document, with per-control descriptions, evidence types, and patent references, is published at /sdos/reference/v1/. The control catalog is cataloged with the NIST OLIR Program as part of SDOS-RuntimeGov-to-AI-RMF-v1.0 (Reference ID 220).
How does SDOS differ from AI safety alignment?¶
AI safety alignment relies on training-time properties of the AI model itself — reinforcement learning from human feedback (RLHF), constitutional AI, safety fine-tuning. SDOS operates structurally below model alignment: it intercepts AI agent operations at the dispatch boundary and evaluates them against a configuration-governed policy. SDOS produces the same governance outcomes regardless of whether the underlying model is well-aligned, misaligned, fine-tuned, or untrained.
Who is SDOS designed for?¶
CISOs, GRC auditors, AI risk assessors, federal program managers, prime contractors evaluating AI governance subcontractors, and any organization deploying autonomous or semi-autonomous AI agent workflows in regulated environments. SDOS is applicable wherever AI agents invoke tools, make decisions, or produce outputs on behalf of an operator.
How was this crosswalk developed?¶
Through four review rounds and three independent red-team gap analyses. Each round produced a versioned spreadsheet with documented changes; convergence on SHIP was unanimous before submission to the NIST OLIR Program.
Maintenance¶
This document is maintained by AAM Cyber as part of the SDOS Reference Library. The library currently covers 17 framework alignments: NIST AI RMF 1.0, NIST CSF 2.0, NIST SP 800-53 Rev 5.2.0, NIST AI 600-1, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, SOC 2, NAIC MDL-668, NERC CIP, IEEE P2863 (draft), and FAA UAS/AAM (principles-mapped). Version history is available at /sdos/reference/changelog/.
Subsequent updates to this CSF 2.0 alignment page will be issued when: (1) the NIST OLIR Program issues screening feedback requiring crosswalk revision, (2) NIST CSF 2.0 releases a revision requiring mapping review, or (3) SDOS controls are added or retired affecting CSF 2.0 mappings.
Intellectual Property¶
The SDOS Runtime Governance Framework was invented by Pharns Genece. Aspects of the framework are the subject of pending U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620. The scope of pending claims is defined by the as-filed specifications and is not coextensive with the descriptions in this control catalog. AAM Cyber, all rights reserved unless otherwise indicated.
Patent inquiries should be directed to AAM Cyber at aamcyber.com.
Contact¶
AAM Cyber aamcyber.com
Questions about SDOS framework alignment with NIST CSF 2.0: [email protected]
SDOS Runtime Governance Framework — NIST CSF 2.0 Alignment, Concept Crosswalk v1.0. Cataloged with the NIST OLIR Program as Reference ID 215; Final status reached 2026-06-22 with zero public comments.