Use NIST’s draft overlays to sharpen the AI security review

AI supplier reviews need a consistent account of use, authority and evidence. A generic cloud questionnaire may cover important infrastructure controls while leaving model, data and tool-specific questions open. Review those gaps against the proposed service rather than adding an undifferentiated AI section.

NIST is developing Control Overlays for Securing AI Systems, built on the SP 800-53 control catalogue that a great many organisations — particularly anyone selling into United States federal supply chains — already use as their control language. The project is explicitly organised around use cases rather than around technology: using a generative assistant, using and fine-tuning a predictive model, single-agent systems, multi-agent systems, and controls for those building AI rather than deploying it.

Use the proposed categories to make the security review more specific. They provide a structure for analysing a service, not a forecast of every buyer’s future questionnaire. The final overlays may change, and the buyer remains responsible for its actual acceptance conditions.

Why the use-case split matters more than the controls

An assistant summarising meeting notes and an agent writing to a production system have different exposure paths. The same policy can govern both if its controls are proportionate and explicit. A uniform checklist without that distinction can omit important authority and effect boundaries.

The overlay structure says something useful about that. These are different security problems with different threat models, and pretending otherwise is what produces policy nobody follows.

1. Case 01 Using a generative assistant The exposure is what goes in and who sees what comes out. Data handling and access, mostly.
2. Case 02 Using and fine-tuning a predictive model The exposure is the training data and the pipeline. Integrity and provenance, mostly.
3. Case 03 A single agent The exposure is what the agent can do. Tool authority, identity, irreversibility.
4. Case 04 Multiple agents All of the above, plus what one agent can cause another to do. Trust between components.
5. Case 05 Building AI systems The exposure is the supply chain — weights, datasets, dependencies and what you pass downstream.

Classify the actual inventory against the relevant use cases and note overlaps. A single service may combine an assistant, predictive model and agent tools. The review should preserve those dependencies rather than force every system into one exclusive category.

What to do with a draft standard

A draft can inform discovery before its wording is final. Map the service and existing controls against the draft’s questions, while recording which conclusions depend on unresolved text. Do not present that exercise as conformance to a final standard.

If your control environment is already expressed in SP 800-53 terms, or in ISO/IEC 27001 terms, the work is to say which existing controls apply to each of the five cases, where they do not reach, and what fills the gap. That analysis holds whatever the published overlay eventually says, because it is an analysis of your estate rather than of the document.

Review agent identity, delegated authority, receiving-service checks and recovery from effects. Existing access, configuration and monitoring controls already address parts of this work. The overlay can help identify adaptations and gaps, rather than implying that classic control catalogues contain no relevant agent controls.

The relationship to everything else

This does not replace the AI Risk Management Framework, and the two do different jobs. The AI RMF is a governance structure — govern, map, measure, manage — that tells an organisation how to reason about AI risk in general. An overlay is a control specification for a particular kind of system, expressed in the language a security function already speaks. Frameworks are for deciding. Overlays are for evidencing.

For an organisation with EU exposure, these overlays do not replace the AI Act’s applicable requirements or conformity route. Use the mapping for the security questions it addresses. Maintain separate evidence for duties outside that scope.

What this does not tell you

The COSAiS materials described here are in development, including a concept paper and discussion outline. Their categories and wording may change. A draft does not establish a final requirement or a certification scheme, and the Institute does not offer certification against it.

It is also not a claim that a control mapping makes a system secure. A mapping tells you which controls you have and which you do not. Whether the ones you have work is a question for testing, and an organisation with a complete map and no red teaming has documented an assumption rather than verified a property.

The security owner should map a consequential service against the relevant use cases, controls and evidence. Record missing authority boundaries and testable gaps, then agree the next review with the business owner. Update the mapping when NIST publishes material changes or the service’s use changes.