AI security threats in SaaS expose new NHI governance gaps

At a glance

What this is: This is an independent analysis of five AI security threats in SaaS, centered on shadow AI, data leakage, shifting terms, storage risk, and third-party exposure.

Why it matters: It matters to IAM and NHI practitioners because SaaS AI features create hidden machine access paths that traditional identity and data controls often do not see soon enough.

👉 Read Dana T's analysis of five AI security threats in SaaS

Context

AI inside SaaS changes the governance problem because access is no longer limited to named users. Hidden AI features, unsanctioned tools, and vendor-managed model behaviour create non-human identity risk that often sits outside normal review cycles. That makes visibility, entitlement control, and data policy enforcement part of the same problem set.

For IAM and NHI teams, the core question is whether the organisation can identify where AI is acting, what data it can reach, and which third parties can inherit that access. The article's starting position is typical: most security teams understand the risk categories, but struggle to operationalise control across SaaS estates.

Key questions

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

A: Treat embedded AI as a machine identity problem with data access implications. Inventory the feature, map the connected permissions, define what data it may use, and monitor retention and sharing paths. If the AI feature can read corporate content, it needs explicit approval, logging, and periodic review like any other privileged integration.

Q: What is the difference between shadow AI and approved SaaS AI usage?

A: Shadow AI is AI use that the organisation has not inventoried, sanctioned, or controlled, while approved SaaS AI usage has been reviewed, policy-bound, and assigned an accountable owner. The difference is not just preference. It is whether identity, data, and retention controls exist before the AI can touch corporate information.

Q: When does AI in SaaS create unacceptable data exposure risk?

A: Risk becomes unacceptable when the AI can ingest sensitive content, retain prompts or files beyond business need, or share data with third parties without clear policy. The tipping point is lack of control over reuse. Once data can be repurposed outside the original access context, governance has already lagged.

Q: How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?

A: Start with delegated access mapping, then remove unnecessary OAuth grants, service accounts, and vendor-side connections. Require documented data-use terms for AI features and revisit them whenever the provider changes conditions. Third-party risk falls when machine trust relationships are visible, limited, and periodically revalidated.

Technical breakdown

Shadow AI in SaaS: why discovery is the first control

Shadow AI appears when employees use unsanctioned AI apps or when SaaS platforms embed AI features that security teams do not inventory. The technical issue is not only app sprawl, but opaque execution paths where AI can read, transform, or transmit data without a clearly governed identity boundary. In NHI terms, the AI component behaves like a privileged workload whose access may not be represented in the IAM catalog. Without discovery, policy enforcement is always reactive, because the control plane cannot govern what it cannot see.

Practical implication: Practitioners should treat AI discovery as an identity inventory problem, not just an application inventory problem.

Data leakage through model training and retention

AI systems often improve by ingesting prompts, files, and interaction history, which can create durable exposure if sensitive material is used for training or retained in logs. The governance problem is that data copied into model pipelines may leave the original storage boundary and become harder to classify, delete, or trace. In practice, this resembles a data exfiltration path created by legitimate workflow usage. IAM and DSPM teams need shared visibility into which identities can submit data to AI services and which policies govern subsequent retention or reuse.

Practical implication: Security teams should classify AI-facing data flows as sensitive pathways and enforce explicit usage rules before broad adoption.

Third-party SaaS AI and delegated access risk

When SaaS vendors add AI features, they often rely on third-party services, integrations, or delegated permissions to function. That means the risk is not limited to the primary application, because OAuth grants, service accounts, and downstream APIs can extend trust to additional systems. This creates an NHI governance challenge: the organisation may approve one application but inherit several machine identities and data paths underneath it. Visibility into those delegated relationships is essential because the access footprint can grow without a corresponding change request.

Practical implication: Review SaaS AI integrations as delegated machine trust relationships, not as simple feature enablement.

Threat narrative

Attacker objective: The attacker or negligent workflow aims to obtain sensitive corporate data through ordinary AI-enabled SaaS usage.

1. Entry occurs when users adopt shadow AI tools or enable embedded SaaS AI features that have not been formally reviewed.
2. Escalation follows when those tools receive access to proprietary documents, prompts, or connected SaaS data through delegated permissions.
3. Impact occurs when sensitive business data or intellectual property is exposed through model training, retention, or third-party sharing.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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 really an identity discovery failure. The core problem is not that employees use AI, but that organisations cannot reliably enumerate every AI-enabled workflow acting on corporate data. Once an AI feature can access files, chats, or connected services, it behaves like a non-human identity that deserves the same governance discipline as any service account. Practitioners should treat discovery as the first security control, not an optional inventory exercise.

Data leakage in SaaS AI is a lifecycle problem, not a single control problem. Training, retention, logging, and downstream sharing create multiple moments where sensitive data can escape the original policy boundary. Encryption alone does not solve that issue because the risk sits in how data is reused after access is granted. Organisations need lifecycle controls that define what AI may ingest, retain, and propagate, then enforce those rules consistently.

Third-party AI access creates identity blast radius. Every delegated SaaS integration expands the number of machine identities that can touch regulated or proprietary data. The practical risk is that a single approved workflow can fan out into a wider chain of OAuth grants, service accounts, and vendor-side processing. That means governance must move from application approval to relationship mapping across the AI supply chain.

AI governance in SaaS is converging with NHI governance. The same controls that matter for service accounts, secrets, and privileged automation also apply to embedded AI capabilities. That convergence will force IAM, security, and data teams to share a control model instead of running separate inventories. Practitioners should build one policy layer for all machine access paths, because separate programs will miss the overlap.

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.
• That visibility gap is not abstract. 38% have no or low visibility, and a further 47% have only partial visibility, which leaves machine trust relationships outside normal control.
• For a broader breach lens, see The 52 NHI breaches Report, which shows how uncontrolled identity paths become operational exposure.

What this signals

Shadow AI will force SaaS governance to become identity-aware. Once AI features can access business data, the control model must track machine identities, delegated permissions, and retention rules together. Teams that still separate application governance from identity governance will keep missing the path where exposure actually occurs.

The next practical shift is toward policy that follows the data, not just the application. That means conditioning AI use on approved data classes, auditable retention, and revocation paths that security teams can verify during reviews.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is already acknowledging that AI and NHI governance are converging.

For practitioners

• Implement AI discovery in SaaS inventories Map embedded AI features, unsanctioned AI apps, and connected integrations across the SaaS stack so security teams can see every machine access path before policy decisions are made.
• Classify AI data flows by sensitivity Define which data types may be submitted to AI services, which must be blocked, and which require approval, then enforce those rules in SaaS, DSPM, and IAM workflows.
• Review delegated permissions for AI integrations Inspect OAuth grants, service accounts, and vendor-side connections tied to AI features, then remove standing access that is not required for the business case.
• Add retention and reuse clauses to AI policy Specify whether prompts, files, and chat history can be retained or used for model training, and align those rules with legal, privacy, and records management requirements.
• Monitor third-party AI changes continuously Reassess SaaS vendor terms, integration scope, and downstream sharing whenever a provider updates AI functionality or data handling conditions.

Key takeaways

• AI features inside SaaS create hidden machine access paths that traditional inventories often miss.
• The main security failure is not adoption volume, but the inability to govern data reuse, delegated access, and retention together.
• IAM, data security, and SaaS governance now need a shared model for non-human identity risk.

Key terms

• Shadow AI: Shadow AI is the use of AI tools or embedded AI features that security teams have not formally approved or inventoried. In SaaS environments, it often appears as an overlooked capability inside a trusted application, which makes discovery and policy enforcement the primary governance challenge.
• Non-Human Identity: A non-human identity is any digital credential or account used by software, workloads, bots, or AI agents rather than a person. These identities can authenticate, access data, and perform actions, so they need lifecycle, privilege, and monitoring controls just like human users do.
• Delegated Access: Delegated access is permission granted to one application or service so it can act on behalf of another system or user. In AI-enabled SaaS, delegated access can extend trust to third-party services and increase the blast radius if the permissions are too broad or poorly monitored.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and downstream services exposed when a single identity is compromised or over-permissioned. For AI in SaaS, it helps teams assess how far one approved integration can spread risk across connected applications and vendor workflows.

Deepen your knowledge

AI security threats in SaaS are a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern shadow AI and delegated machine access together, it is worth exploring.

This post draws on content published by Dana T covering five AI security threats in SaaS. Read the original.