Should AI risk management be handled separately from security and identity programmes?

No. AI risk management should be integrated with security and identity programmes because AI tools often require sensitive data, system access, and delegated authority. If those permissions are not governed like other privileged access, AI becomes another pathway for data exposure, misuse, or uncontrolled automation.

Why This Matters for Security Teams

AI risk management cannot sit in a separate lane from security and identity because AI systems inherit the same enterprise realities as any other privileged technology: they authenticate, access data, call tools, and make decisions that affect operations. If those interactions are not governed through existing control planes, the organisation ends up with shadow privilege, unclear accountability, and weak evidence for audit or incident response. The NIST Cybersecurity Framework 2.0 is useful here because it treats governance, protection, detection, response, and recovery as connected functions rather than isolated programmes.

The practical failure mode is not usually a single AI model breach. It is the accumulation of small governance gaps: a chatbot with access to internal documents, an agent with reusable tokens, a model workflow that bypasses approval, or a developer pipeline that ships an unreviewed integration into production. Identity teams, security teams, and AI governance owners often assume someone else is covering the control boundary, which leaves no one accountable for delegated authority or data handling. In practice, many security teams encounter AI misuse only after sensitive content has already been exposed or an automated action has already been executed, rather than through intentional control design.

How It Works in Practice

Integrated AI risk management means the organisation treats AI capabilities as part of the normal security architecture, not as a separate policy track. That starts with inventory: what AI systems exist, who owns them, what data they ingest, what outputs they generate, and which tools or APIs they can invoke. Next comes access governance. If an AI system can read tickets, create code, query customer records, or trigger workflows, its credentials, secrets, and permissions should be managed with the same discipline applied to other privileged services.

NIST’s NIST AI Risk Management Framework is helpful for structuring governance around mapping, measuring, and managing AI risk, while NIST AI 600-1 Generative AI Profile adds practical focus for GenAI-specific threats such as prompt injection, unsafe output use, and training or retrieval data leakage.

Operationally, security teams should align AI controls to established identity and cyber processes:

• Register AI systems in the asset inventory and assign a business owner and technical owner.
• Classify the data each system can access, including prompts, retrieved content, logs, and outputs.
• Issue scoped, time-bound credentials for AI services and rotate or revoke them like other machine identities.
• Route AI actions that affect production, finance, or customer data through approval or policy checks.
• Log model prompts, tool calls, and high-risk outputs so security can detect misuse and support investigation.

This approach also connects naturally to NIST IR 8596 Cyber AI Profile, which helps teams think about AI as part of cyber defence rather than as a separate novelty. These controls tend to break down when AI is embedded in fast-moving developer workflows with unmanaged API keys, because control ownership and change oversight become unclear.

Common Variations and Edge Cases

Tighter AI control often increases approval overhead and can slow experimentation, so organisations have to balance innovation against risk containment. Best practice is evolving for some areas, especially around agentic AI and autonomous tool use, where there is no universal standard for exactly how much autonomy is acceptable. That makes governance design more important than policy language alone.

Some teams can centralise AI oversight effectively, while others need a federated model with shared guardrails across security, identity, legal, privacy, and platform engineering. The right pattern depends on whether the AI is internal, customer-facing, safety-critical, or connected to regulated data. The important point is that separate governance does not mean separate controls. AI that handles personal data, financial data, or regulated content should inherit the same evidence, retention, and accountability expectations as any other production system. Where AI outputs can directly trigger system changes, the boundary between AI risk and privileged access becomes especially important.

For organisations formalising their programme, the governance language in the CSA Mythos-ready CISO security programme guidance and the management-system approach in ISO/IEC 42001:2023 AI Management System Standard can help define ownership, reviews, and continuous improvement. The edge case to watch is AI embedded in third-party SaaS with opaque sub-processors and limited logs, because identity and security teams may not be able to enforce or even verify the expected controls.

Related resources from NHI Mgmt Group

• When does AI-assisted identity management become a security risk?
• Why do AI-driven attacks increase risk for identity and access management programmes?
• How do identity teams extend AI risk management into existing programmes?
• Why do AI agents create new risk in non-human identity management?