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

At a glance

What this is: This article argues that shadow AI is now embedded inside existing SaaS applications, creating data access paths that traditional review cycles and configuration checks miss.

Why it matters: For IAM and NHI practitioners, the issue is less about adopting new AI tools and more about governing new data-processing behavior inside already-approved systems.

👉 Read Obsidian Security's analysis of shadow AI inside trusted SaaS applications

Context

Shadow AI in SaaS is a governance problem because the risk often appears inside applications that were already approved, trusted, and integrated into daily workflows. When vendors quietly add AI features, the data-processing scope changes even if procurement, legal, and security controls do not. That leaves IAM, NHI, and third-party risk teams trying to govern new behavior with old assumptions.

The practical issue is visibility. A browser-level view of user interactions can reveal when embedded AI features are actually invoked, which data is exposed, and which identities are participating. Without that evidence, organisations may only discover the exposure after a contractual, compliance, or privacy issue has already occurred. That pattern is increasingly typical for SaaS environments.

The article also points to a broader category shift: governance is moving from app approval to continuous authorization of AI-assisted behavior inside approved apps. For NHI practitioners, that means the control problem now includes the AI features themselves, not just the upstream SaaS identity or integration.

Key questions

Q: How should organisations govern embedded AI features inside SaaS apps?

A: Treat embedded AI as a runtime governance problem, not just a procurement issue. Require visibility into feature activation, tie each capability to data classification rules, and re-review the app when a vendor adds new AI processing. If the feature can change what leaves the application, it needs continuous control.

Q: Why do point-in-time reviews fail for shadow AI?

A: Point-in-time reviews assume the application’s behavior stays stable after approval, but SaaS vendors can add AI features later without reopening the original decision. That means the security team may still think the app is unchanged while new model processing is already happening. Continuous monitoring closes that gap.

Q: What is the difference between SaaS AI governance and NHI governance?

A: SaaS AI governance focuses on what the application and model are doing with data, while NHI governance focuses on the identities, tokens, automations, and service paths that make that processing possible. In practice, the two overlap because embedded AI extends identity-controlled access into non-human processing.

Q: When should security teams re-review a trusted SaaS application?

A: Re-review the application whenever a vendor introduces new AI features, changes retention or training behavior, expands third-party processing, or enables user-driven activation. Those changes can alter the effective data-processing scope even when the application name, contract, and owner remain the same.

Technical breakdown

Why embedded AI in SaaS escapes traditional TPRM

Traditional TPRM is built around a point-in-time decision: assess the application, document the approved data scope, and revisit later only when something changes materially. Embedded AI breaks that model because a vendor can introduce a new model, new inference path, or new data retention behavior after the initial review. The application stays the same in the inventory, but the processing logic changes underneath it. That makes the control gap structural, not procedural. If security teams only track the app name, they miss the event that matters: a new AI capability handling sensitive content inside a trusted workflow.

Practical implication: Practitioners should treat AI feature enablement as a change event that requires re-review, not as a cosmetic product update.

Why browser-level monitoring matters for shadow AI detection

Browser-level monitoring sits at the interaction point where a user enters data, enables an AI feature, and receives model output. That matters because SaaS logs and network telemetry often show the app, but not the exact feature invocation or user intent. In practice, the browser becomes the only reliable place to observe whether an embedded AI assistant is summarizing chats, drafting content, or transforming customer data into new artifacts. This is especially important for SaaS platforms that expose limited logs or weak admin controls. The point is not surveillance for its own sake. It is evidence collection for governance.

Practical implication: Use interaction telemetry to determine whether embedded AI is being used on regulated or confidential data before a compliance issue appears.

How embedded AI changes identity and access assumptions

Embedded AI does not always introduce a new standalone identity, but it does extend the effective access path of the user, the SaaS app, and any downstream model or processor the vendor uses. That creates a layered trust problem. The human identity may be authorized for the app, yet the resulting AI processing may move data to third parties or create derived content beyond the original authorization boundary. In NHI terms, the exposure is not only the account or token in play, but the full chain of non-human processing triggered by that identity. That is why access reviews alone are insufficient.

Practical implication: Map AI feature use to data classification and authorization boundaries, not just to user entitlements.

Threat narrative

Attacker objective: The objective is not necessarily theft in the classic sense, but unauthorized processing or exfiltration of sensitive enterprise data through trusted SaaS AI features.

1. Entry occurs when a user enables or invokes an embedded AI feature inside an already-approved SaaS application.
2. Escalation follows as the feature receives access to message history, knowledge base content, customer records, or other sensitive data already in the app.
3. Impact occurs when that data is processed outside the original review scope, creating unauthorized disclosure, contractual breach, or compliance exposure.

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 in SaaS is a governance problem before it is a tooling problem. The central failure is not that organisations lack another detection product. It is that their current approval model assumes software behavior is stable after procurement, which is no longer true for SaaS platforms adding AI features continuously. Security teams need to govern changing processing behavior, not just approved applications. The practical conclusion is that AI feature activation must be treated as a governance event.

Continuous visibility is the new evidence layer for AI-assisted SaaS use. Point-in-time reviews cannot prove whether a user actually activated an embedded AI feature on sensitive data last week or last month. That matters for legal defensibility, not just security response. Where organisations cannot show what happened in the browser, they are left attesting to controls they cannot verify. The practical conclusion is that evidence must be collected where the interaction occurs.

Identity controls must now extend to non-human processing triggered inside SaaS. Even when no separate AI agent identity is obvious, the data path can still cross into non-human processing through embedded model calls, assistants, and automations. This is an NHI governance issue because the effective access decision is no longer limited to the human user. The practical conclusion is that entitlement reviews, data policies, and AI-use approvals must be linked.

Runtime authorization is more relevant than procurement-time authorization for embedded AI. The market is moving toward continuous policy enforcement because SaaS vendors can change features faster than security teams can update static inventories. That does not eliminate TPRM, but it does limit what procurement-time review can prove. The practical conclusion is that organisations should shift from approved-app thinking to approved-behavior thinking.

Ephemeral trust debt: AI features inside trusted SaaS create short-lived but real authorization gaps between product change and security review. The gap lasts only until the organisation detects the new behavior, but that is long enough for sensitive data to move. This makes the exposure easy to overlook and hard to defend after the fact. The practical conclusion is to shorten the gap with continuous detection and policy checks.

From our research:

• 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, according to The State of Non-Human Identity Security.
• From our research: Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to Astrix Security & CSA.
• From our research: For the broader NHI governance playbook, see NHI Lifecycle Management Guide and align embedded AI monitoring to identity lifecycle controls.

What this signals

Shadow AI changes the control plane for SaaS from approval to continuous verification. That shift matters because the organisation can no longer assume that yesterday’s vendor review still describes today’s data processing. The programme implication is straightforward: build detection, evidence retention, and policy enforcement around feature activation, not just application inventory.

As a category, embedded AI is pushing NHI teams to think in terms of identity blast radius. When a user enables an AI feature inside SaaS, the effective access path can extend into external model processing, retained outputs, and downstream integrations. The practical response is to map the data path end to end and constrain the blast radius before the first approval expires.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, embedded AI is landing in a visibility gap that most programmes already struggle to close. Security teams should assume that SaaS AI usage will outpace manual reviews unless they instrument runtime detection and tie it to policy.

For practitioners

• Implement continuous detection for embedded AI use Monitor SaaS interaction points so security teams can see when AI features are activated, what data is being processed, and which users are involved. Use browser-level evidence rather than relying only on release notes or periodic vendor questionnaires.
• Reclassify AI feature activation as a change event Require a review when a trusted SaaS application introduces new AI functionality, even if the app itself is already approved. Tie that review to data classification, retention, third-party processing, and contractual restrictions.
• Map AI usage to data authorization boundaries Document which data categories may be used by embedded AI features, which users can enable them, and which downstream processors are involved. Align the policy with approved data processing agreements and internal handling rules.
• Add runtime evidence to compliance reporting Capture proof that AI interactions were authorized and governed, then retain it for audit and legal review. This is especially important where customer agreements restrict model training, retention, or external processing.

Key takeaways

• Embedded AI inside trusted SaaS creates a governance problem because the application can change after approval without reopening the original security review.
• Visibility at the point of interaction is the only reliable way to prove whether AI features processed sensitive enterprise data.
• Practitioners should shift from static app approval to continuous control over AI feature activation, data scope, and runtime evidence.

Key terms

• Shadow AI: Shadow AI is AI capability used inside an organisation without clear visibility, approval, or governance coverage. In SaaS environments it often appears as embedded features that users can activate inside trusted applications, creating data-processing risk outside the original review scope.
• 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.
• Runtime Authorization: Runtime authorization is the practice of deciding whether a user, system, or feature may act at the moment it is being used. For embedded AI, that means governing feature activation and data use continuously instead of relying only on procurement-time approval.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, or downstream processing that can be reached from a single identity or action. In shadow AI scenarios, one user click can expand exposure from a SaaS account into model processing, retention, and external sharing.

Deepen your knowledge

Shadow AI detection and runtime governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern AI features inside trusted SaaS applications, this is a relevant starting point.

This post draws on content published by Obsidian Security: Shadow AI isn't just new tools, it's hiding in the SaaS you already trust. Read the original.