> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/reference/governance-and-frameworks/g.1-map-your-controls-to-nist-ai-rmf-and-csf-2.0.md).
# G.1 Map your controls to NIST AI RMF and CSF 2.0
The backbone mapping every AI security control family to NIST AI RMF GOVERN, MAP, MEASURE, and MANAGE and NIST CSF 2.0 functions.
*Last reviewed: August 18, 2026*
{% hint style="info" %}
Use NIST AI RMF to explain AI-specific risk work. Use NIST CSF 2.0 to connect that work to the rest of cybersecurity. The same evidence should support both.
{% endhint %}
NIST AI RMF and NIST CSF 2.0 answer different questions.
NIST AI RMF organizes AI risk work into GOVERN, MAP, MEASURE, and MANAGE. It covers risks to individuals, organizations, and society, including model behavior, human oversight, transparency, bias, lifecycle decisions, and context-specific harms.
NIST CSF 2.0 asks whether the organization is managing cybersecurity risk across Govern, Identify, Protect, Detect, Respond, and Recover. It is useful when the control is part of normal security operations: identity, asset inventory, logging, incident response, vendor risk, data protection, or resilience.
For AI security, use them together. Connect AI governance to security operations without reducing the broader AI risk program to cybersecurity alone.
## The short mapping
This is a practical emphasis map, not an official NIST crosswalk. Most control families support more functions and categories than the table shows.
| Handbook domain | NIST AI RMF fit | NIST CSF 2.0 fit | Evidence to keep |
| ---------------------------------- | -------------------- | ------------------------- | ----------------------------------------------------------------------------------- |
| Identity and access | GOVERN, MANAGE | GOVERN, IDENTIFY, PROTECT | SSO settings, SCIM configuration, RBAC exports, owner list, access review records |
| Supply chain and extensibility | MAP, MEASURE, MANAGE | GOVERN, IDENTIFY, PROTECT | Connector intake records, MCP allowlists, plugin review notes, vendor risk records |
| Runtime, sandbox, and autonomy | MAP, MEASURE, MANAGE | PROTECT, DETECT | Sandbox policy, approval settings, egress rules, test logs, exception records |
| Data protection and residency | MAP, MEASURE, MANAGE | GOVERN, IDENTIFY, PROTECT | Data-flow maps, DLP policies, retention settings, ZDR scope, residency evidence |
| Threats and adversarial testing | MAP, MEASURE, MANAGE | DETECT, RESPOND | Threat models, red-team reports, prompt-injection tests, abuse-case catalog |
| Observability, audit, and evidence | MEASURE, MANAGE | DETECT, RESPOND, RECOVER | Compliance API exports, telemetry, SIEM detections, evidence reconciliation reports |
| Rollout and operations | GOVERN, MANAGE | GOVERN, IDENTIFY | Pilot gates, risk acceptance, review cadence, control owners, exception register |
## How to apply NIST AI RMF
Use AI RMF GOVERN for the program layer:
* Who owns AI security policy?
* Who approves a new AI system or AI feature?
* Which roles have authority to accept residual risk?
* How are AI incidents escalated?
* How are legal, privacy, data, HR, procurement, and security involved?
Use AI RMF MAP for context:
* What AI surface is being used: chat, coding agent, browser agent, hosted agent, API app, or low-code builder?
* What data can enter the system?
* What can the system read, write, execute, or send externally?
* Who is affected by the system's output?
* Which vendors, tools, connectors, model endpoints, and logs are in the workflow?
Use AI RMF MEASURE for testing and evidence:
* Has the team tested prompt injection, data leakage, tool misuse, and permission boundaries?
* Are results measured against acceptance criteria?
* Are logs complete enough to investigate a failure?
* Are outputs and decisions sampled after deployment?
* Are controls tested after vendor feature changes?
Use AI RMF MANAGE for treatment:
* Which risks are mitigated, accepted, transferred, or avoided?
* Which controls are required before pilot?
* Which controls are required before production?
* Which incidents trigger suspension or rollback?
* Which review cadence applies after launch?
## How to apply NIST CSF 2.0
Use CSF GOVERN for policy, accountability, and third-party risk:
* AI acceptable use policy
* AI risk appetite
* Approved tool catalog
* Procurement gates
* Vendor and connector ownership
* Review cadence
Use CSF IDENTIFY for inventory and dependency mapping:
* AI systems and surfaces
* Users, agents, service accounts, and API keys
* Data classes and data flows
* Connectors, MCP servers, plugins, skills, packages, and model providers
* Compliance and telemetry sources
Use CSF PROTECT for preventive controls:
* SSO, SCIM, RBAC, tenant restrictions
* DLP and data classification
* Egress controls and sandbox settings
* Approval policies
* Secrets handling
* Allowlists for connectors and extensions
Use CSF DETECT for monitoring:
* Audit logs
* Compliance API exports
* Runtime telemetry
* SIEM detections
* Usage analytics
* Alerts for policy bypass and anomalous AI activity
Use CSF RESPOND for incidents:
* AI incident runbooks
* Vendor escalation paths
* Evidence preservation
* Revocation of tokens, connectors, and agent sessions
* User and legal notification workflow
Use CSF RECOVER for restoration:
* Rollback of agent definitions, plugins, and model configuration
* Credential rotation
* Data exposure follow-up
* Lessons learned
* Control updates after incidents
## Minimum evidence pack
For each approved AI workflow, keep:
* Owner record: business owner, security owner, platform owner, data owner, incident owner.
* System record: purpose, users, vendor, deployment model, data classes, connected tools.
* Control record: required handbook controls, exceptions, compensating controls, approval date.
* Test record: prompt-injection tests, exfiltration tests, permission tests, logging tests.
* Monitoring record: logs collected, retention, SIEM routing, review cadence.
* Change record: vendor changes, enabled features, model changes, connector changes, policy updates.
## Common NIST AI RMF and CSF 2.0 control mapping security failures
* The team maps controls to a framework after rollout instead of using the mapping during intake.
* AI RMF is owned by legal or compliance while the technical controls are owned somewhere else.
* CSF reporting says controls exist, but the evidence does not show that they apply to AI surfaces.
* The matrix treats chat, coding agents, and hosted agents as one deployment model.
* The team tests the model output but not tool calls, connectors, local files, or logs.
## Frequently asked questions about NIST AI RMF and CSF 2.0 control mapping
### Should every AI use case get a full NIST AI RMF assessment?
No. Scale the assessment to the risk. Low-risk internal chat may need inventory, data rules, and logging evidence. A production agent with write access, customer data, or employment decisions needs a full context map, control review, testing record, and named risk acceptance.
### Does NIST CSF 2.0 cover AI-specific risks?
It covers many security outcomes that AI systems need, but it does not give enough AI-specific detail by itself. Pair it with AI RMF and the handbook control matrix.
### Where does the NIST AI RMF Generative AI Profile fit?
Use the Generative AI Profile when the system relies on generative AI, including LLM-based agents, synthetic content, retrieval-augmented generation, or tool use directed by a generative model. It makes generative-AI risks and suggested actions more concrete.
### Who should own the mapping?
Security should maintain the cybersecurity control mapping, with compliance support. The accountable business owner should own the use-case risk decision. Legal and privacy should review regulatory mappings, and platform teams should own evidence for technical settings and telemetry.
## Applicable handbook articles
Coverage is intentionally broad because this page combines the AI RMF's lifecycle risk functions with CSF 2.0 cybersecurity outcomes. Each linked article supplies implementation evidence; the table is not an official one-to-one NIST crosswalk.
| Handbook area | Applicable articles | Why they apply |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| 1. Identity & access | 1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.4 Domain claiming: bringing shadow accounts into enterprise
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies
| Supports AI RMF accountability and human configuration of controls, plus CSF PR.AA identity, authentication, and access outcomes. |
| 2. Connectors, extensions & supply chain | 2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.6 Hooks and lifecycle scripts
2.7 The supply-chain review workflow
2.8 Signing and packaging
2.9 SaaS agent-building supply-chain
2.10 Hosted-agent framework dependencies
| Supports AI RMF third-party risk and CSF GV.SC, ID.AM, and PR.PS supply-chain, asset, and platform-security outcomes. |
| 3. Runtime, sandboxing & autonomy | 3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.5 Computer Use / desktop control risks
3.6 Scheduled and background tasks
3.7 Remote access, dispatch and SSH
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening
| Supports AI RMF testing and risk treatment, plus CSF PR.PS, PR.IR, and DE.CM protection, resilience, and monitoring outcomes. |
| 4. Data protection | 4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.3 Data residency and regional inference
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools
| Supports AI RMF context, privacy, and data-risk work, plus CSF ID.AM and PR.DS data inventory and protection outcomes. |
| 5. Threats & adversarial testing | 5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems
| Supports AI RMF risk identification, testing, evaluation, verification, and validation, plus CSF ID.RA, DE.AE, and RS outcomes. |
| 6. Observability, audit & evidence | 6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.3 Compliance APIs by platform
6.4 Analytics and usage APIs
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence
| Supports AI RMF measurement and monitoring, plus evidence for CSF Detect, Respond, and Recover outcomes. |
| 7. Rollout & operations | 7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix
| Supports AI RMF GOVERN and MANAGE activities, plus CSF Govern and ID.IM improvement outcomes. |
## Further reading
The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.
* [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework). AI RMF 1.0 remains the current published framework; NIST states that a revision is in progress.
* [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)
* [NIST AI RMF Generative AI Profile, NIST AI 600-1](https://doi.org/10.6028/NIST.AI.600-1)
## Related handbook guidance
* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md)
* [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems.md)
* [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md)
* [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://handbook.harmonic.security/reference/governance-and-frameworks/g.1-map-your-controls-to-nist-ai-rmf-and-csf-2.0.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.