By NHI Mgmt Group Editorial TeamBased on Wing Security: “5 AI Security Threats in SaaS” (February 12, 2026)

TL;DR: AI features embedded in SaaS create five security risks, including shadow AI, data leakage through model training, changing terms and conditions, insecure storage, and third-party sharing, all of which expand the attack surface around sensitive data and machine access, according to Wing Security research. The governance gap is visibility, policy control, and lifecycle oversight, not AI adoption itself.


At a glance

What this is: This is an analysis of five AI security threats in SaaS, centred on shadow AI, data leakage, provider terms changes, insecure storage, and third-party sharing.

Why it matters: It matters because SaaS AI features can create unmanaged access paths and data exposure risks that cross NHI, autonomous, and human identity governance boundaries.


Context

AI in SaaS now blends application features, data access, and external integrations into one governance problem. When those capabilities are not inventoried or controlled, security teams lose sight of where sensitive data can move, who can authorise its use, and which identities are actually operating the controls.

The issue is not simply that AI exists inside SaaS. The issue is that AI behaviour can change the trust boundary around customer data, vendor permissions, and third-party sharing faster than standard SaaS review cycles can keep up, which makes identity governance part of the problem rather than a separate layer.


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: Why do SaaS and AI tools create more sensitive data risk than databases?

A: Because modern work happens in motion. Users share, paste, copy and forward data across many services, and GenAI adds new places where regulated information can leave the environment instantly. The risk grows when identity, access and collaboration rules are looser than the data’s sensitivity.

Q: What are the signs that SaaS and AI governance is breaking down in a customer environment?

A: Common warning signs include fragmented oversight across teams, unclear stakeholder ownership, difficulty tracking access after role changes, and rising spend without a matching business case. If customers cannot quickly answer who uses each tool, who approved it, and who pays for it, governance is already lagging. Visibility gaps usually show up before formal control failures do.

Q: How do teams govern third-party AI sharing in SaaS?

A: Treat every downstream recipient as part of the access chain. Security and procurement should validate who receives customer content, why they receive it, how long they keep it, and whether the sharing arrangement is still aligned with policy and contract terms.


Technical breakdown

Shadow AI discovery in SaaS stacks

Shadow AI covers both unknown standalone AI apps and AI features already embedded in SaaS platforms. The operational problem is inventory, because a security team cannot govern what it cannot see. In practice, discovery has to extend beyond sanctioned tools to included AI functions, connected apps, and any workflow that can send data into model-backed services. SSPM is relevant here because the control gap is not configuration alone, it is hidden capability exposure across the SaaS estate.

Practical implication: build discovery processes that identify embedded AI features, not just separate AI tools.

Model training and retained data risk

When SaaS AI systems use customer content for training or improvement, sensitive business data can be incorporated into model behaviour or retained in ways users do not expect. The risk is not limited to a one-time leak. It also includes repeated exposure through ongoing interactions, broad retention, and unclear boundaries on what data can be used for training. That makes data classification and policy enforcement part of the control plane for AI-enabled SaaS.

Practical implication: classify which data may reach AI training paths and audit those paths continuously.

Third-party sharing and SaaS supply chain trust

AI capabilities in SaaS often rely on subcontractors, APIs, or downstream vendors, which creates a layered trust chain. Each additional party introduces another place where sensitive data can be handled, retained, or exposed under different security practices. That is why third-party sharing in AI-enabled SaaS is not only a vendor risk, but an identity governance problem for delegated access, approval scope, and ongoing oversight of who can touch the data.

Practical implication: review third-party sharing paths as delegated access relationships, not just procurement relationships.


Threat narrative

Attacker objective: The objective is to obtain sensitive business data or intellectual property by exploiting AI-enabled SaaS trust paths.

  1. Entry occurs when employees adopt shadow AI tools or activate hidden AI capabilities inside SaaS applications without security review.
  2. Credentialed or authorised access is then used to submit sensitive content, allowing the AI service or its connected providers to receive data the organisation did not intend to expose.
  3. Escalation happens when training, storage, provider updates, or subcontractor access expands the original data boundary beyond the first interaction.
  4. Impact is the exposure of sensitive business data and intellectual property through uncontrolled AI-enabled SaaS workflows.
  • 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 in SaaS is a visibility failure before it is an AI failure. The article is describing hidden AI apps and embedded AI features that security teams do not see until data has already moved. That is an identity governance problem because control cannot exist without inventory, ownership, and policy scope. Practitioners should treat discovery as the first governance boundary for AI-enabled SaaS.

Data leakage through model training exposes a governance assumption that SaaS content stays outside the model. That assumption breaks once user prompts, documents, or business records are absorbed into training or retained in service memory. The implication is that data classification, approved-use policy, and auditability have to sit in front of model access, not after the fact.

Third-party AI sharing creates delegated access that outlives a simple vendor check. When a SaaS provider forwards data to subcontractors or downstream AI services, the real issue becomes who can process customer content and under what lifecycle rules. This is a governance chain, not a single-vendor decision. Practitioners should map the full delegation path before they accept the access model as controlled.

AI in SaaS is turning machine access into a cross-domain governance issue. The same environment now touches human consent, machine behaviour, and vendor delegation in one workflow. That means IAM, NHI governance, and SaaS security posture management can no longer be separated by programme boundaries. The practical conclusion is that teams need one policy model for data use, access scope, and third-party handling across the stack.

Controlled AI adoption is becoming less about blocking tools and more about controlling trust expansion. The article points to a category where AI features can change terms, retention, and sharing without a major technical migration. That shifts practitioner attention from user enablement to lifecycle governance of access, data use, and provider change. The lesson is to manage AI as an access and data governance layer, not a feature toggle.

From our research library:

What this signals

Shadow AI discovery is now a control boundary, not a nice-to-have visibility project. SaaS teams that cannot inventory embedded AI features will miss the point at which policy should apply, and they will learn about risk only after content has already flowed into an unmanaged service. The governance implication is that discovery must precede approval, not follow it.

AI data use must be governed as a lifecycle problem. Once prompts, documents, or application content can be reused for training or retention, the security issue becomes whether policy can still distinguish approved processing from uncontrolled model learning. That means the question is not just who can access the SaaS app, but what happens to the data after access is granted.

43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec. That concern maps directly to SaaS AI features that absorb business content into model behaviour, which is why data classification and model-use policy need to be aligned before users start sharing sensitive material.


For practitioners

  • Map embedded AI features across SaaS applications Inventory AI functions inside approved SaaS platforms as well as standalone AI tools, then assign business and security ownership to each capability.
  • Define approved data-use boundaries for AI training Classify which records, prompts, documents, and attachments may be sent to AI services, and block categories that cannot be used for model improvement or retention.
  • Review third-party AI sharing paths as delegated access Trace which vendors, subcontractors, and connected services can receive customer content, and validate that each handoff has an explicit approval and retention rule.
  • Audit provider terms and retention changes continuously Track SaaS terms updates, storage behaviour, and AI data-retention changes so policy teams can respond before consent and exposure drift beyond acceptable scope.

Key takeaways

  • Shadow AI inside SaaS is a governance problem because security teams cannot enforce policy against AI capabilities they have not discovered.
  • The main risk is not AI adoption itself, but uncontrolled data movement into training, retention, and third-party sharing paths.
  • Practitioners should treat embedded AI features, provider terms, and delegated sharing as one access and data lifecycle to govern.

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, MITRE ATT&CK and CSA MAESTRO define the specific risk controls and attack patterns relevant to this term.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-10 — Human Use of NHIUnsanctioned AI use in SaaS creates hidden access paths outside governance.
NHI-03 — Vulnerable Third-Party NHIThird-party AI sharing extends trust beyond the direct SaaS provider.
NHI-02 — Secret LeakageAI systems can reproduce or expose sensitive content learned from SaaS inputs.
Recommendation — Inventory embedded AI use and block unsanctioned access paths before they handle sensitive data. Map downstream AI vendors and require lifecycle controls for every delegated access path. Classify sensitive content and prevent it from entering AI training or retention paths.
MITRE ATT&CKTA0006; TA0010 — Credential Access; ExfiltrationThe article's threat pattern centres on unauthorized data exposure and movement.
Recommendation — Correlate unauthorized AI use with data exfiltration indicators in your detection pipeline.
CSA MAESTROAgentic AI Threat ModelingThe topic concerns AI-driven trust expansion and delegated data handling.
Recommendation — Model AI-enabled SaaS data paths for delegated access, storage, and downstream sharing.

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.
  • Software As A Service Security Posture Management: Software as a Service Security Posture Management is the continuous assessment and control of security settings, access, and data exposure across SaaS applications. It focuses on misconfigurations, excessive permissions, risky integrations, and weak governance. The discipline maps SaaS controls to policy, detects drift, and supports remediation before exposure becomes an incident.
  • Model Training Exposure: Model training exposure is the risk that business content sent to an AI system becomes part of the model's learned behaviour, retained content, or future responses. For SaaS, the governance question is whether the organisation can control which data is allowed into that path.
  • Delegated AI Sharing: Delegated AI sharing is the transfer of customer or business data from one SaaS service to another vendor, subcontractor, or AI service as part of a processing chain. It extends the access model beyond the primary provider and requires lifecycle oversight, not just procurement review.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on May 26, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org