CISA and NSA's 'Deploying AI Systems Securely' guidance, explained

Most organizations deploying AI today are not training their own foundation models — they are standing up a vendor-built AI system inside their own infrastructure, which means the deployer, not the model developer, is on the hook for the IT environment, access controls and monitoring around it. CISA's own alert frames this guidance's purpose as improving the confidentiality, integrity and availability of AI systems, ensuring appropriate mitigations for AI-specific vulnerabilities, and giving organizations concrete methodologies and controls to protect, detect and respond to malicious activity against an AI system once it's in their environment — the same overlapping territory our guide to MITRE ATLAS catalogs from an adversary-tactics angle and Google's SAIF covers from a single vendor's own framework.

NSA AISC led the publication, joined by CISA, the FBI, the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), the Canadian Centre for Cyber Security (CCCS), New Zealand's NCSC-NZ, and the UK's NCSC-UK — the same "Five Eyes"-plus-US-law-enforcement coalition pattern used across several joint CSIs. It was the first release from NSA AISC, which NSA stood up in September 2023 inside its Cybersecurity Collaboration Center. CISA's alert page is explicit about audience: the guidance "is intended to support National Security System owners and Defense Industrial Base companies that will be deploying and operating AI systems designed and developed by an external entity" — a deployer's document, not a developer's.

Per the CSI and consistent secondary reporting, the deployment-environment recommendations split into three groups: manage deployment-environment governance (confirm the IT environment already applies sound security principles before an AI system goes in, and have whichever team is deploying it coordinate with IT rather than standing up the system outside existing IT standards); ensure a robust architecture (secure-by-design principles and a Zero Trust architecture, with boundary protections, access control, encryption and authentication separating the AI system from the rest of the environment); and harden configurations (don't run a newly deployed model directly in the production enterprise environment, keep the surrounding IT environment hardened and patched, and validate the AI system before it goes live rather than after).

Beyond the deployment environment itself, the guidance recommends validating the AI system before deployment; enforcing strict access controls and API security on the AI system under least-privilege and defense-in-depth principles; and using robust logging, monitoring and user-and-entity behavior analytics (UEBA) to catch insider threats and other malicious activity once the system is live. It also makes an organizational recommendation that's easy to skip past: name one person — typically the CISO or head of information security — accountable for the AI system's cybersecurity specifically, and keep data science, IT infrastructure and cybersecurity teams talking to each other about it rather than treating AI deployment as the data science team's problem alone.

A year later, the same core coalition — NSA AISC, CISA, the FBI and the same four international partners — released a follow-up CSI, "AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems," on 22 May 2025. CISA's own alert describes it as building directly on the 2024 Deploying AI Systems Securely guidance, this time focused on the data side of the AI lifecycle across three risk areas it names explicitly: supply chain, maliciously modified or poisoned data, and data drift. Its ten best practices cover sourcing reliable data with tracked provenance, verifying integrity with cryptographic hashes, using Zero Trust infrastructure, classifying data (and AI output) by sensitivity, FIPS 140-3-compliant storage, data masking, metadata validation, privacy preservation, NIST SP 800-88-compliant secure deletion, and ongoing risk reassessment as threats evolve.

Most of this guidance was written with enterprise and national-security deployers in mind, but a device or firmware vendor embedding a vendor-supplied model into a product is doing exactly the thing the guidance addresses — deploying an externally built AI system into an environment it does not fully control. The access-control, API-security and monitoring recommendations map directly onto treating an embedded model's inference runtime and any AI-related API keys as first-class inventory, the same gap our guide to AI-BOM for embedded AI devices covers; the "validate before deployment" recommendation is a natural fit alongside the kind of threat modeling covered in our guide to the OWASP Top 10 for LLM Applications when the embedded model is LLM-based. None of this makes a device "CSI-compliant" — there is no certification scheme attached to a Cybersecurity Information Sheet — but it is a free, concrete checklist to run an embedded-AI deployment against alongside a conventional firmware security review.

SoftWSP's device and firmware security work already looks for embedded models, inference runtimes and AI-related credentials as part of a firmware assessment; see device & firmware security services for how that scope extends to check deployment-environment hardening and access controls against this guidance's recommendations.

This guide is based on CISA's and NSA's own alert pages and the primary CSI PDFs for both "Deploying AI Systems Securely" (15 April 2024) and "AI Data Security" (22 May 2025), fetched directly, cross-checked against contemporaneous secondary reporting for the deployment-environment sub-category breakdown where the source PDF itself could not be fetched directly in this research pass. It is not a substitute for reading the primary CSI documents and does not constitute security or compliance advice.