Generative AI introduces risks that a general AI risk framework names only in the abstract, and most organisations struggle to turn the NIST AI RMF into concrete controls for chatbots, copilots and agents. NIST AI 600-1, the Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, closes that gap. It defines 12 risks that are unique to or made worse by generative AI (GAI) and lists suggested actions against each subcategory of the AI RMF. This guide explains what the profile covers, its status after the 2025 change of US executive orders, how its action identifiers work, and how to turn it into a working programme. It is written for security, risk and AI platform teams, and for executives who need to know what adopting the profile commits them to.
Key takeaways
- It is a profile, not a new framework. AI 600-1 is a cross-sectoral companion to AI RMF 1.0 (NIST AI 100-1), organised under the same Govern, Map, Measure and Manage functions. Read the NIST AI RMF first.
- Twelve named risks anchor everything. Every suggested action is tagged with the GAI risks it addresses, from Confabulation to Value Chain and Component Integration, so you can build a risk register directly from the document.
- Use is voluntary. NIST states the AI RMF is intended for voluntary use and the profile says not every action applies to every AI actor. There are no penalties; the pressure comes from contracts, regulators and auditors who use it as a benchmark.
- The executive order behind it was revoked, the document was not. The profile was written under Executive Order 14110, which Executive Order 14148 revoked on 20 January 2025. NIST still publishes AI 600-1 as a current publication.
- Information Security and Value Chain are the security team's core. Prompt injection, data poisoning, model weight protection and third-party models sit there, and in agentic systems they turn directly into questions about non-human identities and their permissions.
Scope: who and what is covered
NIST published AI 600-1 on 26 July 2024 (DOI 10.6028/NIST.AI.600-1). It is a cross-sectoral profile: it covers GAI models and applications used across sectors, and supports activities common to many of them, such as using large language models, cloud services and acquisition. It applies to anyone in the AI lifecycle, which the profile describes through "AI Actor Tasks" such as Governance and Oversight, AI Development, AI Deployment, Operation and Monitoring, TEVV (test, evaluation, verification and validation) and Third-party entities.
The profile frames GAI risk along four dimensions that are worth copying into your own risk method:
- Stage of lifecycle: design, development, deployment, operation or decommissioning.
- Scope: an individual model, an application or use case, or the wider ecosystem (the profile gives "algorithmic monocultures" as an ecosystem example).
- Source of risk: the model's design, training or operation, its inputs or outputs, or human behaviour including misuse.
- Time scale: risks can appear abruptly or develop over long periods.
The 12 GAI risks
| # | Risk (as named in AI 600-1) | What it covers | Usual owner |
|---|---|---|---|
| 1 | CBRN Information or Capabilities | Easier access to, or synthesis of, information or design capabilities for chemical, biological, radiological or nuclear weapons | Model provider safety, trust and safety |
| 2 | Confabulation | Confidently stated but false content (hallucination) that misleads users | Product owner, TEVV |
| 3 | Dangerous, Violent, or Hateful Content | Easier production of violent, radicalising or threatening content, including hateful or stereotyping material | Trust and safety |
| 4 | Data Privacy | Leakage, unauthorised use or de-anonymisation of biometric, health, location or other personal data, including training data memorisation and sensitive inference | Privacy office, security |
| 5 | Environmental Impacts | Harm to ecosystems from the compute used to train and run models | Sustainability, procurement |
| 6 | Harmful Bias or Homogenization | Amplified societal bias, performance gaps across groups or languages, overly uniform outputs | Responsible AI, TEVV |
| 7 | Human-AI Configuration | Over-reliance, automation bias, algorithmic aversion, emotional entanglement | Product, human factors |
| 8 | Information Integrity | Easier creation and spread of content that blurs fact and fiction, including mis- and disinformation at scale | Communications, trust and safety |
| 9 | Information Security | Lower barriers to cyber attack, and new attack surfaces such as prompt injection and data poisoning | CISO |
| 10 | Intellectual Property | Unauthorised reproduction of copyrighted, trademarked or licensed content, exposure of trade secrets | Legal |
| 11 | Obscene, Degrading, and/or Abusive Content | Abusive imagery, including synthetic child sexual abuse material and nonconsensual intimate images | Trust and safety, legal |
| 12 | Value Chain and Component Integration | Third-party components, data or models that are poorly vetted or untraceable, reducing transparency and accountability | Procurement, security, third-party risk |
The owner column is our suggestion, not part of the profile. A deployer that only consumes a hosted model will carry most of risks 2, 4, 7, 9, 10 and 12 itself and push risks 1, 3 and 11 into supplier assurance.
Key obligations
AI 600-1 creates no legal obligations. Its "obligations" are suggested actions, grouped in Section 3 under each AI RMF subcategory. Each table lists the actions, the GAI risks each one addresses and the AI Actor Tasks involved. Appendix A then discusses four primary considerations that run through the document: Governance, Content Provenance, Pre-deployment Testing and Incident Disclosure.
How action IDs work
Each action ID has three parts: the function tag (GV for Govern, MP for Map, MS for Measure, MG for Manage), the AI RMF subcategory number and a three-digit sequence. GV-1.1-001 is the first suggested action under GOVERN 1.1. Use these IDs as stable keys in your control library and evidence register, so an auditor can trace a control back to the profile.
Actions security teams should start with
| Action ID | What the profile suggests | Practical control |
|---|---|---|
| GV-1.5-002 | After-action review procedures for GAI incident response and disclosure, updated as needed | Add GAI incident types to the IR plan and run post-incident reviews |
| GV-2.1-001 | Communicate incidents, including through resources such as AI incident databases | Define external sharing criteria and an owner |
| GV-4.3-002 | Minimum criteria for GAI incident reporting | Severity scale and reporting thresholds for prompt injection, data leakage and harmful output |
| GV-6.1-004 | Contracts and service level agreements that set content ownership and provenance expectations | Model and API supplier contract clauses |
| GV-6.1-005 | A use-case-based supplier risk assessment framework to monitor third-party performance and provenance | Tiered due diligence for model providers, plugins and datasets |
| MP-5.1-005 | Adversarial role-playing, GAI red-teaming or chaos testing to find unforeseen failure modes | Pre-release red team with documented scope |
| MS-1.1-001 | Methods to trace the origin and modifications of digital content | Provenance metadata and watermark checks on generated content |
| MS-2.7-007 | Red-teaming for prompt injection and data poisoning | Recurring tests against retrieval sources, tools and fine-tuning pipelines |
| MS-2.8-003 | Digital content transparency tools that keep a tamper-resistant history of content | Signed provenance records for published outputs |
Treat the profile as a menu. NIST says plainly that not every suggested action applies to every AI actor or task; record which actions you adopt, which you reject and why. That decision record is what makes adoption defensible.
The Information Security risk in detail
- Direct prompt injection: an attacker enters malicious prompts straight into the system. MITRE ATLAS tracks this as AML.T0051 LLM Prompt Injection, and OWASP as LLM01:2025 Prompt Injection.
- Indirect prompt injection: the attacker plants instructions in data the system is likely to retrieve, without any direct interface. The EchoLeak Microsoft 365 Copilot case shows how crafted content arriving by email could steer an assistant into exposing data. See the Prompt Injection Guide.
- Data poisoning: tampering with training data to manipulate outputs (ATLAS AML.T0020 Poison Training Data, OWASP LLM04:2025 Data and Model Poisoning).
- Model weights and code: the profile extends security to the availability, integrity and confidentiality of code, training data and weights, and notes that querying a closed production model can reveal information about it (compare ATLAS AML.T0024 Exfiltration via AI Inference API).
- Offensive uplift: GAI can lower the barrier to vulnerability discovery and exploitation, which changes threat assumptions for everything else you defend.
For the full application security view, see the LLM Security Guide.
Timeline and current status
| Date | Event |
|---|---|
| 26 January 2023 | AI RMF 1.0 (NIST AI 100-1) released |
| 30 October 2023 | Executive Order 14110 on Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence; Section 4.1(a)(i)(A) asked NIST for a GAI companion to the AI RMF |
| 26 July 2024 | NIST AI 600-1 published |
| 20 January 2025 | Executive Order 14148 revokes EO 14110 |
| 2026 | NIST states AI RMF 1.0 is being revised as part of the White House AI Action Plan; AI 600-1 remains listed, with its publication page last updated 8 April 2026 |
The practical reading: the profile's origin order has gone, but the document stands as a NIST publication and continues to be cited by buyers and assessors. Because the parent AI RMF is under revision, expect the profile to be revised or realigned too. Key your controls to the risk names and action IDs, and keep a mapping you can update when a new version appears. We cannot say when a revision will be published.
Enforcement and penalties
There is no enforcement body and no penalty for not following AI 600-1. Its weight comes from elsewhere:
- Contracts and procurement: customers and public bodies may ask suppliers to show alignment with the AI RMF and its GAI profile. A documented action-by-action position answers that quickly.
- Audit and assurance: internal audit and external assessors use it as a reference benchmark for "reasonable" GAI risk management.
- Regulatory evidence: organisations subject to the EU AI Act or sector regulators can reuse profile evidence, but alignment with a voluntary US profile does not by itself demonstrate compliance with any law. See the EU AI Act Compliance Guide.
- Standards alignment: organisations certifying to ISO/IEC 42001 often use the profile as a source of GAI-specific controls. See the ISO/IEC 42001 Guide.
Choosing your adoption depth
| Situation | Recommended approach | Trade-off |
|---|---|---|
| Small organisation using hosted assistants only | Adopt risks 4, 7, 9, 10, 12 and the Govern and supplier actions; rely on provider attestations for the rest | Depends on supplier transparency |
| Enterprise building RAG applications and agents | Full Map and Measure coverage for your use cases, red teaming under MS-2.7, provenance actions where content is published | Needs TEVV capacity and tooling |
| Model developer or fine-tuner | All 12 risks, including CBRN and abusive content evaluations, pre-deployment testing per Appendix A | Highest cost, highest scrutiny |
| Already running ISO/IEC 42001 or ISO/IEC 23894 | Use the profile as a GAI control catalogue under your existing risk process rather than a parallel programme | Mapping effort up front |
What it means for AI agents and non-human identities
AI 600-1 was written mainly about models and applications, but its risks land on identities as soon as GAI is given tools. An agent that reads email, calls APIs or commits code acts through service accounts, OAuth grants and API keys, so Information Security, Data Privacy and Value Chain risks become identity questions.
- Prompt injection becomes privilege abuse: an injected instruction executes with whatever the agent's credentials allow. Least privilege and scoped tokens limit the blast radius in a way that prompt filtering cannot. See the AI Agent Authorisation Guide.
- Value chain includes credentials: model gateways, plugins and MCP servers hold API keys. The LiteLLM PyPI package breach shows a compromised component in the GAI toolchain exposing LLM provider keys, which is exactly the Value Chain and Component Integration risk.
- Human-AI Configuration covers approvals: over-reliance shows up as rubber-stamped agent actions. Define which actions require human approval and log who approved.
- Incident disclosure needs identity telemetry: to report a GAI incident under GV-4.3-002 criteria you must know which agent identity acted, with which credential, on whose behalf.
- Inventory first: the profile's governance actions assume you know which GAI systems exist. Inventory agents as non-human identities with an owner and purpose. See the Identity Governance for AI Agents Guide.
Compliance steps
- Confirm the base: establish AI RMF Govern basics (policy, roles, risk tolerance). The profile assumes them. See the NIST AI RMF Guide.
- Inventory GAI use: list models, applications, agents, plugins and datasets, with owner, supplier, data classes and the credentials each uses.
- Classify your role: for each system, decide whether you are developer, deployer, operator or third-party user, which determines the AI Actor Tasks that apply.
- Build the risk register: rate each system against the 12 risks using the four dimensions (lifecycle, scope, source, time scale). Use the AI Risk Assessment Guide for the method.
- Select actions: pick suggested actions by ID, record adopt, adapt or reject decisions with a reason, and assign an owner.
- Pilot on one system: run the selected Measure actions (red teaming, provenance checks, privacy tests) on one high-value application, then fix the gaps before scaling. Keep the pilot behind a feature flag or limited user group so you can withdraw it.
- Wire into operations: add GAI incident types to the incident response plan, supplier clauses to procurement, and test gates to the release pipeline.
- Measure and review: report the metrics below quarterly and revisit the action set whenever NIST revises the AI RMF or the profile.
Detection and measurement
- Log: prompts and responses for high-risk applications (with privacy controls), tool calls and the identity used, retrieval sources, guardrail blocks, model and prompt versions.
- Coverage metric: percentage of inventoried GAI systems with a completed 12-risk assessment.
- Testing metric: percentage of releases that passed a prompt injection and data leakage test under MS-2.7-007 before deployment.
- Supplier metric: percentage of model and plugin suppliers assessed under the GV-6.1-005 framework.
- Identity metric: percentage of agents with a named owner and scoped, rotated credentials.
- Incident metric: mean time to triage GAI incidents against the GV-4.3-002 reporting criteria.
Framework mapping
| AI 600-1 area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Threat references |
|---|---|---|---|
| Govern actions, risk tolerance | GV.RM Risk Management Strategy | PM-9 Risk Management Strategy | None |
| Map, 12-risk assessment | ID.RA Risk Assessment | RA-3 Risk Assessment | None |
| Information Security | ID.RA | SA-11 Developer Testing and Evaluation | ATLAS AML.T0051, AML.T0020; OWASP LLM01:2025, LLM04:2025 |
| Value Chain and Component Integration | GV.SC Cybersecurity Supply Chain Risk Management | SR-3 Supply Chain Controls and Processes | ATLAS AML.T0010 AI Supply Chain Compromise; OWASP LLM03:2025 |
| Data Privacy | ID.RA | RA-3 | OWASP LLM02:2025 Sensitive Information Disclosure |
| Incident Disclosure | GV.RM | IR-6 Incident Reporting | None |
The mapping is ours; NIST does not publish this table in AI 600-1.
Common failure patterns
- Treating the profile as a checklist of hundreds of mandatory items: teams stall. Select actions per use case and record the rationale.
- Reading only the risk list: the value is in the action tables and the Appendix A considerations; a register of 12 headings with no actions changes nothing.
- Ignoring indirect prompt injection: testing only the chat box misses poisoned documents, emails and web pages pulled in by retrieval, as EchoLeak showed.
- Leaving agent credentials out of scope: assessing the model but not the keys and tokens it uses, so an injected instruction inherits broad access.
- No supplier evidence: accepting a model provider's marketing claims instead of contract terms and assessments under GV-6.1.
- Citing the revoked order as current policy: state the status accurately in policies and customer responses.
Practitioner checklist
- Read AI 600-1 alongside AI RMF 1.0 and the AI RMF Playbook, not in isolation.
- Inventory every GAI model, application, agent, plugin and dataset with an owner and the credentials it uses.
- Assess each system against all 12 risks by their exact names, using the four risk dimensions.
- Adopt actions by ID and record adopt, adapt or reject decisions with reasons.
- Red-team for direct and indirect prompt injection and data poisoning before each significant release.
- Put provenance and ownership terms into model and plugin supplier contracts.
- Add GAI incident types and reporting criteria to the incident response plan.
- Scope, rotate and monitor every credential an agent holds, and log which identity performed each tool call.
- Describe the profile's status accurately: voluntary, current, origin order revoked, parent framework under revision.
Standards and references
- NIST: AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- NIST: Generative Artificial Intelligence Profile publication page
- NIST: AI Risk Management Framework
- US Government Publishing Office: Executive Order 14148, Initial Rescissions of Harmful Executive Orders and Actions
- MITRE ATLAS: LLM Prompt Injection
- OWASP: Top 10 for LLM Applications 2025
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: NIST AI RMF Guide · AI Risk Assessment Guide · LLM Security Guide · AI Red Teaming Guide · ISO/IEC 23894 AI Risk Management Guide. This guide summarises NIST AI 600-1 and is not legal advice.