Shadow AI in SaaS is exposing data and training risks

At a glance

What this is: This is an analysis of Shadow AI in SaaS and the exposure created when embedded AI capabilities can learn from, store, or share organisational data.

Why it matters: It matters to IAM and NHI practitioners because AI-enabled SaaS expands the governance surface beyond access control into data use, consent, and automated remediation.

By the numbers:

• 99.7% of organizations now utilize applications embedded with AI capabilities.
• 70% of widely used applications can leverage customer data to train their models.

👉 Read Wing Security's analysis of Shadow AI in SaaS and AI data risk

Context

Shadow AI creates a governance gap when AI capability sits inside normal SaaS workflows and users do not realise that their inputs may be retained, trained on, or redistributed. For IAM and NHI practitioners, the issue is not just who can sign in, but what an authenticated application is allowed to do with organisational data once it is inside the environment.

The article frames Shadow AI as both unsanctioned AI applications and ordinary SaaS tools with hidden AI functions, which makes the control problem broader than a classic app allowlist. That is a typical starting point for organisations that have focused on access provisioning and missed data-use governance, model exposure, and automated remediation.

Wing Security's own framing is that discovery must be paired with control over how AI learns and stores data. That reflects a wider shift in NHI governance toward continuous policy enforcement across software identity, data handling, and user consent.

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 embedded AI in SaaS create a governance gap?

A: Embedded AI creates a governance gap because authenticated access to an application does not reveal how that application will use the data it receives. A user may believe they are simply uploading content, while the platform may store it, train on it, or redistribute it. That turns data handling into an identity and policy problem.

Q: What is the difference between Shadow AI and ordinary SaaS risk?

A: Ordinary SaaS risk focuses on access, misconfiguration, and data exposure in a known application. Shadow AI adds a second layer: hidden or unclear AI behaviour that can learn from, retain, or reuse the data users provide. The difference is that the security issue extends beyond who can use the app to how the app behaves after access is granted.

Q: When should organisations restrict AI features in SaaS?

A: Organisations should restrict AI features when the tool handles sensitive data, the retention rules are unclear, or the vendor cannot explain how training occurs. If the business cannot prove that the data handling model matches policy, the safer choice is to disable the feature or route usage through a controlled exception process.

Technical breakdown

Shadow AI in SaaS: discovery problems and control gaps

Shadow AI appears when AI features exist inside SaaS tools without clear user awareness, central approval, or policy visibility. In practice, that means a normal login can activate an AI workflow that processes prompts, attachments, tickets, or documents outside the security team's intended scope. The technical challenge is not only finding the application. It is understanding whether the AI feature stores content, uses it for training, or forwards it to another service, often through vendor-managed infrastructure that the customer cannot inspect deeply. Practical implication: build SaaS discovery around AI-capable functions, not just app names.

Practical implication: classify SaaS applications by AI data-handling behaviour and tie each class to an explicit policy decision.

How AI training and retention expand NHI risk

When a SaaS platform can learn from customer input, every authenticated session becomes a potential data leakage path. The risk is amplified in NHI-heavy environments because service accounts, integrations, and automated workflows can generate large volumes of machine-originated content that may be ingested by AI systems. Unlike a one-time file upload, model training and retention create persistence, which means the exposure can outlast the original transaction. Practical implication: treat AI training permissions as a data governance control, not a user preference checkbox.

Practical implication: review whether service accounts, bots, and integrations can submit sensitive material to AI features by default.

Automated remediation for AI-enabled SaaS controls

Automated remediation matters because Shadow AI spreads faster than manual review cycles can keep up. SSPM-style workflows can identify AI-enabled apps, classify risk, and trigger actions such as restriction, approval, or user notification. The security value comes from shortening the gap between discovery and response, especially where users adopt tools faster than policy teams can update controls. Practical implication: map every detected AI-capable SaaS app to a predefined response so teams do not rely on ad hoc decisions.

Practical implication: predefine remediation playbooks for AI-capable SaaS apps before discovery starts producing alerts.

Threat narrative

Attacker objective: The objective is to obtain or indirectly persist access to sensitive organisational data through AI-enabled SaaS workflows.

1. Entry occurs when a user or integration authenticates to a SaaS application that silently includes AI features.
2. Escalation happens when prompts, uploads, or workflow data are retained or used for model learning beyond the organisation's intent.
3. Impact follows when sensitive data, intellectual property, or proprietary knowledge is exposed through training, retention, or unintended redistribution.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 now a governance problem, not a discovery problem. Finding AI-capable SaaS is only the first step because the real control question is what those tools are allowed to do with organisational data. Once AI features can train on user input or retain content beyond the session, access governance alone is insufficient. Practitioners should treat AI behaviour as part of the application's identity and policy profile.

Ephemeral user consent is a weak control for persistent data use. A single user action can create a durable downstream effect when SaaS AI features ingest content into model training, analytics, or retention pipelines. That changes the risk model for NHI-heavy environments, where service accounts and automation can amplify the amount of data submitted. Security teams should move consent and training permissions into centrally enforced policy.

Automated remediation is becoming a baseline requirement for SaaS AI governance. Manual review does not scale when AI capability is embedded across almost every common business application. The field is moving toward classification, policy decisioning, and workflow automation as standard operating controls. Practitioners should expect Shadow AI management to converge with SSPM, data governance, and NHI policy enforcement.

AI-capable SaaS expands the identity perimeter into data-use authority. Traditional IAM answers who can log in, but not whether an authenticated app can train on or store sensitive content. That creates an identity blast radius problem because the same access path can carry very different data consequences. Teams should extend governance models so software identity includes permitted data behaviour.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap points to a broader governance shift, explored in NHI Lifecycle Management Guide, where discovery must be paired with lifecycle control.

What this signals

Shadow AI governance will increasingly look like NHI governance with a data policy layer attached. As AI features become normal inside SaaS, teams need a control model that covers application identity, delegated access, and data-use permissions together. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the governance gap is already wider than most programmes assume, according to The State of Non-Human Identity Security.

Identity teams should expect AI feature approval to move into the same workflow as secrets, access reviews, and lifecycle controls. The operational signal is clear: if a SaaS tool can learn from customer data, then app approval is no longer just a procurement step. It becomes an access and data classification decision that should be documented, reviewed, and reversed when conditions change.

For practitioners

• Inventory AI-capable SaaS features Classify applications by whether AI features are visible, hidden, or user-enabled, and record how each feature handles prompts, uploads, and retention. Use the inventory to separate approved AI use from unmanaged Shadow AI before users spread it further.
• Set policy for training and retention Define whether organisational data, intellectual property, or customer content may be used for model training, stored for quality improvement, or shared across tenants. Where policy is unclear, restrict the feature and route exceptions through formal review.
• Automate response for risky apps Map each AI-capable SaaS finding to a predefined action such as restrict, approve, notify, or block, and connect that action to your SSPM or governance workflow. This shortens the time between discovery and containment.
• Tie app approvals to data classification Require teams to justify AI-enabled SaaS use against the sensitivity of the data it will process. High-value intellectual property, regulated data, and confidential operational content should trigger stricter approval and logging requirements.

Key takeaways

• Shadow AI in SaaS turns everyday application use into a data governance issue because AI features can retain or train on content after access is granted.
• The main evidence is broad adoption and weak visibility, which means security teams are dealing with scale before they have consistent controls.
• Practitioners should tie discovery to policy, automate response, and classify AI-capable SaaS by data behaviour rather than by brand name alone.

Key terms

• Shadow AI: Shadow AI is the use of AI applications or embedded AI features that are not fully sanctioned, visible, or governed by security teams. In SaaS environments, it includes both unsanctioned tools and ordinary applications whose AI behaviour is hidden from users, creating data-use and compliance risk.
• AI-capable SaaS: AI-capable SaaS is a software-as-a-service application that includes machine learning or generative AI functions capable of processing user data. These features may summarise, store, train on, or redistribute content, so they must be governed as data-handling controls as much as application features.
• SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.
• Data training exposure: Data training exposure is the risk that organisational content submitted to an AI system becomes part of model learning, retention, or downstream reuse. The concern is not only immediate disclosure but also persistence, because the information may influence future outputs or remain stored outside the original workflow.

Deepen your knowledge

Shadow AI governance and NHI lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-capable SaaS in a similar environment, it is worth exploring.

This post draws on content published by Wing Security: To AI or Not to AI? SSPM Is the Answer. Read the original.