NIST 800-53 Rev 5 Evidence Mapping for AI Agents
NIST SP 800-53 Rev 5 is the federal security baseline. An AI agent inside a federal or FedRAMP-bound system behaves like a non-human actor that needs access enforcement, event logging, change control, and incident handling. Runtime authorization gives the AC, AU, CM, and IR control families an evidence path for AI agent workloads.
Last updated: May 20, 2026
What is NIST SP 800-53?
NIST Special Publication 800-53 Revision 5 was published by the National Institute of Standards and Technology in September 2020 (with errata releases through 2023). It defines security and privacy controls for federal information systems and organizations. For agent work, the practical mapping is to non-human subjects and service identities: software acting with delegated privileges needs access rules, audit records, change control, and incident handling. Federal agencies use 800-53 baselines under FISMA; FedRAMP inherits subsets; CMMC Level 2 inherits NIST SP 800-171, which derives from 800-53.
Why it applies to AI agents
Rev 5's access-control language covers subjects beyond human operators. An AI agent acting through service credentials should be treated as a governed non-human actor: it authenticates, requests actions, and creates audit records. The relevant AC, AU, CM, and IR controls apply when that actor can affect regulated systems or data.
The risk is that traditional 800-53 implementations were built for human accounts and deterministic services. Agents are neither. They authenticate once but make downstream tool calls. They are non-deterministic and may attempt unauthorized actions. Without runtime authorization at the tool boundary, AC-3 (Access Enforcement) may be evidenced at the API gateway without covering the action the agent takes.
Control mapping: NIST 800-53 Rev 5 to Veto features
The table maps the controls most directly engaged by agent activity. Inheritance into FedRAMP Moderate/High and CMMC Level 2 baselines is noted where relevant.
| Control | Requirement | Veto feature |
|---|---|---|
| AC-2 | Account management for non-organizational users (NPE accounts) | Per-agent API keys scoped to project and organization; key rotation history in decision record |
| AC-3 | Access enforcement based on approved authorizations | Runtime authorization at each governed tool call; deny-by-default; allow only what policy explicitly permits |
| AC-6 | Least privilege restricts access to minimum necessary | Policy-as-code requires explicit enumeration of tools and arguments per agent role |
| AC-6(9) | Log use of privileged functions | Decision record distinguishes high-privilege tools; alert configuration on review-required tool use |
| AU-2 | Event logging for auditable events | Each governed authorization decision is recorded; configurable event categories per tool |
| AU-3 | Content of audit records: what, when, where, source, outcome, identity | Decision record entry includes tool name, timestamp, runtime context, agent ID, outcome, reviewer ID |
| AU-6 | Audit record review, analysis, and reporting | Decision aggregates with filters; SIEM webhook for integration with Splunk, Sentinel, or Chronicle |
| AU-12 | Audit record generation by designated system components | SDK records each governed decision; exportable decision record |
| CM-3 | Configuration change control with documented approval | Policy-as-code in git; reviewer approval and policy validation where configured |
| CM-5 | Access restrictions for change | Owner review, branch protection, and signed-commit workflows where configured |
| IR-4 | Incident handling capability with detection, analysis, containment, eradication, recovery | Policy rollback in one commit; emergency kill-switch policy; forensic trail from decision records |
| IR-5 | Tracking and documenting security incidents | Decision record query by date and outcome helps reconstruct incident timeline and action sequence |
Evidence Veto provides
An assessor performing an Authority to Operate (ATO) review or 3PAO assessment expects artifacts they can map to each control. Veto outputs support those artifacts:
Policy artifacts (AC-3, AC-6)
YAML policy files enumerate tools, arguments, and approval rules per agent. They can be stored with version control history showing authorized changes.
Audit records (AU-2, AU-3, AU-12)
Decision record entries include agent ID, tool, arguments, policy version SHA, outcome, reviewer ID, and RFC 3339 timestamp. Exportable as JSON or CSV.
Change records (CM-3, CM-5)
Policy change history can include reviewer approvals, validation runs, and signed commits when your workflow requires them.
Incident artifacts (IR-4, IR-5)
Filtered decision record queries help reconstruct what an agent did before, during, and after an incident. Policy diffs document containment actions.
Implementation timeline
Frequently asked questions
Is NIST SP 800-53 mandatory?
Which 800-53 control families touch AI agents?
How does Veto map to AU-3 (Content of Audit Records)?
How does this relate to FedRAMP and CMMC?
Related evidence resources
Agents are non-organizational users. They need AC, AU, CM, and IR evidence too.