AI sprawl across departments is outpacing identity controls

At a glance

What this is: This analysis shows that department-specific AI sprawl is creating hundreds of unsanctioned tools and bypassing traditional discovery models.

Why it matters: It matters because IAM, IGA, and security teams need controls that can see and govern AI usage across human users, workflows, and emerging agentic patterns before shadow adoption hardens into policy debt.

By the numbers:

• Product and Engineering teams use 200+ unique AI applications.
• Sales and Marketing have adopted 170+ AI applications.
• Traditional discovery methods catch less than 20% of AI tools.

👉 Read Zluri's analysis of department-specific AI sprawl and discovery gaps

Context

AI sprawl is what happens when different departments adopt AI tools independently, outside a shared governance model. In this article, the core problem is not just tool volume but the way department-specific buying patterns defeat normal identity and procurement controls before security teams can map the exposure.

For IAM and IGA programmes, this is a visibility and control problem first, and a tooling problem second. Once AI is embedded through personal accounts, browser extensions, APIs, and embedded features in SaaS platforms, the usual discovery path misses both the identity behind the action and the data that moves through it.

Key questions

Q: How should security teams discover shadow AI across departments?

A: Use multiple discovery paths at once: identity provider logs, expense data, endpoint telemetry, browser extension inventory, and cloud API monitoring. No single source will catch departmental AI sprawl because users adopt tools through different identities and payment paths. The goal is a defensible inventory that connects usage to people, data, and business context.

Q: Why do departmental AI tools create governance gaps for IAM teams?

A: Departmental AI tools create gaps because adoption happens in parallel, with different users, different data types, and different approval paths. IAM teams lose consistency when one department uses personal accounts, another uses embedded AI in SaaS, and a third buys stand-alone subscriptions. The result is a fragmented identity surface that access reviews cannot reliably cover.

Q: What should organisations do when employees use AI tools outside approved channels?

A: First, classify the usage by data sensitivity and identity path, then decide whether the tool should be approved, restricted, or replaced with a sanctioned alternative. Do not start with punishment. Start with visibility, because employees often adopt tools to solve real work problems. The most durable control is a combination of approved options, risk-based review, and clear policy enforcement.

Q: How can teams reduce shadow AI without blocking useful work?

A: Create an approved catalog for common use cases, fast-track low-risk requests, and reserve stricter review for tools that process sensitive data or introduce broader access. If the approved path is slower than the shadow path, users will bypass it. The practical answer is to make safe adoption easier than unmanaged adoption.

Technical breakdown

Why departmental AI adoption defeats standard discovery

Department-level AI adoption fragments the control plane. Engineering prefers code and model tools, Marketing prefers content generation, Support prefers conversational and voice tools, and each group often adopts through different payment and authentication paths. That means discovery based on one signal, such as SSO logs or procurement records, only sees part of the landscape. The governance problem is not merely that tools are hidden. It is that the same capability appears in multiple forms across multiple departments, so the inventory changes faster than manual review cycles can keep up.

Practical implication: teams need multi-channel discovery that combines identity logs, expense data, endpoint signals, and browser telemetry.

How shadow AI bypasses identity and access controls

Shadow AI often bypasses formal IAM by using personal accounts, free tiers, browser extensions, and direct API usage. In some cases, engineers and business users access tools without creating a corporate authentication event at all. That matters because identity systems can only govern what they can see, and these paths leave weak or no enterprise trace. Once AI usage happens through unmanaged identities or outside the approved app stack, access reviews, entitlement management, and even DLP become reactive rather than preventive.

Practical implication: treat browser, expense, and API signals as identity telemetry, not just IT hygiene data.

Why AI sprawl creates a data governance problem, not just a license problem

The risk profile changes by department, but the failure mode is consistent: sensitive data is copied into tools that were never assessed for retention, training, or downstream sharing. Engineering may expose code and architecture, Marketing may expose customer and campaign data, and Support may expose PHI or PII. This is where AI sprawl becomes an identity issue, because the identity attached to the tool determines what data leaves the environment and whether that use can be governed, reviewed, or revoked later.

Practical implication: align AI tool approval with data sensitivity and identity type, not with department preference alone.

Threat narrative

Attacker objective: The practical objective is to capture sensitive enterprise data or workflow context through unmanaged AI usage and move it outside governed identity and access controls.

1. Entry occurs when employees adopt AI tools through personal accounts, free tiers, browser extensions, or embedded SaaS features that do not trigger a formal enterprise authentication event.
2. Escalation happens as departments expand usage from low-risk tasks into workflows that carry code, customer data, strategic plans, or regulated information across multiple tools.
3. Impact follows when unmanaged AI use creates data leakage, duplicated capabilities, inconsistent controls, and governance gaps that identity teams cannot easily inventory or revoke.

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

Departmental AI sprawl is an identity governance problem disguised as a software adoption story. The article shows that Engineering, Marketing, Support, Design, and Operations are each building separate AI inventories through different acquisition paths and different risk profiles. That breaks the assumption that discovery can be done once, centrally, and then governed uniformly. Practitioners should treat departmental AI adoption as a federated identity surface, not as isolated SaaS noise.

AI discovery based on a single control plane is already obsolete. SSO logs, procurement reviews, and manual app inventories each catch only part of the exposure because AI is being adopted through expenses, embedded features, endpoints, and personal accounts. This is a classic visibility gap, but the named concept here is decentralised AI visibility debt: the longer departments adopt independently, the more incomplete the governance record becomes. Security teams should recognise that incomplete visibility compounds into policy failure, not just reporting error.

Identity does not always mediate AI use, and that is the point of failure. The article repeatedly describes paths where users interact with AI without a stable corporate identity event, especially through free tiers, personal accounts, and browser add-ons. That means access reviews were designed for a condition where usage is visible long enough to certify, but this condition no longer holds for much of shadow AI. The implication is that governance models built around reviewable entitlement states need rethinking when the usage event itself is the only trace.

Data governance and identity governance are converging inside AI adoption decisions. The real control question is not whether a department can buy a tool, but whether the identity behind that tool is authorised to move the data it will see. Engineering, Marketing, and Support each expose different data classes, so approval logic must be tied to identity type, data sensitivity, and usage context together. That is where NHI, human IAM, and emerging agentic patterns start to converge in one control problem.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, followed by inadequate monitoring and logging at 37%, according to the same report.
• For the governance lens behind this sprawl problem, see Ultimate Guide to NHIs - Key Challenges and Risks.

What this signals

Decentralised AI adoption is forcing identity teams to think in programme terms, not app terms. The control question is no longer how to approve one more tool, but how to detect repeated patterns of unmanaged access across departments before the inventory becomes ungovernable. For the broader identity programme, that means browser telemetry, expense data, and SaaS feature mapping now belong in the same operational conversation as access reviews and entitlement governance.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the visibility problem extends well beyond AI tooling and into delegated access more generally. That is the programme signal: if you cannot see the third-party path, you cannot claim to govern the identity path.

For practitioners

• Build multi-channel AI discovery Combine SSO logs, expense exports, endpoint telemetry, and browser extension inventory so discovery does not depend on a single enterprise control plane.
• Classify AI tools by department and data sensitivity Map each discovered tool to the department using it, the identity path used to reach it, and the sensitivity of the data it can process.
• Tie approvals to identity and data context Do not approve AI tools on functionality alone. Require different approval paths for tools that can process source code, customer data, regulated records, or strategic material.
• Create sanctioned alternatives for common use cases Publish a small approved catalog for chat, code generation, content creation, transcription, and customer intelligence so users have a viable path that does not require shadow adoption.

Key takeaways

• Department-specific AI adoption creates a fragmented identity surface that traditional discovery and review processes do not fully cover.
• The scale of the problem is already material, with some departments using 200+ AI applications while standard discovery still misses most of the estate.
• The practical response is multi-channel discovery, risk-based approval, and identity-aware data controls tied to how each department actually uses AI.

Key terms

• Shadow AI: AI tools or services used inside an organisation without clear approval, visibility, or control from the security team. In practice, it includes personal accounts, free tiers, embedded SaaS features, browser extensions, and API usage that bypass normal governance and leave the identity programme blind to the real access path.
• AI Sprawl: The uncontrolled growth of AI tools across teams, departments, and workflows. Unlike a simple software inventory problem, AI sprawl creates fragmented ownership, inconsistent approval paths, and hidden data movement, which makes it harder for IAM and security teams to maintain a reliable access record.
• Identity Surface: The full set of identities, accounts, tokens, and access paths that can reach organisational data and systems. For AI adoption, the identity surface expands when employees use personal credentials, embedded features, or direct API calls that do not pass through standard enterprise controls.

What's in the full article

Zluri's full article covers the operational detail this post intentionally leaves for the source:

• Department-by-department tool categories and examples for Engineering, Marketing, Support, Operations, and Design
• The four-method detection playbook, including log analysis, expense review, network monitoring, and browser extension inventory
• Specific risk-based approval tiers and timing targets for low-risk versus high-risk AI requests
• A practical consolidation model for reducing overlapping AI tools while preserving team autonomy

👉 The full Zluri article covers the detection playbook, control tiers, and consolidation approach in detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.