Enterprise AI sprawl is outrunning governance and risk controls

At a glance

What this is: Singul AI argues that enterprise AI adoption has accelerated into a governance problem, with widespread use, rapid service growth, and shadow AI outpacing onboarding and policy enforcement.

Why it matters: IAM, IGA, PAM, and security teams need to treat AI tools and agents as governed access surfaces because unmanaged usage can expose data, bypass policy, and multiply control gaps across the enterprise.

By the numbers:

• More than 90% of employees are using AI in some capacity.
• Organizations are adding 8 to 50 new AI services per week, averaging 31 per week.
• Nearly 50% of AI services in use are classified as high risk based on the vendor's AI Trust Feed scoring.
• 75% of employees using AI rely on unvetted or unsanctioned AI tools.

Context

Enterprise AI adoption is no longer limited to pilots or a single sanctioned assistant. It now spans public AI services, homegrown LLM apps, embedded SaaS features, and endpoint tools used across multiple business functions, which means the control problem has shifted from adoption to governance.

That shift matters because AI services behave like a new class of access surface. When employees adopt tools faster than onboarding, policy review, and data classification can keep up, organisations create shadow AI, duplicate accounts, and unmanaged data paths that sit outside normal IAM and security oversight.

Key questions

Q: How should organisations govern AI usage when employees use unapproved tools?

A: Organisations should start with visibility, not enforcement. If teams cannot see which apps, agents, or workflows are being used, they cannot assess data exposure or apply meaningful controls. Once usage is mapped, policy can shift from blanket bans to context-based decisions that reflect sensitivity, role, and business purpose.

Q: Why do AI-accelerated platforms increase identity and access risk?

A: They increase risk because the platform concentrates sensitive data, compute, and decision-making in one place. If an attacker compromises one control plane, the blast radius can extend across datasets, models, agents, and downstream experiments. That is why identity, authorization, and logging need to be coordinated as one control system.

Q: What do security teams get wrong about Shadow AI?

A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem. The hidden risk can be an undocumented token, an over-permissioned service account, or an autonomous agent with unreviewed reach. Inventory the identity layer before you decide the tool is the issue.

Q: How do teams know whether AI governance is actually working?

A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement. If auditors can ask for a transaction and receive a complete record in hours, not weeks, the programme is producing usable control evidence rather than just documentation.

Technical breakdown

Why AI service sprawl creates an identity governance problem

AI service sprawl happens when employees, teams, and SaaS platforms introduce new AI tools faster than governance can inventory them. The result is not just tool sprawl but identity sprawl, because each service may bring its own accounts, API keys, permissions, and data-sharing defaults. In practice, security teams lose a clean view of who can access which model, what data it can see, and whether the access was approved. That breaks standard IAM assumptions that entitlements can be inventoried, reviewed, and revoked on a manageable schedule. See the AI Agent Authorisation Guide.

Practical implication: Treat every AI service as a governed identity surface, not just a software purchase.

Why shadow AI undermines policy enforcement and data control

Shadow AI appears when employees choose unapproved tools because sanctioned onboarding is too slow or too restrictive. That creates a policy gap: the organisation may have rules for data handling, retention, and access approval, but those rules do not reach the tool actually in use. The same risk appears when users run both enterprise and personal versions of the same AI service, because data can cross from controlled environments into uncontrolled ones. This is a governance failure as much as a security one, because the enterprise no longer knows where business data is processed or by whom. Read Zero Trust for AI Agents.

Practical implication: Block unmanaged AI usage through discovery, approved alternatives, and policy-backed enforcement.

How embedded SaaS AI and MCP-style integrations expand the attack surface

Embedded AI features inside SaaS applications can activate automatically, which means the organisation may inherit AI capability without a separate procurement or risk review. When those features connect to internal data or external models, the trust boundary moves again. MCPs and related integration patterns intensify this because tools, connectors, and runtime permissions can expose credentials, data, or actions far beyond the original application intent. The control issue is not simply whether AI is present, but whether the organisation can bound what the AI can retrieve, infer, and do across the stack. See the MCP Security Guide.

Practical implication: Review embedded AI features and integrations as runtime access paths, not passive product add-ons.

Threat narrative

Attacker objective: The objective is to reach enterprise data and actions through AI services that the organisation has not fully governed.

1. Entry occurs when employees adopt sanctioned, unsanctioned, or embedded AI services faster than the organisation can inventory and approve them.
2. Credential and access exposure follows when those services operate with broad account permissions, shared logins, personal subscriptions, or unreviewed integrations.
3. Escalation emerges as data moves between enterprise and personal AI tools, allowing business information to flow outside governed controls.
4. Impact is data leakage, governance loss, and a rising pool of AI services that security teams cannot confidently classify, monitor, or decommission.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

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

NHI Mgmt Group analysis

AI service sprawl is the new governance debt: the core problem is not AI adoption itself but the rate at which unmanaged services, accounts, and embedded features accumulate faster than governance can absorb them. That creates an identity and access inventory problem inside the AI stack, where no single team can reliably say which tools exist, who approved them, or what data they can reach. Practitioners should treat AI inventory as an access-control prerequisite, not an administrative afterthought.

Shadow AI is a control failure, not just a user behaviour issue: when employees bypass slow onboarding to meet business demand, they expose a gap between policy intent and operational reality. The article shows why sanctioning a tool is not enough if users can still reach personal accounts, alternative models, or embedded features with the same data. The governance lesson is to align approval speed, usable alternatives, and enforcement, otherwise the prohibited path becomes the default path.

High-risk AI drift is what happens when risk scoring cannot keep pace with usage growth: nearly half of the services in use are described as high risk, yet the environment is still expanding rapidly. That means static reviews will always lag behind runtime conditions unless control is continuous. For identity teams, the relevant question is not whether a service was once approved, but whether its current permissions, data exposure, and integration chain still match the original decision. Practitioners should govern AI like a living entitlement set, not a one-time purchase.

Endpoint AI agents need runtime governance because local execution collapses the old trust boundary: tools such as Claude Code, Cursor, ChatGPT Desktop, and MCP-connected workflows do not stay neatly inside the browser or the SaaS app. They operate in the developer workstation and terminal, where secrets, tokens, and source code are all within reach. That means agent control has to include runtime identity, task scope, and data access limits, not just policy approval. Practitioners should extend AI coding agents security thinking to every endpoint AI surface that can act on enterprise data.

AI control is becoming a cross-domain discipline: the article sits at the intersection of IAM, data protection, endpoint governance, and SaaS risk management. No single control family solves this because the issue spans discovery, authorization, data handling, and user behaviour. That makes AI governance a programme-level problem, not a point solution problem. Practitioners should build a shared operating model across security, IT, and data teams so AI usage is visible before it becomes normalised.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

AI governance debt: when service growth outpaces approval workflows, organisations accumulate a backlog of unreviewed tools, duplicate accounts, and unmanaged data paths. The programme response has to shift from periodic review to continuous control monitoring, because the environment changes faster than annual governance cycles can absorb it. That is where identity, data, and security ownership need a shared operating model.

The article's numbers point to a structural mismatch between access and risk. 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which means privilege decisions are already being made inconsistently across the estate, according to the 2026 Infrastructure Identity Survey.

Where AI access is least-privileged, outcomes change materially. Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.

For practitioners

• Inventory every AI service and embedded AI feature Create a continuously updated inventory of public AI tools, homegrown LLM apps, embedded SaaS AI, and endpoint AI agents, then assign owners and data classifications.
• Enforce approved-path usage for enterprise AI Route employees toward sanctioned AI services with usable onboarding, rather than leaving them to personal subscriptions or shadow AI workarounds.
• Review AI permissions at the point of use Check what data each AI service can access, what accounts it uses, and whether the permissions still match the approved business need.
• Tighten controls on endpoint AI tooling Apply stricter governance to coding assistants, desktop agents, and MCP-connected tools that can interact with code, secrets, or production systems.
• Separate enterprise and personal AI accounts Prevent mixed usage that allows the same user to move business data between controlled and uncontrolled environments.

Key takeaways

• Enterprise AI is now a governance and access problem because adoption is spreading faster than onboarding, classification, and approval processes.
• Shadow AI and embedded SaaS AI create unmanaged data paths that traditional policy documents do not control on their own.
• Security teams need continuous inventory, scoped access, and enforceable approved alternatives if they want AI usage to remain visible and governable.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide

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 Service Sprawl: AI service sprawl is the uncontrolled growth of AI tools, models, and embedded features across an organisation. It creates overlapping identities, duplicated subscriptions, and inconsistent access decisions that make governance and monitoring harder than the technology itself.
• AI Governance Debt: AI governance debt is the accumulation of unmanaged AI usage, delayed approvals, weak ownership, and inconsistent policy enforcement. Like technical debt, it compounds over time and reduces an organisation's ability to classify, approve, and constrain AI risk at runtime.
• Endpoint AI Agent: An endpoint AI agent is a locally executed AI system that operates on a workstation, terminal, or developer device rather than only inside a cloud service. Because it can interact with files, tokens, and code on the device, its permissions and trust boundary must be governed like any other privileged execution surface.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners build the identity and access foundations needed to govern AI systems, service accounts, and other non-human actors.