Shadow AI is a governance problem, not a ban problem

At a glance

What this is: Hoxhunt argues that Shadow AI is best treated as a governance and behaviour problem, not something organisations can solve through blanket prohibition.

Why it matters: For IAM, NHI and security teams, the important issue is not only tool approval but the permissions, accounts and data pathways employees create when they use AI outside sanctioned controls.

By the numbers:

• 45% of employees use AI regularly on work devices, approved or not, up from 15% a year earlier.
• 63% of UK workers had already used generative AI for work, and nearly a third of those users were doing so without their employer's knowledge.
• 67% of employees accessing AI services were using non-corporate accounts on their work devices.

Context

Shadow AI is the unapproved use of AI tools, accounts or features by employees, and it becomes a security problem when people connect those tools to company data, systems and permissions. The issue is not simply that an AI service exists outside policy, but that workers can now move from a prompt to delegated access in minutes.

The core governance gap is that organisations often regulate the tool while the workforce is optimising for the task. That gap is widening as employees use personal accounts, unsanctioned services and connected agents to get work done faster than approved channels allow.

In practice, Shadow AI sits at the intersection of security awareness, acceptable use, data handling and identity governance. That makes it typical of modern work, not an edge case, which is why bans alone rarely contain it.

Key questions

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

A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.

Q: Why does Shadow AI create more risk when employees and developers use enterprise data in external tools?

A: Shadow AI raises risk because external AI services can process sensitive inputs outside approved data protection, audit, and compliance controls. Once data leaves managed environments, teams lose visibility into retention, inference, and downstream use. The result is exposure of proprietary or regulated information, plus a weaker ability to prove how decisions and outputs were produced.

Q: What are the signs that shadow AI controls are failing in practice?

A: Shadow AI controls are failing when sensitive data moves through copy-paste, uploads, or API calls outside sanctioned workflows, yet the organisation has no alerting or enforcement at the point of transfer. Other warning signs include heavy personal account use, unclear approved-tool lists, and developers submitting source code or internal structures to external AI services without review.

Q: Should organisations prioritise monitoring or user enablement first for Shadow AI?

A: Do both, but start with the specific work people are trying to complete. Monitoring tells you where the risk sits. Enablement tells you why it exists. If you only watch, users route around you. If you only enable, you may miss the high-risk services and data flows that need hard limits.

Technical breakdown

Why banning AI tools does not remove the underlying behaviour

A ban changes the route, not the demand. When employees believe AI improves their productivity or job prospects, they look for alternate paths, including personal accounts, embedded third-party sites and home devices. The security control may block one app, but it does not remove the task pressure, the desire for speed or the perceived business value. That is why Shadow AI often shifts into less visible channels rather than disappearing. The technical lesson is that governance has to account for user behaviour, not just application inventory. Practical implication: treat bypass behaviour as a signal that the approved path is too slow, too weak or too hard to find. See the AI Acceptable Use Policy Template.

Practical implication: Treat bypass behaviour as a signal that the approved path is too slow, too weak or too hard to find.

Why delegated access expands Shadow AI risk beyond data leakage

The bigger risk is no longer only what an AI tool can read. Once a user connects email, cloud storage, CRM or other systems, the tool may act through the permissions the user already has. That turns an unsanctioned model or agent into a delegated actor with real authority, which is why OAuth grants, connected apps and broad workspace permissions matter as much as content-sharing decisions. If the tool is manipulated, compromised or prompted to act on malicious instructions, the blast radius follows the user’s own access scope. Practical implication: govern connected permissions as part of the AI control plane, not as a separate IT problem. See the Third-Party AI Risk Guide.

Practical implication: Govern connected permissions as part of the AI control plane, not as a separate IT problem.

How AI panic and reactance turn controls into workarounds

Shadow AI is accelerated by mixed messaging. Employees are told to adopt AI, stay current and be productive, but also to avoid the wrong tools and avoid risky data sharing. When the approved path feels slower than the workaround, reactance kicks in and people restore the freedom they think has been taken away. That is why control design matters as much as policy wording. If the restriction is obvious but the safe path is clumsy, users will find another route. Practical implication: build controls that preserve task completion while constraining data, identity and delegation risk.

Practical implication: Build controls that preserve task completion while constraining data, identity and delegation risk.

Threat narrative

Attacker objective: The attacker or misused tool aims to gain data, delegated access and actionable authority through an employee's trusted permissions.

1. Entry occurs when an employee uses an unapproved AI tool, free account or embedded service to complete work on a corporate device or through a personal route.
2. Credential harvesting is replaced by delegated access, because the employee may grant OAuth permissions or connect the tool to email, storage or business systems.
3. Escalation happens when the tool can read, send, update or execute through legitimate permissions the employee already holds, increasing the blast radius of compromise or misuse.
4. Impact is data exposure, unauthorised actions or hidden persistence of risky workflows outside sanctioned governance.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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

Shadow AI is fundamentally a delegation governance problem. The article makes clear that the risk is not just content leakage but the authority employees hand to AI tools through connected accounts, APIs and workspace permissions. That places Shadow AI squarely in the identity governance domain because the control boundary is no longer only the user, but the user plus everything they let the tool do. Teams should govern AI as delegated access, not as a novelty app category.

The named concept here is the AI delegation blast radius. Once a user connects an unsanctioned tool to email, calendar, storage or CRM, the security question becomes how far that tool can move under legitimate permissions. Third-party AI risk matters because unmanaged integrations can inherit trust without inheriting governance. Practitioners should evaluate connected AI with the same discipline they use for third-party access and high-risk OAuth grants.

Blanket bans usually shift risk into less visible channels. The article's examples show employees moving to embedded services, home devices and personal email when the sanctioned path is blocked. That means the control failure is often poor route design, not simply weak policy. Security leaders should expect workarounds and design for them, rather than assuming prohibition will remove demand.

Psychological safety is a security control in Shadow AI programmes. If people fear punishment for asking or disclosing a mistake, they keep risky AI use invisible. That weakens discovery, incident response and policy tuning. The better control is a reporting culture that surfaces unsafe behaviour early and lets security teams shape the safer path around actual work patterns.

For identity teams, Shadow AI is where acceptable use meets entitlement scope. The same employee who can access a sanctioned SaaS app may also be able to authorise an unmanaged AI service with the same identity. That makes policy, approval workflows and permission reviews inseparable from one another. Practitioners should treat AI adoption as a governed access decision, not only a training issue.

From our research library:

• One in five organisations reported a breach due to shadow AI, and 97% of those breached through an AI model or application lacked proper AI access controls, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

AI delegation blast radius: the real control problem is how far an unsanctioned AI service can act once it inherits a user's permissions. Security teams should focus on connected identity scope, because the risk grows with every workspace, mailbox or storage system an employee authorises.

Shadow AI programmes need to move from policy wording to permission design. If the safe route is slow, employees will keep creating side channels, and the organisation will keep discovering those routes after data and access have already spread.

The concern is no longer only leakage. 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec, which shows how the issue extends from user behaviour into data reuse risk.

For practitioners

• Map employee AI usage by account type Identify where staff are using personal, corporate and embedded AI services on work devices, then classify which routes are sanctioned, tolerated or prohibited.
• Review delegated permissions on connected AI tools Audit OAuth grants, email access, storage connectors and CRM integrations that let AI tools act inside other systems, then remove unused or excessive access.
• Shorten the path to approved AI use Make the sanctioned route faster than the workaround by reducing approval friction, publishing approved tool lists and giving clear guidance on data handling. See the AI Acceptable Use Policy Template.
• Build reporting that rewards early disclosure Create a no-blame path for employees to report unsafe AI use, accidental data sharing or suspicious tool behaviour before the issue spreads.

Key takeaways

• Shadow AI persists when employees can reach AI through easier routes than the ones security teams approve.
• The highest-risk behaviour is not just pasting data into AI, but attaching AI to accounts, storage and messaging systems with delegated authority.
• Security leaders should make the safe path faster, more visible and more usable than the workaround if they want to reduce shadow use.

Related NHI Mgmt Group resources: Shadow AI and AI Agent Discovery Guide · AI Acceptable Use Policy Template · Third-Party AI Risk Guide · Agentic AI Security Policy Template

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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Acceptable Use Policy: An acceptable use policy defines which data, tools, workflows, and actions are permitted for an identity or system. For AI governance, it becomes the boundary that turns vague intent into enforceable scope, which auditors and security teams can test against actual runtime behaviour.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security practitioners connect identity controls to the AI and access patterns now reshaping the enterprise.