Hidden AI in SaaS is exposing governance blind spots

At a glance

What this is: This is a JumpCloud analysis of hidden AI inside SaaS, showing that embedded GenAI and MCP support can change application risk without changing the app category.

Why it matters: It matters because IAM, SaaS governance, and shadow AI programmes need discovery that tracks capability as well as application identity, or approved tools can quietly expand their access and data exposure surface.

By the numbers:

• 92% of SaaS vendors plan to increase their use of AI in the coming year.
• 60%+ of enterprise SaaS products already have embedded AI features.

Context

Hidden AI in SaaS is the problem of approved applications gaining new AI capabilities after they have already passed through governance and procurement. The app still looks like the same identity in the inventory, but its behaviour, data handling, and integration potential may no longer match the original approval decision.

For IAM and SaaS governance teams, that breaks a common assumption: category-based discovery tells you enough about application risk. Once AI features are embedded inside trusted SaaS tools, shadow AI can exist inside sanctioned software, which means discovery, policy, and access review processes need a capability-aware view rather than a static one.

MCP adds a second layer of concern because it describes apps that can connect AI models to data sources and actions. In practice, that shifts the question from whether an app is an AI tool to whether it is now an AI-enabled access path that should be governed like a higher-risk integration surface.

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 does embedded AI in SaaS create a governance gap?

A: Embedded AI creates a governance gap because authenticated access to an application does not reveal how that application will use the data it receives. A user may believe they are simply uploading content, while the platform may store it, train on it, or redistribute it. That turns data handling into an identity and policy problem.

Q: How should teams detect hidden AI in a SaaS estate?

A: Use discovery that combines business category with capability labels such as AI Powered and MCP Supported. That approach surfaces embedded AI inside trusted tools, which is where many shadow AI risks now live, instead of only flagging standalone AI applications.

Q: How should security teams secure MCP deployments in SaaS and developer environments?

A: Security teams should treat MCP as a new trust boundary, not just another integration layer. Protect both the agent-to-server and server-to-SaaS paths with short-lived authentication, per-user authorization, tool whitelisting, and inspection of tool responses before they reach the model context. Add audit logging, data classification, and redaction for sensitive content such as PII, PHI, secrets, and source code.

Technical breakdown

Why static SaaS categories miss hidden AI risk

Traditional SaaS discovery models classify applications by business category such as productivity, design, or collaboration. That works until vendors add embedded GenAI features, because the app’s label stays stable while its functional behaviour changes. A tool that was once a standard collaboration platform can start generating content, summarising meetings, or analysing data without appearing in an AI-only filter. This is a discovery problem, but it is also an identity problem because governance decisions are made against the app record. If the record does not capture capability, the control plane is already behind the software surface.

Practical implication: classify SaaS by both category and embedded capability so governance decisions reflect current function, not last year’s approval record.

What the AI Powered and MCP Supported labels change

A secondary metadata layer lets organisations keep the original business category while adding machine-readable attributes for embedded AI and MCP support. That matters because the same application can now be relevant to procurement, data governance, and emerging agent connectivity at the same time. The AI Powered label identifies where GenAI capability exists. The MCP Supported label identifies where model-to-tool or model-to-data integration may become possible. Together, they create a more precise inventory for policy enforcement, review, and escalation decisions without forcing category rebuilds across the entire SaaS estate.

Practical implication: use secondary labels to drive policy, filtering, and escalation without overwriting the business taxonomy used by the organisation.

Why MCP support is a governance signal, not just a feature flag

MCP, or Model Context Protocol, is relevant because it standardises how AI models connect to tools and data sources. When a SaaS application supports it, the app can become part of an AI-driven workflow chain rather than just a static business tool. That shifts the governance question from usage alone to potential exposure. Even if no one is actively using MCP today, the support status marks a future integration path that may require stronger API controls, approval rules, and data access boundaries. In identity terms, this is a capability that can widen who or what may act through the application.

Practical implication: treat MCP support as a pre-risk indicator and review API permissions before AI workflows become operational.

NHI Mgmt Group analysis

Hidden AI creates a governance blind spot because application identity no longer predicts application behaviour: approved SaaS can gain GenAI features after the original access decision has been made. That means the control owner is governing a stale description of the tool, not the tool as it exists today. The practical consequence is that discovery must become capability-aware, or policy will always lag vendor release cycles.

Capability labeling is the right abstraction for shadow AI inside sanctioned software: a simple AI-only app category is too crude for modern SaaS estates. Embedded AI now lives inside productivity, design, and communications tools, so the inventory needs to preserve business classification while layering in risk-relevant attributes. Practitioners should see this as a categorisation problem first and a user-behaviour problem second.

MCP Supported is a future-state control signal, not a product feature to ignore: if a SaaS app can connect AI models to data and actions, it belongs on a watch list even before agentic use is widespread. That is where the market is heading, and the governance model needs to anticipate model-to-tool pathways before they become routine. The implication is that access governance must begin with potential integration surface, not only observed usage.

Hidden AI turns acceptable use policy into a moving target: once embedded AI can appear inside approved tools, AUPs written around app names and categories lose precision. The named concept here is capability drift, where a sanctioned application accumulates risk without changing its label. Practitioners should align policy review with capability changes, not just procurement events.

This is also an IAM inventory problem, not only a shadow AI problem: the organization cannot govern what it cannot enumerate accurately. If the SaaS catalog does not surface embedded AI and MCP support, access reviews, data controls, and third-party risk workflows are all making decisions from incomplete context. The control question is no longer whether the app is approved, but what changed after approval and who is now accountable for that change.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Capability drift: SaaS governance is now about detecting when approved software acquires new behaviour after approval. The inventory has to track embedded AI, connector support, and other functional changes, or access decisions will be made against an outdated risk picture.

Shadow AI is no longer confined to unknown apps at the perimeter. In many environments, the more important question is whether sanctioned tools have quietly become AI-enabled enough to change data exposure, integration risk, or policy scope without a new procurement event.

For practitioners

• Classify SaaS by capability, not only category Add embedded AI and MCP support as secondary metadata fields in the SaaS catalog so approvals, reviews, and policy decisions reflect current function.
• Re-run discovery on approved applications Review existing productivity, collaboration, design, and support tools for newly introduced GenAI features, especially where vendors ship capability updates without category changes.
• Separate usage from capability in governance decisions Treat the presence of AI features as a governance trigger even when there is no evidence of active use, because capability still expands the policy surface.
• Review API and integration permissions on MCP-supported apps Prioritise applications that can connect AI models to data sources and actions, then validate whether existing authorisation scopes remain appropriate.
• Update acceptable use policy triggers Tie policy review to feature changes, vendor release notes, and newly detected labels rather than waiting for users to report AI usage.

Key takeaways

• Hidden AI inside approved SaaS tools breaks the assumption that app category is a reliable proxy for risk.
• Embedded GenAI and MCP support create governance blind spots because capability can change while the application identity stays the same.
• Discovery, policy, and access review processes need to track capability drift, not only software approval status.

Key terms

• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• 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.
• MCP Supported: MCP Supported means a system, tool, or platform can connect to and operate with the Model Context Protocol. In practice, it can expose or consume standardized tool and data interfaces so AI agents can request context, invoke actions, and receive structured responses under defined permissions, logging, and policy controls.
• Secondary Metadata Layer: A secondary metadata layer adds risk-relevant attributes to an existing application catalog without replacing the primary business category. It helps security teams preserve procurement and budget taxonomy while also classifying capability, integration potential, and other control-relevant traits.

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.