What are the NIST COSAiS SP 800-53 control overlays for securing AI systems?
The NIST Control Overlays for Securing AI Systems (COSAiS) project is NIST's effort to publish SP 800-53-based overlays for securing AI systems. If you already run SP 800-53 or a FedRAMP-style control program, understand the status before you plan around it: as of NIST's January 2026 update, no initial public draft of any overlay had been posted. The published materials are the project concept paper and an annotated outline for the Using and Fine-Tuning Predictive AI overlay. Check the COSAiS project page for any draft released after that update, because the overlay list and timing can change. The overlays are planned for five use cases: adapting and using generative AI, using and fine-tuning predictive AI, single-agent AI systems, multi-agent AI systems, and security controls for AI developers. Which of these you run, and whether you build, fine-tune or buy the model, determines which overlay will apply and which of your existing SP 800-53 control implementations it will modify. A bank that buys a hosted assistant and a team that fine-tunes its own classifier will face different overlays, so map each AI system to a use case before you assess gaps.
Responsibilities split three ways. NIST owns the overlays and their content. Your organization owns its control implementation, the system boundary and the evidence that the controls operate. Your independent assessor is the only party that issues assessment conclusions about those controls, and no overlay will certify you. Ask your assessor now how they will treat an overlay that is still a draft, and ask your authorizing official whether a draft overlay can be cited in a system security plan. Those answers decide whether you can start remediation in parallel with NIST's drafting or must wait for a final publication.
The five AI use cases COSAiS plans to cover
This table compares the five use cases NIST's COSAiS project plans to address with SP 800-53 control overlays, showing the kind of system each one targets and the organizations most likely to need it. Read each row as a scope test: find the system type that matches your deployment, then check its status, since the agent and developer overlays were planned rather than published in the sources reviewed.
| Use case | System it targets | Organizations most likely to need it | Status in the sources reviewed |
|---|---|---|---|
| Adapting and using generative AI | Generative AI assistants and large language models used through an interface, API or embedded product feature | Agencies and regulated firms deploying chat assistants or LLM features built on a vendor model | Planned; no initial public draft listed in the January 2026 project update |
| Using and fine-tuning predictive AI | Predictive models, such as classifiers and scoring models, that are used or adapted on the organization's own data | Banks, insurers, health systems and public agencies running risk scoring, fraud or eligibility models | Annotated outline (discussion draft) released January 8, 2026; no initial public draft listed |
| Single-agent AI systems | One AI agent that plans and calls tools, APIs or data sources to complete tasks with limited human steps | Organizations automating workflows, such as ticket handling or internal research agents, with access to production systems | Planned; not published as of the sources reviewed |
| Multi-agent AI systems | Several agents that coordinate, delegate tasks or pass outputs to one another | Organizations orchestrating agent teams across business functions or vendor platforms | Planned; not published as of the sources reviewed |
| Security controls for AI developers | The build environment, training pipeline and model development practices for teams that create AI models | Model developers and software teams that train, fine-tune or ship AI models, often aligned with SP 800-218A | Planned; not published as of the sources reviewed |
| Ask the vendor or project team | Confirm which overlays have reached draft or final status before you map controls to them | All organizations planning an assessment against an overlay | Check the COSAiS project page for current status before relying on any use case |
Which documents COSAiS draws on and why it matters
COSAiS does not start from zero. It builds on a secure development framework, a draft AI-specific standard and NIST's adversarial machine learning taxonomy, then maps that material onto SP 800-53 controls. Teams that run SP 800-53 or FedRAMP-style programs should read each source alongside the overlay to understand where the controls come from.
SP 800-218A for model development
Finalized July 26, 2024, SP 800-218A extends the Secure Software Development Framework (SSDF) 1.1 with practices for AI model development. For an overlay, it supplies the development-side expectations: how training data, model configuration and model artifacts are handled inside the secure development lifecycle. Teams that train or fine-tune models should map its practices to their existing SSDF evidence, such as build records, review sign-offs and model provenance logs, and confirm which SP 800-53 controls in their system boundary cover those practices.
Draft NIST AI 800-1
NIST AI 800-1 is a draft that COSAiS also draws on. Because it is not final, its requirements can change before the overlays are released. Treat it as a reference for the direction of AI security practices, not as a settled baseline. Ask your overlay owner or assessor which version of the draft the overlay references, and record that version in your system security plan so the control narrative does not drift when the draft is revised.
NIST AI 100-2e2025 attack taxonomy
NIST AI 100-2e2025 is the adversarial machine learning taxonomy. It names attack classes against predictive and generative AI, such as poisoning, evasion, privacy attacks and prompt injection, and describes mitigations and their limits. For an overlay, it defines the threats that the controls must address. SP 800-53 teams should read it alongside the overlay to check that each threat in their use case has a control, a monitoring method or a documented risk acceptance.
Reading the sources together
The three sources serve different purposes. SP 800-218A governs how models are built, AI 800-1 is still moving, and AI 100-2e2025 describes what attackers do. An overlay tailors SP 800-53 to combine them for a specific use case. Teams should build a crosswalk that lists each overlay control next to the source paragraph it reflects, so an assessor can trace why a control exists and which source needs review when a draft changes.
Why the sources matter for assessment
Assessors test against the control text and its stated purpose. When a source is a draft, the assessment may rely on whatever the final overlay says, so organizations should not write control narratives that depend on draft wording. Confirm with the COSAiS project which materials are final, which are discussion drafts and which are still being developed before you map evidence to any AI-specific control.
Where the COSAiS drafts stood in 2026
The dated sequence shows how NIST moved COSAiS from a project page to a concept paper and then to a single discussion draft, which tells readers what exists to review and what is still pending.
Project page opens the COSAiS effort
On July 10, 2025, NIST created the COSAiS project page on CSRC. The page is the central location for the project's scope, its planned overlays and later postings. Security and compliance leads should bookmark it, because it is the source that shows which overlay materials NIST has actually published. The step is complete once the team has confirmed the page is listed under NIST's CSRC project pages and has noted the creation date for its records.
Concept paper opens for public comment
On August 14, 2025, NIST made the COSAiS concept paper available for comment. The paper sets out the five planned AI use cases and the SP 800-53 approach the overlays will follow. Comments came from outside NIST, so this step is where industry, agencies and assessors first had a documented chance to shape the overlay structure. Teams that want to understand the intended scope should read the concept paper before any later draft, since it defines what the overlays are meant to cover.
Predictive AI annotated outline is released
On January 8, 2026, NIST released an annotated outline, labeled as a discussion draft, for the Using and Fine-Tuning Predictive AI overlay. NIST published it to support Cyber AI Profile Workshop #2 on January 14, 2026. The outline is a structural preview, not an overlay with final control baselines. Readers should treat it as the most concrete COSAiS material available for review, and they should confirm its current status on the CSRC project page before citing it in an assessment.
Workshop discussion informs feedback
NIST held Cyber AI Profile Workshop #2 on January 14, 2026, where participants could discuss the predictive AI outline alongside the related Cyber AI Profile work. This step is where practitioners compare the outline with their own SP 800-53 baselines and identify gaps, such as AI-specific risks that existing control language does not address. Organizations that take part should record their questions and proposed changes in writing so they can be submitted through the feedback channel.
Initial feedback deadline is set
NIST set February 13, 2026 as the date by which initial feedback was due for the initial public draft of the predictive AI overlay. Feedback submitted before that date was intended to inform the draft that NIST would publish next. Any team that wants its input considered should confirm the submission route and any later comment windows on the CSRC project page, since the deadline applied to that specific stage.
Project page shows no initial public draft
As of its January 2026 update, the COSAiS project page listed no initial public draft of any overlay. The concept paper and the predictive AI annotated outline were the only published materials. This is the point at which the sequence stood when the record was last confirmed. Organizations should not treat the outline as a finished overlay or cite it as a baseline in audit documentation, because NIST had not issued a public draft of any overlay at that time.
Check the CSRC page for current status
Because the status described here reflects the January 2026 update, readers should check the CSRC COSAiS project page directly before planning work. Confirm whether any initial public draft has been posted for an overlay, whether new comment periods are open, and whether the five planned use cases have changed. The step is complete when the team has recorded the date it checked the page and the version of each document it plans to reference.
How to plan control work before final overlays exist
Start by mapping your current AI systems to the five COSAiS use cases: adapting and using generative AI, using and fine-tuning predictive AI, single-agent AI systems, multi-agent AI systems, and security controls for AI developers. Most organizations run more than one of these at once, for example a predictive scoring model that feeds an assistant, so record each system against every use case that applies rather than picking one. Next, build an inventory of the AI components those systems depend on: model artifacts, training and fine-tuning datasets, retrieval stores, prompt and orchestration code, tool connectors, model hosting endpoints and the accounts that call them. Your existing asset inventory and configuration baseline are the natural starting point, but expect AI components to be missing from them.
With the inventory in hand, check how each SP 800-53 control family you already implement applies to the model, data and agent components. Access control, audit logging, configuration management, system and information integrity, and supply chain risk management will each need a decision for every component type. For agents, ask whether tool permissions follow least privilege and whether tool output is logged and validated. For fine-tuned models, ask who approves training data and how changes to weights are tracked. Record each decision with an owner, the control it touches and the evidence you would show an assessor today. Where no decision is possible yet, log it as a documented gap.
Treat planned overlay content as a moving target. The COSAiS project page lists no initial public draft of any overlay as of its January 2026 update, and the predictive AI material is a discussion draft from January 8, 2026, not a final control set. Its annotated outline may change in wording, scope or control selection before a public draft is issued. Avoid writing policy text that quotes overlay language you have not seen in a final publication. Instead, tie each gap to the SP 800-53 control it affects, note the open question, and set a review point at each COSAiS publication. Confirm the current status on the NIST COSAiS project page before each planning cycle.
What an SP 800-53 program should have in place now
NIST has not published a final COSAiS overlay, so the work that matters now is the inventory, mapping and evidence that any overlay will assume you already have. Each card below describes one item to have in place and how to check it against your own environment.
AI system inventory tied to boundaries
List every AI system that touches your authorization boundary, including hosted models, embedded AI features in SaaS tools and internal agents. For each entry, record the owning system security plan, the boundary it sits inside and the data classes it processes. Check the inventory against network flow records and cloud account listings, since AI services are often enabled without a ticket. An inventory that misses a system leaves its overlay controls with nothing to attach to.
Use case mapping per system
For each inventoried system, document which of the five planned COSAiS use cases it falls under: generative AI assistants and LLMs, predictive AI use and fine-tuning, single-agent systems, multi-agent systems, or AI developer security controls. Systems that fit more than one use case should be recorded with each one. Check the mapping with the system owner and confirm that a reviewer can trace each use case back to a specific system boundary and data flow.
SP 800-53 evidence for supporting infrastructure
AI workloads inherit most of their security from the infrastructure beneath them. Collect current evidence for the SP 800-53 controls that cover that infrastructure, such as access enforcement, audit logging, configuration baselines, vulnerability scanning and contingency planning for the hosts, containers, storage and networks that run the models. Check that the evidence is dated within your assessment cycle and that it names the AI components in scope rather than only the general platform.
Model and data supply chain records
Keep a record for every pre-trained model, dataset, plugin and third-party component the AI system uses. Include the source, version or hash, license, the date it was obtained and who approved it. The COSAiS planned overlays draw on NIST SP 800-218A, which addresses AI model development practices, so the same records will support both. Check that each model in production has a traceable origin and that no model was pulled into the environment outside the approval path.
Agent tool permissions and logging
For any agentic system, document each tool the agent can call, the permissions granted to each tool, the identity the agent runs under and the approval steps for high-impact actions. Confirm that every tool invocation and its input and output are logged to a store the agent cannot modify. Check the permission list against what the agent actually calls during test runs, because excess tool access is the gap most likely to remain undetected.
Plan to update the system security plan
Draft the steps for revising each affected system security plan once overlays are published, including who reviews the changes, which controls are added or tailored and how the assessor is notified. Set the trigger for the update to the publication of a final overlay rather than a draft, because drafts may change. Check that the plan names an owner, that the affected plans are listed and that the revision would not stall the next scheduled assessment.
Who owns what when overlays arrive
Your organization remains the owner of the system and of every control decision. The COSAiS overlays are built on SP 800-53, so the authorizing official, system owner and security team still carry the same accountability they hold for any federal or FedRAMP-style system. When an overlay is published, your team decides which overlay applies to each AI system, which controls are tailored in or out, and how each control is implemented in your environment.
- System security plan: Your team writes and maintains the system security plan, including the AI use case, the system boundary and the data flows through models, plugins and agents.
- Control selection and tailoring: Your team decides which overlay applies to the use case, which baseline it extends, and which controls are tailored, with a documented rationale for each change.
- Risk acceptance: Your team records residual risk and the people who accept it, including any decision to defer a control until a final overlay is published.
- Implementation decisions: Your team chooses the technologies, hosting model and responsible owners for each control.
- Ongoing operations: Your team runs monitoring, incident response and change control after the system is in service.
Before relying on any draft, confirm with NIST's published project materials which overlays have reached a stage you can cite in a plan.
An implementation partner such as DeployOpen works inside your environment to prepare the systems and evidence that the controls describe. The partner does not select controls on your behalf, accept risk, or issue any assessment result. Its job is to make the implemented controls real, observable and documented so your team and the assessor can test them.
- System preparation: The partner builds or hardens self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks, according to the implementation decisions your team has approved.
- Logging and access controls: The partner configures audit logging, identity and access management, and role separation on the platforms, so that the events an assessor will sample exist and can be retrieved.
- Evidence assembly: The partner collects configuration exports, change records, test outputs and runbook entries mapped to the controls in your plan.
- Documentation support: The partner drafts implementation statements for your review, but your team signs them off.
- Scope agreement: Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
Ask any partner to state in writing that it does not issue reports, attestations or authorizations, and which deliverables it will hand to your team.
The independent assessor tests whether the implemented controls work as described and reports its findings. Assessors are independent of both your team and the implementation partner. In a federal or FedRAMP-style program, the authorization conclusion rests with the authorizing official, who relies on the assessor's findings. Only an independent assessor or certification body issues the reports that customers and regulators rely on.
- Test planning: The assessor selects the controls to test, the sample sizes and the evidence it will request, usually based on the assessment procedures published for SP 800-53.
- Control testing: The assessor interviews staff, observes operation, inspects configurations and reviews logs.
- Findings: The assessor records findings, including deficiencies, and your team responds through a plan of action and milestones.
- Authorization inputs: The assessor's report feeds the authorizing official's decision, which remains with your organization.
- Independence: The assessor should not have designed or built the controls it tests.
Confirm the assessor's qualifications and the report types it issues before the engagement begins, and confirm with the authorizing official which overlay version the assessment will use.
What delays AI control projects and how to avoid it
Most delays in COSAiS-based work come from timing and scoping decisions made before any control is tested. The four cards below cover the mistakes that stall projects most often and a practical check for each one.
Waiting for a final overlay
Teams often pause all AI control work until NIST publishes a final overlay for their use case. As of the January 2026 update of the COSAiS project page, no initial public draft of any overlay had been listed, so a wait can be open-ended. Start with the controls you already own in your SP 800-53 baseline, then map which AI components they touch. Check whether your work plan has an item that can proceed without an overlay, and confirm the current status on the COSAiS project page before each planning cycle.
Treating drafts as passed controls
A discussion draft or annotated outline is not a published control overlay, and it does not establish that any control is in place. The predictive AI annotated outline released on January 8, 2026 was offered for feedback, with initial feedback due February 13, 2026 for an initial public draft. Record each draft as a planning input with its status and date, not as evidence. Before an assessment, confirm which version of any overlay the assessor will use, and keep your own control evidence tied to the baseline controls you actually operate.
Unclear AI system boundaries
Scope creep usually begins when no one can say where an AI system starts and stops. A single assistant may depend on a model endpoint, a retrieval index, plugins, logging pipelines and an identity provider, and each may sit under a different owner. COSAiS separates use cases such as generative AI, predictive AI, single-agent and multi-agent systems, so the use case determines which overlay applies. Before scoping, write a boundary diagram that lists every component, its owner and its use case, and get sign-off from the system owner before controls are assigned.
Mixing AI RMF and SP 800-53 evidence
AI RMF subcategories describe governance outcomes and suggested actions, while SP 800-53 controls describe specific safeguards and assessment procedures. When teams put AI RMF language directly into control evidence, assessors cannot tell which control is satisfied. Build a documented crosswalk that links each AI RMF subcategory to the relevant control or overlay item, and mark any link as your own mapping rather than an official one. Review the crosswalk with your assessor before fieldwork, and keep each evidence artifact tagged to a single control identifier.
Questions SP 800-53 teams ask about COSAiS
Is there a published COSAiS overlay today?
As of the project's January 2026 update, no initial public draft of any COSAiS overlay was listed on the CSRC project page. The published materials were the project concept paper, which was made available for comment on August 14, 2025, and an annotated outline (discussion draft) for the Using and Fine-Tuning Predictive AI overlay, released on January 8, 2026. That outline was tied to Cyber AI Profile Workshop #2, with initial feedback due February 13, 2026 for the initial public draft. Because drafts change quickly, check the NIST COSAiS project page for the current status before you write any control language into a system security plan.
Does COSAiS replace SP 800-53?
No. COSAiS is a series of control overlays built on SP 800-53, so the baseline control catalog stays in place and the overlays add or tailor AI-specific guidance for each use case. Your existing SP 800-53 control implementation, assessment and monitoring processes remain the foundation. The overlays aim to protect the confidentiality, integrity and availability of information and users in each AI use case, drawing also on SP 800-218A, draft NIST AI 800-1 and NIST AI 100-2e2025. Treat them as a layer you apply to systems that use AI, not as a separate framework to adopt.
Do we need COSAiS to use AI in a FedRAMP system?
The COSAiS material published so far does not establish a requirement to use COSAiS for a FedRAMP system. Confirm with your authorizing official, your FedRAMP package reviewers and the current COSAiS project page what applies to your authorization boundary and AI use case. Meanwhile, the defensible approach is to document how your AI components are inside the boundary, which controls apply, and how you assess them against the SP 800-53 baseline you already use. Ask your sponsor in writing whether they expect COSAiS-based content, and note the answer in your decision records.
How much effort should we plan now and what drives it?
No effort estimate for COSAiS overlays has been published, so plan from your own inventory rather than a duration. The main drivers are the number of AI systems in scope, which of the five planned use cases each one matches (generative AI assistants and LLMs, predictive AI, single-agent systems, multi-agent systems, or AI developer security), how many of your SP 800-53 controls already cover the AI components, and how much of the work depends on the draft overlays changing. Start by listing AI components and their data flows, mapping each to a use case, and marking which control implementations need new evidence. That inventory is useful whatever the final overlays say.
Can we do the work ourselves?
Yes, most of the groundwork is internal. Your team already knows its system boundaries, control owners and assessment cycle, and can run the AI component inventory, data flow mapping and gap review against SP 800-53 without outside help. Outside help is most useful for engineering tasks such as hardening self-hosted model services, logging and monitoring for agent actions, and building test evidence. DeployOpen prepares systems, controls and evidence for compliance assessments inside your own infrastructure, under a written, fixed scope, but it does not write the authorization decision or sign off on the controls.
Who certifies or authorizes the result?
Your authorizing official or agency decision-maker authorizes the system, and an independent assessor tests the controls. COSAiS overlays are guidance that NIST publishes, so NIST does not certify or authorize any implementation. For FedRAMP, the authorization decision sits with the government sponsor or other authorizing body. Implementation partners, including DeployOpen, prepare systems, documentation and evidence, but they do not issue assessment reports, attestations or authorizations. Ask any consultant to state in writing which parts of the work they perform and which parts an independent assessor or authorizing official must sign.
How DeployOpen prepares SP 800-53 AI controls and evidence
DeployOpen helps organizations prepare the systems, controls and evidence that an SP 800-53 control program would need once NIST COSAiS overlays are final and adopted. We plan and build self-hosted open-source platforms inside your own infrastructure, and we do not issue audit reports, attestations or certifications.
How we scope
- Engagements are fixed-scope, with the systems, AI use cases and deliverables agreed in writing before work starts.
- We confirm which of the five planned COSAiS use cases apply to your AI systems and which of your existing SP 800-53 baselines they touch.
- We agree with you which NIST drafts are in scope, since COSAiS overlays were still in development and the project page listed no initial public draft as of January 2026.
How we build
- We map your AI components, data flows and access paths to the SP 800-53 control families your program already uses.
- We configure and harden self-hosted platforms in your cloud accounts, data centers or air-gapped networks to support those controls.
- We test the configured systems against the requirements in the written scope, and we record gaps and remediation steps for your review.
How we hand over
- We document each control implementation, with the system configuration, owner and evidence source that an assessor would ask for.
- We deliver evidence packages, including configuration records, test results and logs, organized so your internal team or independent assessor can review them.
- We agree handover of runbooks and documentation, so your staff can operate and update the controls after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, which cover changes as COSAiS drafts and the Cyber AI Profile evolve.
- We can update control documentation and evidence when NIST publishes a revised overlay draft that affects your scope.
- Your organization owns its controls and its authorization decisions, and any formal assessment remains with your independent assessor or authorizing official.
Sources and further reading
- NIST CSRC: Control Overlays for Securing AI Systems (COSAiS) project ↗
- NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models ↗
- NIST IR 8596 (initial preliminary draft), Cybersecurity Framework Profile for AI ↗
- NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0) ↗
- NIST AI 600-1, AI RMF: Generative Artificial Intelligence Profile ↗

