What the Guidance Is and Who Produced It
The April 15, 2024 advisory—formally titled "Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems"—was jointly authored by the National Security Agency, the Cybersecurity and Infrastructure Security Agency, the Federal Bureau of Investigation, the Australian Signals Directorate, the Canadian Centre for Cyber Security, New Zealand's National Cyber Security Centre, and the UK's National Cyber Security Centre. [CSI: Deploying AI Systems Securely, media.defense.gov, April 15, 2024]
The seven-partner authorship matters for how to read the document. This is not aspirational policy drafted by a policy office; it reflects operational experience from signals intelligence and national cybersecurity organizations that collectively monitor adversarial exploitation of AI-enabled systems at scale. The advisory is not theoretical. Where it describes threat patterns, those patterns have been observed. Where it recommends controls, those controls were chosen because they address documented gaps in how production AI deployments are actually secured.
The scope is deployment security, not model development or algorithmic governance. The document addresses what happens after a model is built, trained, and validated—the phase between development and operational fielding that traditional software security frameworks were not designed to handle, and where DoD programs are most exposed. A Risk Management Framework (RMF) authorization was designed for software whose behavior is determined by code. An AI system's effective behavior is also determined by the data it receives, the environment it operates in, and how its outputs are interpreted—none of which an ATO captures once a system leaves the lab.
The Four Principal Attack Surfaces
The guidance organizes the threat model around four categories of adversarial action against deployed AI systems.
Adversarial inputs. Inputs crafted to cause misclassification, incorrect detections, or manipulated outputs from the model inference pipeline. In defense applications, this is directly relevant to any system where adversaries can influence what the sensors see: imagery fed to an AI-enabled targeting system, signals fed to an EW response system, or sensor data fed to an autonomous platform's perception stack. The specific form of adversarial input depends on the modality—visual, acoustic, radio frequency, or text—but the underlying principle is the same: a production AI system in an adversarial environment will encounter inputs that were not in its training distribution, some of which were deliberately designed to exploit the gap.
Data and model poisoning. Manipulation of the data or model artifacts that shape what the system has learned. Relevant to any program with continuous learning, periodic retraining on operational data, or vendor-supplied model updates. An AI system that incorporates new training data from field operations is only as trustworthy as the integrity of that data pipeline. An update that introduces a backdoor or a degraded capability can propagate from one retraining cycle to every deployment derived from it.
Model and information extraction. Queries designed to extract model structure, training data, or sensitive operational information from inference APIs. In a defense context, an adversary who can send repeated queries to an AI system can potentially reconstruct the model's decision logic, infer classified patterns in the training data, or identify conditions under which the system produces exploitable outputs. This applies to any system with an exposed inference endpoint—including edge deployments that may be captured physically.
Supply chain compromise. Compromised model weights, ML frameworks, datasets, or development toolchains delivered through the acquisition and integration pipeline. A pre-trained foundation model obtained from a commercial provider, a PyTorch update installed via an automated dependency management pipeline, a training dataset with corrupted labels—each is a supply chain vector with no direct analog in traditional software acquisition. The guidance specifically calls out the risk that AI components from commercial sources may carry security assumptions, training data provenance limitations, or intended behaviors that were not designed for the defense context.
Key Security Controls and Their Acquisition Implications
The guidance recommends controls organized around three phases of deployment: before the AI system goes live, while it operates, and when it is updated.
Before deployment: The guidance calls for threat modeling the AI system specifically—identifying which of the four attack surfaces are in scope, which components handle sensitive inputs, what failure modes are operationally acceptable, and where human override is required. This is a different exercise from a standard system security plan, and it produces documentation that program offices currently do not have a standard format for. The most practical acquisition implication is this: requiring vendors to deliver a structured AI System Card as part of the technical data package. An AI System Card documents training data provenance, known performance limitations, adversarial test results, and the operational envelope within which the system was evaluated. Without one, program offices cannot accurately assess what they are accepting at milestone or fielding review.
Model and artifact protection: The guidance treats model weights as security-sensitive artifacts requiring access controls, integrity verification, and audit logging throughout the deployment lifecycle—including transit to edge deployments and over-the-air updates. The analogy the document draws is to firmware: any update pathway that delivers new model weights to a fielded system without cryptographic integrity verification is an attack surface. That is the correct engineering standard, and most defense AI programs are not currently meeting it for model updates even when they are meeting it for software patches.
The guidance also explicitly addresses the inference environment: the compute infrastructure where the model runs should be isolated from the development and training environment, and from general-purpose IT infrastructure on the same network. This has practical implications for programs that share computing resources across AI development, validation, and production operation—a common pattern in programs that moved fast to field capability and have not separated environments.
Operational monitoring: Once deployed, a model's effective performance can degrade without any change to the code—through environmental shift, input distribution change, or adversarial conditioning of production data. The guidance recommends monitoring model input and output distributions in operation, not just system-level uptime and error logs. A system reporting clean infrastructure health metrics while its model produces systematically degraded outputs has a security and operational problem that traditional IT monitoring does not surface. Defining the monitoring requirements—what distribution metrics, what alert thresholds, what triggers human review—is a program management responsibility, and it needs to be in the requirements baseline and funded as infrastructure, not added as a post-fielding enhancement.
Supply chain controls: The guidance calls for treating ML frameworks, pre-trained model weights, and training datasets as supply chain components requiring the same provenance and integrity verification applied to software packages under Executive Order 14028 and CMMC implementation. This includes software bills of materials (SBOMs) that explicitly cover model weights and their version lineage, not just software dependencies. Most current defense SBOM implementations do not include model artifacts. Programs that have achieved CMMC certification but have not inventoried their AI component supply chain have a gap in their actual security posture even if their documentation reflects compliance.
What Program Managers Need to Do
The guidance creates a set of concrete actions that program offices can execute against existing programs without waiting for policy updates.
Map the guidance to current contract requirements. Review performance work statements and system specifications against the four attack surfaces and key controls. Where the vendor is not required to demonstrate adversarial input resistance, model integrity controls, or supply chain provenance, that is a gap. Some gaps will require contract modifications; others can be addressed in existing data deliverable requirements by specifying what the vendor must document and when.
Require AI System Cards at milestones. The most important new deliverable is a structured document covering model provenance, training data lineage, known performance limitations, and adversarial test scope. Defining the required format in the contract—rather than accepting whatever documentation the vendor provides—determines whether that document is useful for oversight purposes or a compliance checkbox.
Incorporate AI-specific controls into the RMF package. The ATO process needs to address the four attack surfaces as explicitly as it addresses network segmentation, access control, and vulnerability management. Program Security Engineers and Authorizing Officials who have not previously worked with AI systems may need specific technical assistance scoping these controls. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) provides a complementary structure that can be mapped to NIST SP 800-53 for the authorization package.
Scope model monitoring as an operational requirement. Monitoring model output distributions against validated baselines is not a nice-to-have; for a system with operational authority, it is the mechanism by which the program can claim continued assurance after initial fielding. This needs to be a stated system requirement—traceable through design and test—not an infrastructure component added after operational testing.
Brief leadership on AI supply chain exposure. Most PEOs have received briefings on software supply chain security under EO 14028 and CMMC. Very few have received a specific briefing on ML-specific supply chain vectors: compromised model weights, poisoned training datasets, or malicious ML framework updates. That is an open risk for most programs integrating commercial AI components, and it should be explicitly identified in the program protection plan.
Three Questions Before the Next Program Review
Regardless of where a program is in the acquisition lifecycle, three questions establish the current security posture against the NSA–CISA threat model:
- Has the system been tested against adversarially crafted inputs? If the answer is that the system has not been red-teamed for adversarial ML attacks, the program does not know how it behaves in the adversarial environment it is designed to operate in. That is not a compliance finding in isolation; it is operational risk that should be documented and briefed.
- Is there a monitoring framework that detects model performance degradation in operation? If no one has defined what distribution metrics to track and what thresholds trigger human review, the program is flying blind on whether the deployed model is performing as validated.
- Is model update authority controlled and audited? If model weights can be updated by a vendor or a pipeline without a formal change control process, the program has an uncontrolled modification vector that the authorization package does not account for.
A "no" on any of these does not automatically require stopping work. It does require documenting the risk, briefing decision authority, and setting a timeline for remediation proportional to the system's operational authority and adversarial exposure.
Integration with Zero Trust and CMMC
The NSA–CISA guidance complements rather than replaces the DoD Zero Trust Strategy and the CMMC 2.0 framework. Zero Trust architecture provides the network segmentation, identity verification, and least-privilege access control that the guidance identifies as foundational: an AI inference pipeline that is accessible from the general enterprise network because microsegmentation was not implemented is more exposed on every attack surface the guidance describes. CMMC 2.0 covers the broader information security posture required to handle controlled unclassified information and federal contract information; the AI guidance adds ML-specific controls that CMMC's current control set does not address.
For programs pursuing CMMC Level 2 or Level 3 certification, the AI guidance should be treated as a technical supplement that extends coverage to the ML-specific attack surface. Achieving CMMC certification without incorporating AI-specific controls means the program's actual security posture does not match what the certification implies for AI-enabled components.
Sources and further reading
- NSA, CISA, FBI, ASD, CCCS, NCSC-NZ, NCSC-UK. "Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems." Cybersecurity Information Sheet, April 15, 2024. media.defense.gov.
- CISA. "Cybersecurity and Infrastructure Security Agency Roadmap for Artificial Intelligence." November 2023. cisa.gov.
- NIST. "Artificial Intelligence Risk Management Framework (AI RMF 1.0)." January 2023. ai.nist.gov.
- DoD CDAO. "DoD AI Adoption Strategy." November 2023. ai.mil.
- Executive Order 14028. "Improving the Nation's Cybersecurity." May 12, 2021. federalregister.gov.
- NIST SP 800-53 Rev. 5. "Security and Privacy Controls for Information Systems and Organizations." September 2020. csrc.nist.gov.
Spartan X's Arbiter platform addresses one of the hardest problems the NSA–CISA–FBI framework identifies: establishing continuous behavioral assurance for AI systems operating in environments where the model itself is a target. Defense programs facing ATO renewals and program office audits increasingly need the ability to demonstrate sustained model integrity across operational cycles, not just at initial fielding. That is the capability Arbiter is designed to provide—and the gap the guidance makes explicit.
