Shadow AI discovery needs identity-aware controls, not just policy

At a glance

What this is: LEVO says Shadow AI discovery has to cover unsanctioned AI use across SaaS, browsers, APIs, and MCP gateways, with identity and token sprawl treated as part of the discovery problem.

Why it matters: This matters because AI exposure often comes through hidden connectors, over-privileged grants, and long-lived credentials, which creates an IAM and NHI governance issue as much as a policy problem.

Context

Shadow AI is an access and governance problem, not just an approval problem. Once AI features are embedded in SaaS, browser tools, workflow automations, and emerging MCP integrations, the organisation can lose track of who or what is moving data, which permissions were granted, and whether those permissions still match the data being processed. The identity question is central because unsanctioned AI usually enters through accounts, tokens, and delegated access rather than through a standalone application build.

Traditional policy controls fail when usage is hidden inside approved tools or appears as ordinary user activity. A useful discovery programme therefore has to join application visibility, identity inventory, and data-flow review so security teams can separate benign enablement from uncontrolled access paths. That is typical of current AI adoption: teams move faster than governance, so discovery has to be continuous rather than a one-time audit.

Key questions

Q: How should security teams govern Shadow AI in SaaS applications?

A: Security teams should govern Shadow AI by classifying AI-capable SaaS tools, deciding what data each tool may process, and enforcing those decisions centrally. Discovery is necessary but not sufficient. The control layer must cover model training, retention, sharing, and exceptions so users cannot create hidden data-use risk through ordinary application activity.

Q: Why does shadow AI create risk even when there is no obvious external traffic?

A: Because many AI tools now run locally, inside IDE extensions, containers, or MCP-connected workflows that do not depend on a visible outbound session. Those tools can still access data, invoke APIs, or expose credentials from the endpoint. If governance depends only on network destinations, local models and embedded agents remain effectively invisible.

Q: What are the signs that an AI project has become shadow AI?

A: The main signs are orphaned agents, unmanaged MCP connections, and AI logic appearing in branches or services without a clear owner or approved governance path. If security cannot map the component back to a repository, a team, and a permission scope, the project is already outside normal control boundaries.

Q: When should organisations block an AI app instead of approving it?

A: Block an AI app when its access scope, data handling, or downstream integrations exceed the organisation's risk tolerance and cannot be constrained with policy. If the app touches sensitive systems, lacks credible security posture, or can widen access dynamically, approval should wait until controls can be enforced at runtime.

Technical breakdown

How shadow AI hides inside sanctioned platforms

Shadow AI does not always look like a new app. It often appears as a feature toggle inside a SaaS product, a browser-based assistant, or an integration that quietly inherits the parent platform’s access. That makes discovery difficult because the risky behaviour is masked by a trusted control plane. In practice, the security issue is not only usage but delegated reach: once a connector can read tickets, docs, CRM records, or code repositories, the AI path becomes part of the organisation’s data-access model. The same is true for MCP-style integrations, which can expose tool and data access through a standardised interface.

Practical implication: inventory AI features wherever they live and tie each one back to the data sources and permissions it can touch.

Why identity and token sprawl are the real discovery signal

Shadow AI becomes materially riskier when it is driven by OAuth grants, API keys, service accounts, or long-lived tokens. Those credentials can outlast the user session, bypass normal review paths, and persist even after the underlying AI use case changes. From an NHI governance perspective, the important question is not just whether AI is allowed, but whether its delegated identity can be scoped, expired, and revoked cleanly. Over-privileged tokens create hidden reach across systems, especially when they are shared between users, apps, or automations. That is why AI discovery and NHI discovery are converging topics.

Practical implication: treat AI-linked tokens and grants as first-class NHIs and review them for scope, ownership, and expiry.

What the two-lane response model changes operationally

The two-lane model separates low-risk enablement from high-risk containment. Enablement means approved tools, restricted data classes, and minimal scopes. Containment means unapproved tools touching sensitive data, broad SaaS grants, or agents able to mutate state without approvals. This is more than a policy split. It is a governance design that recognises different levels of business tolerance and different identity controls for each lane. In effect, security teams need a decision structure that can move approved use cases forward without allowing uncontrolled access paths to become normalised.

Practical implication: create separate approval and containment workflows so teams can act on risky AI use without blocking low-risk productivity.

Threat narrative

Attacker objective: The objective is to gain access to valuable business data or operational workflows through unmanaged AI-connected identities and integrations.

1. Entry begins when employees use public AI tools, SaaS AI features, or MCP-connected workflows that were never formally reviewed.
2. Credential access and delegation follow when the AI service inherits OAuth grants, API keys, or long-lived tokens with broad system reach.
3. Impact occurs when sensitive data is copied, summarised, or mutated through unapproved AI paths that security teams did not know existed.

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.
• Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.

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 discovery is now an identity governance problem, not a policy enforcement problem. Policies describe acceptable use, but they do not reveal which accounts, tokens, and delegated grants are actually moving data. Once AI is embedded in SaaS and browser workflows, the real control point shifts to identity inventory and access scope. Practitioners should treat discovery as a live governance process, not a static policy register.

Identity-aware discovery is the only way to separate safe enablement from hidden reach. The article’s useful contribution is that it moves beyond tool listing and into the question of who or what can act on behalf of the organisation. That matters because AI features often inherit permissions from the parent account, which makes the access path more important than the interface itself. Security teams should align AI discovery with NHI governance and delegated access review.

MCP expands the discovery perimeter because it standardises tool access for AI systems. A standard is not a control, but it does make integration easier to deploy before governance catches up. That creates a new class of discoverable assets, especially where an MCP server can connect an AI application to internal systems. Practitioners should assume the control gap will be in inventory and authorisation, not in the protocol alone.

Shadow AI should be managed as AI governance debt. Every unreviewed connector, token, and agent workflow adds future remediation cost because it creates hidden dependencies across identity, data, and application teams. The better model is continuous discovery plus fast classification, so organisations can keep low-risk adoption moving while containing high-risk paths. Practitioners should design for lifecycle governance, not one-off cleanup.

Two-lane response is the right operational pattern for this category. If security teams try to force every AI use case through the same approval channel, they will either slow adoption or lose control through bypass behaviour. A differentiated model creates room for sanctioned experimentation while giving security a defined containment path for unapproved access. Practitioners should build those lanes into AI security governance now.

From our research library:

• 76% of organisations cite shadow AI as a definite or probable problem, up from 61% in 2025, according to HiddenLayer's 2026 AI Threat Landscape Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Shadow AI governance debt: every unreviewed connector, token, and SaaS feature toggle increases the amount of hidden access security teams will eventually need to classify, contain, or revoke. That burden grows because AI use often arrives through ordinary accounts and delegated permissions, not through a visible new system, so the right control is continuous discovery paired with identity review.

The most practical response is to align AI discovery with NHI lifecycle management. If an AI workflow can act, read, or write through a token or grant, it has entered the same governance domain as other non-human access paths and should be inventoried, scoped, and retired the same way.

For practitioners

• Define approved and restricted AI use cases Publish an allowlist of approved AI services, models, and connectors, then classify restricted data types that can never flow into unapproved tools.
• Inventory AI features inside SaaS platforms Review tenant settings, admin toggles, and user-level enablement so hidden AI features do not inherit sensitive data access by default.
• Map AI-linked tokens and grants Find OAuth grants, API keys, and service accounts tied to AI apps or AI features, then remove shared or long-lived credentials.
• Discover agentic workflows and tool access Search for automation frameworks, agent runners, and MCP servers, then document what tools they can call and what data sources they can reach.
• Create separate enablement and containment paths Route approved low-risk use cases to a fast-track review while sending broad-grant, write-capable, or unsanctioned AI use into containment.

Key takeaways

• Shadow AI becomes a governance problem when AI features inherit access through SaaS, browsers, APIs, and MCP-connected workflows.
• Identity and token sprawl are the control gap because delegated credentials can outlast the use case and keep hidden access alive.
• A two-lane model lets teams allow low-risk AI use while containing broad-grant and write-capable workflows that need review.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.

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 gives security and identity teams a common foundation for governing delegated access across modern AI and application ecosystems.