What the Guidance Is and Who Produced It
The guidance, formally "Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems," was released April 15, 2024. Its first page lists the authors as NSA's Artificial Intelligence Security Center (AISC), CISA, the FBI, the Australian Signals Directorate's Australian Cyber Security Centre, the Canadian Centre for Cyber Security, New Zealand's National Cyber Security Centre and the UK's National Cyber Security Centre (joint guidance, p. 1).
The authorship matters, but so does the document's own description of itself. It comes from the signals-intelligence, law-enforcement and national cybersecurity agencies of five nations, and it says it expands on the "secure deployment" and "secure operation and maintenance" sections of their 2023 Guidelines for secure AI system development. It is a best-practices sheet, not a standard: "The best practices may not be applicable to all environments, so the mitigations should be adapted to specific use cases and threat profiles." It also says plainly that "AI security is a rapidly evolving area of research" (joint guidance, p. 1).
The scope is deployment, not model development. The practices are "most applicable to organizations deploying and operating externally developed AI systems on premises or in private cloud environments, especially those in high-threat, high-value environments" (p. 2). That describes most defense programs buying AI capability from a vendor. The document is written for any organization in that position, not for defense specifically, and it says its practices align with the cross-sector Cybersecurity Performance Goals that CISA and NIST developed.
Our view: this deployment phase is where Risk Management Framework (RMF) authorizations fit AI least well. An authorization to operate (ATO) captures a system's configuration at a point in time. An AI system's effective behavior also depends on the data it receives, the environment it runs in and the model version it is running, all of which can change after the authorization is granted.
How the Guidance Is Organized
The guidance groups its practices into three areas: "secure the deployment environment, continuously protect the AI system, and securely operate and maintain the AI system" (p. 2). These are areas of practice, not a timeline, though they roughly follow the life of a fielded system.
- Secure the deployment environment: governance, architecture and hardened configuration of the IT environment the AI system runs in, including Zero Trust and secure-by-design principles.
- Continuously protect the AI system: validating models and artifacts before and during use, securing exposed APIs, actively monitoring model behavior and protecting model weights.
- Secure AI operation and maintenance: access controls, user training, external audits and penetration testing, logging and monitoring, updates, backup and recovery, and secure deletion.
Four Attack Surfaces the Controls Address (Spartan X Analysis)
The guidance does not publish a formal threat taxonomy. It names threats in passing: data poisoning or backdoor attacks (p. 4), prompt injection (p. 7), model inversion (p. 7), oracle-style adversarial compromise attempts (p. 8) and supply chain risk in external models and data (p. 6) (joint guidance). We group those threats into four attack surfaces to help program offices map them to requirements. The grouping and the defense examples below are ours, not the document's.
Adversarial and malicious inputs. Inputs crafted to manipulate what the model produces. The guidance tells deployers to validate and sanitize "all input data" to reduce the risk of malicious input such as prompt injection, and to watch for "high frequency or repetitive inputs" as possible signs of automated compromise attempts (pp. 7–8). In a defense setting, this matters wherever an adversary can influence what a system sees: imagery for a targeting aid, signals for an electronic warfare response, sensor data for an autonomous platform's perception stack, or text for a language model supporting staff work.
Data and model poisoning. Manipulation of the data or artifacts that shape what the system has learned. The guidance recommends identifying and protecting proprietary training and fine-tuning data sources and keeping "a catalog of trusted and valid data sources" to protect against "potential data poisoning or backdoor attacks" (p. 4). Programs that retrain on operational data or accept vendor model updates should also read the follow-on AI Data Security best-practices guide that CISA, NSA, the FBI and international partners released May 22, 2025, which addresses data security and integrity risks across the AI lifecycle.
Model and information extraction. Attempts to steal weights or pull sensitive information out of a model through its interfaces. The guidance says to "monitor for attempts to access or elicit data from the AI model or aggregate inference responses" and to ensure APIs "return only the minimal data required for the task to inhibit model inversion" (p. 7). For defense systems, this applies to any exposed inference endpoint, and in our assessment it applies with extra force to edge hardware that could be physically captured.
Supply chain compromise. Compromised external models, datasets or tooling delivered through acquisition and integration. The guidance tells deployers to review the source of AI models and supply chain security, and to "carefully inspect models, especially imported pre-trained models, inside a secure development zone prior to considering them for tuning, training, and deployment" (pp. 6, 9). A commercial foundation model, an ML framework update pulled in by an automated dependency pipeline and a third-party dataset are all supply chain components in this sense.
Key Practices and Their Acquisition Implications
Threat models and contracts. The guidance directs deployers to "require the primary developer of the AI system to provide a threat model for their system," and says the deployment team should use that threat model to implement security practices, assess threats and plan mitigations (pp. 3–4). It also says to "consider deployment environment security requirements when developing contracts for AI system products or services" (p. 4). For a program office, both points land in the contract: if the vendor is not required to deliver a threat model, the program cannot follow the guidance.
A Spartan X recommendation, not a requirement of the guidance: specify a structured AI System Card as a contract deliverable alongside the threat model. It should document training data provenance, known performance limitations, the scope of adversarial testing and the operating envelope in which the system was evaluated. Without something like it, program offices have little basis for judging what they are accepting at a milestone or fielding decision.
Model weight protection. The guidance's conclusion calls model weights "the essence of the AI system" (p. 10). Its specific practices include an access control system for weights limited to privileged users with two-person control and two-person integrity, encryption of weights, outputs and logs at rest with keys stored in a hardware security module, cryptographic methods, digital signatures and checksums to confirm each artifact's origin and integrity, and aggressive isolation of weight storage, for example in "a highly restricted zone (HRZ)" (pp. 4–7). By analogy (our framing, not the document's), any pathway that delivers new weights to a fielded system without integrity verification should be treated like an unverified firmware update.
Isolation of the runtime environment. The guidance calls for sandboxing the environment running ML models "within hardened containers or virtual machines," establishing protections for "the boundaries between the IT environment and the AI system," inspecting imported models in a secure development zone before deployment, and isolating weight storage (pp. 4–7). Separating production inference from shared development and training compute follows from those practices, though the guidance does not prescribe it. Programs that moved fast and still share infrastructure across development, validation and operation should check whether those boundaries exist in practice.
Operational monitoring. The guidance says to "collect logs to cover inputs, outputs, intermediate states, and errors," to monitor the model's architecture and configuration for unauthorized changes, to "watch for data drift," and to set alerts for oracle-style compromise attempts and other anomalies (pp. 7–8). Our point: a system can report clean infrastructure health while its model's outputs degrade, so the program has to define what it will measure (input and output distributions against validated baselines, for example), what thresholds trigger human review and who acts on an alert. That belongs in the requirements baseline and the budget, not in a post-fielding enhancement list.
Change control, testing and rollback. The guidance calls for storing code and artifacts, including models, parameters, configurations and data, in a version control system "to ensure only validated code is used and any changes are tracked." It says to test models for robustness and vulnerabilities after modification using techniques "such as adversarial testing," to "run a full evaluation" of accuracy, performance and security before redeploying an updated model, and to prepare automated rollbacks with a human in the loop (pp. 6, 8). It also recommends engaging external security experts to conduct audits and penetration testing on ready-to-deploy AI systems (p. 8).
Supply chain controls. The guidance calls for evaluating and securing "the supply chain for any external AI models and data," checking that they meet organizational standards, preferring suppliers that follow secure-by-design principles, and making sure risks are "understood and accepted" where parts of the supply chain cannot meet those standards (p. 6). A natural extension, and our recommendation rather than the guidance's, is to bring model weights and datasets into the software bill of materials and provenance practices that programs already apply to software under Executive Order 14028, with version lineage for each model.
Faster Model Refresh Raises the Stakes
Program offices should read this guidance alongside the Secretary of War's January 9, 2026 memorandum, "Artificial Intelligence Strategy for the Department of War." It directs CDAO to set a delivery cadence that "enables the latest models to be deployed within 30 days of public release," calls for eliminating blockers to "Authorizations to Operate (ATOs), test and evaluation and certification," and directs CDAO to ensure "all existing AI policy guidance at the Department aligns with the directives laid out in this memorandum."
That creates a real tradeoff. One credible alternative to the controls described here is to accept vendor model updates on a fast cadence with lighter program-level review, relying on ATO reciprocity and the vendor's own testing. That approach makes sense for low-consequence uses such as drafting, search or analysis support, where a human reviews every output and a bad model version is cheap to roll back. It makes much less sense for systems whose outputs feed targeting, weapons employment or autonomous behavior with little human review. For those, a 30-day refresh means the guidance's integrity checks, full re-evaluation before redeployment and rollback controls have to be automated and fast, not skipped. The evidence that should move a program toward the lighter path is a record of vendor updates passing the program's own regression and adversarial tests without surprises. The evidence that should move it away is any unexplained behavior change between versions.
What Program Managers Need to Do
These actions can be taken on existing programs without waiting for new policy. They are Spartan X recommendations built on the guidance.
- Map the guidance to current contract requirements. Review performance work statements and system specifications against the three practice areas and the four attack surfaces above. Where the vendor is not required to provide a threat model, demonstrate model integrity controls or document supply chain provenance, that is a gap. Some gaps will need contract modifications; others can be closed through data deliverable requirements.
- Require a threat model and an AI System Card at milestones. The threat model comes straight from the guidance. Define the System Card's format in the contract rather than accepting whatever documentation the vendor provides, so the document is useful for oversight and not a checkbox.
- Bring AI-specific controls into the RMF package. The ATO should address weight protection, input validation, monitoring and change control as explicitly as it addresses network segmentation and vulnerability management. Security engineers and authorizing officials new to AI may need technical help scoping these controls. The NIST AI Risk Management Framework, released January 26, 2023 for voluntary use and now being revised, which the guidance itself cites, offers a complementary risk structure.
- Make model monitoring a stated system requirement. For a system with operational authority, monitoring outputs against validated baselines is how the program supports a claim of continued assurance after fielding. It should be traceable through design and test.
- Name ML supply chain vectors in the program protection plan. In our observation, software supply chain briefings have rarely singled out compromised weights, poisoned datasets or malicious ML framework updates. Program protection plans should name them explicitly.
Three Questions Before the Next Program Review
Regardless of where a program sits in the acquisition lifecycle, three questions establish its posture against the practices in the NSA–CISA–FBI guidance:
- Has the system been tested against adversarially crafted inputs, and by whom? The guidance recommends adversarial testing after modification and external audits and penetration testing on ready-to-deploy systems (pp. 6, 8). If neither has happened, the program does not know how the system behaves in the environment it was built for. Document that as operational risk and brief it.
- Is there a monitoring framework that would detect model degradation or compromise in operation? If no one has defined what to log, what drift looks like and what triggers human review, the program cannot tell whether the deployed model still performs as validated.
- Is model update authority controlled, versioned and reversible? If a vendor or pipeline can push new weights without version control, full re-evaluation and a tested rollback, the program has an uncontrolled modification path that its 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 the decision authority and setting a remediation timeline proportional to the system's operational authority and adversarial exposure.
How the Guidance Fits with Zero Trust and CMMC
The guidance tells deployers to "apply secure by design principles and Zero Trust (ZT) frameworks to the architecture" and to "adopt a ZT mindset, which assumes a breach is inevitable or has already occurred" (pp. 4–5). For Zero Trust, it cites NSA's Embracing a Zero Trust Security Model and CISA's Zero Trust Maturity Model. In practice, an AI inference pipeline reachable from the general enterprise network because segmentation was never implemented is more exposed on every attack surface discussed above.
CMMC is a different instrument. The CMMC Program rule (32 CFR Part 170, effective December 16, 2024) exists to "verify contractors have implemented required security measures necessary to safeguard Federal Contract Information (FCI) and Controlled Unclassified Information (CUI)," and the DFARS rule that brings it into contracts took effect November 10, 2025. It covers defense contractors' information systems. It does not certify an acquisition program or a fielded AI system. Contractors holding CMMC Level 2 or Level 3 status should not assume it covers ML-specific risks such as model-weight theft or poisoning; the AI guidance adds those practices.
Sources and further reading
- NSA AISC, CISA, FBI, ASD's ACSC, CCCS, NCSC-NZ and NCSC-UK. Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems. Joint Cybersecurity Information, April 2024, Ver. 1.0.
- CISA. Joint Guidance on Deploying AI Systems Securely. Alert, April 15, 2024.
- CISA. New Best Practices Guide for Securing AI Data Released. Alert on "AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems," May 22, 2025.
- Secretary of War. "Artificial Intelligence Strategy for the Department of War." Memorandum, January 9, 2026. Signed memorandum (PDF), media.defense.gov.
- NIST. AI Risk Management Framework. AI RMF 1.0 released January 26, 2023; under revision.
- DoD. Cybersecurity Maturity Model Certification (CMMC) Program. Final rule, 32 CFR Part 170, effective December 16, 2024.
- DoD. DFARS: Assessing Contractor Implementation of Cybersecurity Requirements (DFARS Case 2019-D041). Final rule, effective November 10, 2025.
- Executive Order 14028, Improving the Nation's Cybersecurity. Signed May 12, 2021.
- NIST. SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. September 2020; Release 5.2.0, August 27, 2025.
- CISA. Roadmap for AI. 2023–2024 roadmap, now archived.
Spartan X's Arbiter platform is built for one of the practices the guidance emphasizes most: actively monitoring AI behavior in operation. Arbiter cross-checks outputs across multiple models, builds behavioral profiles for supervised agents to flag anomalies, records cryptographic audit trails, and can run at the edge in disconnected environments. For programs facing ATO renewals and faster model refresh, that kind of evidence shows how a fielded AI system is actually behaving, not just how it performed at initial test.
