SDOS Runtime Governance Framework — NIST SP 800-53 Rev 5.2.0 Alignment¶
Informative Reference Name: SDOS-RuntimeGov-to-SP-800-53-Rev-5.2.0-v1.0
Reference Version: 1.10
Focal Document: NIST Special Publication 800-53 Revision 5.2.0 (Security and Privacy Controls for Information Systems and Organizations, August 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 217
Status: Final — public review concluded 2026-06-22 with zero comments
Trifecta Companions: Ref 220 — AI RMF 1.0 · Ref 215 — CSF 2.0
Change Log: View full version history
Key Facts¶
- What: Concept Crosswalk mapping SDOS Runtime Governance Framework controls to NIST Special Publication 800-53 Revision 5.2.0.
- Who: AAM Cyber, authoring organization. Pharns Genece, inventor.
- Scope: 269 of 622 SP 800-53 Rev 5.2.0 controls mapped across 10 control families using 20 of 24 canonical SDOS reference elements.
- Coverage: AC (55), AU (34), CA (17), CM (36), IA (29), PL (6), PT (8), RA (14), SC (30), SI (40).
- Row count: 483 mapped rows total (one mapping per row per NIST OLIR Program guidance).
- Relationship type: Supportive — SDOS provides structural enforcement at the AI agent dispatch layer that supports federal control intent within the governance-relevant scope.
- Status: Cataloged with the NIST OLIR Program 2026-05-21 as Reference ID 217; 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 215 (CSF 2.0).
- Strength of Relationship: 27 of 483 mapped rows explicitly characterized as
intersects with(5.6% density); remaining mappings supportive without explicit characterization. Density sits between the AI RMF Ref 220 baseline (0%) and the CSF 2.0 companion submission (9.3%), reflecting the granularity of the SP 800-53 control surface — fewer controls reach textbook-embodiment threshold in a more granular framework. - 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 Special Publication 800-53 Revision 5.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 federal cybersecurity practitioners, CISOs and security architects operating AI agents in federal or federally-regulated environments, authorization officials and assessors performing SP 800-53 control assessments on AI-using systems, AI governance practitioners, compliance teams supporting FedRAMP/FISMA/federal contract security obligations, and auditors evaluating AI agent governance against SP 800-53 control baselines.
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 |
| Governance-Relevant Scope | The set of operations subject to SDOS dispatch-time enforcement, as distinct from host-OS, network-layer, firmware, or organizational operations outside the SDOS 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 |
| Scope-Bounded Mapping | A mapping comment that explicitly declares what SDOS does within the governance-relevant scope and notes what is outside that scope, to avoid overclaim |
| 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 SP 800-53 Rev 5.2.0 alignment, SDOS provides runtime enforcement at the dispatch layer that supports federal control intent within the AI agent governance-relevant scope. The 10 control families addressed in this crosswalk cover access, audit, identification, configuration, system communications, system integrity, risk assessment, monitoring, planning, and PII processing — the federal control surfaces where AI-agent operations are most directly governable at the dispatch boundary.
Control families addressing organizational, physical, personnel, and supply-chain-lifecycle requirements (AT, CP, IR, MA, MP, PE, PM, PS, SA, SR) are intentionally not mapped in this submission, as those families address obligations outside the SDOS dispatch-time enforcement scope.
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 catalogued under SDOS Catalog v1.0 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 |
Catalog usage in this crosswalk: 20 of 24 SDOS reference elements appear in SP 800-53 mappings. The four absent (SDOS-GV-03, SDOS-GV-05, SDOS-RM-02, SDOS-RM-03) are semantic variants of SDOS-GV-01 and SDOS-RM-01 that did not surface as distinct mapping targets in the SP 800-53 control surface; the base IDs cover the same conceptual ground in the federal control catalog.
Concept Crosswalk Overview¶
This Concept Crosswalk maps the SDOS Runtime Governance Framework — Control Catalog and Reference Document (v1.10) to NIST SP 800-53 Rev 5.2.0. SDOS binds AI model selection, tool invocation, outbound execution, and audit logging to governance rules through the 24 controls in the catalog.
This Informative Reference identifies, for each mapped SP 800-53 control, the SDOS control(s) that support the control's intent at the dispatch and enforcement layer.
Coverage Summary
| SP 800-53 Control Family | Controls Mapped | Mapped Rows | Strength Fills |
|---|---|---|---|
| AC — Access Control | 55 | 89 | 3 |
| AU — Audit and Accountability | 34 | 52 | 4 |
| CA — Assessment, Authorization, and Monitoring | 17 | 31 | 1 |
| CM — Configuration Management | 36 | 76 | 8 |
| IA — Identification and Authentication | 29 | 49 | 3 |
| PL — Planning | 6 | 11 | 0 |
| PT — PII Processing and Transparency | 8 | 17 | 1 |
| RA — Risk Assessment | 14 | 25 | 0 |
| SC — System and Communications Protection | 30 | 57 | 1 |
| SI — System and Information Integrity | 40 | 76 | 6 |
| Total | 269 | 483 | 27 |
Relationship Type: Supportive. The SDOS framework operates at the dispatch and enforcement layer below model alignment, providing structural controls that support SP 800-53 control intent without claiming equivalence. Controls outside the runtime AI governance scope (organizational documentation, physical security, personnel training, supplier contract lifecycle, hardware management) are intentionally not mapped.
Strength of Relationship. 27 of 483 mapped rows are marked intersects with (5.6% density), applied conservatively only where SDOS is the runtime embodiment of the control's enforcement clause within the governance-relevant scope. Where SP 800-53 controls extend beyond the SDOS dispatch boundary, the per-row Comments column in the submitted spreadsheet explicitly declares the scope-bounded relationship to avoid overclaim.
How to Read This Page¶
Each family summary table below shows, for one SP 800-53 control family:
- SP 800-53 Control — the focal document element identifier (e.g.,
AC-03,CM-02) - Description — abbreviated control text (full text in the submitted spreadsheet and in NIST SP 800-53B)
- SDOS Controls — the SDOS reference element(s) that support the control 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 spreadsheet (one row per (control, SDOS-ID) pair with full mapping rationale per row) is the artifact submitted to the NIST OLIR Program and remains the authoritative mapping reference.
Strength-Fill Highlights¶
The 27 mapped rows characterized as intersects with represent textbook-embodiment claims where SDOS is the runtime mechanism implementing the control's enforcement clause within the governance-relevant scope. These are listed below for reviewer convenience; the remaining 456 supportive mappings are documented in the submitted spreadsheet.
Access Control (AC) — 3 strength fills¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| AC-03 Access Enforcement | SDOS-AD-01 | Default-deny pre-admission is the runtime enforcement of approved authorizations at the governed dispatch boundary |
| AC-06 Least Privilege | SDOS-AD-01 | Default-deny pre-admission is the architectural enforcement of least privilege within the governance-relevant scope |
| AC-24 Access Control Decisions | SDOS-AD-01 | Access control decisions are applied to each access request through default-deny pre-admission at the dispatch boundary |
Audit and Accountability (AU) — 4 strength fills¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| AU-09 Protection of Audit Information | SDOS-AU-02 | Append-only audit log integrity is the architectural protection against unauthorized modification or deletion of audit information |
| AU-09(01) Hardware Write-Once Media | SDOS-AU-02 | Append-only audit log integrity is the software analogue of write-once media for governance-relevant audit records |
| AU-10 Non-Repudiation | SDOS-AU-01 | Non-repudiation is provided by per-invocation audit records that bind every governed operation to its attested principal identity |
| AU-12 Audit Record Generation | SDOS-AU-01 | Audit record generation capability for governance-relevant events is implemented through per-invocation audit records produced at every dispatch |
Configuration Management (CM) — 8 strength fills¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| CM-02 Baseline Configuration | SDOS-GV-01 | For the governance-relevant scope, configuration-governed module activation is the runtime baseline; the signed activation manifest is honored by the dispatch engine. Whole-system baseline coverage is outside this scope. |
| CM-02(02) Automation Support for Accuracy | SDOS-GV-01 | Currency, completeness, accuracy, and availability of the governance-relevant dispatch baseline are automated through configuration-governed module activation |
| CM-03(05) Automated Security Response | SDOS-AD-01 | Default-deny pre-admission implements automated security response to unauthorized baseline changes within the governance-relevant scope |
| CM-06 Configuration Settings | SDOS-GV-01 | Configuration-governed module activation is the establishment and enforcement of governance-relevant configuration settings |
| CM-06(01) Automated Management | SDOS-GV-01 | Automated management, application, and verification of governance-relevant configuration settings is the core function of configuration-governed module activation |
| CM-06(02) Respond to Unauthorized Changes | SDOS-GV-01 | Configuration-governed module activation detects unauthorized governance-relevant setting changes by rejecting manifests that fail signature or version checks |
| CM-07 Least Functionality | SDOS-AD-01 | Within the governance-relevant scope, default-deny pre-admission enforces least functionality at the governed dispatch boundary. Host-OS and network-stack functions outside the governed scope are not enforced by SDOS. |
| CM-07(05) Authorized Software — Allow-by-Exception | SDOS-AD-01 | Default-deny pre-admission is the allow-by-exception execution policy for governance-relevant modules |
Identification and Authentication (IA) — 3 strength fills¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| IA-02 Identification and Authentication (Organizational Users) | SDOS-IA-01 | Attested agent identity uniquely identifies and authenticates principals at the dispatch boundary |
| IA-03 Device Identification and Authentication | SDOS-IA-02 | For governance-relevant service-to-service and module-to-module communication, attested module identity provides cryptographic verification at the dispatch boundary. Hardware/network-layer device authentication is outside this scope. |
| IA-09 Service Identification and Authentication | SDOS-IA-02 | Unique identification and authentication of governance-relevant system services and applications is provided by attested module identity |
System and Communications Protection (SC) — 1 strength fill¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| SC-07(05) Deny by Default / Allow by Exception | SDOS-AD-01 | Default-deny pre-admission is the deny-by-default, allow-by-exception enforcement at the governed dispatch boundary |
System and Information Integrity (SI) — 6 strength fills¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| SI-07 Software, Firmware, and Information Integrity | SDOS-IA-02 | Attested module identity is the integrity verification mechanism for governance-relevant software and firmware |
| SI-07(01) Integrity Checks | SDOS-IA-02 | Attested module identity performs an integrity check at every dispatch event and at startup |
| SI-07(05) Automated Response to Integrity Violations | SDOS-AD-01 | Default-deny pre-admission automatically implements the configured response on integrity violation |
| SI-07(06) Cryptographic Protection | SDOS-IA-02 | For governance-relevant software modules, attested module identity is the cryptographic mechanism that detects unauthorized changes. Firmware and arbitrary information at rest are outside this scope unless encapsulated as governed modules. |
| SI-07(12) Integrity Verification | SDOS-IA-02 | Attested module identity verifies module integrity prior to execution; dispatch is blocked until cryptographic verification succeeds |
| SI-07(15) Code Authentication | SDOS-IA-02 | For governance-relevant software and firmware components, attested module identity is the cryptographic mechanism authenticating components prior to admission |
Assessment, Authorization, and Monitoring (CA) — 1 strength fill¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| CA-07 Continuous Monitoring | SDOS-AU-01 | Per-invocation audit records emit structured monitoring evidence synchronously with every dispatch decision, providing the continuous-monitoring substrate for governance-relevant control effectiveness. Organizational monitoring strategy, frequency definition, and assessment-result reporting are outside this scope. |
PII Processing and Transparency (PT) — 1 strength fill¶
| SP 800-53 Control | SDOS Control | Embodiment |
|---|---|---|
| PT-02(02) Automated Enforcement of Authorized Processing | SDOS-AD-01 | Default-deny pre-admission is the automated mechanism enforcing authorized processing of PII at the governed dispatch boundary |
Catalog Discipline and Scope-Bounding¶
Eight mapping comments in the submitted spreadsheet use explicit scope-bounding language to declare what SDOS does within the governance-relevant scope and what is outside that scope. This is a deliberate discipline to avoid overclaim where SP 800-53 controls extend beyond the SDOS dispatch boundary. Examples:
- CM-02 baseline configuration includes firmware and network settings; SDOS covers the runtime dispatch baseline only
- CM-07 least functionality includes host-OS and listening-port restrictions; SDOS covers governance-relevant operations only
- CA-07 continuous monitoring includes organizational strategy and assessment-result reporting; SDOS provides the audit substrate only
- IA-03 device identification includes hardware/network-layer authentication; SDOS covers service-to-service authentication only
- SI-07(06) integrity covers firmware and information at rest; SDOS covers governance-relevant software modules only
- SC-12 cryptographic key establishment covers full key lifecycle; SDOS covers governance-relevant signing keys only
- RA-03(04) advanced analytics is organizational; SDOS provides the structured event substrate as input only
- RA-05(04) discoverability assessment is organizational; SDOS reduces the dispatch footprint as enforcement input only
The full per-row scope-bounding language is in the submitted spreadsheet's Comments column.
Control Families Not Mapped¶
The following SP 800-53 control families are intentionally not mapped in this submission. They address obligations outside the SDOS dispatch-time enforcement scope and were excluded for the same reason as the CSF 2.0 unmapped subcategories:
| Family | Reason |
|---|---|
| AT — Awareness and Training | Personnel training and awareness obligations |
| CP — Contingency Planning | Organizational continuity planning |
| IR — Incident Response | Organizational incident response procedures (audit substrate supports IR family obligations from outside their scope) |
| MA — Maintenance | Hardware maintenance lifecycle |
| MP — Media Protection | Physical media handling |
| PE — Physical and Environmental Protection | Physical security |
| PM — Program Management | Organizational program management |
| PS — Personnel Security | HR and personnel screening |
| SA — System and Services Acquisition | Acquisition lifecycle and SDLC |
| SR — Supply Chain Risk Management | Supplier contract and lifecycle management |
These exclusions are deliberate. The SDOS dispatch-time enforcement boundary does not extend to organizational, physical, personnel, or contract-lifecycle obligations.
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 part of the SDOS Runtime Governance trifecta cataloged with the NIST OLIR Program — all three reached Final status with zero public comments:
- SDOS-RuntimeGov-to-AI-RMF-v1.0 — Reference ID 220, Final 2026-06-15 (catalog detail page)
- SDOS-RuntimeGov-to-CSF-2.0-v1.0 — Reference ID 215, Final 2026-06-22 (alignment page)
- SDOS-RuntimeGov-to-SP-800-53-Rev-5.2.0-v1.0 — Reference ID 217, Final 2026-06-22 (this document)
Together, these three OLIR references provide a federal cybersecurity alignment trifecta covering AI-specific risk management (AI RMF), general cybersecurity posture (CSF 2.0), and the federal control catalog underlying FedRAMP and FISMA (SP 800-53 Rev 5.2.0).
Authoritative sources:
- NIST Special Publication 800-53 Revision 5.2.0 (focal document) — csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- 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 submission is cataloged as NIST OLIR Reference ID 217 and reached Final status on 2026-06-22 with zero public comments.
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. SP 800-53 Rev 5.2.0 alignment focuses on the federal control families that govern access, audit, identification, configuration, system communications, and integrity in environments where AI agents operate.
The SDOS framework does not replace organizational, physical, or personnel security 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 in federal and federally-regulated environments.
The complete control catalog with all 24 SDOS controls and their detailed descriptions is available at /sdos/reference/v1/.
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 SP 800-53). The crosswalk identifies, for each control in the focal document, which reference document elements support that control. OLIR submissions are reviewed by NIST and, when accepted, are cataloged as Informative References that practitioners can use for framework alignment.
How many SP 800-53 Rev 5.2.0 controls does SDOS map to?¶
269 of 622 SP 800-53 Rev 5.2.0 controls are mapped across 10 control families (AC, AU, IA, CM, SC, SI, RA, CA, PL, PT). The 10 unmapped control families (AT, CP, IR, MA, MP, PE, PM, PS, SA, SR) address obligations outside the SDOS dispatch-time enforcement scope.
What is the relationship type between SDOS and NIST SP 800-53 Rev 5.2.0?¶
Supportive. SDOS provides structural enforcement at the AI agent dispatch layer that supports the operational and technical SP 800-53 control intent within the governance-relevant scope. SDOS does not claim equivalence with the full SP 800-53 control catalog; it provides a runtime governance layer that complements, rather than replaces, organizational, physical, and personnel 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 control share common scope and intent but are not strict subsets of each other. On this crosswalk, 27 of 483 mapped rows (5.6% density) are explicitly characterized as intersects with; remaining mappings leave the optional Strength column blank.
Why is the strength-of-relationship density different across the trifecta submissions?¶
The three OLIR submissions show progressively-applied discipline: AI RMF v1.8 (0% density, the earliest submission, before strength-fill discipline was formalized), CSF 2.0 v1.0 (9.3% density, applying the discipline to coarser CSF subcategories where more controls reach textbook-embodiment threshold), and SP 800-53 v1.0 (5.6% density, applying the same discipline to granular SP 800-53 controls where fewer reach textbook-embodiment threshold). The same rule is applied across all three submissions: assert intersects with only where SDOS is the runtime embodiment of the control's enforcement clause within the governance-relevant scope, defensible under hostile review.
Why are some SDOS catalog IDs absent from the SP 800-53 mapping?¶
20 of 24 SDOS catalog IDs are used in this crosswalk. The four absent (SDOS-GV-03, SDOS-GV-05, SDOS-RM-02, SDOS-RM-03) are semantic variants of SDOS-GV-01 and SDOS-RM-01 that did not surface as distinct mapping targets in the SP 800-53 control surface. The base IDs cover the same conceptual ground in the federal control catalog. The AI RMF and CSF 2.0 companion submissions use all 24 IDs because those frameworks have control-surface vocabulary that distinguishes the variants from the base IDs.
What does scope-bounding mean and where does it appear?¶
Scope-bounding is a deliberate discipline applied across this submission: where an SP 800-53 control includes enforcement clauses that extend beyond the SDOS dispatch boundary (e.g., firmware integrity, full key lifecycle, host-OS functions), the per-row Comments column explicitly declares what SDOS does within the governance-relevant scope and what is outside that scope. This avoids overclaim while preserving the legitimate mapping. Eight mappings use explicit scope-bounding language: CM-02, CM-02(02), CM-07, CA-07, IA-03, SI-07(06), RA-03(04), RA-05(04), and SC-12.
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?¶
Federal cybersecurity practitioners; CISOs and security architects operating AI agents in federal or federally-regulated environments; authorization officials and assessors performing SP 800-53 control assessments on AI-using systems; AI governance practitioners; compliance teams supporting FedRAMP, FISMA, or federal contract security obligations; auditors evaluating AI agent governance against SP 800-53 control baselines.
How was this crosswalk developed?¶
Through twelve validation rounds: internal review panel (3 passes), independent multi-model review (3 passes), adversarial red team pass, trifecta consistency audit, expert governance decisions, hostile OLIR analyst review, patent-gap check, and cross-submission review. Eight strength-fill comments were revised with explicit scope-bounding language per the adversarial pass. SDOS-DE-01 and SDOS-DE-02 are reserved exclusively for governed multi-agent deliberation per SDOS Catalog v1.0 — detection-substrate mappings use SDOS-AU-01/AU-02. Convergence on PROCEED was unanimous before submission.
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 SP 800-53 alignment page will be issued when: (1) the NIST OLIR Program issues screening feedback requiring crosswalk revision, (2) NIST SP 800-53 releases a revision requiring mapping review, or (3) SDOS controls are added or retired affecting SP 800-53 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 SP 800-53 Rev 5.2.0: [email protected]
SDOS Runtime Governance Framework — NIST SP 800-53 Rev 5.2.0 Alignment, Concept Crosswalk v1.0. Cataloged with the NIST OLIR Program as Reference ID 217; Final status reached 2026-06-22 with zero public comments.