Security teams are being asked to show which SP 800-53 controls protect their AI systems, and NIST's answer, the COSAiS overlays, is still in draft. The Control Overlays for Securing AI Systems project (renamed by NIST in October 2026, see below) tailors the SP 800-53 catalogue to five AI use cases: generative assistants, predictive models, single agents, multi-agent systems and AI developers. This guide goes deeper than our general NIST Control Overlays Guide: it explains what NIST has actually published, which controls the first annotated outline names, what the overlays say about service accounts and agent identities, and how to apply the approach now without waiting for a final document. It is written for control owners, assessors and architects in US federal agencies, their suppliers, and any organisation that already runs an SP 800-53 programme. Status checked on 8 November 2026.
Key takeaways
- COSAiS is now COSIS. NIST's project page states the project was renamed Control Overlays for Super Intelligence Systems on 20 October 2026, citing a 29 September 2026 executive order; documents already issued keep the original name and the technical scope is unchanged.
- Nothing is final yet. NIST has published a concept paper (14 August 2025) and one annotated outline for predictive AI (8 January 2026); no public draft overlay was listed on the project page when we checked.
- The overlays assume a Moderate baseline. The annotated outline treats the SP 800-53B Moderate baseline as already implemented and adds or tailors controls on top, so an immature base programme cannot be fixed by the overlay.
- Least privilege is written for non-human identities. The AC-6 discussion calls for unique, non-shared identities for training pipelines, inference services and monitoring agents, with service accounts scoped to specific datasets, model artefacts and compute.
- Start with the outline's control set today. AC-6, CM-2, CM-4, RA-5, SA-11(2), SC-7(10), SI-3(8) and SI-4(2) are a defensible interim selection for any AI system you must assess now.
What it is and who it applies to
An overlay is a fully specified set of controls, enhancements, parameter values and supplemental guidance that tailors SP 800-53 for a technology or environment. NIST's concept paper describes the COSAiS overlays as a library that organisations can use individually or combine, to manage the risks of each AI use case alongside their existing cybersecurity programme. They protect the model, model artefacts, related information assets in the deployment infrastructure and the security of outputs. The project page lists training and test data, model weights and configuration settings as components in scope.
The overlays are deliberately narrow. The concept paper says they are not a comprehensive enterprise control set: they assume access control, account management, configuration management and incident response already exist. Broader trustworthiness concerns such as fairness, validity and explainability are left to the NIST AI RMF Guide, which the overlays sit alongside.
The five use cases
| Use case (concept paper name) | Audience | Scenarios NIST describes | Planned volume |
|---|---|---|---|
| Adapting and Using Generative AI: Assistant/LLM | Organisations using AI to create content | Internal summaries and data analysis using retrieval augmented generation, with an on-premises or third-party hosted LLM and local, mixed or web data | NISTIR 8605B |
| Using and Fine-Tuning Predictive AI | Organisations using historical data to inform decisions | Third-party or on-premises models with proprietary or public-facing input; the outline uses predictive maintenance and candidate recruitment screening | NISTIR 8605A |
| Using AI Agent Systems: Single Agent | Organisations automating tasks and workflows | An enterprise copilot connected to email, files, calendars and internal systems through MCP; a coding assistant that edits code, manages pull requests, runs tests and helps deploy | NISTIR 8605D |
| Using AI Agent Systems: Multi-Agent | Organisations automating multi-workstream tasks | Cooperating agents over MCP or A2A, illustrated by an expense reimbursement workflow; NIST calls this the least mature use case | NISTIR 8605D |
| Security Controls for AI Developers | AI developers | Maps SP 800-53 controls to model artefacts and practices in SP 800-218A and draft NIST AI 800-1 | NISTIR 8605C |
Who it applies to: the overlays are guidance, not a mandate. They matter most to federal agencies and contractors whose systems are authorised against SP 800-53, to cloud providers preparing AI services for federal authorisation (see the FedRAMP Guide), and to private organisations that use SP 800-53 as their control catalogue. Any FedRAMP use of the overlays would be a FedRAMP decision; we found no FedRAMP statement adopting them.
Structure and key requirements
The January 2026 annotated outline for predictive AI is the only document that shows how an overlay will look. It sets out the planned series: NISTIR 8605 (overview and methodology), 8605A (predictive AI), 8605B (generative AI), 8605C (AI developers) and 8605D (agentic AI, single and multi-agent). Each overlay control entry has three tailoring elements: a Control Requirement, Organization-Defined Parameters and a Discussion. Each control is flagged as in or out of the SP 800-53B Moderate baseline, tied to lifecycle phases (Model Training, Model Deployment, Model Maintenance, Continuous) and linked to attacks in NIST AI 100-2e2025, the adversarial machine learning taxonomy covered in our Adversarial ML Taxonomy Guide. Control enhancements can be selected without the base control, which is assumed to exist in the underlying IT system.
Controls written up in the predictive AI outline
| Control | In Moderate baseline | Lifecycle phase | What it protects in an AI system |
|---|---|---|---|
| AC-6 Least Privilege | Yes | Continuous | Scoped access for pipelines, inference services and agents to data, artefacts and compute |
| CM-2 Baseline Configuration | Yes | Training, Maintenance | Known-good model, pipeline and environment configuration |
| CM-4 Impact Analyses | Yes | Continuous | Assessing retraining, fine-tuning and data changes before release |
| RA-5 Vulnerability Monitoring and Scanning | Yes | Continuous | Frameworks, libraries and model-serving stacks |
| SA-11(2) Threat Modeling and Vulnerability Analyses | No | Training, Deployment | Threat models that include poisoning, evasion and extraction |
| SA-15(1) Quality Metrics | No | Training, Deployment | Defined model quality thresholds as release criteria |
| SA-15(8) Reuse of Threat and Vulnerability Information | No | Training, Deployment, Maintenance | Feeding AI attack intelligence into development |
| SC-5(3) Detection and Monitoring (DoS) | No | Deployment, Maintenance | Resource exhaustion of inference endpoints |
| SC-7(10) Prevent Exfiltration | No | Deployment, Maintenance | Model and data exfiltration, including through query abuse |
| SI-3(8) Detect Unauthorized Commands | No | Continuous | Unauthorised commands reaching model services |
| SI-4(2) Automated Tools for Real-time Analysis | Yes | Continuous | Live monitoring of inputs, outputs and drift |
The outline also proposes, without full write-ups yet, controls including AC-3, AC-22, AU-2, AU-6, CA-3, CA-7, CA-8, CM-3, CM-5, CM-6, SC-28, SI-7, SI-10, SR-4 and SR-11. Read that list as the likely shape of 8605A, not as a final selection.
Identity and NHI requirements
AI systems are run almost entirely by non-human identities: training jobs, feature pipelines, inference services, evaluation harnesses, monitoring agents and, in the agentic use cases, the agents themselves. The AC-6 discussion in the annotated outline is the clearest identity requirement NIST has published for the series so far. It applies least privilege to non-human identities, including services and AI agents, recommends unique and non-shared identities for training pipelines, inference services and monitoring agents, restricts service accounts to specific datasets, model artefacts and compute resources, notes that access needs change across the lifecycle, and suggests integrating AC-6 into the enterprise ICAM implementation.
- Separate identities per lifecycle stage: a training identity that can read curated datasets and write candidate weights should not be the identity that serves the model. Promotion to production should be a controlled change (CM-3, CM-5) performed by a distinct release identity.
- Service authentication: the outline assumes the base programme already provides IA-9 Service Identification and Authentication and IA-5 Authenticator Management. Use workload identity federation instead of static keys where the platform supports it. See the Workload Identity Federation Guide.
- Agent identities: the agentic volume (8605D) has not been drafted. Until it is, apply AC-6, AC-2 Account Management and AC-24 Access Control Decisions to each agent as a distinct identity with an owner, and log every tool call (AU-2, AU-12). The concept paper's single-agent scenarios connect agents to email, files and code repositories through MCP, which makes the agent's delegated tokens the main exposure. See the Agent Identity and Access Guide and the MCP Security Guide.
- Lifecycle reviews: because access needs change between training, deployment and maintenance, recertify AI service accounts at each stage gate, not only on a calendar.
Implementation steps
- Confirm the base. Check the AI system's authorisation boundary against the Moderate baseline. Gaps in AC-2, CM-2 or AU-2 at the base level will undermine every overlay control.
- Classify each AI system by use case. Assign it to one or more of the five use cases; a coding assistant that also calls a hosted LLM touches both the generative and single-agent use cases, and overlays are designed to be combined.
- Inventory AI components. Record models, weights, training and test datasets, configuration, prompts, connectors and the non-human identities that touch each one. This feeds CM-8 style inventory and the ID.AM outcomes in CSF 2.0.
- Select interim controls. Adopt the eleven written-up controls from the predictive outline as a floor for every AI system, then add SC-28 and SI-7 for weights and datasets at rest, and SR-4 and SR-11 for third-party models.
- Set parameters. Define the organisation-defined values the overlay leaves open: monitoring thresholds for SI-4(2), exfiltration indicators for SC-7(10), quality metrics for SA-15(1), and review frequency for AC-6(7).
- Write AI-specific discussion text. In the system security plan, explain how each control addresses poisoning, evasion, extraction and drift, citing NIST AI 100-2e2025 attack classes as the outline does.
- Pilot on one system. Assess one predictive or RAG system end to end before rolling the selection across the portfolio.
- Track NIST and reconcile. When NISTIR 8605 and 8605A drafts appear, map your interim selection to them and record differences as tailoring decisions. Keep the interim selection as the documented fallback if a draft changes materially.
Small and large organisations: a small team can adopt the eleven-control floor and a single AI section in its system security plan. A large agency or provider should build a reusable organisational overlay with standard parameter values, so every AI system is assessed the same way.
Evidence and assessment
Because the overlays reuse SP 800-53, assessors can use the SP 800-53A assessment procedures they already know. What changes is the evidence.
| Control | Evidence an assessor should expect for an AI system |
|---|---|
| AC-6 | List of AI service accounts and agent identities, their scopes to datasets, artefact stores and compute, and the last review date |
| CM-2, CM-4 | Versioned model and pipeline configuration; impact analysis records for retraining and fine-tuning releases |
| RA-5 | Scan results covering ML frameworks, model-serving containers and notebooks |
| SA-11(2) | A threat model that names AI attack classes and the mitigations chosen |
| SC-7(10) | Egress controls on training and serving environments; alerts for bulk artefact downloads or unusual query volumes |
| SI-4(2) | Real-time monitoring of inference inputs and outputs, with alert and triage records |
| SC-28, SI-7 | Encryption and integrity verification (hashes or signatures) for weights and datasets |
Metrics that show it is working:
- Percentage of AI systems with a documented use case classification and overlay selection.
- Percentage of AI non-human identities that are unique, owned and reviewed within the last 90 days.
- Percentage of model releases with a recorded CM-4 impact analysis.
- Mean time to triage SI-4(2) alerts on inference services.
- Number of shared or static credentials used by AI pipelines, trending to zero.
Mapping to other frameworks
| Overlay control | NIST CSF 2.0 | Related NIST AI document |
|---|---|---|
| AC-6, AC-2, IA-9 | PR.AA-01, PR.AA-05 | Annotated outline AC-6 discussion on non-human identities |
| CM-2, CM-3, CM-4 | PR.PS-01 | SP 800-218A for developer practices |
| RA-5 | ID.RA-01 | NIST AI 100-2e2025 attack classes |
| SC-28, SI-7 | PR.DS-01 | Model weights named as in-scope component |
| SI-4(2), SC-7(10) | DE.CM-09 | NIST AI 100-2e2025 extraction and evasion |
| SR-4, SR-11 | GV.SC-07 | Draft NIST AI 800-1 for foundation model developers |
NIST says it is coordinating the overlays with the Cybersecurity Framework Profile for AI so the two are complementary; see the NIST Cyber AI Profile Guide. For developer-side practices that Use Case 5 will map, see the NIST SP 800-218A SSDF Community Profile for Generative AI Guide. Organisations certifying to ISO/IEC 27001 can carry the selection across with the NIST SP 800-53 to ISO 27001 Mapping Guide.
Common pitfalls
- Waiting for the final overlay. The outline targeted Q3 FY2026 for public drafts of NISTIR 8605 and 8605A and 2027 for finalisation, pending resources. That date has passed without a listed draft. Systems going live now need an interim selection.
- Treating the overlay as the whole control set. NIST is explicit that it is not. An AI system with no AC-2 account lifecycle or AU-6 log review is not made secure by adding SC-7(10).
- One shared service account for the pipeline. A single identity that reads data, trains, publishes and serves breaks the AC-6 guidance and makes weight theft or poisoning hard to attribute.
- Ignoring the rename in records. Searching or citing only "COSIS" or only "COSAiS" misses half the material. Record both names in policy references.
- Copying the outline's attack identifiers. The draft's attack references are work in progress; cite NIST AI 100-2e2025 attack classes by name until the published overlay fixes the identifiers.
- Applying the agentic use cases without agent identity controls. Agents connected through MCP to mail and code repositories hold powerful delegated tokens; scope them before the overlay arrives, not after.
Practitioner checklist
- Record the project under both names, COSAiS and COSIS, and subscribe to the NIST project page and mailing list for draft releases.
- Confirm each AI system meets the SP 800-53B Moderate baseline before adding overlay controls.
- Classify every AI system against the five use cases and note where more than one applies.
- Inventory models, weights, datasets, configuration and the non-human identities that touch them.
- Adopt the eleven written-up controls from the predictive outline as an interim floor, plus SC-28, SI-7, SR-4 and SR-11.
- Give training, release, inference and monitoring their own unique identities, each scoped to named datasets, artefacts and compute.
- Set organisation-defined parameters and AI-specific discussion text in each system security plan.
- Collect the evidence listed above and run one pilot assessment before scaling.
- Reconcile your selection with NISTIR 8605 drafts when they are published and document the differences.
Standards and references
- NIST: SP 800-53 Control Overlays for Super Intelligence Systems (COSIS), formerly COSAiS
- The White House: Executive Order 14434, Inaugurating the Era of Super Intelligence (29 September 2026)
- NIST: SP 800-53 Control Overlays for Securing AI Systems Concept Paper
- NIST: Control Overlays for Securing AI Systems, Using and Fine-Tuning Predictive AI, Annotated Outline
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- NIST: AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
- NIST: SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
Related NHI Mgmt Group resources: NIST Control Overlays Guide · NIST Cyber AI Profile Guide · Agent Identity and Access Guide · Securing AI Model Weights. This guide summarises NIST guidance that is still in draft and is not legal advice.