Shadow AI is outpacing SaaS controls in enterprise environments

At a glance

What this is: This is an analysis of how unsanctioned and embedded AI features inside SaaS tools create a new class of governance and data exposure risk.

Why it matters: It matters because IAM and NHI teams must account for AI-enabled access paths, hidden integrations, and data egress that traditional SaaS controls do not fully govern.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Valence Security's analysis of Shadow AI in SaaS environments

Context

Shadow AI is the use of generative AI tools without security team visibility or governance, and it now extends beyond standalone apps into sanctioned SaaS platforms with embedded copilots. For IAM and NHI practitioners, the problem is not only who can sign in, but what autonomous or semi-autonomous features can do once inside approved workflows.

That creates a governance gap because identity controls were built around users, service accounts, and static integrations, not prompt-driven data movement and hidden AI features. The practical question for security teams is whether existing access reviews, data classification, and SaaS posture controls can actually see and constrain AI-enabled activity.

Valence Security frames the issue as a successor to Shadow IT, and that comparison is useful only if teams remember the scale has changed. Shadow AI can move sensitive content into external model systems, personal accounts, or opaque integrations while remaining invisible to conventional SaaS monitoring.

Key questions

Q: How should security teams govern shadow AI in SaaS environments?

A: Security teams should inventory AI-enabled features, classify the data those features can touch, and enforce approved-use rules at the application and identity layers. The practical goal is not to block every model interaction. It is to ensure that prompts, file uploads, and connected data sources stay within defined risk boundaries.

Q: What is the difference between shadow IT and shadow AI?

A: Shadow IT is the use of unapproved software, while shadow AI is the use of unapproved or unmanaged generative AI services and embedded copilots. Shadow AI is harder to govern because it often hides inside sanctioned SaaS tools and can move data into external model systems without obvious signs.

Q: Why do AI copilots complicate identity governance?

A: AI copilots complicate identity governance because they inherit user context, connect to data sources, and can act on information the business did not intend to expose. That means the access decision is no longer limited to the user or app login. It now includes the model layer and its downstream integrations.

Q: Should organisations block AI tools or enable them safely?

A: Organisations should enable AI safely rather than rely on blanket blocking. Bans often push employees toward personal accounts and unmonitored tools, which reduces visibility and increases risk. A safer model combines approved AI paths, data classification, monitoring, and clear enforcement for prohibited content.

Technical breakdown

Why shadow AI creates hidden identity and data paths

Shadow AI becomes risky when employees use GenAI services that sit outside approved identity governance or when sanctioned SaaS products expose AI features that were enabled without meaningful review. The technical issue is not just authentication. It is that prompts, uploaded files, connected drives, and delegated app permissions can create new data paths that bypass normal access assumptions. In practice, an AI feature can act like an unreviewed downstream processor with broad read permissions and unclear retention behavior. That means the security team may understand the SaaS tenant but not the AI layer running inside it.

Practical implication: Treat AI-enabled workflows as separate access pathways that need explicit discovery and policy control.

Why SaaS posture management is not enough for ai copilots

SaaS Security Posture Management was designed to find misconfigurations, risky app connections, and overbroad permissions in business software. AI copilots complicate that model because they often operate inside approved applications, inherit user context, and blend human prompts with connected data sources. The result is a monitoring blind spot: the SaaS app looks sanctioned, but the AI behavior inside it may not be. This is especially relevant when features such as document summarization, code assistance, or inbox drafting can move sensitive content into systems outside the enterprise boundary.

Practical implication: Extend SaaS controls to inspect AI-enabled features, not just the parent application.

How shadow AI changes non-human identity governance

AI assistants and embedded copilots can behave like non-human identities because they execute with delegated authority, connect to tools, and process enterprise data at machine speed. That makes them governance subjects, not just features. Traditional NHI controls such as secrets rotation, service-account review, and least privilege still matter, but they are incomplete if the organization does not also govern prompts, model access, and downstream integrations. The control problem shifts from single credential management to lifecycle oversight for AI-enabled access chains.

Practical implication: Add AI actors and AI-enabled integrations to the same lifecycle, review, and offboarding discipline used for other NHIs.

Threat narrative

Attacker objective: The attacker objective is to capture sensitive enterprise data through AI-mediated workflows that bypass normal visibility and control.

1. Entry occurs when employees use unsanctioned AI tools or activate embedded copilots inside approved SaaS applications without security oversight.
2. Escalation follows when those tools are granted access to documents, chats, code, or connected cloud storage that contain sensitive enterprise data.
3. Impact is the leakage or retention of regulated, proprietary, or operational data outside the enterprise boundary, where it may be harder to recover or audit.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent 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

Shadow AI is not a policy exception. It is a control-plane failure. Once employees can move sensitive data into model systems, the organization no longer governs the full path of access and retention. That is especially true when AI is embedded inside already-approved SaaS platforms, because the surface area expands without a matching change in review. The right response is to treat AI usage as an identity and data-flow problem, not a training problem.

AI copilots introduce a new kind of ephemeral trust debt. Security teams often assume approved SaaS access is bounded by the original application contract, but AI features can inherit broader context and create longer-lived downstream exposure than the user intended. That means the trust decision is made once, while the data risk persists across prompts, exports, and connected services. Practitioners should assume inherited access is broader than the business owner expects.

Visibility is the prerequisite control, not the end goal. A security team cannot govern AI usage it cannot inventory, classify, or constrain. The field should stop treating AI discovery as a nice-to-have telemetry project and start treating it as the baseline for policy enforcement, access review, and incident scoping. The practitioner conclusion is simple: if the AI layer is invisible, the governance model is already behind.

Shadow AI validates the convergence of SaaS security and NHI governance. The same organizations that struggle to inventory service accounts, tokens, and external integrations are now facing AI features that act with delegated authority and opaque downstream behavior. This does not replace existing NHI controls, but it does expose their limits. Teams should expand NHI governance to include AI-assisted access paths and approval workflows.

The market will increasingly reward control over discovery, classification, and enforcement rather than blanket restriction. Employees adopt AI because it speeds work, and bans tend to push that activity into personal accounts and unmonitored tools. The category is moving toward governance that preserves productivity while reducing data exposure. Practitioners should plan for controlled enablement, not prohibition.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Our research also shows that only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For teams dealing with hidden AI features and unmanaged access paths, the next step is to study the NHI Lifecycle Management Guide for discovery, rotation, and offboarding practices.

What this signals

Shadow AI will keep widening the gap between what security teams approve and what employees actually use. The practical programme response is to move from occasional policy updates to continuous discovery across SaaS tenants, browser-based tools, and embedded AI features. That shift matters because governance without inventory is paperwork, not control.

The next control question is whether identity teams can trace which prompts, files, and delegated permissions created a given data flow. With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, the broader access problem is already established; AI simply adds another path for it to spread.

Identity blast radius: the useful unit of measurement is no longer the account alone, but the set of systems, data classes, and external services reachable from that identity. Teams that define blast radius clearly can prioritize controls around the highest-risk AI-enabled workflows instead of trying to govern every use case equally.

For practitioners

• Inventory all AI-enabled SaaS features Build a current list of copilots, assistant modes, and embedded model features in sanctioned SaaS platforms, then map which users can activate them and what data sources they can reach. Tie that inventory to application owners and security review cycles.
• Classify data that must never enter prompts Define prompt-safe and prompt-prohibited data categories for source code, customer records, contracts, HR data, and financial material. Enforce the policy with user guidance, access controls, and logging where the platform supports it.
• Expand NHI governance to AI-assisted access chains Review whether connected apps, service accounts, API keys, and delegated permissions expose AI features to more data than intended. Apply the NHI Lifecycle Management Guide to those connections so discovery, rotation, and offboarding are not limited to traditional machine identities.
• Monitor for personal-account workarounds Detect when employees bypass enterprise controls by using personal AI accounts or unsanctioned browser-based tools. Pair usage monitoring with approved alternatives so users have a governed path that does not depend on shadow workarounds.
• Red-team AI data exposure scenarios Test what happens when employees paste regulated or proprietary content into ChatGPT-style tools, then trace where the data could persist, replicate, or be retrained. Use the findings to set incident response playbooks and executive reporting criteria.

Key takeaways

• Shadow AI turns approved SaaS platforms into hidden data pathways when embedded copilots and unsanctioned tools are left outside governance.
• The risk is structural because AI can inherit access, move sensitive content, and persist outside the control assumptions of traditional SaaS security.
• Security teams should respond with discovery, data classification, and NHI-aware lifecycle controls rather than blanket bans.

Key terms

• Shadow AI: Shadow AI is the use of generative AI tools or embedded AI features without security team visibility, approval, or control. It includes both standalone tools and copilot-style functions inside sanctioned SaaS applications. The risk is data exposure, policy bypass, and unmanaged access paths.
• AI-enabled SaaS feature: An AI-enabled SaaS feature is a built-in model capability inside an approved application, such as summarisation, drafting, or analysis. These features can inherit user context and connected data sources, which means they may create new exposure even when the parent application is sanctioned.
• Identity blast radius: Identity blast radius is the total set of systems, data, and services reachable through a given identity or delegated access path. In AI contexts, it includes prompts, connected apps, and downstream model interactions. The concept helps teams prioritise which access chains need the strictest controls.

Deepen your knowledge

Shadow AI, SaaS posture, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for AI-enabled access paths, it is worth exploring.

This post draws on content published by Valence Security: AI Security: Shadow AI is the New Shadow IT (and It’s Already in Your Enterprise). Read the original.