AI governance is exposing the limits of existing IAM controls

At a glance

What this is: This is an analysis of how existing IAM and device controls support AI governance, with shadow AI emerging as the main exposure point when employees use AI tools outside approved oversight.

Why it matters: It matters because identity teams can no longer treat AI adoption as a separate problem; they need to extend access, device, and policy controls to govern where data goes and who can use AI tools.

By the numbers:

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

Context

AI governance is the set of controls, policies, and accountability mechanisms that determine how AI tools are approved, used, and monitored. In this article, the governance gap is not a lack of security tooling, but a mismatch between rapid AI adoption and the controls organisations already have in place.

The article’s central claim is that IAM, device management, and data protection controls remain relevant, but they are only effective when applied as part of an explicit AI governance model. Shadow AI becomes the practical failure mode because users can route data into tools that were never reviewed, approved, or monitored by security teams.

Key questions

Q: How should security teams govern shadow AI without blocking business productivity?

A: Start by identifying the identities and credentials behind AI use, then classify each one by data sensitivity, connected systems, and business purpose. Governance works best when organisations control the access path rather than banning the tool outright. That means inventory, approval, monitoring, and revocation all need to follow the same identity path.

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 breaks when employees use unapproved AI tools with company data?

A: Governance breaks because the organisation loses visibility into where data and secrets are going, who can access them, and how they are being reused. Unapproved tools can copy credentials into unmanaged workflows, which weakens revocation and makes audit trails incomplete. The result is shadow access outside the main identity programme.

Q: How do organisations know if AI identity governance is working?

A: They should be able to answer three questions quickly: which agents exist, which credentials each one uses, and who is accountable for each identity’s lifecycle. If any of those answers require manual searching across teams, the governance model is still incomplete and the environment remains difficult to audit.

Technical breakdown

Shadow AI creates a governance blind spot, not just a usage problem

Shadow AI appears when employees use AI tools or platforms outside IT or security oversight. The security issue is not simply that a tool exists, but that the organisation loses the ability to define approved data flows, retention terms, and access boundaries. Once staff paste source code, customer data, or internal documents into unmanaged AI services, the organisation has effectively moved sensitive information into a separate processing environment with different rules and no consistent control plane.

Practical implication: treat shadow AI as an access and data governance problem, not only an awareness issue.

IAM can restrict access, but it cannot by itself govern AI usage intent

IAM is still central because it decides who can reach specific tools and under what conditions. However, AI governance also depends on what users are allowed to do once access is granted, including the kinds of data they can submit and the business contexts in which AI tools may be used. That means identity policy must be paired with acceptable-use rules, application review, and monitoring for sanctioned and unsanctioned AI services.

Practical implication: align access policy with AI usage policy so authentication does not become a false sense of control.

Device management helps contain shadow AI by narrowing the endpoint surface

Device management provides inventory, patching, and policy enforcement across laptops, phones, and tablets. In an AI context, that matters because unmanaged endpoints can be used to reach consumer AI services, bypass browser controls, or move sensitive content outside the enterprise boundary. The strength of the control is visibility. If you do not know which devices are active, compliant, and connected, you cannot reliably govern where AI interactions begin or what data they touch.

Practical implication: use endpoint inventory and posture checks to block or flag AI use from unmanaged devices.

Threat narrative

Attacker objective: The practical objective is not always an external intruder, but the unauthorised movement of sensitive business data into environments the organisation does not govern.

1. Entry occurs when a trusted employee uses an unsanctioned AI tool from a normal work device, often to speed up writing, coding, or analysis.
2. Credential or access abuse is not always the trigger here; the key failure is that approved identity and device controls do not extend into the unmanaged AI service boundary.
3. Impact occurs when sensitive code, documents, or regulated data is exposed outside the organisation’s intended controls and may persist in logs, prompts, or downstream model processing.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is an identity governance problem before it is an AI problem: unmanaged AI use emerges when users can move from approved identity to unapproved data processing without a new control decision. Existing IAM can authenticate the user, but it does not automatically govern the AI endpoint or the data submitted to it. The implication is that AI governance must start with user-to-tool authorisation, not only with model oversight.

IAM controls remain necessary, but they are not a complete AI governance model: identity policy can restrict who may reach specific AI tools, yet it does not define what data may be submitted, what retention terms apply, or which workflows are off limits. That gap is why IAM becomes the first line of defence rather than the full control stack. Practitioners need to treat AI usage policy as a separate governance layer with its own enforcement points.

Device management becomes part of AI governance when endpoints are the path to shadow AI: endpoint inventory, patching, and posture checks are not just hygiene controls when AI tools are involved. They help determine whether the organisation can see and constrain where AI interactions originate. The named concept here is AI governance boundary drift: the distance between the identity policy that grants access and the data boundary where AI services actually process content. Teams should assume that drift is already present unless they can prove otherwise.

The controls already in place are useful only if they are re-scoped for AI use cases: the article is right that organisations do not need to reinvent security from scratch, but reuse works only when identity, endpoint, and data rules are translated into explicit AI operating rules. That is the real governance task. Practitioners should reframe AI adoption as a policy extension exercise, not a tool-sprawl exception.

Education reduces mistakes, but governance failures are usually structural: the Samsung example shows that trusted staff can leak data without malicious intent, yet the lasting weakness is the absence of approved guardrails around AI use. Training matters, but it cannot substitute for enforceable boundaries, monitored usage, and clear accountability for sanctioned AI services. The field needs less reliance on user discretion and more on governable patterns.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Policy Template

What this signals

Shadow AI turns AI adoption into a governance boundary problem for identity teams. Existing IAM can still be the enforcement point, but only if access policy is extended to cover approved tools, allowed data types, and the conditions under which AI use is acceptable.

AI governance boundary drift: the gap between who is authenticated and where data is actually processed will keep widening unless organisations deliberately connect identity policy, device posture, and data handling rules. The practical test is not whether users can access AI, but whether the organisation can prove that access remains within governed boundaries.

For practitioners

• Define an approved AI use policy Specify which AI services are allowed, what data may be used, and which work contexts require prior approval. Make the policy enforceable through access decisions rather than leaving it as guidance alone.
• Extend IAM rules to AI tool access Map identity groups to AI service access tiers, then require explicit authorisation for tools that process source code, regulated data, or internal documents. Review exceptions regularly so access does not become de facto approved use.
• Use endpoint posture to block unmanaged AI use Tie device compliance, inventory, and patch status to access conditions for AI services. Treat unmanaged or out-of-policy endpoints as higher risk because they can bypass enterprise visibility and send data to consumer AI platforms.
• Separate user training from control enforcement Train staff on what kinds of content must never be pasted into AI tools, but back that guidance with logging, app controls, and escalation paths. Education alone will not stop accidental data exposure.

Key takeaways

• Shadow AI is the clearest sign that AI governance cannot rely on IAM alone, because authentication does not control what users submit to external AI services.
• The article cites IBM’s finding that 63% of organisations lacked formal AI guidelines, which helps explain why sensitive data is still leaking into unmanaged tools.
• The immediate governance task is to align access policy, device controls, and acceptable-use rules so AI adoption stays inside approved boundaries.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Endpoint posture: Endpoint posture is the current security state of a device, including patch level, configuration, and management status. When posture is tied to identity and access decisions, it becomes part of the organisation's authorization logic rather than a background inventory metric.
• Governance Boundary Drift: Governance boundary drift is the widening gap between the controls that authorise an action and the environment where the action is actually executed. In AI use cases, it appears when identity policy is enforced but data is processed in unmanaged tools outside the intended boundary.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.