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.

Stages are not functions

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.

The crosswalk, by CSF function

Each line gives the CSF 2.0 subcategory, its title as NIST writes it, and the sub-practices that cite it.

Govern

  • GV.OC-03. Legal, regulatory, and contractual requirements regarding cybersecurity are understood and managed: 9.1 (meet legal reporting duties).
  • GV.RR-02. Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced: 2.6 (structured risk assessment, senior leadership sign-off).
  • GV.RM-06. A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated: 2.6.

Identify

  • ID.RA-05. Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk: 1.4 (persistence and communication channels), 1.8 (expect agents to exploit misconfigurations).
  • ID.RA-06. Risk responses are chosen, prioritized, planned, tracked, and communicated: 1.8, 2.1 (incident and near-miss indicators and severity).
  • ID.IM-01. Improvements are identified from evaluations: 10.2 (facilitate third-party review).
  • ID.IM-02. Improvements are identified from security tests and exercises: 1.9 (red-team controls), 2.2 (drills), 4.1 (red-team monitors).
  • ID.IM-03. Improvements are identified from execution of operational processes, procedures, and activities: 5.4 (log analysis and root cause), 7.4 (replay the incident against new controls), 10.3 (publish improvements).
  • ID.IM-04. Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved: 7.4.

Protect

  • PR.AA-05. Access permissions, entitlements, and authorizations incorporate least privilege and separation of duties: 1.1 (least privilege for agents).
  • PR.IR-01. Networks and environments are protected from unauthorized logical access and usage: 1.2 (single-use infrastructure), 1.4, 1.5 (egress allowlist through a monitored gateway), 3.1 (define each agent's intended boundaries).
  • PR.DS-01. The confidentiality, integrity, and availability of data-at-rest are protected: 1.10 (good engineering practice).
  • PR.PS-04. Log records are generated and made available for continuous monitoring: 3.2 (monitor every layer), 5.3 (tamper-resistant logs).
  • PR.PS-06. Secure software development practices are integrated: 1.10.

Detect

  • DE.CM-01. Networks and network services are monitored to find potentially adverse events: 3.2.
  • DE.CM-06. External service provider activities and services are monitored: 3.2.
  • DE.CM-09. Computing hardware and software, runtime environments, and their data are monitored: 3.2, 4.2 (treat agent output as potentially containing exploits aimed at the monitors).
  • DE.AE-02. Potentially adverse events are analyzed to better understand associated activities: 3.5 (escalation and canaries).
  • DE.AE-03. Information is correlated from multiple sources: 3.3 (agents cannot touch their monitors; cross-check monitoring layers).
  • DE.AE-06. Information on adverse events is provided to authorized staff and tools: 3.5, 5.5 (model-assisted investigation, verified by humans).

Respond

  • RS.MA-01. The incident response plan is executed in coordination with relevant third parties: 5.5.
  • RS.MA-03. Incidents are categorized and prioritized: 2.1, 9.3.
  • RS.AN-03. Analysis is performed to establish what has taken place and the root cause: 5.4.
  • RS.AN-07. Incident data and metadata are collected, and their integrity and provenance are preserved: 5.1 (preserve rejected actions and tool calls), 5.2 (preserve configuration), 5.3.
  • RS.AN-08. An incident's magnitude is estimated and validated: 6.1 (shutdown policies calibrated to severity).
  • RS.MI-01. Incidents are contained: 1.7, 6.1.
  • RS.MI-02. Incidents are eradicated: 6.2 (automatic shutdown), 6.4 (revoke credentials), 6.5 (remove persistence), 7.2.
  • RS.CO-02. Internal and external stakeholders are notified of incidents: 8.1 (notify affected parties), 9.1.
  • RS.CO-03. Information is shared with designated internal and external stakeholders: 8.2, 9.3, 10.3.

Recover

  • RC.RP-03. The integrity of backups and other restoration assets is verified before using them for restoration: 7.1 (rebuild from verified baselines).
  • RC.RP-05. The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed: 6.4, 7.3 (prove containment works before restart).
  • RC.RP-06. The end of incident recovery is declared based on criteria, and incident-related documentation is completed: 7.5 (document the restart decision), 7.6 (after-action report).

That is 32 subcategories in total. Titles are abridged where NIST's run long; the CSF 2.0 document has the full wording.

What the map shows

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:

  • 1.3. Give agents instructions that state task scope and rules of engagement. Instructions are a control input for an agent. They are not for a server.
  • 2.4. Use independent external auditors to verify that control, monitoring and detection work as intended.
  • 2.5. Consider publishing identifiers for agent traffic, so defenders can recognize it.
  • 3.4. Monitor with multiple models, ideally from different model families.
  • 5.6. Check whether other, similar agents were involved or showed the same control failure.
  • 6.3. Depending on severity, pause similar agents until controls are strengthened and verified.
  • 7.7. Design recovery during training so it does not reinforce the behavior or make it harder to detect. That one is for model developers.
  • 8.3. Share lessons across the value chain, including the model developer and infrastructure providers.

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.

Keep the map as data, not a slide

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

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.

How we help

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.

Three questions to test yourself

  1. For PR.IR-01 and RS.MI-02, the two subcategories the practices lean on most, can you name the control owner and show the evidence for your agents specifically?
  2. Who in your organization owns practice 6.3, pausing every similar agent after one incident?
  3. When version 2.0 of the key practices appears, how long would it take you to know what changed for your controls?