NIST 800-53 for AI systems: the COSAiS overlays

A generative AI assistant typically sits in front of users, takes prompts, and draws on internal documents or external model services. Existing Rev. 5 families that assessors commonly examine as areas to tailor include AC for who can use the assistant and which data sources it can reach, AU for recording prompts, responses and administrative actions, SC for protecting data in transit and at rest, and SA for the terms and documentation of any external model service.

• Access scope (AC): Decide which user groups can use the assistant and which repositories it may retrieve from, and record the reasoning.
• Audit content (AU): Determine whether prompts and outputs are logged, how long they are kept, and how logs protect personal or confidential data.
• Boundary and encryption (SC): Document how traffic to the model endpoint is protected and where inference data is stored.
• Acquired services (SA, SR): Record what the model provider documents about data handling, and how that bears on supplier assessment.
• Output handling (SI): Set input validation and monitoring for unsafe or incorrect outputs as part of system integrity.

Confirm with your assessor which families they expect to see examined for this system, and keep each tailoring decision with its risk-based justification in the system security and privacy plan.

A predictive model that informs a regulated decision, such as credit, eligibility or triage, shifts the emphasis toward risk assessment, change control and monitoring of model behavior over time. Assessors often look at RA for categorizing the decision's impact and assessing risk, CM for controlling model versions and changes, SI for monitoring and integrity of inputs and outputs, and PM or PT where the decision uses personal information.

• Impact categorization (RA): Document the decision's consequences and how the model's role informs the security categorization.
• Change control (CM): Track model versions, training data sources and configuration baselines, and approve changes before deployment.
• Monitoring (SI): Define what is monitored for input drift, output anomalies and integrity of the scoring pipeline.
• Personal information (PT): Where the model processes PII, confirm the authority and purpose for processing are documented.
• Risk response (RA, PM): Assign owners for risk acceptance and review decisions when monitoring shows degraded performance.

The regulated context may impose requirements outside SP 800-53, so confirm with your compliance lead which obligations apply before choosing which families to tailor.

An agent that calls tools, APIs or other systems on a user's behalf creates a new set of permissions and actions that must be bounded. Assessors commonly examine AC for least privilege and the scope of each tool, AU for recording tool calls and their outcomes, CM for the allowed tools and configuration of the agent, and SA or SR for the external components and services it depends on.

• Least privilege (AC): Limit each tool credential to the actions the agent needs, and document approval for elevated actions.
• Action logging (AU): Record the tool invoked, the parameters, the initiating user and the result, with protected log storage.
• Configuration baseline (CM): Maintain an inventory of permitted tools, prompts and plug-ins, and control changes to them.
• Component provenance (SR, SA): Track where agent frameworks, plug-ins and models come from, and how they are updated.
• Failure handling (SI, IR): Define how the agent halts on unexpected behavior and how incidents involving agent actions are reported.

Decide which tool actions require human approval, and record that decision with its justification, since the boundary is an organizational determination rather than a control the standard fixes.

An environment where engineers build, fine-tune and test AI systems concentrates risk in training data, code repositories, and build pipelines. Assessors often examine SA for secure development practice and testing, CM for controlling code and model artifacts, AC for access to training data, and SR for the provenance of datasets, libraries and pretrained models. COSAiS has listed controls for AI developers as a planned use case, but no overlay is yet released.

• Secure development (SA): Document secure coding, code review and testing practices that apply to model code and pipelines.
• Artifact control (CM): Track model weights, datasets and container images with versioned baselines and signed components where feasible.
• Data access (AC): Restrict access to training and evaluation data by role, and review that access on a schedule you define.
• Supply chain (SR): Record the source and integrity checks for pretrained models, datasets and open-source dependencies.
• Testing (RA, SI): Scan dependencies and run adversarial or robustness tests, and document the results as assessment evidence.

Make sure the environment's tailoring is documented separately from production systems, since its risk profile and assessment boundary may differ.

Your organization owns the AI system, its controls and every risk decision made about it. No overlay has been released as a final, applicable control set for AI systems, so your team must first decide which SP 800-53 controls and enhancements apply to each AI system through tailoring, and document why. Those decisions belong in the system security and privacy plan (SSP), which records how each control is implemented, by whom and with which parameters.

• Scope and categorization: define the AI system boundary, its data flows, its users and its impact level before selecting controls.
• Tailoring decisions: justify every control added, removed or parameterized, since SP 800-53B expects defensible, risk-based determinations.
• Risk acceptance: decide which residual risks remain open and who accepts them, including those tied to model behavior or third-party models.
• SSP and plan of action and milestones: author, approve and keep current the SSP and track gaps in a plan of action and milestones.
• Operating controls: staff the processes that cannot be automated, such as access reviews, incident response and vendor oversight.

Before engaging any partner or assessor, confirm that your team can name a control owner for every AI-specific control in scope.

An implementation partner such as DeployOpen prepares systems, configuration, logging and evidence for the controls your team has selected. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. It also runs security testing where contracted. It does not own your controls, does not accept risk on your behalf and does not issue audit reports, attestations or certifications.

• Build and configuration: deploy the AI platform components in your environment and apply hardened settings mapped to the selected controls.
• Logging and monitoring: configure audit records, retention and alerting so the evidence the assessor will request exists and is protected.
• Evidence preparation: assemble configuration baselines, access records and test results organized against the control identifiers.
• Security testing: where contracted, test applications, APIs, infrastructure and AI components, including agent behavior, and report findings to your team.
• Documentation handover: deliver runbooks and implementation statements your team reviews and adopts into the SSP.

Confirm in the written scope which controls the partner prepares, which it only tests, and which it does not touch at all.

The independent assessor or auditor tests whether the controls are implemented and operating as the SSP describes, and issues the assessment report or certificate. Assessors use the SP 800-53A procedures, which define determination statements and examine, interview and test methods for each control. Their independence is what gives the result weight, so they should not design the controls they test.

• Procedure-based testing: examine documents, interview staff and test configurations against the SP 800-53A procedures for each control.
• Evidence sampling: request logs, tickets, reviews and test results for a defined period and population.
• Findings and report: record deficiencies and issue the assessment report under the assessor's own name.
• Authorization inputs: the assessment report feeds your authorizing official's decision, which remains your organization's decision.
• Independence rules: confirm the assessor has no role in building or running the AI system being assessed.

Before engaging an assessor, ask which SP 800-53A procedures and AI-specific control sets they will use, and whether they will accept overlay content not yet finalized.