TL;DR: NIST’s Cybersecurity Framework Profile for Artificial Intelligence folds AI into existing cyber risk management, with emphasis on trust, identity, provenance, auditability, and lifecycle controls across Govern through Recover, according to Keyfactor’s summary of NIST IR 8596. The draft makes AI a current identity and governance problem, not a separate future discipline.
At a glance
What this is: NIST’s Cyber AI Profile draft frames AI as part of mainstream cyber risk and centers trust, identity, and lifecycle governance.
Why it matters: It matters because IAM, NHI, and security teams now have to govern AI systems with the same control rigor they already apply to people, workloads, and machine identities.
By the numbers:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
👉 Read Keyfactor’s analysis of the NIST Cyber AI Profile draft
Context
AI security is no longer a side issue for identity and cyber programmes. The NIST Cyber AI Profile draft, built on NIST IR 8596 and CSF 2.0, treats AI as something that must be governed inside existing risk, access, and recovery structures rather than as an exception.
That framing matters for IAM and NHI teams because the control question changes from whether AI should be allowed into the environment to how its identity, permissions, provenance, and accountability are enforced once it is already there. The draft also reflects a broader shift toward identity-first governance for machines and AI systems.
For practitioners, the practical signal is that AI governance is converging with machine identity and zero trust work. The organizations that already manage workload identity, secrets, and access review processes are closest to being able to extend those controls to AI systems without inventing a parallel security model.
Key questions
Q: How should security teams govern AI systems inside existing IAM programmes?
A: Start by treating AI systems as governed assets with identity, access, and audit obligations, not as experimental exceptions. Put them into the same inventory, risk register, and review cadence used for other production systems. Then define what the system may access, which actions must be logged, and who owns approval and recovery decisions.
Q: Why do AI agents change the way organisations think about zero trust?
A: AI agents can operate continuously, act at machine speed, and influence multiple systems without waiting for a human decision at each step. That breaks static trust assumptions. Zero trust for AI therefore needs continuous verification, traceable identity, and least privilege for the agent itself, not just the human who requested it.
Q: What should teams review first when adding AI to an existing security model?
A: Review identity, authorization, provenance, and recovery first, because those controls determine whether AI can be trusted in production. If the organisation cannot show who the AI is, what it can do, where its data came from, and how it is contained when it fails, the security model is incomplete.
Q: Who is accountable when an AI system makes a harmful decision?
A: Accountability should rest with the business and control owners who approved the system, its permissions, and its operating scope. AI does not remove ownership. Security, risk, and platform teams need a clear governance chain for approvals, logging, rollback, and recovery so responsibility survives automation.
Technical breakdown
How the NIST Cyber AI Profile extends CSF 2.0 to AI systems
The draft does not replace the Cybersecurity Framework. It maps AI security concerns into the familiar Govern, Identify, Protect, Detect, Respond, and Recover functions, which is a strong signal that AI controls should be operationalised through existing enterprise risk structures. That approach matters because it treats AI as a cyber asset with lifecycle obligations, not as a separate governance island. The practical effect is that boards, CISOs, and control owners can use established assurance processes instead of waiting for a new AI-only taxonomy to mature.
Practical implication: map AI assets into your CSF-based control inventory instead of creating a separate policy stack.
Identity, authorization, and auditability for AI agents
NIST’s emphasis on authentication, authorization, accountability, and auditability shows that AI systems are being assessed as actors that need bounded identity, not just as software outputs. For agents and services, that means unique traceability, defined permissions, and logs that can be attributed to a specific system action. This aligns closely with machine identity governance: if a system can initiate action, the environment needs a reliable way to distinguish the actor, its privileges, and the records of what it did. That is the minimum condition for control.
Practical implication: require identity, permission, and audit records for AI actions before allowing production access.
AI supply chain risk now includes data, prompts, and providers
The draft broadens supply chain thinking beyond code to include models, training data, prompts, inference services, APIs, and third-party AI providers. That matters because provenance is no longer just a software question. It becomes a trust question about what data shaped the model, what service executed the inference, and what external dependency could change the outcome. For security teams, this is a reminder that AI control boundaries are distributed across more parties than a conventional application stack.
Practical implication: extend supplier review and provenance checks to AI data, model, and service dependencies.
NHI Mgmt Group analysis
AI governance is becoming an identity problem before it is a model problem. The draft’s most useful signal is that AI systems are expected to be governed through familiar security disciplines, especially identity, access, and auditability. That means the central question is not model sophistication but whether the system can be attributed, bounded, and reviewed like any other cyber actor. Practitioners should treat AI governance as an extension of machine identity controls, not a standalone innovation exercise.
Trust infrastructure, not model internals, will decide whether AI can be governed at enterprise scale. NIST’s repeated focus on provenance, traceability, authentication, and accountability shows that control credibility depends on surrounding assurance mechanisms. If those mechanisms are weak, the organization cannot reliably explain what the AI consumed, what it changed, or who is responsible. The implication is that trust architecture becomes a core control plane for AI-enabled environments.
Identity-first security is now the bridge between AI risk and existing cyber programmes. The draft reinforces a broader trend that AI must fit within established CSF, zero trust, and lifecycle governance models. That positions IAM, PAM, and NHI teams as the practical owners of much of the control fabric needed for AI adoption. Practitioners should assume the AI programme will succeed or fail on the strength of identity governance already in place.
Zero Trust assumptions now need to extend to non-human and AI actors alike. The draft’s logic is that continuous verification and least privilege cannot stop at human users. AI systems and agents act continuously and can affect systems at machine speed, which means static trust assumptions age badly. Security leaders should read this as a signal that identity boundaries for machines and AI are converging, not diverging.
Control design must account for lifecycle, not just initial authorization. The draft’s emphasis on governance, response, and recovery shows that AI access cannot be treated as a one-time approval event. If an AI system changes role, data scope, or provider dependency, the governance model has to change with it. Practitioners should therefore align AI oversight with lifecycle and recertification discipline already used for other non-human identities.
From our research:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
- That gap between confidence and reality is why teams should also read The State of Non-Human Identity Security for the governance patterns that reduce hidden access risk.
What this signals
Identity governance is becoming the common language for AI, NHI, and human access. The NIST draft reinforces that AI controls will be judged against the same questions security teams already ask of workload identity and privileged access: who can act, what can they reach, and how is it traced. That convergence means identity programmes will increasingly be measured on whether they can extend one control model across people, services, and AI actors without creating parallel exceptions.
Trust debt will accumulate wherever AI dependencies are added without provenance controls. Once prompts, models, and inference APIs become part of the delivery chain, the organisation inherits new sources of uncertainty that IAM alone cannot absorb. The next step for practitioners is to connect supplier assurance, secrets governance, and logging discipline so AI adoption does not outpace control evidence.
With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, the broader lesson is that embedded access often hides faster than teams can review it. That is the same failure pattern AI governance will face if model and provider relationships are not captured in the same lifecycle process as other non-human access.
For practitioners
- Inventory AI systems inside existing control registers Map every AI system, service, and agent into the same risk register and asset inventory used for other production systems, including third-party tools that embed AI functions.
- Bind AI actions to traceable identities Require unique identity, permission scoping, and audit logs for each AI service or agent so security teams can attribute actions after the fact.
- Extend provenance checks to AI dependencies Review model sources, training data, inference APIs, prompts, and external AI providers as part of supply chain governance, not as a separate review path.
- Apply lifecycle controls to AI access Use review, recertification, and offboarding processes when an AI system changes scope, owner, or provider relationship, instead of leaving old permissions in place.
Key takeaways
- The NIST Cyber AI Profile draft treats AI as a governed cyber actor, which pulls identity and lifecycle controls into the centre of AI security.
- The practical risk is not only model misuse but weak provenance, weak attribution, and weak accountability across AI dependencies.
- Security teams should extend existing IAM, NHI, and zero trust controls to AI systems now, before separate exceptions become permanent gaps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | The draft centers governance, accountability, and trust for AI systems. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | AI agents need continuous verification and least privilege. |
| OWASP Non-Human Identity Top 10 | NHI-03 | AI systems acting as services need lifecycle and credential governance. |
Use AI RMF GOVERN and MAP to establish ownership, risk boundaries, and review cadence for AI systems.
Key terms
- AI System Identity: The identity assigned to an AI service, model, or agent so the organisation can control and audit its actions. In practice, it ties permissions, logs, and ownership to a specific system actor, which is essential when AI can access data or trigger actions in production.
- Provenance: Provenance is the traceable origin and history of data, models, prompts, and external services used by an AI system. Security teams use it to judge whether inputs and dependencies can be trusted, and to understand what influenced a model’s output or decision path.
- AI Lifecycle Governance: AI lifecycle governance is the set of review, approval, monitoring, and offboarding controls that apply from deployment through retirement. It ensures AI systems do not keep outdated access, undocumented dependencies, or unowned operational risk after their scope changes.
- Continuous Verification: Continuous verification is the practice of rechecking identity, trust, and authorization as systems operate, rather than only at login or initial approval. For AI and machine actors, it is the control pattern that replaces static trust assumptions with ongoing validation.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
This post draws on content published by Keyfactor: What the NIST Cyber AI Profile Draft Tells Us About the Future of AI and Cybersecurity. Read the original.
Published by the NHIMG editorial team on 2026-01-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org