NIST SP 800-53 Controls for LLM Applications

No Native LLM Mapping Exists in SP 800-53

NIST SP 800-53 Revision 5 organizes 20 control families, including Access Control, Audit and Accountability, System and Communications Protection, and Configuration Management. These families are written to be technology-neutral, and the control catalog does not define LLM-specific or generative-AI-specific control identifiers. Related NIST publications inform but do not formally crosswalk to 800-53.

The AI Risk Management Framework (AI RMF 1.0, January 2023) provides a general risk-management structure for AI systems. The Generative AI Profile (NIST AI 600-1, July 2024) identifies generative-AI risk categories such as information integrity, data privacy, and value-chain integration, which overlap conceptually with families like SI and SC without being labeled as such. Draft SP 800-218A extends the Secure Software Development Framework with practices for generative AI, referencing concepts like provenance tracking that relate to AU control objectives but again without explicit control mapping.

Control Families Requiring LLM-Specific Interpretation

Five control families demand the most reinterpretation when applied to LLM architectures. The table below summarizes where conventional assumptions break down and what must be reconsidered.

Access Control and Audit and Accountability for LLM Components

Access Control concepts such as least privilege and role-based access assume static user or service accounts. LLM applications introduce agent identities that invoke tools dynamically based on model reasoning, which does not map cleanly to that assumption. Satisfying AC intent for an LLM system typically requires explicit permission scoping for each tool an agent can call, evaluated at the point of invocation rather than assumed from a static role.

Audit and Accountability controls present a related challenge. Traditional AU controls assume deterministic, reproducible system events, but identical prompts to an LLM can produce different outputs and different tool-calling behavior across sessions. Meeting AU intent requires logging architecture that captures both the input context and the resulting action, such as tool call parameters and the corresponding model output, at a granularity sufficient to reconstruct decision paths even when the underlying behavior is not deterministic.

System and Communications Protection and Configuration Management

System and Communications Protection controls addressing boundary protection and transmission confidentiality apply directly to LLM API calls, tool integrations, and retrieval-augmented data flows, but 800-53 does not define what constitutes an AI-specific boundary. In practice, this means treating each tool call and each retrieval request as a distinct communication path subject to boundary controls, rather than treating the model as a single opaque endpoint.

Configuration Management controls for baseline configuration and change control are complicated by the pace of model updates, prompt template changes, and third-party model version shifts, none of which are addressed in legacy CM guidance written for conventional software releases. Configuration baselines for LLM systems should treat model version, prompt template version, and connected tool or plugin inventory as discrete configuration items, tracked through the same change control process used for other system components.

Runtime policy enforcement, meaning the interception and evaluation of tool calls before execution, is an emerging architectural pattern used to satisfy the intent of both AC and SC controls, though it is not a codified 800-53 requirement.

Where Traditional Controls Fall Short

Several gaps separate conventional 800-53 implementation from the architectural realities of LLM applications. Identification and Authentication controls are written for human or service identities and do not explicitly cover agent-to-agent or agent-to-tool authentication, which is increasingly common in multi-agent and tool-calling architectures.

Access control policy enforcement for agent tool use should sit at a control point separate from the model itself, since model output alone cannot be treated as an authoritative access decision. Non-deterministic model behavior also affects how assessors interpret AU evidence, since two runs of the same workflow may produce different audit trails even without a system fault.

Governance teams should document, for each control family, whether the control translates directly from traditional IT practice or requires a supplementary interpretation or compensating control to address AI-specific risks such as prompt manipulation or dynamic tool invocation.