SDOS Runtime Governance Framework — FedRAMP Rev 5 Alignment¶
SDOS Version: 1.3
Standard: FedRAMP Revision 5 — Federal Risk and Authorization Management Program (based on NIST SP 800-53 Rev 5.2.0)
Effective Date: January 2023
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 the FedRAMP Revision 5 control baseline (NIST SP 800-53 Rev 5.2.0). It is intended to assist federal system owners, cloud service providers (CSPs), and Third Party Assessment Organizations (3PAOs) evaluating SDOS as a technical control layer for AI systems within FedRAMP-authorized cloud environments.
This is an informative alignment document. It does not constitute a FedRAMP System Security Plan (SSP), an Authority to Operate (ATO), or a determination of FedRAMP compliance. Organizations must engage authorized 3PAOs and sponsoring agencies for formal FedRAMP authorization.
Applicability¶
This document applies to organizations deploying agentic AI workflows within FedRAMP-authorized cloud environments. It is relevant when:
- A Cloud Service Provider (CSP) is documenting AI agent governance controls in a System Security Plan (SSP), or
- A federal agency is evaluating AI system runtime controls against NIST SP 800-53 Rev 5.2.0 control families, or
- An AI system operating within a FedRAMP boundary requires documentation of access control, audit, and configuration management controls.
This document focuses on control families where SDOS has the strongest alignment: AU (Audit and Accountability), AC (Access Control), IA (Identification and Authentication), CM (Configuration Management), and SI (System and Information Integrity).
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 NIST 800-53 control. |
| 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 control. |
| Out of Scope | The control falls entirely outside the operational boundary of a runtime governance framework. |
FedRAMP Impact Levels¶
FedRAMP defines three impact levels with increasing control baseline requirements:
| Level | Description |
|---|---|
| Low | Systems where compromise has limited adverse effect |
| Moderate | Systems where compromise has serious adverse effect — most federal systems |
| High | Systems where compromise has severe or catastrophic effect |
SDOS addresses AI-layer controls applicable across all three impact levels. The mapping table notes where controls apply specifically at Moderate or High baselines.
Glossary¶
| Term | Definition |
|---|---|
| ATO | Authority to Operate — formal federal authorization to operate a system |
| CSP | Cloud Service Provider — entity seeking FedRAMP authorization |
| 3PAO | Third Party Assessment Organization — FedRAMP-authorized assessor |
| SSP | System Security Plan — documentation of security controls implementation |
| Control Family | NIST SP 800-53 grouping of related security controls (AC, AU, CM, IA, etc.) |
| 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 FedRAMP context, SDOS governs what AI agents are permitted to do before they execute — enforcing access policy, logging every invocation, and blocking unauthorized outbound operations. This covers the agent-layer slice of NIST 800-53 technical controls within a federal cloud environment.
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):
| Control Family | Content | Why Out of Scope |
|---|---|---|
| PE (Physical Protection) | Physical access controls | Physical security layer |
| MP (Media Protection) | Media handling and disposal | Data storage layer |
| SA (System and Services Acquisition) | SDLC and procurement | Pre-deployment |
| PL (Planning) | Security planning | Organizational obligation |
| PS (Personnel Security) | Background checks, training | HR/organizational obligation |
| CP (Contingency Planning) | Backup and recovery | Infrastructure-layer obligation |
Strongest Alignment: AU, AC, and IA Control Families¶
AU — Audit and Accountability
The AU control family is the strongest SDOS alignment domain in FedRAMP. SDOS satisfies the technical audit record generation and protection controls at the AI agent layer:
- SDOS-AU-01 satisfies AU-2 (Event Logging) and AU-12 (Audit Record Generation) — a structured audit record is generated for every agent invocation before the result is returned.
- SDOS-AU-02 satisfies AU-9 (Protection of Audit Information) — append-only log integrity directly implements tamper-protection. Note: SDOS-EN-04 addresses non-repudiation of output records (AU-10), not audit store protection; it is correctly mapped under AU-10 only.
- SDOS-AU-03 contributes to AU-9(2) (Store Audit Records in Separate Physical System, High baseline only) — dual audit trail provides the structural pattern; Strong satisfaction requires deployment-time placement of the two repositories in physically or logically separated trust domains with independent administrative control.
- SDOS-EN-04 contributes to AU-10 (Non-Repudiation, High baseline only) — tamper-evident egress records provide non-repudiable evidence of governed output operations.
AC — Access Control
The AC control family requires least-privilege enforcement and access authorization. SDOS implements this at the agent dispatch layer:
- SDOS-GV-01 satisfies AC-3 (Access Enforcement) — only explicitly configured modules may activate.
- SDOS-GV-03 and SDOS-AD-01 satisfy AC-6 (Least Privilege) — default-deny ensures every agent starts without access and receives only explicitly granted permissions.
- SDOS-GV-02 and SDOS-RM-03 satisfy AC-6(1) (Authorize Access to Security Functions) — risk-tiered model selection restricts high-capability models to high-risk operations.
IA — Identification and Authentication
The IA control family requires unique identification and strong authentication. SDOS provides this at the AI agent boundary:
- SDOS-IA-01 satisfies IA-3 (Device Identification and Authentication) — cryptographically verified unique identity for every agent operating in a governed session.
- SDOS-IA-02 satisfies IA-9 (Service Identification and Authentication, High baseline only) — module identity is verified before activation, ensuring no unregistered component executes. Note: NIST SP 800-53 IA-2 governs human user authentication and is out of scope; AI agent NPE authentication is correctly addressed under IA-9. IA-9 is not required at Low or Moderate baselines.
Full Mapping Table¶
| NIST SP 800-53 Rev 5.2.0 Control | SDOS Controls | Mapping Strength | FedRAMP Level | Notes |
|---|---|---|---|---|
| AC-2 Account Management | IA-01, IA-02, GV-01 | Partial — Identity Verification at Activation | Cryptographic identity verification + config-governed activation address the runtime identity and access scope aspects of AC-2 at the AI agent layer. AC-2's full scope includes account provisioning, periodic review, de-provisioning, and disabling — account lifecycle management obligations outside SDOS's operational boundary. | |
| AC-3 Access Enforcement | GV-01, GV-03, EN-01 | Strong | Low/Mod/High | Config-governed activation + default-deny + pre-egress enforcement |
| AC-6 Least Privilege | GV-03, AD-01, RM-03 | Strong | Mod/High | Default-deny + risk-floor binding = least-privilege enforcement at dispatch. AC-6 is not in the FedRAMP Low baseline. |
| AC-6(1) Authorize Access to Security Functions | GV-02, RM-03 | Partial — Capability-Tier Restriction | Risk-tiered model selection and risk-floor binding restrict high-capability AI operations to appropriate risk tiers — a functional analog to AC-6(1)'s explicit authorization requirement for security function access. AC-6(1) expects a named authorization mechanism for specific security functions; SDOS implements this as a risk-classification gate rather than an explicit function-authorization list. | |
| AC-17 Remote Access | EN-01, EN-02, IA-01 | Partial — agent scope | Low/Mod/High | Pre-egress enforcement + identity verification cover AI agent remote operations |
| AU-2 Event Logging | AU-01 | Strong | Low/Mod/High | Per-invocation audit record captures every agent access event |
| AU-3 Content of Audit Records | AU-01, IA-01 | Strong | Low/Mod/High | Structured records include agent identity, operation type, risk classification, outcome, and timestamp |
| AU-9 Protection of Audit Information | AU-02 | Strong | Low/Mod/High | Append-only log integrity directly implements AU-9's tamper-protection requirement at the AI agent audit layer. EN-04 (tamper-evident egress) addresses non-repudiation of output records (AU-10), not audit store protection — it is mapped under AU-10, not AU-9. |
| AU-9(2) Store Audit Records in Separate Physical System | AU-03 | Partial — Substrate-Dependent | High | Dual audit trail provides the structural pattern. AU-9(2)'s "separate physical system" requirement is satisfied only when the two repositories are deployed in physically or logically separated trust domains with independent administrative control. SDOS produces the dual-write behavior; physical/administrative separation is a deployment-tier obligation. Note: AU-9(2) is in the FedRAMP High baseline only; the Moderate baseline includes AU-9 and AU-9(4), not AU-9(2). |
| AU-10 Non-Repudiation | EN-04, AU-01 | Strong | High | Tamper-evident egress audit + per-invocation records provide non-repudiable evidence. Note: AU-10 is in the FedRAMP High baseline only; it is not required at Low or Moderate. |
| AU-11 Audit Record Retention | AU-02, AU-03 | Partial — structural only | Low/Mod/High | Append-only integrity + dual trail provide structural foundation; retention schedule is a deployment obligation |
| AU-12 Audit Record Generation | AU-01, EN-04 | Strong | Low/Mod/High | Per-invocation generation + governed egress audit = complete record generation at AI agent layer |
| CM-2 Baseline Configuration | IN-01, GV-01 | Strong | Low/Mod/High | Governance baseline integrity verification + config-governed activation = maintained baseline |
| CM-3 Configuration Change Control | IN-01, IN-02 | Strong | Mod/High | Baseline drift detection + system halt = automated change detection and response |
| CM-6 Configuration Settings | GV-01, GV-03 | Strong | Low/Mod/High | Policy-governed activation settings enforce security configuration |
| CM-7 Least Functionality | GV-01, GV-03, AD-01 | Strong | Low/Mod/High | Only explicitly configured modules activate — no default or implicit functionality |
| CM-8 System Component Inventory | IA-02, IN-03 | Strong | Low/Mod/High | Verified module identity + manifest integrity = verified component inventory at activation |
| IA-2 Identification and Authentication (Organizational Users) | — | Out of Scope — Non-Person Entity | Low/Mod/High | NIST SP 800-53 IA-2 governs authentication of organizational users. AI agents are non-person entities (NPEs); their authentication is addressed under IA-9. SDOS does not authenticate human users. |
| IA-9 Service Identification and Authentication | IA-01, IA-02 | Strong | High | IA-9 governs identification and authentication of services and processes acting on behalf of users — the correct NIST SP 800-53 control for AI agent NPE authentication. SDOS-IA-01 (cryptographically verified agent identity) and SDOS-IA-02 (verified module identity) directly satisfy IA-9 at the AI agent boundary. Note: IA-9 is in the FedRAMP High baseline only; it is not required at Low or Moderate. |
| IA-3 Device Identification and Authentication | IA-01 | Partial — Substrate-Dependent | Mod/High | Cryptographically verified agent identity provides device-equivalent authentication at the AI agent boundary when SDOS is deployed on a TEE-backed substrate. Without hardware-rooted attestation, IA-3 is satisfied at the logical-device layer; full IA-3 satisfaction is substrate-dependent. |
| IA-5 Authenticator Management | IA-01, GV-04 | Partial — Identity Verification at Activation | Cryptographic identity verification + cross-module continuity address runtime authenticator integrity at the AI agent layer. IA-5's full scope includes authenticator issuance, rotation schedules, revocation, and protection — authenticator lifecycle management obligations outside SDOS's operational boundary. | |
| SI-2 Flaw Remediation | IN-01, IN-02 | Partial — governance scope | Low/Mod/High | Baseline integrity + drift detection cover governance configuration; general patch management is infrastructure-layer |
| SI-3 Malicious Code Protection | IN-03, GV-01 | Partial — module scope | Low/Mod/High | Module manifest integrity + config-governed activation provide AI module integrity; general malware protection is endpoint-layer |
| SI-4 System Monitoring | AU-01, IN-01, IN-02 | Partial — agent layer | Low/Mod/High | Per-invocation audit + baseline monitoring cover AI agent operations; general network monitoring is infrastructure-layer |
| SI-7 Software, Firmware, and Information Integrity | IN-01, IN-02, IN-03 | Partial — Governance Configuration Scope | Mod/High | Governance baseline integrity verification (IN-01), drift detection (IN-02), and module manifest integrity (IN-03) verify the integrity of SDOS governance configuration and module manifests. SI-7's full scope includes host OS, container, and firmware integrity — these are infrastructure-layer obligations outside SDOS operational boundary. |
| SI-12 Information Management and Retention | AU-02, AU-03 | Partial — structural only | Low/Mod/High | Append-only integrity + dual trail provide the technical foundation; retention policy is an organizational obligation |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | CM-2/CM-6/CM-7: baseline configuration and least functionality |
| SDOS-GV-02 — Governance-Tiered Model Selection | AC-6(1): authorized access to security functions by risk tier |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | AC-6: least-privilege foundation |
| SDOS-GV-04 — Cross-Module Governance Continuity | IA-5: authenticator management across module boundaries |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | AC-3: access enforcement independent of system behavior |
Risk Management (RM)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | AC-6: risk-based access tiering at execution |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | AC-6(1): capability allocation proportional to risk |
| SDOS-RM-03 — Risk-Floor Model Binding | AC-6: minimum capability floor as access restriction |
Enforcement (EN)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | AC-3/AC-17: access enforcement at execution boundary |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | AC-3: secondary enforcement at module boundary |
| SDOS-EN-03 — Fail-Closed Degradation | SI-4/CP: operational resilience posture |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | AU-10 (High only)/AU-12: non-repudiable output records |
Identity and Attestation (IA)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | IA-9 (High only): service identification and authentication at AI agent boundary; IA-3: device-equivalent authentication (substrate-dependent) |
| SDOS-IA-02 — Attested Module Identity | IA-9 (High only)/CM-8: module identification before activation and component inventory |
Audit (AU)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | AU-2/AU-3/AU-12: audit event logging and record content |
| SDOS-AU-02 — Append-Only Audit Log Integrity | AU-9: protection of audit information (EN-04 maps to AU-10, not AU-9) |
| SDOS-AU-03 — Dual Audit Trail | AU-9(2) (High only)/AU-11: independent storage and retention |
Integrity (IN)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | CM-2/SI-7: baseline and software integrity |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | CM-3/SI-7: change detection with automated response |
| SDOS-IN-03 — Module Manifest Integrity | CM-8/SI-3: component inventory and module integrity |
Admission (AD)¶
| Control | FedRAMP Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | AC-6/CM-7: least privilege and least functionality |
FedRAMP Tailored Applicability¶
SDOS controls are also applicable to FedRAMP Tailored baselines for low-impact SaaS offerings (LI-SaaS). The control families with the strongest SDOS alignment — AU, AC, IA, and CM — are all represented in the FedRAMP Tailored baseline.
Note on FedRAMP Program Evolution¶
FedRAMP launched the FedRAMP 20x initiative in 2025, introducing significant changes to the authorization process including automated assessment approaches and updated CSP documentation requirements. The control baseline mapped in this document (NIST SP 800-53 Rev 5.2.0) remains the technical foundation under FedRAMP 20x. Organizations pursuing FedRAMP authorization should monitor GSA and OMB guidance at fedramp.gov for current process requirements, as authorization workflows continue to evolve.
Note on NIST AI RMF Alignment¶
SDOS's primary mapping target is NIST AI RMF 1.0. Since FedRAMP Rev 5 is based on NIST SP 800-53 Rev 5.2.0, there is significant structural coherence between the two. Organizations using SDOS within a FedRAMP environment benefit from the same control set satisfying both the AI governance requirements of NIST AI RMF and the federal authorization requirements of FedRAMP.
The complete NIST AI RMF mapping is available at: SDOS Control Catalog and Reference Document v1.3
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, and ISO 42001. For organizations subject to multiple frameworks, SDOS controls address overlapping technical requirements simultaneously.
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 FedRAMP requirements: [email protected]
SDOS Runtime Governance Framework — FedRAMP Revision 5 Alignment. Version 1.4. Published 2026-05-03. Last updated 2026-05-12.