AI governance is exposing the limits of existing IAM controls

At a glance

What this is: This is a practitioner analysis of how existing IAM, device, and data controls can support AI governance, with shadow AI emerging as the central risk.

Why it matters: It matters because security teams are being asked to govern AI use without losing control of identities, endpoints, and sensitive data across human, NHI, and autonomous workflows.

By the numbers:

• 63% of organizations lacked formal guidelines for managing AI, failing to prevent the use of shadow AI.

👉 Read JumpCloud's analysis of AI governance, shadow AI, and IAM controls

Context

AI governance is now an identity and control problem, not just an application policy problem. When employees adopt AI tools outside IT oversight, the core question becomes which identities, devices, and data paths those tools can reach before security can constrain them.

The article argues that teams do not need to rebuild security from scratch, but that claim only holds if existing IAM, endpoint, and data controls are actually mapped to AI use cases. Shadow AI shows where those controls stop at the human workflow and fail to follow the data into external systems.

Key questions

Q: How should security teams govern shadow AI without blocking useful adoption?

A: Start by governing access, not by banning tools. Security teams should map approved AI services to identities, roles, and managed devices, then define which data classes may be submitted. That gives employees a safe path for experimentation while preventing unsanctioned services from becoming invisible data exits. The key is enforcement at the identity and endpoint layer.

Q: Why do existing IAM controls only partially solve AI governance?

A: IAM decides who can reach a service, but AI governance also has to control what data is submitted and how the service may use it. Once a prompt or file leaves the environment, authentication alone cannot recover the exposure. IAM is necessary, but it must be paired with endpoint policy and data handling rules.

Q: What do organisations get wrong about shadow AI risk?

A: They focus on the novelty of AI tools and miss the older control failures underneath them. Shadow AI usually appears because identity policy, endpoint control, and data classification are not aligned. If those controls do not work together, employees can move regulated or sensitive content into external systems without triggering meaningful enforcement.

Q: How can security teams reduce AI data leakage from managed endpoints?

A: Use device management to restrict which endpoints can access approved AI services, require patching and inventory visibility, and block unmanaged browsers or devices from handling sensitive workflows. The goal is to stop data from leaving through an endpoint that cannot be inspected or governed. That makes containment possible before the prompt is sent.

Technical breakdown

Shadow AI and identity governance

Shadow AI appears when employees use AI tools without security approval or governance visibility. In practice, the risk is not only the tool itself but the identity context attached to it: who authenticated, what device was used, and which data was exposed to the service. That makes AI use an extension of IAM, not a separate policy island. If identity controls cannot distinguish sanctioned AI access from ad hoc use, governance loses its ability to enforce boundaries at the point of interaction.

Practical implication: map approved AI access paths to identities and devices before data reaches unapproved tools.

IAM as the access checkpoint for AI tools

IAM remains the decision layer that determines who may connect to AI services and under what conditions. For AI governance, this means access policy, conditional access, and role scope must cover both sanctioned applications and the services that can ingest enterprise data. The problem is not that IAM is obsolete. The problem is that many organisations still treat AI as a user productivity issue rather than an access governance issue, which leaves policy gaps around data export and prompt-based interaction.

Practical implication: extend identity policy to cover AI services that can accept corporate data or prompts.

Device management and endpoint control for AI use

Device management becomes critical because endpoints are often the first place shadow AI appears. A managed device can provide inventory, patch status, and usage visibility, which helps security teams spot unauthorized access to AI tools before the activity spreads. Endpoint policy also matters because many AI interactions begin in browsers or local apps where sensitive data can be copied into external systems. If device posture is not part of the access decision, the organization loses a major control point for containment.

Practical implication: require managed, patched devices for any AI workflow that can touch company data.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is an identity governance failure before it is an AI problem. The article correctly points to unmanaged adoption, but the deeper issue is that enterprise controls were designed for approved software paths, not for employees creating new data egress routes through third-party models. When the access path is invisible, governance cannot certify what it cannot see. The practitioner conclusion is that AI usage must be brought under identity and device control before policy can mean anything.

Existing IAM controls are necessary, but they are not sufficient for AI governance. IAM can decide who is allowed to reach a service, yet it does not automatically govern what content gets submitted, retained, or reused once the service is reached. That distinction matters because AI tools turn an access event into a data-handling event. Practitioners should treat AI exposure as an access plus data boundary problem, not as a simple authentication issue.

Device management is the hidden enforcement layer for shadow AI. The article’s emphasis on endpoints is directionally correct because unmanaged devices bypass the most practical inspection and policy mechanisms available to security teams. A controlled endpoint inventory gives security teams a chance to distinguish sanctioned AI use from informal experimentation. The practitioner conclusion is that endpoint governance is part of AI governance, not a supporting detail.

AI governance should be built as an extension of existing control planes, not as a separate program. The strongest operational model is to reuse identity, device, and data controls already in place, then bind them to AI-specific policy decisions. That reduces fragmentation and avoids the common mistake of creating a parallel “AI policy” layer with no enforcement path. The practitioner conclusion is to anchor AI governance in the controls the organisation can already operationalize.

From our research:

• 72% of organizations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• Shadow AI governance should be treated as a control-plane problem, which aligns with the Top 10 NHI Issues and the identity boundary issues it documents.

What this signals

Shadow AI will keep expanding wherever identity policy stops at the human user and does not extend to the service, device, and data path. The programme risk is no longer just unauthorized software use. It is unmanaged data movement through approved identities on unapproved services, which means teams need visibility into where prompts and files are actually going before they can claim governance.

AI governance needs the same operational discipline as NHI governance. If an organisation already understands how to constrain service accounts, tokens, and device trust, it can adapt those patterns to AI workflows without inventing a separate control philosophy. The next step is aligning approved use cases to identity and endpoint enforcement, then measuring how much AI traffic still sits outside policy.

Runtime containment becomes the practical goal. The more AI usage blends into daily work, the more security teams need controls that decide at the moment of access whether the request, device, and data combination is acceptable. That is the line between managed adoption and shadow AI sprawl.

For practitioners

• Map all approved AI entry points Inventory which identities, applications, and managed devices are allowed to reach AI services that can process company data. Tie those paths to explicit policy so that unsanctioned tools do not inherit enterprise trust by default.
• Extend conditional access to AI services Apply access rules that consider user role, device posture, and data sensitivity before prompts or files can leave the environment. Make the control decision happen before the external AI interaction begins.
• Treat shadow AI as a discovery problem Add endpoint telemetry, browser visibility, and identity logs to find where employees are already using AI tools. The first remediation step is to see the interaction surface, including unmanaged devices and unsanctioned SaaS use.
• Define AI data handling boundaries Write policy for what content may be entered into external models, how it is classified, and which user groups may make that decision. Keep the rule operational by linking it to identity policy and device enforcement.

Key takeaways

• Shadow AI is exposing a governance gap that traditional IAM cannot close on its own.
• The scale signal is clear: IBM says 63% of organizations lacked formal AI guidelines, which left shadow AI unchecked.
• Security teams should extend identity, device, and data controls to every AI entry point before usage spreads further.

Key terms

• Shadow AI: Shadow AI is the use of AI tools or services outside approved IT and security oversight. In practice, it creates hidden data paths, unclear accountability, and uncontrolled retention risk because the organisation cannot enforce policy on what it cannot see.
• Conditional access: Conditional access is an access decision that depends on signals such as identity, device posture, location, or risk. For AI governance, it becomes the practical gate that can stop prompts and files from reaching unapproved external services.
• Managed device: A managed device is an endpoint enrolled in organisational controls for inventory, patching, policy enforcement, and monitoring. In AI governance, it matters because endpoint control is often the last enforceable barrier before sensitive data leaves the environment.

Deepen your knowledge

AI governance and shadow AI control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending existing identity controls into AI workflows, this is a practical place to start.

This post draws on content published by JumpCloud: AI governance, shadow AI, and the controls already in place. Read the original.