If you build or deploy generative AI, the National Institute of Standards and Technology (NIST) has written guidance for your systems. NIST AI 600-1, the Generative AI Profile, is a companion to the NIST AI Risk Management Framework (AI RMF) that names 12 risks unique to or made worse by generative AI and suggests actions to manage each one. NIST published it in July 2024. It’s voluntary, but a Texas statute ties one of its liability defenses to the profile. This guide explains what the profile contains, why it matters now, and six steps to work through it, with the action IDs so your team can trace each step back to NIST’s text.
What the profile is #
The AI RMF organizes AI risk work into four functions:
- Govern: who is accountable, and what are the rules
- Map: what AI do we run, and what could go wrong
- Measure: how do we test it
- Manage: what do we do about what we find
A profile is an implementation of those functions, categories, and subcategories for a specific technology. This one covers generative AI and applies across sectors.
NIST tags its suggested actions with IDs such as GV-1.6-001, where the letters show the function: GV for Govern, MP for Map, MS for Measure, and MG for Manage.
The profile lists actions for some AI RMF subcategories, not all of them. Not every action applies to every organization, since some are for teams that build models and others are for teams that deploy them. And the actions focus mainly on four considerations from NIST’s working group: governance, content provenance, pre-deployment testing, and incident disclosure.
Why it matters now #
The Texas Responsible AI Governance Act (TRAIGA, HB 149) took effect January 1, 2026. It prohibits a short list of intentional AI misuses. The attorney general leads enforcement, there’s no private right of action, and the attorney general must give written notice and 60 days to cure (Secs. 552.101 and 552.104). The statute also protects companies that find problems themselves. A company can’t be found liable for a violation it discovers through testing, including adversarial or red-team testing (Sec. 552.105(e)(2)(B)). It also can’t be found liable for a violation it discovers through an internal review process if it substantially complies with the most recent version of NIST’s Generative AI Profile or another recognized AI risk management framework (Sec. 552.105(e)(2)(D)). Talk to counsel about how this applies to you.
It will keep changing. NIST is revising AI RMF 1.0 under the July 2025 AI Action Plan, and the profile itself says future revisions will add subcategories, risks, and suggested actions. Keep your mapping in a form you can update.
The 12 risks #
NIST describes these as risks “unique to or exacerbated by” generative AI. Here they are in NIST’s order.
| Risk | What it means |
|---|---|
| CBRN information or capabilities | Easier access to information about chemical, biological, radiological, or nuclear weapons and other dangerous materials |
| Confabulation | Confidently stated but false content, often called hallucination |
| Dangerous, violent, or hateful content | Easier production of violent or hateful content, or recommendations of self-harm or illegal acts |
| Data privacy | Leakage, unauthorized use, or de-anonymization of personal or sensitive data |
| Environmental impacts | Heavy compute use in training and running models |
| Harmful bias or homogenization | Amplified societal bias, uneven performance across groups or languages, and overly uniform outputs |
| Human-AI configuration | Poor human-AI interaction, such as over-reliance, automation bias, or emotional entanglement |
| Information integrity | Lower barriers to producing misinformation and disinformation at scale |
| Information security | Lower barriers for offensive cyber activity, plus a bigger attack surface for the AI itself |
| Intellectual property | Easier replication of copyrighted, trademarked, or licensed content, and exposure of trade secrets |
| Obscene, degrading, and/or abusive content | Abusive synthetic content, including non-consensual intimate imagery and synthetic child sexual abuse material |
| Value chain and component integration | Untraceable third-party datasets, pre-trained models, and software, and weak supplier vetting |
Two of these sit closest to a security team’s work. Information security cuts both ways: generative AI can help attackers, and it gives them more to attack. Value chain risk is the supply chain problem. When a system is assembled from third-party models, datasets, and software, it’s hard to trace where a failure started. More broadly, NIST warns about “algorithmic monocultures”: when many organizations use the same model for consequential decisions, one flaw can cause correlated failures across all of them.
Key terms, as NIST defines them. Prompt injection means changing the input a generative AI system receives so it behaves in unintended ways. In a direct attack, someone types the malicious prompt. In an indirect attack, adversaries plant instructions in data the system is likely to retrieve. Jailbreaking means deliberately crafting prompts to get around output controls. Data poisoning means compromising a training dataset to manipulate a model’s behavior.
Six steps to work through the profile #
You don’t need to adopt all of it at once. This sequence follows the AI RMF’s order.
1. Inventory every generative AI system and what it depends on (Govern)
GV-1.6-001 says to enumerate your generative AI systems for your AI inventory. GV-1.6-003 lists what each entry should include: the underlying foundation models and versions, data provenance, known issues from incident and vulnerability databases, and who provides human oversight. GV-6.1-007 adds an inventory of third parties with access to your content, and an approved list of generative AI technologies and providers. If your AI takes actions, include the tools it connects to: Model Context Protocol (MCP) servers (connectors that let an agent use outside tools) and agent skills (add-on instruction packages). In the two months before August 2026, Enkrypt AI scanned 268,000+ tools across 25,000 MCP servers and found 143,000+ vulnerabilities affecting 73% of those servers.
2. Set go/no-go thresholds and a way to switch things off (Govern)
GV-1.3-002 calls for minimum performance or assurance thresholds as part of deployment approval, and GV-1.3-007 asks for a plan to halt a system that poses unacceptable risk. GV-1.7-001 and MG-2.4-004 cover protocols to deactivate a system and criteria for when to do it. Decide these before launch, not during an incident.
3. Plan adversarial testing around how the system is used (Map)
MP-2.3-005 calls for plans for regular adversarial testing to find vulnerabilities and potential misuse. MP-5.1-005 suggests adversarial role-playing, red teaming, or chaos testing to find failure modes nobody anticipated, and MS-1.1-008 asks you to decide where red teaming would help most for your context of use. Red teaming means attacking your own AI the way a bad actor would.
4. Red team security and privacy (Measure)
MS-2.7-007 calls for AI red teaming to assess resilience against abuse of the system to attack others (such as malicious code generation or phishing content), attacks on generative AI such as prompt injection, and machine learning attacks such as adversarial prompts, data poisoning, and model extraction. MS-2.10-001 does the same for privacy, testing whether the system outputs training data or reveals personal, confidential, or proprietary information. MS-2.7-008 asks you to verify that fine-tuning doesn’t weaken safety and security controls, and MS-4.2-001 calls for adversarial testing at a regular cadence.
MS-1.3-003 adds an independence rule: the people running structured feedback exercises such as red teaming shouldn’t be directly involved in building the same model. MS-2.3-004 names a purpose-built test environment, NIST Dioptra.
### 5. Test the output risks (Measure)
For confabulation, MS-2.5-003 asks you to verify sources and citations in outputs, before launch and in operation. For dangerous content, MS-2.6-006 asks you to verify the system handles queries that could facilitate manipulation, extortion, impersonation, cyberattacks, or weapons creation, and MS-2.6-007 asks you to regularly evaluate how easily safety measures can be circumvented. For bias, MS-2.11-002 suggests fairness assessments across groups, including red teaming with counterfactual and low-context prompts.
6. Monitor, respond, and keep evidence (Measure, Manage, and Govern)
MS-2.5-006 asks you to review security and safety guardrails regularly, especially in new circumstances. MG-4.1-002 calls for post-deployment monitoring, particularly for confabulation, CBRN, and cyber risks. MG-2.3-001 covers incident response and recovery plans, and GV-4.3-002 sets minimum incident reporting fields, such as system ID, title, reporter, date, description, impacts, and who was affected. When you fine-tune a model or adopt a third-party one for a new use, MG-3.1-003 asks you to reassess it.
Then keep the record. GV-1.5-003 calls for a retention policy covering the history of your testing and evaluation, and MS-2.8-002 asks you to document the instructions given to red teamers. If you rely on the Texas defense described above, that record is what you’d point to.
What the profile says about AI agents #
The profile covers generative AI broadly and isn’t agent-specific. It does list autonomous agents among the threats to assess (MS-2.7-001), and GV-4.2-003 asks you to include downstream impacts, such as third-party plugins, in your impact documentation. Since then, NIST has launched the AI Agent Standards Initiative (February 17, 2026) and is developing SP 800-53 control overlays (tailored security controls) for securing AI systems, including agent use cases. The agent-specific overlays are still in development. Until they’re published, treat an agent’s tool access as part of the system you test.
What to watch next #
- The [AI RMF 1.0 revision](https://www.nist.gov/itl/ai-risk-management-framework) and the updates that follow it
- New deliverables from the [AI Agent Standards Initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative)
- Agent-specific [control overlays for SP 800-53](https://csrc.nist.gov/projects/cosais)
How Enkrypt AI helps #
Enkrypt AI, by Anaconda, supports several of the testing and record-keeping actions in the six steps. Agent Red Teaming attacks your generative AI systems the way an adversary would, including agents with tool access, and, on paid plans, maps each finding to the NIST AI RMF, the Open Worldwide Application Security Project (OWASP) Top 10 for Large Language Model Applications, and the EU AI Act. Each finding includes reproduction steps and a severity rating. On Scale and Enterprise plans, fixed findings become regression tests you can run in continuous integration (CI) before each release, which adds to the record step 6 describes. The Agent Policy Engine turns your policies and regulation text into controls, each traced to its source clause, so testing, runtime guardrails, and evidence work from one policy. The MCP Scanner checks the servers your agents connect to. You can scan a server for free from its product page.
Two public resources help too. The LLM Safety Leaderboard ranks more than 200 models (as of October 2026) on Enkrypt AI’s NIST risk score, Enkrypt AI’s own measure rather than a NIST rating: the average attack success rate across tests for bias, harmful content, toxicity, CBRN, and insecure code generation. It also reports an OWASP score. The Agent Incident Registry is a public catalog of verified agent incidents, classified into a risk taxonomy crosswalked to the NIST AI RMF, which makes it one source for the known issues GV-1.6-003 asks you to track.
Enterprise plans support virtual private cloud (VPC) or on-premises deployment. To see how Enkrypt AI, by Anaconda, works on your own systems, explore AI security & guardrails or request a demo.
FAQ #
What is NIST AI 600-1?
It’s the Generative AI Profile, published in July 2024 as a companion to the NIST AI Risk Management Framework. It names 12 risks unique to or made worse by generative AI and suggests actions, organized by AI RMF subcategory, to manage them.
Is NIST AI 600-1 mandatory?
No. It’s voluntary. But Texas’s TRAIGA ties one of its liability defenses to it. A company can’t be found liable for a violation it discovers through testing, including red-team testing, or through an internal review process if it substantially complies with NIST’s Generative AI Profile or another recognized framework (Sec. 552.105(e)). Talk to counsel about how this applies to you.
Does NIST AI 600-1 require red teaming?
No. It suggests red teaming in several places, including MEASURE 2.7 for security and MEASURE 2.10 for privacy, and recommends adversarial testing at a regular cadence. Like the whole framework, it’s voluntary. Learn more about red teaming for agents.
Does it cover AI agents?
Not specifically. It mentions autonomous agents as a threat to assess, and NIST has since launched separate agent work, including the AI Agent Standards Initiative and agent control overlays that are still in development.