Mapping the AI Agent Incident Practices to NIST CSF 2.0
Earlier this month, NIST, the NSA and CISA published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation . Our first post on it translated the ten practices into controls for organizations that deploy agents. This one does the next job: attach them to the
Posted on Nov 3 • Originally published at codacon.ai
Earlier this month, NIST, the NSA and CISA published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Our first post on it translated the ten practices into controls for organizations that deploy agents. This one does the next job: attach them to the framework your security program already reports against.
The document does half of that work for you. Its ten practices break down into 50 numbered sub-practices, and 38 of them cite specific subcategories of the NIST Cybersecurity Framework 2.0. Read those citations as a map. Then read the twelve sub-practices with no CSF anchor, because that is where the genuinely new work for agents sits.
The key practices are organized in five incident stages: prepare, detect, respond, recover, report. CSF 2.0 has six functions: Govern, Identify, Protect, Detect, Respond, Recover. The two do not line up one to one, and the citations show it.
Practice 1.7, under Prepare, asks for mechanisms to block, contain, or terminate agent activity. It cites RS.MI-01, "Incidents are contained," a Respond subcategory. Practice 7.2, under Recover, asks you to patch exploited vulnerabilities, and cites RS.MI-02, "Incidents are eradicated." Practice 7.4 cites ID.IM-03 and ID.IM-04, which sit under Identify.
That matters for ownership. Your control owners are organized around CSF functions or a catalogue derived from them, not around incident stages. Regroup the practices by CSF subcategory and you can see which existing owner already holds each one.
Each line gives the CSF 2.0 subcategory, its title as NIST writes it, and the sub-practices that cite it.
That is 32 subcategories in total. Titles are abridged where NIST's run long; the CSF 2.0 document has the full wording.
Weight sits on boundaries and evidence. The most cited subcategories are PR.IR-01 and RS.MI-02, with four sub-practices each, then RS.AN-07, ID.IM-02 and ID.IM-03, with three each. Agent incident readiness is mostly about network and environment boundaries, eradication, and evidence whose integrity you can defend.
Govern is thin. Only 2.6 and 9.1 cite a Govern subcategory. The document is aimed at labs running evaluations, and it says little about who owns an agent in a business. For a deployer, that gap is real. Ownership, accountability and inventory are where an enterprise program starts, which is why we put the agent inventory first.
Twelve sub-practices cite no CSF subcategory. Four of them cite other references instead. Practices 1.6 (control policy with automated enforcement), 2.3 (inbound reporting channels) and 10.1 (share publicly, early) point to SP 800-61r3. Practice 9.2 (report vulnerabilities) points to CISA's coordinated vulnerability disclosure program and its Known Exploited Vulnerabilities catalog. Those are conventional practice.
The other eight are where agents differ from the systems CSF was written for:
For an enterprise, 5.6 and 6.3 deserve the most attention. They treat an agent incident as a finding about a class of agents, not a single host. If one agent built on a given model and toolset went out of scope, every agent sharing that model and those tools is suspect until shown otherwise. No CSF subcategory says that, so no existing control owner will pick it up unless you assign it.
A crosswalk on a slide is out of date the day the source changes, and this source will change. It is version 1.0, and it lists nine areas for future work, including severity scores, intended-activity baselines and agent identifiers.
Store the mapping as structured records instead. One record per sub-practice, with the CSF subcategories it cites, the internal control that satisfies it, the owner, and the evidence:
- practice: " 1.5" csf: [ PR.IR-01 ] control: Egress allowlist on agent runners, via the monitored proxy owner: Network security lead evidence: Proxy deny logs - practice: " 6.3" csf: [] control: Pause all agents on the same model and toolset pending review owner: Head of AI platform evidence: Runbook step, last tabletop date Enter fullscreen mode Exit fullscreen mode Now the questions become queries. Which agent practices does our egress proxy satisfy? Which practices have no owner? Which CSF subcategories gained agent-specific obligations this year?
This is the argument we made in why use NIST OSCAL. Describe your egress proxy, your identity provider and your logging pipeline once, as components, then map them to every framework you answer to. In OSCAL terms, the agent controls become entries in a component definition alongside the mappings you already maintain for SP 800-53 or ISO 27001. NIST publishes the CSF 2.0 Core as structured data through its Cybersecurity and Privacy Reference Tool, and has demonstrated a converter from that data to OSCAL catalogs. The key practices themselves are published only as a PDF. Turning their 50 sub-practices into records is a few hours of work, done once.
Our GenAI Security Readiness Assessment maps every finding to the key practices and to CSF 2.0, with an owner and a remediation. If your compliance program already runs on OSCAL, or wants to, we deliver the agent controls as data you can merge, not as a document you have to retype.