NIST SP 800-53 Rev 5.2 Control Overlay for Agentic AI Systems
August 11, 2026 · View on GitHub
Version: 0.1.0 | Impact Level: FIPS Moderate | Scope: Single-agent, internal enterprise
Quick Reference
35 controls across 10 families. Key families for AI agent systems:
| Family | Controls | Agent-Specific Focus |
|---|---|---|
| AC (Access Control) | AC-2, AC-3, AC-5, AC-6, AC-12, AC-17 | Agent identity, least privilege, session management |
| AU (Audit) | AU-2, AU-3, AU-6, AU-12 | Agent action logging, structured audit records |
| CM (Config Mgmt) | CM-2, CM-3, CM-5, CM-6, CM-7 | Baseline configs, change control, least functionality |
| IA (Identification) | IA-2, IA-5, IA-8 | Agent authentication, credential management |
| SA (System Acq) | SA-4, SA-11, SA-15 | Acquisition, testing, development process |
| SI (System Integrity) | SI-2, SI-3, SI-10, SI-11 | Input validation, malicious code protection |
Full control overlay with agent behaviors and verification methods in sections below.
Disclaimer: This document is informational only and is not authoritative federal policy. It does not replace NIST SP 800-53, the COSAiS project deliverables, or agency-specific security plans. Each agency must tailor these control overlays to their specific Authority to Operate (ATO) requirements, organizational policies, risk tolerance, and applicable laws and regulations.
Key words: "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used per RFC 2119.
1. Introduction
1.1 Purpose
This document provides a NIST SP 800-53 Rev 5.2 control overlay specifically tailored for federal information systems that incorporate AI coding agents. It maps standard security controls to the concrete behaviors, risks, and verification methods relevant when an AI agent assists a developer in writing, reviewing, testing, and deploying software.
A control overlay selects, supplements, and refines a baseline set of controls for a specific technology context. This overlay addresses the question: What additional or modified implementation detail is needed when an AI coding agent operates within a FIPS Moderate system?
1.2 Relationship to NIST COSAiS
The NIST COSAiS (Control Overlays for Securing AI Systems) project is developing official 800-53 overlays for AI systems. This document is aligned with the COSAiS project goals and structure but is not an official COSAiS deliverable. When official COSAiS overlays are published, agencies SHOULD adopt those authoritative documents and use this overlay as supplemental implementation guidance specific to coding agents.
1.3 How to Use This Document
- Identify applicable controls from your system's FIPS Moderate baseline (see NIST SP 800-53B)
- Locate the control in the tables below to find agent-specific implementation detail
- Implement the standard control requirement plus the agent-specific guidance
- Verify using the specified verification method
- Cross-reference the linked section of AGENTS.md or docs/CODING_PRACTICES.md for behavioral rules and coding standards that operationalize the control
1.4 Scope
- System type: Internal enterprise applications with AI coding agent assistance
- Agent model: Single agent assisting a single developer (not multi-agent orchestration)
- Impact level: FIPS Moderate (the most common baseline for federal internal systems)
- Agent activities covered: Code generation, code review, testing, dependency management, configuration management, documentation, and deployment assistance
2. Priority Legend
Controls are prioritized based on the immediacy of risk when AI agents are introduced into the development workflow.
| Priority | Label | Timeline | Criteria |
|---|---|---|---|
| P1 | Critical | Implement immediately (before agent use) | Controls that, if absent, create direct risk of data breach, unauthorized access, or loss of accountability. The system MUST NOT operate an AI agent without these controls in place. |
| P2 | Important | Implement within 30 days of agent deployment | Controls that reduce significant risk and are required for ongoing compliance. Temporary compensating controls MAY be used during the 30-day window. |
| P3 | Recommended | Implement within 90 days of agent deployment | Controls that strengthen the security posture and improve operational maturity. These SHOULD be implemented but are lower risk if briefly deferred. |
3. Control Families
3.1 AC — Access Control
Access control is foundational for AI agents. Agents inherit the permissions of the invoking user but introduce new risks: they may request resources the user did not intend, operate across session boundaries, or accumulate privileges through tool chaining.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| AC-2 | Account Management | P1 | Manage information system accounts including establishing, activating, modifying, reviewing, disabling, and removing accounts. | AI agents MUST operate under a distinct, identifiable account or token that is traceable to both the agent and the invoking user. Shared or generic agent credentials are prohibited. Agent accounts MUST be reviewed quarterly and disabled when not in active use. Agencies SHOULD maintain an inventory of all agent accounts and their associated permissions. | Review account inventory for agent-specific entries; verify each agent token maps to exactly one user; confirm quarterly review records exist. | AGENTS.md 2.1 |
| AC-3 | Access Enforcement | P1 | Enforce approved authorizations for logical access to information and system resources. | Agent access MUST be enforced through the same authorization mechanisms as human users (RBAC/ABAC). The agent MUST NOT bypass access controls by using tool chaining, API composition, or indirect access paths. Every resource access by the agent MUST be checked against the invoking user's permissions at the time of the request, not at session establishment. | Attempt agent operations against resources outside the user's authorized scope; confirm denial; review access logs for unauthorized access attempts. | AGENTS.md 3.1 |
| AC-5 | Separation of Duties | P2 | Enforce separation of duties through assigned access authorizations. | The agent MUST NOT both generate code and approve it for production deployment. The development and review/approval functions MUST remain with separate human individuals. The agent MAY assist with review (flagging issues, running scanners) but MUST NOT be the sole reviewer for production-bound code. | Verify that CI/CD pipelines require a human approval gate that the agent cannot satisfy; confirm no agent token has both write and merge permissions on protected branches. | AGENTS.md 8.2 |
| AC-6 | Least Privilege | P1 | Employ the principle of least privilege, allowing only authorized accesses necessary for users to accomplish assigned tasks. | Agent permissions MUST be scoped to the current task, not broadly granted. The agent MUST NOT request or use write access to production systems, administrative interfaces, or security infrastructure unless the specific task requires it and the user explicitly approves. File system access SHOULD be restricted to the project directory. Network access SHOULD be limited to explicitly authorized endpoints. | Review agent token scopes and compare against minimum required permissions; test that agent cannot access resources outside its designated scope; verify no wildcard or administrative permissions are assigned. | AGENTS.md 3.1 |
| AC-12 | Session Termination | P2 | Automatically terminate a user session after a defined period of inactivity or under defined conditions. | Agent sessions MUST have a defined maximum duration and idle timeout consistent with agency session management policy. Agent sessions MUST NOT persist credentials, tokens, or state between unrelated sessions. When a session terminates, all cached credentials, temporary files, and in-memory secrets MUST be purged. | Verify session timeout configuration; confirm that after session expiration the agent cannot perform authenticated actions; test that no credentials persist on disk after session termination. | AGENTS.md 2.3 |
| AC-17 | Remote Access | P2 | Establish usage restrictions, configuration requirements, connection requirements, and implementation guidance for each type of remote access allowed. | When the AI agent operates through a cloud-hosted service (e.g., SaaS IDE, hosted API), the remote access pathway MUST use FIPS-validated encryption (TLS 1.2+). Agency network security teams MUST authorize the remote access path before agent deployment. The agent MUST NOT create tunnels, reverse shells, or unapproved network connections. | Review network architecture diagrams for agent communication paths; verify TLS version and cipher suites; confirm agency approval documentation for each remote access method. | AGENTS.md 6.1 |
3.2 AU — Audit and Accountability
AI agents can perform dozens of actions per minute. Without adequate audit logging, it becomes impossible to reconstruct what the agent did, why it did it, and whether its actions were appropriate.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| AU-2 | Event Logging | P1 | Identify the events that the system is capable of logging in support of the audit function. | The following agent-specific events MUST be logged: all file creates, reads, modifications, and deletions; all command executions (including the full command string); all network requests (destination, method, status code); all dependency installations and modifications; all git operations; all prompts and instructions received from the user. Agencies SHOULD also log agent decision rationale for significant actions. | Review the logging configuration to confirm all listed event types are captured; generate each event type and confirm it appears in audit logs within the expected timeframe. | AGENTS.md 2.2 |
| AU-3 | Content of Audit Records | P1 | Ensure that audit records contain sufficient information to establish what events occurred, when they occurred, where they occurred, the sources of the events, and the outcomes of the events. | Agent audit records MUST include: (1) timestamp in ISO 8601 UTC format, (2) the agent identifier (name, version), (3) the invoking user identity, (4) the action performed, (5) the target resource (file path, URL, command), (6) the outcome (success/failure), and (7) a session or correlation ID linking the action to the originating user request. Records SHOULD include the prompt or instruction that triggered the action. | Inspect a sample of audit records for completeness against the seven required fields; verify no fields are blank or contain placeholder values. | AGENTS.md 2.2 |
| AU-6 | Audit Record Review, Analysis, and Reporting | P2 | Review and analyze system audit records for indications of inappropriate or unusual activity. | Agencies MUST establish a process to review agent audit logs at a frequency commensurate with risk (at minimum weekly for active agent deployments). Reviews SHOULD look for: (1) actions outside normal working hours, (2) access to files or systems not related to the assigned task, (3) unusually high volume of operations, (4) failed access attempts, and (5) patterns indicating prompt injection or goal hijacking. Automated alerting SHOULD supplement manual review. | Confirm audit review schedule is documented and followed; verify that at least one review has occurred in the past review period; confirm alerting rules exist for the five listed anomaly patterns. | AGENTS.md 2.2 |
| AU-12 | Audit Record Generation | P1 | Provide audit record generation capability for the events defined in AU-2 at all system components where needed. | Agent audit logging MUST be enabled by default and MUST NOT be configurable to a disabled state by the agent itself. The agent MUST NOT be able to modify, delete, or suppress its own audit logs. Log storage MUST be separate from the agent's operational file system (e.g., a centralized SIEM, append-only log service, or write-once storage). | Verify that the agent cannot write to or delete entries from the log store; confirm that disabling logging requires an administrative action outside the agent's capabilities; test that logs are being written to the designated central log repository. | AGENTS.md 2.2 |
3.3 CM — Configuration Management
AI agents modify configurations, install dependencies, and alter build pipelines. Without configuration management controls, agents can introduce drift, create unauthorized configurations, or subvert change management processes.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| CM-2 | Baseline Configuration | P2 | Develop, document, and maintain a current baseline configuration of the information system. | The development environment baseline MUST document which AI agent(s) are authorized, their versions, permitted plugins/extensions, and their configuration settings. Changes to the agent configuration (model version, tool permissions, prompt templates) MUST be tracked as baseline changes. Agencies SHOULD maintain a configuration file (e.g., AGENTS.md or equivalent) in version control that defines the agent's authorized behavior. | Review the documented baseline for agent-related entries; compare the running agent configuration against the documented baseline; verify the baseline is version-controlled and has a change history. | AGENTS.md 12.1 |
| CM-3 | Configuration Change Control | P1 | Track, review, approve, and audit changes to the information system. | All changes made by the agent to source code, configuration, infrastructure definitions, and CI/CD pipelines MUST go through the same change control process (pull requests, code review, approval gates) as human-authored changes. The agent MUST NOT commit directly to protected branches. Agents MUST NOT bypass pre-commit hooks, required reviewers, or CI checks. | Verify that the agent cannot push directly to main/production branches; confirm pre-commit hooks run on agent-generated commits; review recent agent-authored PRs for required approvals. | AGENTS.md 3.2 |
| CM-5 | Access Restrictions for Change | P2 | Define, document, approve, and enforce physical and logical access restrictions associated with changes to the information system. | Agent write access to production environments, infrastructure configurations, and security-critical files (authentication modules, authorization policies, encryption configurations) MUST require explicit human approval for each change. The agent MUST NOT have standing write access to production. Deployment credentials SHOULD be restricted to CI/CD service accounts that the agent cannot directly invoke. | Verify that the agent has no credentials granting direct production access; confirm that production deployment requires a human-initiated action; test that the agent cannot modify security-critical configuration files without triggering an approval workflow. | AGENTS.md 3.2 |
| CM-6 | Configuration Settings | P2 | Establish and document mandatory configuration settings for IT products using the most restrictive mode consistent with operational requirements. | Agent tools MUST be configured with the most restrictive settings by default (e.g., no network access, no system-level package installation, project-directory-only file access). Agents MUST NOT be able to modify their own configuration settings. Configuration changes MUST require administrative action by an authorized human. | Review agent configuration for default-deny posture; test that the agent cannot alter its own tool permissions; verify that configuration files are protected from agent modification. | AGENTS.md 12.1 |
| CM-7 | Least Functionality | P1 | Configure the system to provide only essential capabilities and prohibit or restrict the use of non-essential functions, ports, protocols, and services. | Agent capabilities (tools, commands, file system access, network access) MUST be limited to those required for the assigned task. The agent MUST NOT have the ability to install arbitrary system packages, open network ports, start services, or modify OS-level configurations. Agencies SHOULD maintain an explicit allowlist of permitted agent capabilities rather than relying on a denylist of prohibited ones. | Review the agent's tool and capability configuration for an explicit allowlist; test each prohibited action (port opening, package installation, service start) and confirm it is blocked; compare enabled capabilities against task requirements. | AGENTS.md 3.1, AGENTS.md 10 |
3.4 IA — Identification and Authentication
AI agents introduce a new class of non-person entity (NPE) that must be identified and authenticated distinctly from the human users they assist.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| IA-2 | Identification and Authentication (Organizational Users) | P1 | Uniquely identify and authenticate organizational users or processes acting on behalf of organizational users. | The AI agent MUST be uniquely identifiable in all system interactions. The agent's identity MUST be distinct from the human user's identity (separate token, service account, or user-agent string). Multi-factor authentication requirements for the invoking user MUST NOT be bypassed by agent delegation. The agent MUST NOT authenticate using a human's personal credentials. | Verify that agent actions are attributed to a distinct agent identity in audit logs; confirm the agent uses a dedicated token (not a personal access token); verify MFA is enforced on the user session that invokes the agent. | AGENTS.md 2.1 |
| IA-5 | Authenticator Management | P1 | Manage information system authenticators by verifying the identity of the individual, group, role, or device receiving the authenticator. | Agent tokens and credentials MUST be managed with the same rigor as human credentials: rotated on a defined schedule (at minimum every 90 days), revoked immediately upon compromise, and stored in approved secrets management systems (never in source code, environment files committed to version control, or agent configuration files). Agent tokens SHOULD be short-lived (hours, not months) and scoped to minimum required permissions. | Verify agent tokens are stored in an approved secrets management system; confirm rotation schedule documentation; check token creation dates against the rotation policy; verify no agent tokens appear in version control history. | docs/CODING_PRACTICES.md 4 |
| IA-8 | Identification and Authentication (Non-Organizational Users) | P2 | Uniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users. | When the AI agent is provided by a third-party vendor (e.g., a SaaS AI coding assistant), the agent's identity and the vendor's authentication mechanisms MUST be evaluated as part of the system's ATO. The agency MUST verify that the vendor's agent identification meets federal identity assurance requirements. Agencies SHOULD require FedRAMP authorization for cloud-hosted AI agent services. | Review ATO documentation for third-party agent identity assessment; verify FedRAMP authorization status of cloud-hosted agent services; confirm vendor authentication mechanisms are documented and assessed. | AGENTS.md 2.1 |
3.5 IR — Incident Response
AI agents can both cause and detect security incidents. Agents may introduce vulnerabilities through generated code, mishandle sensitive data, or be manipulated through prompt injection. Conversely, agents may discover vulnerabilities or anomalies during their operation.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| IR-4 | Incident Handling | P1 | Implement an incident handling capability for security incidents that includes preparation, detection, analysis, containment, eradication, and recovery. | The agency's incident response plan MUST address AI agent-specific scenarios: (1) agent-generated code introduces a vulnerability into production, (2) agent credentials are compromised, (3) prompt injection causes the agent to take unauthorized actions, (4) agent accesses or discloses data outside its authorization scope. Response procedures MUST include the ability to immediately revoke the agent's credentials and disable agent access. The agent itself MUST stop and report to the user when it detects a potential security issue rather than attempting independent remediation. | Verify the incident response plan includes AI agent scenarios; conduct a tabletop exercise for at least one agent-specific scenario; confirm the ability to revoke agent access within the required timeframe (per agency policy). | AGENTS.md 9.1 |
| IR-6 | Incident Reporting | P2 | Require personnel to report suspected security incidents to the organizational incident response capability. | Procedures MUST define when and how to report AI agent-related security incidents. Reportable agent events include: agent acting outside its authorized scope, agent generating code containing known vulnerability patterns, agent accessing data it should not have access to, suspected prompt injection, and agent credential compromise. The agent itself MUST log all anomalies and surface them to the user; it MUST NOT independently decide that an anomaly is not worth reporting. | Verify reporting procedures cover agent-specific incident types; review recent agent anomaly logs for proper escalation; confirm that the incident reporting workflow is documented and accessible to all agent users. | AGENTS.md 9.2 |
3.6 RA — Risk Assessment
Introducing AI agents into the development workflow changes the risk profile of the information system. Risk assessments must account for agent-specific threat vectors.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| RA-3 | Risk Assessment | P2 | Conduct an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits. | The system risk assessment MUST address AI agent-specific threats: prompt injection, insecure code generation, supply chain compromise through agent-suggested dependencies, data exfiltration through agent tool use, privilege escalation through tool chaining, and loss of accountability if agent actions are not properly attributed. The assessment SHOULD reference the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications as threat enumerations. Risk assessments MUST be updated when the agent model version, vendor, or capability set changes. | Verify the risk assessment document includes AI agent threat analysis; confirm it references OWASP LLM and Agentic top-10 lists; check that the assessment has been updated since the most recent agent configuration change. | AGENTS.md 1 |
| RA-5 | Vulnerability Monitoring and Scanning | P1 | Monitor and scan for vulnerabilities in the information system and hosted applications and remediate discovered vulnerabilities. | Vulnerability scanning MUST include AI agent-generated code. Static application security testing (SAST) and software composition analysis (SCA) MUST run on all code, regardless of whether a human or an agent wrote it. Scanning MUST occur before code is merged to protected branches. Known vulnerability databases (NVD, GitHub Advisory, OSV) MUST be checked for all agent-recommended dependencies before installation. The agent itself SHOULD check for known vulnerabilities before suggesting a dependency. | Verify that SAST and SCA tools run in CI on all pull requests (including agent-authored PRs); confirm dependency vulnerability scanning is integrated into the development workflow; review scan results for recent agent-authored code changes. | AGENTS.md 9.2, docs/CODING_PRACTICES.md 5.2 |
3.7 SA — System and Services Acquisition
AI agents are often third-party services or tools. Acquisition, development process, and supply chain controls must extend to the agent itself and the code it generates.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| SA-4 | Acquisition Process | P2 | Include security and privacy requirements, descriptions, and criteria in the acquisition contract for the information system, component, or service. | Contracts or terms of service for AI coding agent tools MUST address: (1) where user code and prompts are sent and stored, (2) whether code is used for model training, (3) data residency requirements (FedRAMP boundary), (4) incident notification procedures, (5) compliance with FIPS cryptographic requirements for data in transit and at rest, and (6) the vendor's vulnerability disclosure and patching process. Agencies SHOULD require FedRAMP authorization for cloud-hosted agent services. | Review procurement documentation or terms of service for the six required topics; verify FedRAMP authorization status; confirm data residency meets agency requirements. | docs/CODING_PRACTICES.md 5.1 |
| SA-11 | Developer Testing and Evaluation | P1 | Require the developer of the system, component, or service to create and implement a security assessment plan and produce evidence of execution. | All AI agent-generated code MUST undergo the same testing requirements as human-written code: unit tests, integration tests, and security testing. The agent MUST NOT self-certify its own output as tested and secure. Human developers retain responsibility for verifying test adequacy. Test coverage MUST include the specific risks of AI-generated code: hallucinated API calls, insecure patterns, and incorrect error handling. Agencies SHOULD require that agents generate tests alongside production code. | Verify that CI pipelines enforce test execution on agent-authored code; confirm that test coverage reports include agent-generated files; review test cases for coverage of AI-specific risk patterns (hallucinated APIs, insecure defaults). | AGENTS.md 8, docs/CODING_PRACTICES.md 1.2 |
| SR-3 | Supply Chain Controls and Processes (incl. former SA-12 Supply Chain Protection) | P2 | Protect against supply chain threats to the system, component, or service by employing appropriate security safeguards. (SA-12 was withdrawn in 800-53 Rev 5 and incorporated into the SR family; see the consolidated SR-3 row below for the full agent-specific implementation.) | The AI agent itself is a supply chain component — assess the agent vendor's security practices, data handling, and update mechanisms; dependencies the agent suggests/installs are subject to the same supply chain controls. See the SR-3 row below for full guidance. | See consolidated SR-3 row. | AGENTS.md 7, docs/CODING_PRACTICES.md 5 |
| SA-15 | Development Process, Standards, and Tools | P2 | Require developers to follow a documented development process that includes defined security and privacy standards, tools, and practices. | The development process documentation MUST address AI agent use: when agents may be used, what types of tasks they may perform, what review processes apply to agent-generated output, and what tools are authorized. Agents MUST be configured to follow the documented coding standards (e.g., via AGENTS.md, docs/CODING_PRACTICES.md, or equivalent project-level configuration). The documented process MUST specify that human review is required before agent-generated code reaches production. | Verify the development process documentation addresses AI agent use; confirm agents are configured with project-level behavior rules; review recent agent-authored PRs for compliance with the documented process. | docs/CODING_PRACTICES.md 1.1 |
3.8 SC — System and Communications Protection
AI agents communicate with external services (model APIs, package registries, documentation sources) and handle sensitive code and data. Communications protection controls must extend to all agent communication paths.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| SC-7 | Boundary Protection | P1 | Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system. | All agent communication with external services (model inference APIs, package registries, documentation sources) MUST transit approved network boundaries and be subject to the same monitoring and filtering as other system communications. The agent MUST NOT bypass network segmentation, proxy configurations, or firewall rules. Agencies MUST document all external endpoints the agent communicates with and include them in the system's boundary definition and authorization. | Review network flow diagrams for agent communication paths; verify all agent-accessed endpoints are documented in the system authorization boundary; confirm proxy/firewall rules apply to agent traffic; test that the agent cannot reach unauthorized external endpoints. | AGENTS.md 6.1 |
| SC-8 | Transmission Confidentiality and Integrity | P1 | Protect the confidentiality and integrity of transmitted information. | All data transmitted between the agent and external services (including the model inference API, which receives source code and prompts) MUST be encrypted using FIPS-validated cryptographic mechanisms (TLS 1.2 or later with approved cipher suites). Certificate validation MUST NOT be disabled. The agent MUST NOT transmit sensitive data (source code, credentials, PII) over unencrypted channels. | Verify TLS version and cipher suite configuration for all agent communication paths; confirm certificate validation is enforced; test that the agent rejects connections with invalid or self-signed certificates (unless an agency-managed CA is in use). | AGENTS.md 6.1, docs/CODING_PRACTICES.md 8.1 |
| SC-13 | Cryptographic Protection | P2 | Implement FIPS-validated or NSA-approved cryptography to protect information confidentiality and integrity. | When the agent generates code that uses cryptographic functions, the code MUST use FIPS 140-2/3 validated modules or libraries. The agent MUST NOT generate custom cryptographic implementations, weak algorithms (MD5, SHA-1 for security purposes, DES, RC4), or hardcoded keys/IVs. The agent SHOULD recommend current NIST-approved algorithms (AES-256, SHA-256 or higher, RSA-2048+ or ECDSA P-256+). | Review agent-generated code for cryptographic function usage; verify all referenced libraries are FIPS-validated; scan for weak algorithm usage and hardcoded cryptographic material. | AGENTS.md 5.4 |
| SC-28 | Protection of Information at Rest | P1 | Protect the confidentiality and integrity of information at rest. | Any data the agent writes to disk (temporary files, cached responses, generated code containing sensitive values, session state) MUST be protected using FIPS-validated encryption when it contains sensitive information. The agent MUST NOT write secrets, credentials, or PII to unencrypted temporary files, log files, or working directories. When a session ends, the agent MUST ensure temporary files are securely deleted. | Verify that agent working directories do not contain residual sensitive data after session termination; confirm encryption is applied to any agent-managed persistent storage; scan agent temporary file locations for secrets or PII. | AGENTS.md 4.1, docs/CODING_PRACTICES.md 4 |
3.9 SI — System and Information Integrity
AI agents process untrusted input (prompts, code, external data) and produce output that directly affects system integrity (generated code, configuration changes). Integrity controls are essential to prevent the agent from introducing vulnerabilities or being manipulated.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| SI-2 | Flaw Remediation | P1 | Identify, report, and correct information system flaws. | When the agent discovers a vulnerability in existing code (during review, testing, or development), it MUST report the finding to the user and MUST NOT silently suppress it. Agents MUST NOT create public issues for security vulnerabilities. The agent SHOULD suggest remediation aligned with the applicable CWE. Agent-generated code that is subsequently found to contain vulnerabilities MUST be tracked and remediated through the same flaw remediation process as human-authored code. The agent tool itself MUST be updated promptly when vendor patches are available. | Verify the agent reports discovered vulnerabilities to the user; confirm agent-generated vulnerabilities are tracked in the vulnerability management system; check that the agent tool version is current and patching is timely. | AGENTS.md 9.2 |
| SI-3 | Malicious Code Protection | P1 | Implement malicious code protection mechanisms at system entry and exit points. | AI agent-generated code MUST be scanned for malicious patterns (backdoors, data exfiltration, obfuscated code, unauthorized network connections) before deployment. The agent MUST NOT execute arbitrary code received from external sources. The agent MUST NOT include code that creates backdoors, hidden access mechanisms, or reverse shells. SAST scanning in CI MUST cover agent-authored code. Agencies SHOULD treat agent output with the same suspicion as code from an untrusted external source. | Verify SAST scanning is configured for all repositories where the agent operates; confirm scanning rules include backdoor and obfuscation detection patterns; review a sample of agent-generated code for prohibited patterns. | AGENTS.md 10 |
| SI-10 | Information Input Validation | P1 | Check the validity of information inputs. | The agent MUST validate all external input it processes: user prompts, file contents, API responses, and data from external systems. The agent MUST treat instructions embedded in untrusted data (code comments, issue descriptions, API responses) as data to be analyzed, not commands to execute. This is the primary defense against prompt injection attacks. The agent MUST generate code that validates all external inputs using allowlists, type checking, and boundary validation. | Test the agent's response to prompts containing embedded injection attempts; verify agent-generated code includes input validation for all external data sources; review for string-concatenated SQL or shell commands in generated code. | AGENTS.md 11, docs/CODING_PRACTICES.md 2.1 |
| SI-11 | Error Handling | P2 | Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited. | The agent MUST generate code that handles errors explicitly (no empty catch blocks, no silent failures). Error messages in agent-generated code MUST NOT expose internal system details (stack traces, internal paths, SQL queries, internal hostnames) to end users. The agent MUST log errors with sufficient context for debugging without leaking sensitive data. When the agent itself encounters an error, it MUST report it to the user rather than silently continuing. | Review agent-generated code for empty catch blocks and exposed internal details in error messages; verify that agent-generated error responses use structured error types; confirm the agent reports its own operational errors to the user. | AGENTS.md 5.3, docs/CODING_PRACTICES.md 6.1 |
3.10 SR — Supply Chain Risk Management
AI agents represent a new supply chain vector: the agent itself is a third-party tool, and the code it generates may introduce dependencies and patterns from its training data.
| Control | Name | Priority | Description | Agent-Specific Implementation | Verification Method | Cross-Reference |
|---|---|---|---|---|---|---|
| SR-3 | Supply Chain Controls and Processes | P2 | Establish a process for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes. | The AI agent MUST only install packages from authorized registries. Package names MUST be verified to prevent typosquatting. The agent MUST check for known vulnerabilities (NVD, GitHub Advisory Database, OSV) before suggesting or installing any dependency. Lock files (package-lock.json, poetry.lock, Cargo.lock, go.sum) MUST be committed and changes to them MUST be reviewed. The agent SHOULD generate or update the SBOM when dependencies change. Agencies MUST include the AI agent vendor in their supply chain risk assessment. | Verify the agent is configured to use only authorized registries; test that the agent checks vulnerability databases before installing packages; review recent lock file changes for unexpected modifications; confirm the agent vendor is included in the supply chain risk assessment. | AGENTS.md 7.1, docs/CODING_PRACTICES.md 5.2 |
| SR-11 | Component Authenticity | P2 | Develop and implement anti-counterfeit policy and procedures that include means to detect and prevent counterfeit components from entering the system. | All dependencies installed by the agent MUST be verified for authenticity: package signatures SHOULD be checked when available, checksums MUST be verified against the lock file, and the source registry MUST match the authorized registry list. The agent MUST NOT install packages from mirrored or proxy registries that are not authorized by the agency. The agent itself MUST be obtained from the vendor's official distribution channel and its integrity verified (checksum, signature). | Verify lock file checksums match installed packages; confirm the agent was obtained from the vendor's official channel; verify the agent binary or package integrity against the vendor's published checksum; review registry configuration for unauthorized mirrors. | AGENTS.md 7.2, docs/CODING_PRACTICES.md 5.2 |
4. AI RMF Cross-Reference
Each 800-53 control family supports one or more functions of the NIST AI Risk Management Framework (AI RMF 1.0). This mapping helps agencies connect their existing 800-53 compliance work to the AI RMF lifecycle.
| 800-53 Control Family | Primary AI RMF Function | AI RMF Category | Rationale |
|---|---|---|---|
| AC (Access Control) | MANAGE | MANAGE 1 (Risk responses allocated) | Access controls are risk mitigation measures that limit what the AI agent can do, directly managing identified risks. |
| AU (Audit and Accountability) | MEASURE | MEASURE 2 (AI systems evaluated), MEASURE 4 (Feedback about efficacy of measurement) | Audit logs provide the measurement data needed to evaluate whether the agent is behaving within expected parameters. |
| CM (Configuration Management) | GOVERN | GOVERN 1 (Policies, processes, procedures, and practices) | Configuration baselines and change control establish the governance framework within which the agent operates. |
| IA (Identification and Authentication) | GOVERN | GOVERN 6 (Accountability mechanisms in place) | Agent identification underpins accountability — you cannot hold an entity accountable if you cannot identify it. |
| IR (Incident Response) | MANAGE | MANAGE 4 (Risks prioritized and responded to) | Incident response procedures are the operational mechanism for responding to AI agent-related risks that materialize. |
| RA (Risk Assessment) | MAP | MAP 1 (Context established), MAP 5 (Impacts characterized) | Risk assessment maps the AI agent's context, identifies threats, and characterizes potential impacts. |
| SA (System and Services Acquisition) | MAP | MAP 3 (AI capabilities, targeted users, and deployment setting) | Acquisition controls ensure the AI agent's capabilities, data handling, and deployment context are understood before adoption. |
| SC (System and Communications Protection) | MANAGE | MANAGE 2 (Strategies to maximize AI benefits and minimize negative impacts) | Communications protection controls directly manage the risk of data exposure and unauthorized data flow during agent operation. |
| SI (System and Information Integrity) | MEASURE | MEASURE 2 (AI systems evaluated) | Input validation, flaw remediation, and malicious code protection are ongoing integrity measurements of the AI agent's output. |
| SR (Supply Chain Risk Management) | MAP | MAP 3 (AI capabilities, targeted users, and deployment setting) | Supply chain controls map the agent and its dependencies as components with their own risk profiles. |
5. Implementation Roadmap
Phase 1 — P1 Controls (Implement Before Agent Deployment)
These controls MUST be in place before an AI agent is authorized for use in the development environment. They represent the minimum security posture for accountable agent operation.
| Order | Control | Action |
|---|---|---|
| 1 | IA-2 | Establish a distinct agent identity (dedicated token or service account) separate from the human user's credentials. |
| 2 | IA-5 | Store agent credentials in an approved secrets management system with a defined rotation schedule. |
| 3 | AC-2 | Register the agent account in the account inventory with documented permissions and review schedule. |
| 4 | AC-3 | Configure access enforcement so the agent's resource access is checked against the invoking user's current permissions. |
| 5 | AC-6 | Scope agent permissions to the minimum required. Restrict file system access to project directories and network access to authorized endpoints. |
| 6 | AU-2, AU-3, AU-12 | Enable comprehensive audit logging for all agent actions. Verify logs are written to a protected, centralized log store. |
| 7 | CM-3 | Configure version control to require pull requests and human review for all agent-authored changes. Block direct commits to protected branches. |
| 8 | CM-7 | Configure the agent with an explicit allowlist of permitted capabilities. Disable all unnecessary tool access. |
| 9 | SC-7 | Document all external endpoints the agent communicates with. Verify they are within the authorized network boundary. |
| 10 | SC-8 | Verify TLS 1.2+ with FIPS-approved cipher suites on all agent communication paths. Confirm certificate validation is enforced. |
| 11 | SC-28 | Confirm no sensitive data persists in agent working directories after session termination. |
| 12 | SI-2 | Verify the agent version is current and the vendor's patching process is documented. |
| 13 | SI-3 | Configure SAST and SCA scanning in CI to cover all code, including agent-generated code. |
| 14 | SI-10 | Test the agent's resistance to prompt injection using representative attack patterns. |
| 15 | SA-11 | Verify CI pipelines enforce test execution and security scanning on agent-authored pull requests. |
| 16 | IR-4 | Update the incident response plan to include at least two AI agent-specific scenarios. |
| 17 | RA-5 | Confirm vulnerability scanning covers agent-generated code and agent-suggested dependencies. |
Phase 2 — P2 Controls (Implement Within 30 Days)
These controls reduce significant risk and are required for ongoing compliance. Temporary compensating controls (documented in the system security plan) MAY be used during this phase.
| Order | Control | Action |
|---|---|---|
| 1 | AC-5 | Verify separation of duties: the agent cannot both author and approve code for production. |
| 2 | AC-12 | Configure session timeouts and verify credential purging on session termination. |
| 3 | AC-17 | Document and obtain approval for all remote access paths used by the agent. |
| 4 | CM-2 | Document the agent configuration baseline (version, tools, permissions, prompts) in version control. |
| 5 | CM-5 | Verify the agent has no standing write access to production environments. |
| 6 | CM-6 | Verify the agent is configured with maximum restriction defaults and cannot modify its own settings. |
| 7 | IA-8 | Assess third-party agent vendor identity and authentication mechanisms for ATO documentation. |
| 8 | IR-6 | Document agent-specific incident reporting procedures and train agent users. |
| 9 | RA-3 | Update the system risk assessment to include AI agent threat analysis referencing OWASP LLM and Agentic top-10 lists. |
| 10 | SA-4 | Review agent vendor contracts or terms of service for the six required topics (data handling, training, residency, incidents, crypto, patching). |
| 11 | SR-3 | Include the AI agent vendor in the supply chain risk assessment. (Formerly mapped to the withdrawn SA-12.) |
| 12 | SA-15 | Update development process documentation to address AI agent use, review requirements, and authorized tools. |
| 13 | SC-13 | Verify agent-generated cryptographic code uses FIPS-validated modules and current algorithms. |
| 14 | SI-11 | Verify agent-generated error handling does not expose internal system details. |
| 15 | SR-3 | Configure the agent to use only authorized registries and verify vulnerability checking before dependency installation. |
| 16 | SR-11 | Verify agent and dependency authenticity through signatures and checksums. |
Phase 3 — P3 Controls (Implement Within 90 Days)
These controls improve operational maturity. No controls in this overlay are assigned P3 priority, but agencies SHOULD use this phase to:
| Order | Action |
|---|---|
| 1 | Conduct a tabletop exercise for AI agent incident response scenarios. |
| 2 | Implement automated alerting for anomalous agent behavior patterns (AU-6). |
| 3 | Establish a quarterly agent account review cycle (AC-2). |
| 4 | Generate and maintain SBOMs for all agent-managed dependency changes (SR-3). |
| 5 | Evaluate agent-generated code quality metrics over time to identify recurring insecure patterns. |
| 6 | Review and refine agent permission scopes based on operational experience (AC-6 continuous improvement). |
| 7 | Benchmark agent audit log completeness against AU-3 requirements monthly. |
Version History
| Date | Version | Change |
|---|---|---|
| 2026-02-25 | 0.1.0 | Initial release — FIPS Moderate overlay for single-agent, internal enterprise scope |
Framework References
- NIST SP 800-53 Rev 5.2.0 — Security and Privacy Controls for Information Systems and Organizations (September 2024)
- NIST SP 800-53B — Control Baselines for Information Systems and Organizations (December 2020, updated November 2024)
- NIST COSAiS — Control Overlays for Securing AI Systems (Draft 2026)
- NIST AI RMF 1.0 — AI Risk Management Framework (January 2023)
- NIST AI 600-1 — Generative AI Profile for AI RMF (July 2024)
- NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models (June 2024)
- NCCoE AI Agent Identity — Software and AI Agent Identity and Authorization Concept Paper (February 2026)
- OWASP Top 10 for LLM Applications 2025 (November 2024)
- OWASP Top 10 for Agentic Applications 2026 (December 2025)
- OMB M-25-21 — AI Governance (April 2025)
- FedRAMP 20x — Cloud/AI Service Authorization (2025)