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.
Why Shadow AI in SaaS Becomes a Governance Problem
shadow ai in SaaS is not just an unsanctioned app problem. It is a data-governance and identity problem because users can turn ordinary SaaS features into hidden model inputs, retention stores, and sharing paths. Security teams need to classify which AI-capable services are allowed, what data they may process, and whether prompts or files can be reused for training. Current guidance suggests pairing discovery with policy enforcement, since discovery alone does not stop sensitive data from flowing into a vendor-controlled model.
The risk is amplified when SaaS tools are connected through OAuth apps and API tokens, because those connections can outlive the original business need and create invisible data access. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes it hard to see where Shadow AI is already embedded. That visibility gap is why governance must include inventory, approval, and ongoing review, not one-time allowlisting. See The State of Non-Human Identity Security and the NIST Cybersecurity Framework 2.0 for the control and accountability model.
In practice, many security teams encounter Shadow AI only after sensitive content has already been entered into a SaaS assistant, rather than through intentional governance.
How Security Teams Should Govern It Operationally
The practical model is to treat each AI-capable SaaS application as a controllable data-processing boundary. Start by classifying the tool, the tenant, and the connected identity path: human user, service account, OAuth app, or agent. Then define what content is permitted, whether the tool may use customer data for training, how long prompts and outputs are retained, and whether the service may share data with subprocessors.
Security teams should back that policy with central enforcement. That means integrating SaaS controls with CASB, SSO, DLP, and approval workflows so users cannot silently enable AI features that bypass review. Where a vendor offers tenant-level controls, disable training by default, restrict external sharing, and require admin approval for new integrations. Where the control surface is weak, the safer answer is to block the feature or route users to an approved alternative. This approach aligns with the governance and lifecycle themes in Top 10 NHI Issues and the lifecycle framing in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- Inventory AI-capable SaaS features by tenant, business owner, and data class.
- Set default-deny rules for training, retention, and external sharing.
- Review OAuth apps and service tokens as NHI assets, not just “integrations.”
- Use conditional access and DLP to stop sensitive prompts from leaving approved boundaries.
- Require exceptions to expire, with periodic recertification and removal.
For policy structure, NIST Cybersecurity Framework 2.0 gives a practical way to map governance, protect, and monitor actions across the SaaS stack. These controls tend to break down when teams rely on manual app approvals in large SaaS estates because hidden AI features, delegated tokens, and user-led configuration changes move faster than review cycles.
Where the Standard Answer Breaks Down
Tighter control often increases friction, so organisations have to balance user productivity against data exposure and vendor lock-in. That tradeoff becomes most visible in marketing, sales, support, and engineering environments where users expect instant AI assistance and SaaS vendors keep adding new AI features without a separate procurement event.
There is no universal standard for every SaaS AI feature yet, so guidance is still evolving on how much control should sit at the identity layer versus the application layer. In practice, the safest approach is to treat any feature that can summarise, draft, search, or auto-complete from enterprise content as a governed AI surface, even when the vendor does not brand it as “AI.” NHIMG’s Snowflake breach and Salesloft OAuth token breach show how quickly exposed or overextended tokens can turn routine access into broad data access, which is exactly the pattern Shadow AI governance is meant to prevent.
The strongest programmes also distinguish between low-risk copilots and higher-risk tools that retain prompts, learn from customer data, or chain into other systems. That distinction matters because the same SaaS app may be acceptable for public content but not for regulated, confidential, or customer-identifiable material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shadow AI often relies on long-lived SaaS tokens and integrations. |
| NIST CSF 2.0 | PR.AC-4 | Governance depends on controlling who can use AI features and data paths. |
| NIST AI RMF | Shadow AI creates unmanaged AI risk across people, process, and technology. |
Inventory SaaS identities, rotate exposed tokens, and remove standing access to AI-enabled apps.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
