Securing artificial intelligence has moved well past the point where a set of ethical principles or a governance checklist can carry the weight on its own. Machine learning teams need controls they can actually point to in an audit, controls that map onto real pipelines, real model weights, and real inference endpoints. Enterprise security programs built around traditional IT assumptions routinely stall when they meet a non-deterministic system that produces a different output every time it runs.
The National Institute of Standards and Technology launched the Control Overlays for Securing AI Systems initiative, known by its working name COSAiS, to close exactly that gap. NIST released the project concept paper on August 14, 2025, setting out a plan to take the trusted control catalog in NIST SP 800-53 Revision 5 and apply it directly to machine learning operations, foundation models, and autonomous software workflows. It is one of the more concrete signals, yet that federal AI security policy is shifting from abstract principle toward auditable engineering practice.
What Are NIST AI Control Overlays?
An overlay, in NIST vocabulary, is a tailored specification built on top of an existing control baseline. Rather than inventing a new catalog from scratch, an overlay takes controls that already exist, such as access management, audit logging, configuration management, and supply chain risk handling, and adjusts their scope, parameters, and implementation guidance to fit a particular technology or mission. NIST has used this mechanism before for cloud environments and industrial control systems, and COSAiS applies the same logic to machine learning.
According to NIST project documentation on the Computer Security Resource Center, control overlays enable organizations and communities of interest to customize controls or control baselines for a specific technology, system, mission space, and environment of operation. Controls can be selected from the SP 800-53 catalog, modified to address unique risks or applications, and supplemented to provide application-specific guidance for implementers. That core idea explains the entire design philosophy behind the project: adapt what already works instead of starting over.
It helps to be precise about what COSAiS is not. It is not a replacement for the NIST AI Risk Management Framework (AI RMF 1.0), and it is not a competing standard. The AI RMF operates at the level of organizational governance, structured around the functions Govern, Map, Measure, and Manage, dealing with broad trustworthiness concerns such as fairness, transparency, and accountability. COSAiS sits one layer down, supplying the specific, testable technical controls that a security engineer would actually write into a System Security Plan to satisfy those higher-level goals. NIST concept paper makes this relationship explicit, noting that the AI RMF addresses risk and trustworthiness considerations that fall outside the scope of SP 800-53 security and privacy controls, and that the overlays are meant to be used alongside the AI RMF rather than in place of it.
The project continues to progress. Since the August 2025 concept paper, NIST has kept the work moving through public workshops and draft releases, most recently an annotated outline covering predictive AI systems in January 2026.
Why NIST Is Building AI-Specific Control Overlays
Traditional infrastructure security assumes deterministic behavior. A firewall rule either blocks a packet or it does not. An access control list either grants a user permission or it does not. That predictability is precisely what conventional controls were built to protect, and it is precisely what machine learning systems do not offer.
Neural networks learn statistical patterns from enormous datasets, and their behavior at inference time is probabilistic rather than scripted. That shift creates a category of risk that legacy tooling simply was not designed to see.
Data provenance and poisoning are one of the clearest examples. A conventional security check confirms that a database is reachable and that permissions are correctly set. It has nothing to say about whether an attacker quietly altered a fraction of the training data months earlier to plant a backdoor that only activates under specific conditions. Model integrity and weight theft raise a related but distinct problem: the trained weights of a model are both the organization’s intellectual property and its execution logic in one file, which means they need cryptographic signing, hardened storage, and runtime memory protections that a standard file server was never built to provide. Non-deterministic execution undermines input validation as security engineers have always practiced it, because a generative system can be steered through prompt injection or context manipulation in ways that never trip a conventional pattern-matching filter. Opaque dependencies, from open-source model hubs to serialized tensor files to the sprawling Python library ecosystem that most ML pipelines run on, dramatically widen the software supply chain that a security team is responsible for defending.
NIST could have written a brand-new, AI-only cybersecurity catalog. It chose not to, and the reasoning is practical rather than philosophical. Most federal agencies and a large share of the private sector already run compliance programs anchored to SP 800-53. Building a parallel track would have forced security teams to maintain two separate sets of controls, two audit trails, and two assessment procedures for systems that increasingly overlap. By extending the existing catalog instead, COSAiS lets organizations reuse the continuous monitoring tools, authorization boundaries, and assessment procedures they already operate, extending them to cover machine learning components. NIST project materials describe this directly: control overlays let organizations that already implement SP 800-53 and have the institutional processes in place to plan control implementations and assess control effectiveness extend that same infrastructure to AI systems rather than rebuilding it.
How COSAiS Uses NIST SP 800-53
The mechanics of COSAiS follow a consistent pattern across every use case. NIST team first identifies which controls in the SP 800-53 catalog already touch the parts of the system that matter for AI, meaning data pipelines, model storage, inference endpoints, and orchestration layers. From there, tailoring adjusts the scope of each control so it captures the realities of a machine learning lifecycle instead of only a conventional application lifecycle.
A useful way to picture this is to look at how two familiar controls change character once they are pulled into an AI context. Under standard SP 800-53 guidance, AC-6 (Least Privilege) restricts which users can touch which servers and files. Reframed for machine learning, that same control reasonably extends to cover who can access training data repositories, who can modify hyperparameter configurations, who can run model evaluation suites, and who can pull raw model weights, since each of those assets carries its own distinct risk if it falls into the wrong hands. SI-4 (System Monitoring) shows a similar shift. In a conventional network, SI-4 is about watching packet flows and flagging anomalies. Applied to an AI system, the same underlying discipline of continuous monitoring extends to inference latency, embedding drift over time, and token distribution anomalies that can signal an adversary probing a model for extraction.
The reassuring part for security leaders is that none of this requires tearing down an existing program. Because the overlays map onto the existing SP 800-53B baselines at the Low, Moderate, and High impact levels, a security officer can assess AI components through the same Risk Management Framework procedures already in use, applying an AI-aware lens to the controls touching machine learning assets.
The AI Use Cases Covered by COSAiS
NIST deliberately avoided writing one generic rulebook for every kind of AI deployment, because a chatbot, a fraud-scoring model, and a fleet of autonomous agents fail in very different ways. The concept paper instead organizes the work around distinct use cases, spanning generative AI, predictive AI, single and multi-agent systems, and AI developers building or fine-tuning models.
Generative AI and Large Language Models
This use case covers the conversational assistants, text transformers, and retrieval-augmented generation systems that most organizations think of first when discussing AI. The overlay priorities here center on indirect prompt injection, unwanted leakage of information out of the context window, unauthorized retrieval from connected vector databases, and tool calls that a model triggers without adequate verification.
Predictive AI and Machine Learning Systems
Predictive models take structured, historical data and turn it into classifications, risk scores, or automated decisions, the kind of system that underwrites a loan or flags a fraudulent transaction. Because this use case is furthest along in the drafting process, it offers the clearest window into how detailed the finished overlays will be. Controls here focus on preventing training data contamination, monitoring whether feature attributions stay stable over time, auditing the logic behind automated scoring, and watching for the query patterns that indicate a model extraction attempt.
Single AI Agents
An autonomous agent takes a goal, decomposes it into a multi-step plan, and calls external tools or APIs with little or no human review in the loop. The overlay controls for this use case target the boundaries of an agent’s memory, the scope of the privileges it holds when calling external APIs, explicit guardrails on what the agent is permitted to attempt, and automated circuit breakers that stop an agent from looping indefinitely on a failing task.
Multi-Agent AI Systems
Once multiple specialized agents start negotiating with each other and passing state between one another to complete a multi-stage task, the attack surface changes again. Controls here address authentication between agents, cryptographic integrity of the sessions they share, containment strategies that stop one agent failure from cascading into the rest of the system, and isolation procedures for an agent that starts behaving outside its intended parameters.
AI System Developers and Model Builders
This use case is aimed at the organizations actually training foundation models, fine-tuning open-weight models, or running ML engineering pipelines day to day. It draws heavily on NIST’s existing secure software development work, aligning controls with secure coding practices, cryptographic signing of model artifacts, verification of dataset integrity, hardware security during training runs, and dual-use safety evaluation before a model ships.
AI Security Risks Addressed by the Overlays
Each overlay ties specific SP 800-53 control families to a concrete vulnerability somewhere in the machine learning lifecycle, rather than describing risk in the abstract.
Protecting training data and dataset integrity draws primarily on the Audit and Accountability family (AU) and Supply Chain Risk Management family (SR). In practice, that means tracking the cryptographic lineage of training samples, verifying that data scrubbing actually happened as documented, and continuously auditing the pipelines feeding a model so poisoning attempts do not slip through unnoticed.
Model integrity relies on the Configuration Management family (CM) and System and Services Acquisition family (SA). The core requirement is cryptographic signing of model weight files, so that unauthorized modification, parameter tampering, or a silent model swap during deployment gets caught before causing damage.
Adversarial robustness falls under System and Communications Protection (SC). Overlays in this area call for active defenses against evasion attacks, adversarial perturbations, prompt injection payloads, and membership inference attacks that try to reconstruct sensitive information from the training set.
Model weight security is handled through the Access Control (AC) and Physical and Environmental Protection (PE) families. Trained weights are treated as critical assets deserving encrypted storage at rest, restricted memory access during inference, and firm export controls to prevent unauthorized extraction.
Configuration safety for the machine learning frameworks, orchestration layers, and vector stores that most AI stacks run on means disabling debug interfaces in production, blocking arbitrary code execution inside parsing libraries, a known and recurring vector in ML tooling, and enforcing secure defaults across distributed training clusters.
Development and component interaction risk is addressed through secure software development controls that apply real scrutiny to third-party models, open-source tokenizers, pipeline dependencies, and the APIs connecting one component of an AI system to another.
Where COSAiS Fits in the NIST AI Security Landscape
NIST maintains a distinct collection of publications touching AI and security, and it is essential to understand how each relates to COSAiS rather than treating them as interchangeable.
The NIST Risk Management Framework (SP 800-37) is the foundational federal process for managing risk across a system lifecycle, serving as the core process COSAiS plugs into. NIST SP 800-53 Revision 5 is the underlying control catalog itself, a library containing roughly 1,196 individual security and privacy controls covering everything from access management to incident response. The AI Risk Management Framework (AI RMF 1.0) is the voluntary, principle-level guidance organized around Govern, Map, Measure, and Manage, dealing with broader concerns like bias and transparency that sit outside a pure security control catalog. SP 800-218A extends NIST Secure Software Development Framework specifically toward generative AI and dual-use foundation models, identifying which model artifacts and practices most need protecting. NIST has also published AI 100-2e2025, a taxonomy of adversarial machine learning attacks and mitigations that directly informs how COSAiS controls get tailored, along with the draft AI 800-1, which focuses on managing misuse risk for dual-use foundation models. Sitting alongside all of this is NIST’s broader Cyber AI Profile work, a strategic document mapping cybersecurity posture to AI operations across critical infrastructure sectors.
COSAiS is the technical layer that turns the governance language of the AI RMF and the developer guidance in SP 800-218A into specific, testable SP 800-53 controls that an assessor can actually check off during an audit. NIST concept paper diagrams this relationship directly, showing the control overlays drawing on AI 100-2e2025, draft AI 800-1, and SP 800-218A to inform how SP 800-53 controls get selected and tailored for each use case.
Using COSAiS in an Existing Security Program
Adopting COSAiS does not require a security team to rebuild its program. The practical path starts with mapping the organization’s architecture, deciding whether a given deployment is generative, predictive, agentic, or a mixture of these, since that determines which overlay applies.
From there, the team pulls the relevant COSAiS overlay document and isolates the control families that matter for that architecture, cross-referencing those selections against whatever baseline the organization runs, commonly SP 800-53B Moderate for most commercial and civilian federal systems. The parameter modifications of the overlay fold into existing standard operating procedures rather than replacing them outright.
Logging configurations offer a clear example of this process:
- Extend existing log retention rules to capture full prompt histories and context parameters.
- Record vector database query metadata and embedding lookups alongside standard access logs.
- Monitor inference timing data to detect potential model extraction or resource exhaustion attempts.
Once those changes are in place, a gap analysis surfaces what remains missing, whether that is an unencrypted model cache sitting on disk or an API-connected plugin nobody has reviewed.
One detail worth building into any ongoing program: control implementations tied to an AI system are not a static exercise. Whenever a model gets retrained, a context window gets expanded, or the underlying pipeline undergoes a meaningful configuration change, the controls attached to that system need to be reassessed, since the risk profile can shift substantially even when the surrounding infrastructure has not changed at all.
Current Status of NIST AI Control Overlays
COSAiS remains an active, evolving project inside NIST Computer Security Division, progressing steadily through public development phases. The overall roadmap covers the five use cases outlined earlier: generative systems, predictive systems, single agents, multi-agent systems, and model developers, though the pace of drafting differs across each area.
The predictive AI use case has moved furthest. NIST published an annotated outline, described as a discussion draft, of the Predictive AI Control Overlay on January 8, 2026, timed to support discussion at the Cyber AI Profile Workshop #2 held on January 14, 2026. NIST requested initial feedback on that outline by February 13, 2026, so it could be factored into the first full public draft. NIST also held an earlier public webinar on September 25, 2025, where project leads walked through how SP 800-53 maps onto common AI use cases and previewed the role overlays play in simplifying AI security work going forward.
Draft material for the generative AI and autonomous agent overlays is expected to follow through 2026 and into 2027, though NIST has not published a fixed release date for each document. Because every draft undergoes active public comment and revision, the practical approach for any security team is to treat current material as directional rather than final, checking the NIST Computer Security Resource Center COSAiS project page for the latest version before locking in a control baseline for an audit or authorization package.
What NIST SP 800-53 Control Overlays Mean for AI Security
The real significance of COSAiS is less about any single control mapping and more about the underlying principle: machine learning does not have to be treated as an ungovernable black box demanding a completely new security discipline built from scratch. NIST’s approach shows that the discipline security teams have spent decades refining can be extended, carefully and deliberately, to cover a genuinely new class of technology.
By tailoring SP 800-53 rather than replacing it, COSAiS gives security practitioners, auditors, and ML engineers a shared technical vocabulary, one where a control like least privilege or continuous monitoring carries consistent operational meaning whether it protects a file server or a fleet of model weights. That shared language empowers organizations to secure their data pipelines, model weights, and autonomous AI agents without forcing security teams to throw out the established programs they have spent years building.