Protocol note: SWT3 is an industry-agnostic cryptographic witness protocol. The evidence described in this guide is identical regardless of deployment environment or data classification level. This walkthrough maps NIST SP 800-53 controls (the foundation of CMMC v2.0) to SWT3 procedures so assessors can verify AI system compliance using independently verifiable cryptographic evidence.
Contents
1. AI Systems in CMMC Assessment Scope 2. NIST 800-53 to SWT3 Mapping Overview 3. Access Control (AC) 4. Awareness and Training (AT) 5. Audit and Accountability (AU) 6. Security Assessment (CA) 7. Configuration Management (CM) 8. Incident Response (IR) 9. Planning (PL) 10. Program Management (PM) 11. Risk Assessment (RA) 12. System Acquisition (SA) 13. System and Communications Protection (SC) 14. System and Information Integrity (SI) 15. Witness Anchor Anatomy 16. Integration with SSP and POA&M Artifacts 17. DFARS 252.204-7012 Connection1. AI Systems in CMMC Assessment Scope
CMMC v2.0 does not carve out AI systems from assessment scope. Any system that stores, processes, or transmits controlled information falls under the assessment boundary, regardless of whether it uses traditional rule-based logic or machine learning inference. When an organization deploys an AI model that touches data within the authorization boundary, that model becomes an assessed component of the information system.
The practical question for assessors is not whether AI falls in scope, but how to gather sufficient evidence that AI-specific risks are managed. Traditional STIG checklists and vulnerability scans do not capture model drift, inference authorization, training data provenance, or algorithmic fairness. SWT3 witness anchors fill this gap by producing cryptographic evidence at the procedure level, each tied to a specific NIST 800-53 control.
When AI enters the assessment boundary
- Controlled data processing: The model ingests, generates, or transforms data subject to applicable data classification requirements
- Controlled data-adjacent decision-making: The model's output directly influences decisions about classified or controlled assets, personnel, or contracts
- Shared infrastructure: The model runs on the same authorization boundary as controlled data systems, even if the model itself does not directly process controlled data
- Supply chain integration: A service provider uses AI in delivering services within the authorization boundary
2. NIST 800-53 to SWT3 Mapping Overview
The SWT3 protocol maps 30 AI-specific procedures to 20 NIST SP 800-53 controls across 12 CMMC practice families. Each procedure generates a witness anchor -- a cryptographic attestation record with a SHA-256 fingerprint, clearing level, and immutable timestamp. These anchors constitute machine-verifiable evidence that a specific control requirement was evaluated at a specific point in time.
| NIST 800-53 Control | SWT3 Procedure(s) | Count | CMMC Family |
|---|---|---|---|
| AC-4 Information Flow | AI-ACC.1 | 1 | Access Control |
| AT-2 Literacy Training | AI-GOV.2 | 1 | Awareness & Training |
| AU-5 Audit Response | AI-VIO.1 | 1 | Audit & Accountability |
| AU-10 Non-repudiation | AI-AUDIT.2 | 1 | Audit & Accountability |
| AU-11 Audit Retention | AI-LOG.1 | 1 | Audit & Accountability |
| CA-2 Assessments | AI-CYBER.1 | 1 | Security Assessment |
| CM-2 Baseline Config | AI-BASE.1 | 1 | Config Management |
| CM-3 Change Control | AI-AUTO.2, AI-MDL.3 | 2 | Config Management |
| CM-6 Config Settings | AI-ENV.1 | 1 | Config Management |
| CM-8 Component Inventory | AI-SBOM.1 | 1 | Config Management |
| IR-6 Incident Reporting | AI-INCIDENT.1, AI-IR.1 | 2 | Incident Response |
| PL-8 Security Architecture | AI-HW.1, AI-HW.3 | 2 | Planning |
| PM-9 Risk Strategy | AI-IMPACT.1, AI-RISK.1 | 2 | Program Management |
| PM-28 Risk Framing | AI-GOV.1 | 1 | Program Management |
| RA-3 Risk Assessment | AI-DPIA.1, AI-FAIR.2 | 2 | Risk Assessment |
| RA-5 Vulnerability Monitoring | AI-REDTEAM.1 | 1 | Risk Assessment |
| SA-4 Acquisition Process | AI-SUPPLY.1 | 1 | System Acquisition |
| SC-28 Data Protection | AI-SEC.1, AI-SEC.2 | 2 | System/Comms Protection |
| SI-4 System Monitoring | AI-DRIFT.1, AI-INF.1, AI-INF.2, AI-PERF.1, AI-ROBUST.1 | 5 | System/Info Integrity |
| SI-7 Software Integrity | AI-MDL.5, AI-MDL.6, AI-MDL.7 | 3 | System/Info Integrity |
Total: 20 controls, 30 procedures across 12 CMMC practice families.
3. Access Control (AC)
CMMC requirement
Organizations must enforce information flow policies that prevent unauthorized disclosure of controlled data. When an AI system processes sensitive information, the access control boundary extends to the inference pipeline: who can query the model, what data the model can access, and where the model's outputs are routed. AC-4 requires that information flow enforcement mechanisms prevent unauthorized information flow beyond the authorization boundary.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| AC-4 | AI-ACC.1 | Pre-Inference Authorization | Records whether each inference request was authorized before execution, including the authorization_id, requesting agent, and clearing level applied to the response |
How the assessor evaluates this
Request AI-ACC.1 anchors for the assessment period. Each anchor records the authorization decision that occurred before model inference. Verify that the authorization_id field references a valid access control policy, and confirm that no inferences were executed without a corresponding authorization anchor. Cross-reference the clearing levels applied to responses -- the clearing level should be commensurate with the sensitivity of the input data as determined by the applicable classification scheme.
Data sensitivity considerations
When an AI model processes sensitive or controlled data, every inference constitutes an information flow event. The clearing level in the witness anchor should match the sensitivity classification of the input data. A model ingesting highly sensitive data at clearing level 0 (Analytics) would represent an access control failure, because the clearing level does not match the sensitivity of the data being processed.
Missing authorization for batch inference jobs
Organizations frequently run batch AI processing overnight. These jobs skip the interactive authorization workflow, resulting in inferences with no AI-ACC.1 anchor. Remediation: implement service account authorization that mints anchors for automated workloads.
4. Awareness and Training (AT)
CMMC requirement
Personnel who interact with AI systems in regulated environments must receive training on AI-specific risks, including prompt injection, data poisoning, model manipulation, and unintended data disclosure through model outputs. AT-2 requires that this training is documented and current.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| AT-2 | AI-GOV.2 | AI Governance Training | Records completion of AI-specific security awareness training, including training date, personnel identifier, and curriculum version |
How the assessor evaluates this
Request AI-GOV.2 anchors covering all personnel with access to AI systems in the authorization boundary. Verify that training was completed within the past 12 months and that the curriculum version addresses current threats. The anchor's observation field should reference the training module identifier. Cross-check against the organization's personnel roster to identify anyone with AI system access who lacks a corresponding training anchor.
Data sensitivity considerations
Personnel operating AI systems that process sensitive data face unique risks that general cybersecurity awareness training does not cover. A machine learning engineer who does not understand that model weights can memorize sensitive data fragments may inadvertently export a fine-tuned model outside the boundary. AT-2 training for AI operators should cover data sensitivity recognition, model extraction risks, and proper handling of AI-generated documents that may contain controlled information.
Generic cybersecurity training with no AI module
Organizations check the AT-2 box with annual security awareness training that never mentions AI. When AI systems enter the boundary, the training curriculum must be updated to address AI-specific attack vectors. Look for AI-GOV.2 anchors that reference a distinct AI training module, not a general security awareness course.
5. Audit and Accountability (AU)
CMMC requirement
AI systems must generate audit records sufficient for after-the-fact investigation of security incidents, maintain non-repudiation of AI-generated outputs, and retain audit data for the prescribed retention period. In regulated environments, this means every AI inference that touches controlled data must be traceable, attributable, and preserved.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| AU-5 | AI-VIO.1 | Violation Detection | Records policy boundary violations detected during AI operations, including the violated policy, severity, and corrective action taken |
| AU-10 | AI-AUDIT.2 | External Timestamp Attestation | Provides RFC 3161-compliant external timestamps on witness anchors, establishing non-repudiation through a trusted third-party time-stamping authority |
| AU-11 | AI-LOG.1 | Inference Logging | Records the retention status of inference logs, including log location, retention period, and whether logs are protected against modification |
How the assessor evaluates this
The AU family is where SWT3 delivers its strongest value to assessors. Traditional audit evidence for AI systems is often limited to application logs that are easily modified and lack cryptographic integrity. SWT3 anchors provide three layers of assurance:
- AI-VIO.1: Review violation anchors to confirm that policy boundary enforcement is active and that violations trigger documented responses
- AI-AUDIT.2: Verify that external timestamps use RFC 3161 from a trusted TSA. This establishes non-repudiation independent of the organization's own systems
- AI-LOG.1: Confirm that inference logs are retained for the period required by the System Security Plan and that the retention anchor records the actual storage location and protection mechanism
Data sensitivity considerations
Applicable retention schedules may require that AI inference logs involving controlled data be retained for specific periods depending on the data classification. AI-LOG.1 anchors should reference the applicable retention schedule. The anchor's observation field should identify which retention schedule applies, as different data classifications may carry different retention requirements.
Inference logs with no integrity protection
Organizations store AI inference logs in plain text files or application databases with no write protection. An insider or compromised process can modify logs to conceal unauthorized data access. AI-LOG.1 anchors that reference integrity-protected storage (append-only, cryptographically signed) satisfy AU-11 far more convincingly than a pointer to an unprotected log directory.
6. Security Assessment (CA)
CMMC requirement
The organization must assess AI system security controls at a defined frequency and document the results. For AI systems in the authorization boundary, this includes not just traditional vulnerability assessments but evaluations of model robustness, adversarial resilience, and operational behavior under stress conditions.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| CA-2 | AI-CYBER.1 | AI Cybersecurity Assessment | Records the execution and results of AI-specific security assessments, including assessment scope, methodology, and identified weaknesses |
How the assessor evaluates this
Request AI-CYBER.1 anchors spanning the assessment period. Each anchor should reference a structured assessment that goes beyond infrastructure-level scanning to include AI-specific evaluation criteria: adversarial input testing, model robustness under distribution shift, and prompt injection resistance. Verify that assessment frequency aligns with the organization's Continuous Monitoring Plan.
Data sensitivity considerations
AI systems processing sensitive data face a threat landscape that includes adversarial actors specifically targeting model behavior to extract controlled information. A CA-2 assessment for an AI system in a regulated environment should include testing for training data extraction attacks, membership inference attacks, and prompt-based data exfiltration. The AI-CYBER.1 anchor should document that these AI-specific threat scenarios were evaluated, not just that a standard vulnerability scan was executed.
7. Configuration Management (CM)
CMMC requirement
AI systems must maintain documented baseline configurations, enforce change control for model updates, track configuration settings for inference environments, and maintain a complete inventory of AI components including models, frameworks, libraries, and training datasets. This is one of the most complex CMMC families for AI systems because the "configuration" of a machine learning model is fundamentally different from traditional software.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| CM-2 | AI-BASE.1 | Baseline Configuration | Records the approved baseline state of an AI model, including model version, framework version, and configuration parameters at the time of authorization |
| CM-3 | AI-AUTO.2 | Autonomous Generation Depth | Witnesses the depth and scope of autonomous content generation, detecting when model behavior deviates from approved operational parameters |
| CM-3 | AI-MDL.3 | Model Versioning | Records model version transitions, including the previous version, new version, change justification, and approval authority |
| CM-6 | AI-ENV.1 | Runtime Environment | Documents the runtime environment configuration including GPU allocation, memory limits, inference timeout settings, and environment variables |
| CM-8 | AI-SBOM.1 | AI Software Bill of Materials | Records the complete dependency tree of an AI system: model provenance, framework versions, library dependencies, and data pipeline components |
How the assessor evaluates this
Configuration management for AI systems requires assessors to think beyond traditional CM practices. A model's "configuration" includes its weights (billions of parameters), hyperparameters, framework version, and the data it was trained on. The assessment should proceed in layers:
Verify the baseline exists (CM-2 / AI-BASE.1)
Request the AI-BASE.1 anchor that establishes the approved operational baseline. This anchor should have been minted when the model received its Authorization to Operate. Compare the baseline anchor's fingerprint to the model's current state. If the model has drifted from baseline without a corresponding CM-3 change record, this is a configuration management finding.
Review change history (CM-3 / AI-MDL.3, AI-AUTO.2)
Pull all AI-MDL.3 anchors to reconstruct the model's version history. Each version transition should reference a change request, approval authority, and testing evidence. AI-AUTO.2 anchors reveal whether the model's autonomous behavior stayed within approved boundaries between version changes.
Validate the runtime environment (CM-6 / AI-ENV.1)
AI-ENV.1 anchors document the inference environment at the time each anchor was minted. Compare environment configurations across time to detect unauthorized changes to GPU allocation, library versions, or security-relevant environment variables.
Confirm component inventory (CM-8 / AI-SBOM.1)
The AI-SBOM.1 anchor should catalog every component in the AI pipeline. Cross-reference against the organization's system-level SBOM. Look for components in the AI SBOM that are not reflected in the system inventory, which would indicate incomplete CM-8 compliance.
Data sensitivity considerations
Model updates in regulated environments carry elevated risk. A model fine-tuned on controlled data incorporates that data into its weights. If the fine-tuned model is later exported, moved to a lower-boundary system, or shared with personnel who lack appropriate access, the embedded data moves with it. CM-3 change control for AI models in regulated environments must include a data sensitivity impact assessment for every model transition. AI-MDL.3 anchors should reference this assessment.
No AI-SBOM.1 for third-party models
Organizations deploy commercial or open-source models (GPT-4, Llama, Mistral) without maintaining a component inventory. The model itself is a component. Its training data provenance, framework dependencies, and API integration libraries must all appear in the SBOM. An AI system with no AI-SBOM.1 anchor fails CM-8.
8. Incident Response (IR)
CMMC requirement
AI-specific incidents must be reported through the same channels as traditional security incidents, but they require additional classification criteria. A model that begins generating controlled data fragments in its outputs to unauthorized users is an incident. A model that exhibits sudden performance degradation may indicate data poisoning. The organization must have procedures for identifying, classifying, and reporting AI-specific incidents.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| IR-6 | AI-INCIDENT.1 | AI Incident Classification | Records the classification and initial triage of AI-specific security incidents, including incident category, severity, affected models, and initial containment actions |
| IR-6 | AI-IR.1 | AI Incident Response | Documents the response actions taken for AI incidents, including investigation findings, root cause analysis, and corrective measures applied |
How the assessor evaluates this
Review the organization's Incident Response Plan for AI-specific incident categories. Then cross-reference against AI-INCIDENT.1 and AI-IR.1 anchors. If the organization has experienced no AI incidents during the assessment period, verify that the IRP at least defines AI incident types and classification criteria. The absence of incident anchors is acceptable only if the IRP demonstrates preparedness; an organization that has no AI incident categories in their IRP and no incident anchors has a gap regardless.
Data sensitivity considerations
Applicable regulations may require reporting cyber incidents involving controlled data within specific timeframes. If an AI model leaks controlled information through its outputs, this constitutes a cyber incident subject to the applicable reporting requirements. AI-INCIDENT.1 anchors that timestamp the initial detection and classification of such incidents provide evidence that the organization met the reporting timeline. Assessors should verify that the time between the AI-INCIDENT.1 anchor and the required notification falls within the prescribed window.
9. Planning (PL)
CMMC requirement
The security architecture must account for AI system components, including the hardware infrastructure that supports model inference. PL-8 requires that the system's security architecture reflects the actual deployed topology, which for AI systems includes GPU clusters, model serving infrastructure, and hardware accelerators.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| PL-8 | AI-HW.1 | Hardware Attestation | Records the hardware platform executing AI inference, including GPU model, driver version, firmware hash, and trusted execution environment status |
| PL-8 | AI-HW.3 | Hardware Compliance Profile | Documents whether the hardware platform meets the security requirements specified in the security architecture, including FIPS validation status and FedRAMP authorization |
How the assessor evaluates this
Request AI-HW.1 and AI-HW.3 anchors and compare the documented hardware profile against the organization's System Security Plan. The hardware running AI inference should appear in the SSP's system boundary diagram. If the organization is running inference on cloud GPU instances (AWS p5, Azure NC, GCP A3), verify that the cloud provider's authorization level matches the sensitivity of the data being processed.
Data sensitivity considerations
Sensitive data processed on GPU hardware introduces data remanence concerns that traditional CPU-based processing does not. GPU memory is not always cleared between inference requests, and multi-tenant GPU sharing (common in cloud environments) can create cross-tenant data exposure risks. AI-HW.3 anchors should document whether dedicated GPU instances are used for sensitive workloads or whether shared GPU infrastructure is acceptable under the organization's risk acceptance framework.
10. Program Management (PM)
CMMC requirement
The organization must maintain a risk management strategy and risk framing approach that accounts for AI-specific risks. This includes identifying AI systems as risk-bearing components, establishing risk tolerance thresholds for model behavior, and integrating AI risk into the organization's overall risk management framework.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| PM-9 | AI-IMPACT.1 | Impact Assessment | Records the assessed impact of AI system deployment on organizational risk posture, including affected mission functions and worst-case failure scenarios |
| PM-9 | AI-RISK.1 | Risk Quantification | Documents quantified risk scores for AI systems, including probability of adverse outcomes, potential impact magnitude, and risk mitigation effectiveness |
| PM-28 | AI-GOV.1 | AI Governance Framework | Records the existence and version of the organization's AI governance policy, including approval authority, review cycle, and scope of covered systems |
How the assessor evaluates this
Program management is where organizational maturity becomes visible. Request AI-GOV.1 anchors to verify that the organization has an AI governance framework that is current and approved by appropriate authority. Then review AI-IMPACT.1 and AI-RISK.1 anchors for each AI system in the boundary. The risk quantification should reflect AI-specific risk factors, not a generic risk score copied from the system-level risk assessment.
Data sensitivity considerations
AI risk in regulated environments can carry significant operational and legal implications. An AI model that misclassifies data sensitivity levels, improperly routes controlled information, or generates misleading analysis does not just create organizational risk -- it creates risk to the mission. AI-IMPACT.1 anchors for models processing sensitive data should reference the specific functions that depend on the model's output and the consequences of model failure or compromise.
11. Risk Assessment (RA)
CMMC requirement
The organization must conduct risk assessments that include AI-specific threat scenarios and maintain an active vulnerability monitoring program that covers AI attack surfaces. This goes beyond traditional RA-3 risk assessments to include algorithmic bias assessment, adversarial robustness testing, and AI red teaming.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| RA-3 | AI-DPIA.1 | Data Protection Impact Assessment | Records the execution of a DPIA for AI systems processing personal or controlled data, including identified risks, mitigations, and residual risk acceptance |
| RA-3 | AI-FAIR.2 | Fairness Evaluation | Documents bias and fairness evaluation results, including demographic parity metrics, disparate impact ratios, and identified bias vectors |
| RA-5 | AI-REDTEAM.1 | AI Red Team Assessment | Records the scope and findings of adversarial testing against AI systems, including attack techniques used, vulnerabilities discovered, and remediation status |
How the assessor evaluates this
Risk assessment for AI systems requires a fundamentally different approach than infrastructure risk assessment. Review AI-DPIA.1 anchors to confirm that data protection impact assessments specifically address AI processing activities. Check AI-FAIR.2 anchors to verify that bias evaluation covers the populations affected by AI decisions. For AI-REDTEAM.1, verify that adversarial testing was conducted by personnel with AI-specific red team skills, not just traditional penetration testers running automated scanners.
Data sensitivity considerations
AI systems that make decisions affecting access to controlled data (document classification, personnel screening, access recommendations) must be evaluated for bias that could result in discriminatory access decisions. If an AI model systematically denies access to a protected demographic group, this creates both a civil rights issue and an operational effectiveness problem. AI-FAIR.2 anchors in regulated environments should demonstrate that bias evaluation specifically tested for discriminatory outcomes in access-related decisions.
No AI red teaming, only infrastructure penetration testing
Organizations satisfy RA-5 with annual penetration tests that target network infrastructure but never test AI model behavior. An infrastructure pentest will not discover prompt injection vulnerabilities, training data extraction attacks, or model manipulation techniques. AI-REDTEAM.1 anchors that reference only infrastructure testing tools indicate a gap in AI-specific vulnerability assessment.
12. System Acquisition (SA)
CMMC requirement
When acquiring AI systems or AI-enabled services, the organization must include security requirements in acquisition documents and verify that acquired AI components meet those requirements. This extends to any service provider's AI systems that operate within the authorization boundary.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| SA-4 | AI-SUPPLY.1 | AI Supply Chain Verification | Records the provenance and integrity verification of acquired AI components, including model source, training data provenance documentation, and vendor security attestations |
How the assessor evaluates this
Request AI-SUPPLY.1 anchors for every third-party AI component in the organization's boundary. This includes commercial AI APIs (OpenAI, Anthropic, AWS Bedrock), open-source models downloaded from public repositories (Hugging Face, GitHub), and AI components embedded in purchased software products. Each anchor should document the component's provenance, the vendor's security posture, and any restrictions on using the component with controlled data.
Data sensitivity considerations
Many commercial AI APIs route data through infrastructure that is not authorized for processing controlled data. An organization using a commercial LLM API to summarize controlled documents may be transmitting sensitive data to systems outside the authorization boundary. AI-SUPPLY.1 anchors should document whether each AI vendor's infrastructure is authorized for the data classifications the organization processes. If the vendor lacks appropriate authorization, the organization needs a risk acceptance or must use an appropriately authorized alternative.
13. System and Communications Protection (SC)
CMMC requirement
Data at rest that includes AI model weights, training datasets, and inference outputs must be protected commensurate with the sensitivity of the information. For AI systems in regulated environments, SC-28 requires that model artifacts containing sensitive or controlled information are encrypted at rest using validated cryptographic modules.
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| SC-28 | AI-SEC.1 | Model Security Baseline | Records the security configuration of the AI model deployment, including encryption status of model weights, API authentication requirements, and network segmentation |
| SC-28 | AI-SEC.2 | Data Pipeline Security | Documents the security controls applied to the AI data pipeline, including encryption of training data at rest, secure transfer mechanisms, and access controls on data stores |
How the assessor evaluates this
Review AI-SEC.1 anchors to confirm that model weights are encrypted at rest, particularly for models fine-tuned on controlled data. Model weights that have been trained on controlled data contain information derived from that data and should be protected accordingly. Review AI-SEC.2 anchors to verify that the data pipeline -- from training data ingestion through inference output delivery -- maintains encryption throughout the entire flow.
Data sensitivity considerations
A model fine-tuned on controlled data effectively becomes a controlled artifact itself. The model weights encode patterns from the training data, and research has demonstrated that training data can be extracted from model weights through various attack techniques. This means that the model binary must be handled and protected at the same sensitivity level as the training data. AI-SEC.1 anchors for fine-tuned models should reflect the appropriate protection controls for the data sensitivity level, not just general encryption at rest.
Model weights trained on controlled data stored without appropriate markings
Organizations fine-tune models on controlled data but store the resulting model weights as regular application files without appropriate sensitivity markings or handling procedures. Because the weights contain information derived from the training data, they must be treated at the same sensitivity level. Check that AI-SEC.1 anchors for fine-tuned models document appropriate protection and that the model files carry the markings required by the applicable classification scheme.
14. System and Information Integrity (SI)
CMMC requirement
AI systems must be monitored for anomalous behavior, model drift, performance degradation, and integrity violations. This is the largest CMMC family for AI systems, covering 8 SWT3 procedures across two controls. SI-4 addresses continuous monitoring of AI operational behavior, while SI-7 ensures the integrity of model artifacts.
SI-4: System Monitoring
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| SI-4 | AI-DRIFT.1 | Model Drift Detection | Records drift measurements comparing current model behavior to the approved baseline, including statistical distribution metrics and drift severity classification |
| SI-4 | AI-INF.1 | Inference Monitoring | Documents individual inference events, including input characteristics, output classification, latency, and confidence score |
| SI-4 | AI-INF.2 | Inference Quality Tracking | Records aggregate inference quality metrics over time, including accuracy trends, error rates, and quality threshold violations |
| SI-4 | AI-PERF.1 | Performance Monitoring | Documents AI system performance metrics including throughput, latency percentiles, resource utilization, and capacity thresholds |
| SI-4 | AI-ROBUST.1 | Robustness Evaluation | Records the results of robustness testing, including performance under adversarial inputs, edge cases, and distribution shift scenarios |
SI-7: Software and Information Integrity
| Control | SWT3 Procedure | Title | What It Witnesses |
|---|---|---|---|
| SI-7 | AI-MDL.5 | Model Weight Integrity | Records a cryptographic hash of the model weights file, enabling detection of unauthorized modifications to the deployed model |
| SI-7 | AI-MDL.6 | Adapter Stack Verification | Documents the integrity of model adapters (LoRA, QLoRA), including adapter provenance, version, and cryptographic hash |
| SI-7 | AI-MDL.7 | Quantization Verification | Records the quantization parameters applied to a model, including quantization method, bit depth, and the integrity hash of the quantized model binary |
How the assessor evaluates this
System and information integrity is where AI systems diverge most sharply from traditional IT. A traditional server's integrity can be verified with file integrity monitoring tools. An AI model's integrity requires verifying that billions of floating-point parameters have not been modified -- and that the model's behavior has not drifted from its approved operational profile even if the parameters remain unchanged.
For SI-4 (monitoring): Request the full set of AI-DRIFT.1, AI-INF.1, AI-INF.2, AI-PERF.1, and AI-ROBUST.1 anchors for the assessment period. Plot the drift measurements over time. Look for drift events that were detected (anchored) but not remediated. Cross-reference performance monitoring anchors against the organization's SLA thresholds. If performance degradation was detected and anchored but no corrective action was taken, this indicates a monitoring-without-response gap.
For SI-7 (integrity): Request AI-MDL.5 anchors and verify that the recorded model hash matches the currently deployed model. If the model uses adapters (LoRA fine-tuning is common), verify AI-MDL.6 anchors for each adapter. For quantized models deployed on edge or resource-constrained devices, verify AI-MDL.7 anchors match the deployed quantized binary.
Data sensitivity considerations
Integrity monitoring for AI systems in regulated environments must detect model tampering that could cause the AI to mishandle controlled data. A compromised model could be manipulated to downgrade data sensitivity classifications, leak controlled information through seemingly benign outputs, or misclassify incoming data to bypass access controls. AI-MDL.5 anchors provide the first line of defense by detecting unauthorized modifications to model weights. AI-DRIFT.1 anchors provide the second line by detecting behavioral changes that might indicate a more sophisticated attack that modifies model behavior through input manipulation rather than weight modification.
Model deployed without baseline integrity hash
Organizations deploy AI models without recording a SHA-256 hash of the model weights at deployment time. Without AI-MDL.5 as a baseline, there is no way to verify that the model currently running is the model that was authorized. This is the AI equivalent of deploying a server without enabling file integrity monitoring -- a fundamental SI-7 gap.
15. Witness Anchor Anatomy
Every SWT3 procedure generates a witness anchor in a standardized format. Understanding this format allows assessors to independently verify anchor authenticity without relying on the organization's own tools. Here is a sample anchor from an AI model integrity check:
| Segment | Value | Meaning |
|---|---|---|
SWT3-E | Enclave tier | Deployed in a dedicated enclave (typical for regulated environments) |
AWS | Cloud provider | Running on AWS (provider segment reflects the deployment infrastructure) |
AI | UCT domain | AI-specific procedure from the Unified Compliance Taxonomy |
MDL5 | Procedure | AI-MDL.5 -- Model Weight Integrity verification |
PASS | Verdict | Model weights match the authorized baseline hash |
1780752000 | Unix epoch | Timestamp of the attestation (verifiable, immutable) |
a3f7c21d9b04 | Fingerprint | SHA-256 truncated hash of the witness payload (12 hex chars) |
Assessors can verify any anchor independently using the public verification endpoint. Enter the full anchor string and the fingerprint is recomputed from the underlying witness data. A match confirms the anchor has not been tampered with since it was minted.
SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. This formula is published, deterministic, and implemented identically across five programming languages (Python, TypeScript, Rust, C#, Ruby). The assessor does not need to trust the organization's tools to verify anchor integrity.
16. Integration with SSP and POA&M Artifacts
SWT3 witness anchors are designed to feed directly into the artifacts that assessors evaluate during an assessment. They do not replace the System Security Plan, POA&M, or Assessment Report -- they provide the cryptographic evidence layer that supports claims made in those documents.
System Security Plan (SSP)
The SSP describes how each CMMC practice is implemented. For AI systems, the SSP should reference the SWT3 procedures that generate continuous compliance evidence. For example, the CM-2 (Baseline Configuration) section of the SSP should describe how AI-BASE.1 anchors establish and verify the approved model baseline. The assessor can then pull AI-BASE.1 anchors to verify the SSP's claims.
Plan of Action and Milestones (POA&M)
When a SWT3 procedure produces a FAIL verdict, this maps directly to a POA&M entry. An AI-MDL.5 FAIL verdict (model integrity check failed) becomes a POA&M item with a remediation milestone. The anchor's timestamp establishes when the finding was identified, and subsequent PASS anchors document when it was remediated. This creates a complete remediation lifecycle from detection to closure, all with cryptographic evidence.
Assessment Report (AR)
The assessment report can reference specific anchor fingerprints as evidence citations. Rather than writing "the organization demonstrated model integrity monitoring," the assessor can write "AI-MDL.5 anchor a3f7c21d9b04 (minted 2026-06-01T00:00:00Z) confirms model weight integrity for the assessed model." This level of specificity makes assessment findings independently verifiable during quality assurance reviews.
17. DFARS 252.204-7012 Connection
DFARS 252.204-7012 is the contractual clause that obligates organizations handling covered defense information to implement adequate security and report cyber incidents. CMMC v2.0 provides the assessment methodology for verifying compliance with this requirement. SWT3 evidence maps to DFARS requirements through three mechanisms:
Adequate security evidence
DFARS requires "adequate security" as defined in NIST SP 800-171. When AI systems process covered defense information, the 30 SWT3 procedures mapped in this walkthrough provide cryptographic evidence that AI-specific security controls are implemented and operational. This evidence is stronger than traditional self-attestation because each anchor includes a verifiable timestamp and tamper-evident fingerprint.
Incident reporting timeline
DFARS requires reporting cyber incidents to DoD within 72 hours of discovery. For AI-specific incidents, the timestamp on AI-INCIDENT.1 anchors establishes the moment of discovery with cryptographic certainty. This protects both the organization and the government: the organization can prove timely reporting, and the government can verify that incidents were not concealed or delayed.
Subcontractor flow-down
DFARS flows down to subcontractors handling covered defense information. When a subcontractor uses AI systems within the authorization boundary, the prime can require the subcontractor to produce SWT3 witness anchors for the relevant procedures. The assessment can then verify subcontractor AI compliance through anchor verification rather than relying solely on the subcontractor's self-reported compliance status.