SDOS Runtime Governance Framework — CMMC 2.0 Alignment¶
SDOS Version: 1.3
Standard: Cybersecurity Maturity Model Certification 2.0 — Level 2 (based on NIST SP 800-171 Rev 2)
Final Rule: December 16, 2024
Version note: This mapping references NIST SP 800-171 Rev 2, which was the operative baseline when CMMC 2.0 was formalized. NIST published SP 800-171 Rev 3 in September 2024. CMMC enforcement is transitioning to Rev 3 requirements. Rev 3 reorganized and renumbered some controls but did not fundamentally change the security domains or objectives relevant to AI agent governance. The SDOS control mappings in this document apply to both Rev 2 and Rev 3 at the domain and objective level. Organizations preparing for CMMC assessments against Rev 3 should verify specific practice identifiers against the current CMMC program documentation at dodcio.defense.gov.
Document Date: 2026-05-03
Authoring Organization: AAM Cyber (aamcyber.com)
Inventor: Pharns Genece
SDOS Control Catalog: View full control definitions
Purpose¶
This document maps the controls of the SDOS Runtime Governance Framework to CMMC 2.0 Level 2 requirements. It is intended to assist defense contractors, system owners, and Certified Third-Party Assessment Organizations (C3PAOs) evaluating SDOS as a technical control layer for AI systems operating in environments that handle Controlled Unclassified Information (CUI).
This is an informative alignment document. It does not constitute a CMMC assessment, a Plan of Action and Milestones (POA&M), or a determination of CMMC compliance. Organizations must engage a C3PAO for formal CMMC Level 2 certification assessments.
Applicability¶
This document applies to organizations in the Defense Industrial Base (DIB) deploying agentic AI workflows in environments subject to CMMC 2.0 requirements. It is relevant when:
- An AI agent operates within or adjacent to a CUI enclave, or
- A contractor is evaluating technical controls at the AI agent boundary for inclusion in a System Security Plan (SSP) or POA&M, or
- A C3PAO is assessing AI-layer controls against NIST SP 800-171 practice requirements.
This document focuses on NIST SP 800-171 domains where SDOS has the strongest alignment: Audit and Accountability (3.3), Access Control (3.1), Identification and Authentication (3.5), and Configuration Management (3.4).
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 comprising the public runtime control set 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 |
How to Use This Document¶
Assessor Use Notice¶
Mapping strength reflects the framework's design coverage of the cited requirement. Operating effectiveness is a property of a specific deployment and must be tested per engagement. Assessors should treat all mappings as control-design assertions requiring implementation verification — including evidence collection, sample selection, and testing against the assessor's own audit objective. The strength rating is the starting point for an assessor's testing plan, not a substitute for it.
Mapping Strength Legend¶
| Rating | Meaning |
|---|---|
| Strong | SDOS provides a direct, mechanism-specific technical implementation of the practice. |
| Partial — [qualifier] | SDOS addresses a defined subset. The qualifier identifies what is covered and what requires additional controls. |
| Weak — Substrate Only | SDOS produces data or infrastructure that enables compliance but does not itself satisfy the practice. |
| Out of Scope | The practice falls entirely outside the operational boundary of a runtime governance framework. |
CMMC 2.0 Structure Reference¶
CMMC 2.0 Level 2 consists of 110 practices across 14 domains, drawn from NIST SP 800-171 Rev 2:
| Domain | Abbreviation | Practice Count |
|---|---|---|
| Access Control | AC | 22 |
| Awareness and Training | AT | 3 |
| Audit and Accountability | AU | 9 |
| Configuration Management | CM | 9 |
| Identification and Authentication | IA | 11 |
| Incident Response | IR | 3 |
| Maintenance | MA | 6 |
| Media Protection | MP | 9 |
| Personnel Security | PS | 2 |
| Physical Protection | PE | 6 |
| Risk Assessment | RA | 3 |
| Security Assessment | CA | 4 |
| System and Communications Protection | SC | 16 |
| System and Information Integrity | SI | 7 |
Glossary¶
| Term | Definition |
|---|---|
| CUI | Controlled Unclassified Information — federal information requiring protection per law, regulation, or policy |
| DIB | Defense Industrial Base — network of contractors supporting DoD |
| C3PAO | Certified Third-Party Assessment Organization — CMMC-authorized assessor |
| POA&M | Plan of Action and Milestones — documented remediation plan for unmet practices |
| SPRS | Supplier Performance Risk System — DoD system where self-assessment scores are submitted |
| Point of dispatch | The moment a task is assigned to an agent before tool execution; the primary SDOS enforcement boundary |
| Governed egress | Outbound operations subject to pre-execution policy enforcement before results are returned |
| Fail-closed degradation | When governance infrastructure is unavailable, SDOS halts operations requiring active governance evaluation |
Scope Statement¶
SDOS operates at the point of dispatch. In a CMMC 2.0 context, SDOS governs what AI agents are permitted to do before they execute — enforcing access policy, logging every invocation, and blocking unauthorized outbound operations within CUI handling environments.
Within scope: Access control enforcement at dispatch, audit log generation and integrity, agent and module identity verification, pre-egress enforcement, and governance baseline integrity.
Outside SDOS Operational Boundary (must be addressed by complementary organizational controls):
| Domain | Content | Why Out of Scope |
|---|---|---|
| AT (Awareness and Training) | Security training | Organizational/HR obligation |
| MA (Maintenance) | System maintenance | Infrastructure obligation |
| MP (Media Protection) | Media handling and disposal | Data storage layer |
| PE (Physical Protection) | Physical access | Physical security layer |
| PS (Personnel Security) | Background checks | HR obligation |
| IR (Incident Response) | IR plan and testing | Organizational process obligation |
Strongest Alignment: Domains 3.3, 3.1, and 3.5¶
3.3 — Audit and Accountability
Domain 3.3 mandates audit record creation, protection, and review for CUI system access. SDOS satisfies the technical audit controls at the AI agent layer:
- SDOS-AU-01 satisfies 3.3.1's audit record generation requirement — a structured audit record is generated for every agent invocation before the result is returned.
- SDOS-AU-02 satisfies 3.3.1's protection requirement — append-only integrity protects logs from modification.
- SDOS-AU-03 contributes to 3.3.1's retention objective — dual audit trail provides structural redundancy. Full 3.3.1 satisfaction also requires an organizational definition of which event types are audited and a documented retention schedule; these are outside SDOS's operational boundary.
- SDOS-EN-04 contributes to 3.3.2 (Ensure the actions of individual users can be traced) — tamper-evident egress records provide non-repudiable evidence.
3.1 — Access Control
Domain 3.1 mandates least-privilege access control for CUI. SDOS implements this at the agent dispatch layer:
- SDOS-GV-01, SDOS-GV-03, and SDOS-AD-01 satisfy 3.1.1 (Limit system access to authorized users) and 3.1.2 (Limit system access to transactions and functions authorized users are permitted to execute).
- SDOS-EN-01 and SDOS-EN-02 contribute to 3.1.3 (Control the flow of CUI) — pre-egress enforcement governs what information AI agents can output and where at the dispatch layer. Full 3.1.3 satisfaction requires CUI controls at the data and path layer (storage, transit, API responses outside the dispatch boundary).
- SDOS-RM-03 and SDOS-GV-02 contribute to 3.1.6 (Use non-privileged accounts when accessing non-security functions) — risk-tiered model selection is a functional analog to non-privileged account enforcement at the AI model layer. The mechanism is real; the control is account-centric, so the mapping is Partial — Capability-Tier Analog.
3.5 — Identification and Authentication
Domain 3.5 mandates identification and authentication for users and system components. SDOS provides this at the AI agent boundary:
- SDOS-IA-01 satisfies 3.5.1 (Identify information system users, processes, and devices) — cryptographically verified unique identity for every agent operating in a governed session.
- SDOS-IA-02 satisfies 3.5.1 at the module level — module identity is verified before activation.
Full Mapping Table¶
| NIST SP 800-171 Practice | SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|
| 3.1.1 Limit access to authorized users, processes, and devices | GV-01, GV-03, AD-01 | Strong | Config-governed activation + default-deny = authorized-access-only enforcement at dispatch |
| 3.1.2 Limit access to authorized transactions and functions | GV-01, GV-03, EN-01 | Strong | Policy-governed module scope + pre-egress enforcement = function-level access limitation |
| 3.1.3 Control the flow of CUI | EN-01, EN-02, GV-05 | Partial — Substrate-Dependent | Pre-egress enforcement at agent + module boundaries governs CUI-adjacent information flow at the dispatch layer. Full 3.1.3 satisfaction requires CUI controls at the data and path layer (storage, API responses, exports). SDOS governs what agents may output and where — it does not bind CUI residing in downstream storage or transit paths outside the dispatch boundary. |
| 3.1.5 Employ principle of least privilege | GV-03, AD-01, RM-03 | Strong | Default-deny + risk-floor binding = least-privilege enforcement at dispatch |
| 3.1.6 Use non-privileged accounts for non-security functions | GV-02, RM-01, RM-03 | Partial — Capability-Tier Analog | Risk-tiered model selection restricts AI agents to capability tiers appropriate to the operation — a functional analog to non-privileged account enforcement. 3.1.6 is written for human/process accounts; SDOS addresses the equivalent constraint at the model-selection layer. The mechanism is real; the control vocabulary is account-centric, not model-centric. |
| 3.1.7 Prevent non-privileged users from executing privileged functions | GV-02, RM-03, AD-01 | Strong | Risk-floor binding + admission gate prevent AI agents from self-escalating to higher capability tiers |
| 3.3.1 Create and retain system audit logs | AU-01, AU-02, AU-03 | Partial — Substrate-Dependent | Per-invocation records (AU-01) + append-only integrity (AU-02) + dual trail (AU-03) satisfy the audit record generation and protection requirements at the AI agent layer. 3.3.1 also requires specifying which event types are audited and establishing a retention schedule — both organizational obligations outside the SDOS operational boundary. SDOS provides the technical audit substrate; the organizational scope definition and retention policy complete the practice. |
| 3.3.2 Ensure individual user actions can be traced | AU-01, IA-01, EN-04 | Strong | Identity-linked audit records + tamper-evident egress = traceable actions per agent identity |
| 3.4.1 Establish and maintain baseline configurations | IN-01, GV-01 | Strong | Governance baseline integrity + config-governed activation = maintained baseline |
| 3.4.2 Establish and enforce security configuration settings | GV-01, GV-03 | Strong | Policy-governed activation settings (GV-01) and default-deny pre-admission (GV-03) enforce security configuration at the AI agent layer |
| 3.4.6 Employ principle of least functionality | GV-01, GV-03, AD-01 | Strong | Only explicitly configured modules activate; no implicit or default functionality |
| 3.4.7 Restrict, disable, or prevent the use of nonessential programs, functions, ports, and protocols | GV-01, EN-01, EN-02 | Strong | Config-governed module scope + pre-egress enforcement restrict AI agent capabilities to configured scope |
| 3.4.8 Apply deny-by-exception policy | GV-03, AD-01 | Strong | Default-deny + explicit admission gate = deny-by-exception at the AI agent boundary |
| 3.4.9 Control and monitor user-installed software | IN-03, GV-01, IA-02 | Partial — Module Scope | Module manifest integrity + config-governed activation + verified module identity enforce software control at the AI module layer. 3.4.9's scope includes user-installed software on CUI system hosts and endpoints — general host-layer software control is an infrastructure obligation outside the SDOS dispatch boundary. |
| 3.5.1 Identify information system users, processes acting on behalf of users, and devices | IA-01, IA-02 | Strong | Cryptographic identity verification for agents (user analog) and modules (device/process analog) |
| 3.5.2 Authenticate users, processes, and devices | IA-01, IA-02 | Strong | Verified identity provides authentication before any governed operation |
| 3.5.3 Use multi-factor authentication | — | Not Applicable — Non-Interactive NPE | NIST SP 800-171 practice 3.5.3 governs multi-factor authentication for organizational users accessing non-privileged and privileged accounts. AI agents operating under SDOS governance are non-person entities (NPEs) — they do not have interactive login sessions to which human MFA applies. NPE authentication is addressed via SDOS-IA-01 cryptographic identity verification under 3.5.1/3.5.2. Where an AI agent has a login path to an organizational system (e.g., a service account credential), that account falls within 3.5.3's scope and must be covered by MFA controls in the broader SSP — SDOS does not satisfy that requirement. |
| 3.5.7 Enforce minimum password complexity | — | Not Applicable | SDOS uses cryptographic identity verification, not passwords. 3.5.7 governs password complexity for human accounts — a mechanism SDOS does not implement and does not need to implement at the AI agent layer. Human password policy is an organizational obligation outside SDOS's operational boundary. |
| 3.13.1 Monitor, control, and protect organizational communications | EN-01, EN-02, EN-04 | Partial — AI Egress Layer | Pre-egress enforcement + subordinate gate + tamper-evident audit govern what AI agents emit and where. 3.13.1's protection scope also covers network-level controls (encryption, segmentation, boundary protection) that operate below the SDOS dispatch layer and are infrastructure obligations outside SDOS's operational boundary. |
| 3.13.2 Employ architectural designs, software development techniques, and systems engineering principles promoting security | GV-05, EN-03, IN-01 | Partial — governance scope | Model-alignment-independent enforcement + fail-closed degradation + baseline integrity cover the governance architecture |
| 3.14.1 Identify, report, and correct information security flaws | IN-01, IN-02 | Partial — governance scope | Baseline integrity + drift detection cover governance configuration flaws; general vulnerability management is outside scope |
| 3.14.6 Monitor organizational systems to detect attacks and indicators of potential attacks | AU-01, IN-01, IN-02 | Partial — agent layer | Per-invocation audit + baseline drift detection provide detection substrate at AI agent layer; network monitoring is infrastructure-layer |
| 3.14.7 Identify unauthorized use of organizational systems | AU-01, IA-01, AD-01 | Strong | Per-invocation records tied to verified identity + default-deny admission = unauthorized-use detection at agent layer |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | 3.4.1/3.4.2/3.4.6: baseline configuration and least functionality |
| SDOS-GV-02 — Governance-Tiered Model Selection | 3.1.6/3.1.7: non-privileged operation enforcement |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | 3.1.5/3.4.8: least privilege and deny-by-exception |
| SDOS-GV-04 — Cross-Module Governance Continuity | 3.5.1: identity continuity across module boundaries |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | 3.13.2: security-promoting architectural design |
Risk Management (RM)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | 3.1.5: risk-based access tiering at execution |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | 3.1.5/3.1.6: capability allocation proportional to risk |
| SDOS-RM-03 — Risk-Floor Model Binding | 3.1.5/3.1.7: minimum capability floor as access restriction |
Enforcement (EN)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | 3.1.3/3.13.1: CUI flow control at execution boundary |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | 3.1.3: secondary boundary enforcement |
| SDOS-EN-03 — Fail-Closed Degradation | 3.13.2: security-promoting architecture |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | 3.3.2: traceable, non-repudiable output records |
Identity and Attestation (IA)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | 3.5.1/3.5.2: identification and authentication at AI agent boundary |
| SDOS-IA-02 — Attested Module Identity | 3.5.1: module identification before activation |
Audit (AU)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | 3.3.1/3.3.2: audit record generation |
| SDOS-AU-02 — Append-Only Audit Log Integrity | 3.3.1: audit log protection |
| SDOS-AU-03 — Dual Audit Trail | 3.3.1: audit log retention and redundancy |
Integrity (IN)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | 3.4.1/3.14.1: baseline and flaw detection |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | 3.4.1/3.14.6: automated detection with halt response |
| SDOS-IN-03 — Module Manifest Integrity | 3.4.9: software control before activation |
Admission (AD)¶
| Control | CMMC 2.0 Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | 3.1.5/3.4.8: least privilege and deny-by-exception foundation |
CMMC 2.0 Context: AI Systems in the Defense Industrial Base¶
AI systems in DIB environments represent an emerging compliance challenge. CMMC 2.0's 110 practices were not written with agentic AI workflows in mind — but the technical obligations they encode (least-privilege access, audit traceability, CUI flow control, configuration management) map directly to the architectural problems a runtime governance framework solves.
Organizations deploying AI agents within CUI-handling systems face a documentation gap: standard SSPs have no template section for AI agent governance. SDOS provides the technical controls, and this mapping provides the documentation substrate to fill that gap against existing CMMC practice requirements.
Relationship to Other Frameworks¶
SDOS is also mapped to NIST AI RMF 1.0, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, and FedRAMP Rev 5. For organizations subject to multiple frameworks, SDOS controls address overlapping technical requirements simultaneously.
CMMC 2.0 Level 2 shares significant control overlap with FedRAMP Moderate. Organizations pursuing both should note that the same SDOS controls satisfy parallel requirements across both frameworks.
Full NIST AI RMF mapping: SDOS Control Catalog and Reference Document v1.3
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. 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.
For alignment purposes, SDOS supports the operational and technical requirements addressing how AI-driven cyber operations are deployed, monitored, and audited. Requirements addressing the organizational, physical, or personnel layer fall outside the SDOS scope and require separate controls.
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 for every framework alignment is published at /sdos/reference/changelog/.
Subsequent updates to this alignment page will be issued when: (1) screening feedback from a recognized standards body requires revision, (2) the focal framework releases a revision requiring mapping review, or (3) SDOS controls are added or retired affecting the alignment.
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 CMMC 2.0 requirements: [email protected]
SDOS Runtime Governance Framework — CMMC 2.0 Level 2 Alignment. Version 1.4. Published 2026-05-03. Last updated 2026-05-12.