Shadow AI in SaaS is breaking point-in-time governance models

At a glance

What this is: This is an analysis of shadow AI inside SaaS applications, showing that embedded AI features can create unreviewed corporate data flows after an initial vendor review has already passed.

Why it matters: It matters because IAM, IGA, PAM, and third-party governance teams can no longer rely on point-in-time approvals when SaaS vendors can quietly change data access behaviour post-procurement.

By the numbers:

• In just 30 days, Obsidian Security observed 69,749 interactions between users and corporate data with SaaS embedded AI features.

Context

Shadow AI in SaaS is a governance problem, not just a discovery problem. When vendors embed AI features into already-approved applications, the original procurement review no longer describes how data is being processed, retained, or exposed.

That breaks the assumption behind point-in-time third-party risk management. Security teams may have approved the application once, but they did not necessarily approve the AI-enabled behaviour that appears later inside the same tool.

For identity and governance programmes, the core issue is whether access, processing, and disclosure boundaries can still be enforced after SaaS vendors change product behaviour without a fresh review.

Key questions

Q: What breaks when hidden AI appears inside approved SaaS applications?

A: Static app categories stop reflecting real risk once vendors embed GenAI or model connectivity into software that was already approved. The inventory still looks clean, but governance decisions, access reviews, and acceptable use policy are now based on stale assumptions about what the application can do.

Q: Why do embedded SaaS AI features create compliance risk even when the app was already reviewed?

A: Because the review usually covered the product at one moment in time, not the later AI capability that now processes data. If the feature can expose sensitive information outside the contractual or policy scope, the organisation can end up violating its own data processing terms without a new procurement event. The risk comes from post-review behaviour change.

Q: What are the signs that SaaS applications may be using AI under the hood without clear visibility from security teams?

A: A common sign is when a vendor’s terms or sub-processor disclosures list OpenAI or other AI services, while internal security, compliance, and legal teams lack the same visibility. Another sign is that the application handles user content in ways that were not captured in the original risk review, especially when AI features appear after initial deployment.

Q: How should teams respond when SaaS vendors add AI features after procurement approval?

A: They should treat the feature change as a new governance event, not as a minor product update. Reassess the data involved, the authorisation path, the logging available, and the contractual commitments already in place. The goal is to decide whether the new behaviour remains within policy before users start relying on it.

Technical breakdown

Why embedded AI inside SaaS changes the control plane

Embedded AI features change the control plane because the application itself becomes the path through which data is sent to an external model. Unlike a separately adopted AI tool, these features can be enabled inside existing SaaS workflows, often by end users and without a new security workflow. That makes the effective boundary shift from procurement-time approval to runtime behaviour. The security question is no longer whether the app is trusted, but whether the specific AI feature is authorised to see the data it can now process.

Practical implication: Treat SaaS AI features as separate data-processing paths, not as harmless extensions of the original application review.

Why point-in-time TPRM misses post-review feature drift

Point-in-time TPRM assumes the vendor relationship is stable after approval. Embedded AI breaks that assumption because vendors can add summarisation, search, content generation, or automation features long after the original assessment. If review cycles are tied only to procurement, the programme will miss feature drift, policy drift, and new data-sharing paths. In practice, the control gap is not the vendor record itself, but the absence of continuous verification that the vendor's live behaviour still matches the approved use case.

Practical implication: Reassess approved SaaS apps on a continuing basis when vendors ship features that change data handling.

Why browser-level visibility matters for AI feature detection

Browser-level monitoring is useful because it observes AI feature activation where the user actually interacts with the application. Logs, configuration inventories, and OAuth scans can show that a capability exists, but they often cannot prove whether an employee used the feature on sensitive data in real time. The browser captures the point of use, which is where authorisation, disclosure, and data entry happen. That makes it the most direct evidence source for whether embedded AI features are being exercised in ways that matter to governance.

Practical implication: Use point-of-use telemetry to confirm active AI feature use instead of inferring behaviour from static app inventories.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• 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

Point-in-time approval is no longer a valid governance boundary for SaaS AI. Once a SaaS application is approved, many programmes treat the risk as stable until the next review cycle. Embedded AI destroys that assumption because the vendor can alter how data is processed after approval, while the organisation continues to treat the app as unchanged. The implication is that governance must follow live feature behaviour, not procurement history.

Shadow AI inside SaaS is a third-party data processing problem with identity consequences. The issue is not only that data leaves the business, but that users can trigger that flow inside an already-authorised application. That creates an identity and authorisation gap between who may use the SaaS app and which AI-enabled data paths are actually permitted. Practitioners need to distinguish app access from feature-level data authority.

Continuous visibility is the new evidence layer for legal and compliance teams. If an organisation cannot show when AI features were used, on what data, and by whom, it cannot reliably attest that the behaviour stayed within policy or contract terms. That is an operational evidence problem as much as a security one. The governance model now depends on proving use, not just approving access.

Embedded AI creates policy drift faster than traditional vendor management cycles can absorb. The vendor can change product behaviour in days, while many SaaS reviews happen quarterly or annually. That mismatch is why a static approved-vendor list is becoming a weak control for AI-enabled SaaS estates. The field needs continuous monitoring, continuous policy enforcement, and clearer separation between application trust and feature trust.

From our research library:

• Only 37% of organisations had policies for managing AI or detecting shadow AI, according to IBM's 2025 Cost of a Data Breach Report.

What this signals

Feature trust is now separate from app trust: security programmes need to assume that an approved SaaS application can still become a new data path once AI is embedded inside it. That means governance has to track runtime behaviour, not just vendor status.

For practitioners, the practical shift is from periodic approval to continuous evidence. If your controls cannot show when embedded AI was used, on what data, and under which policy, you do not actually know whether the SaaS estate is compliant.

For practitioners

• Inventory AI-enabled SaaS features separately from application approvals Create a distinct register for SaaS features that can send data to external AI models, rather than relying on the original vendor approval record.
• Monitor AI feature use at the point of interaction Use browser-level telemetry or equivalent runtime observation to identify when users activate embedded AI features on sensitive corporate data.
• Map AI feature access to data processing obligations Align each permitted AI feature with the data processing agreement, internal policy, and contract restrictions that govern what it may see or generate.
• Trigger re-review when vendors ship feature changes Treat newly embedded AI functionality as a governance event that requires reassessment of data exposure, logging, and authorisation boundaries.

Key takeaways

• Embedded AI inside SaaS turns a previously approved application into a changing data-processing path that existing review cycles may never revisit.
• The governance failure is not only discovery, but the gap between feature drift and the evidence teams need to prove authorised use.
• Security and compliance teams need runtime visibility and feature-level reassessment if they want to govern shadow AI before it becomes a contract or data exposure problem.

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.
• Point-in-Time TPRM: A third-party risk management model that evaluates a vendor at a single approval moment and then assumes the risk posture stays stable. It works for static relationships, but it becomes weak when SaaS vendors can later add AI features that change data handling, retention, or disclosure without a new review.
• Embedded AI: Embedded AI is an AI feature built into an existing application rather than delivered as a separate tool. It matters because the app may already be approved, while the new model behavior changes what data is processed, retained, or sent to third parties.
• Point-of-Use Visibility: Observation of what users are actually doing at the moment they interact with an application or feature. For shadow AI, this matters because configuration inventories and vendor lists can prove a capability exists, but they cannot reliably prove whether the feature is being used on sensitive data right now.

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 building or maturing an IAM programme, it is worth exploring.