Hidden AI in SaaS is exposing governance blind spots

At a glance

What this is: This is an analysis of how embedded AI inside approved SaaS tools creates hidden AI risk and why category-based discovery misses it.

Why it matters: It matters because IAM, NHI, and human governance teams need visibility into changing app capability, not just approved app names, to manage policy, access, and data exposure.

By the numbers:

• 92% of SaaS vendors plan to increase their use of AI in the coming year.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read JumpCloud's analysis of hidden AI labels and Shadow AI discovery

Context

Hidden AI is what happens when approved software gains embedded generative features after procurement, while the security team still sees the original category. That gap matters because identity governance depends on knowing what a tool can do, not only what it was originally bought to do. In practice, shadow AI can appear inside productivity, collaboration, design, and support platforms long before it is obvious in a dashboard.

For IAM and NHI programmes, this is a classification problem as much as a discovery problem. If the governance model assumes software capability is static, then policy, data handling, and access reviews will lag the actual behaviour of the stack. The result is a blind spot where trusted SaaS becomes an unreviewed AI surface without any formal change in ownership.

JumpCloud's labels are one response to that mismatch, but the underlying issue is broader than one platform. Organisations need a way to track capability drift across the application estate, because embedded AI changes the risk profile of approved tools even when user experience and procurement records stay the same.

Key questions

Q: How should security teams govern hidden AI inside approved SaaS apps?

A: They should treat embedded AI as a capability change that can alter data handling, user experience, and exposure without changing the app's category. The practical control is to compare the approved inventory against current feature-level metadata, then route any newly AI-enabled app into policy review, data classification, and access governance before it spreads.

Q: Why do static SaaS categories fail for AI governance?

A: Static categories fail because they describe the product family, not the current behaviour of the application. A collaboration or design tool can gain AI summarisation, transcription, or generation features after approval, which creates new risk even though the category stays the same. Governance needs to track capability drift, not only procurement labels.

Q: What breaks when MCP-supported applications are not tracked separately?

A: The organisation loses sight of which tools can connect AI models to data sources and action endpoints. That matters because MCP support turns an ordinary SaaS application into a possible bridge for machine-to-machine access. Without separate tracking, integration permissions and downstream scopes are reviewed too late, if at all.

Q: How do organisations decide which hidden AI features need the most scrutiny?

A: Prioritise tools that already handle sensitive content, have broad user reach, or expose integration paths through APIs and connectors. Those are the places where embedded AI can change the largest amount of data and decision flow with the least visibility. Start with the tools most likely to affect policy, access, or confidentiality.

Technical breakdown

Embedded GenAI inside approved SaaS

Embedded GenAI is AI functionality added to an existing application without changing the application's primary category. That matters because discovery tools often rely on static tags such as productivity, design, or collaboration, which miss capability changes introduced after approval. The security issue is not the label itself, but the fact that the same trusted application can now generate, summarise, transcribe, or transform data in ways that alter exposure and acceptable-use assumptions. In identity terms, the app is still the same subject, but its operational behaviour has expanded.

Practical implication: track capability drift separately from application category so policy reviews reflect current behaviour, not procurement history.

Model Context Protocol and agent-ready applications

Model Context Protocol, or MCP, is a standard for connecting AI models and agents to external tools and data sources. When an application supports MCP, it is no longer just AI-assisted software. It becomes part of a potential tool-access path for an AI agent that can read data or trigger actions through connected systems. That shifts the control problem from simple app approval to integration governance, because a seemingly ordinary SaaS tool may become a machine-action surface once MCP connectivity is enabled. For NHI teams, that is a new class of indirect access risk.

Practical implication: inventory MCP-supported applications and review their API permissions, scopes, and downstream connectors before agent workflows expand.

Shadow AI dashboards and secondary metadata

A shadow AI dashboard only works if it uses a secondary metadata layer that can sit alongside primary application categories. This avoids breaking budget and ownership models while still surfacing AI capability and protocol support. The technical value is precision: administrators can filter for AI-powered tools, MCP-supported tools, or both, without rebuilding the SaaS catalog from scratch. That kind of metadata layering is increasingly necessary because software estates now evolve through feature insertion rather than product replacement.

Practical implication: use label-based discovery views to separate business category from AI capability, then route the results into policy and review workflows.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Category-based discovery is no longer sufficient for AI governance. The article shows that AI capability is being embedded into approved SaaS rather than appearing only as standalone tools. That means a clean software inventory can still hide real AI exposure if the programme only tracks original product categories. The implication is that governance has to move from static inventory to capability-aware classification.

Hidden AI creates capability drift inside trusted identity relationships. The identity of the application does not change, but the data-processing and action-taking potential does. That is a different governance problem from shadow app discovery, because the risk emerges after approval and inside already-accepted access paths. Practitioners need to treat newly embedded AI as a change in operational behaviour, not as a new app purchase.

Agent-readiness is a distinct governance layer, not just another AI label. The article's MCP Supported tag points to applications that can connect models to tools and data sources. That is the point where AI adoption starts to intersect with NHI control planes, because tool connectivity is what makes future delegation and automation possible. Security teams should read this as a signal that integration permissions are becoming identity controls.

Hidden AI is a named capability-drift problem, not simply a visibility problem. Static dashboards fail because they report what was once approved instead of what the software can do today. That breaks acceptable-use reasoning, data classification, and access review assumptions at the same time. The practitioner conclusion is straightforward: governance must follow capability changes as closely as it follows user access.

NIST CSF and application governance should be aligned to change detection, not just inventory reporting. The relevant lesson is that discovery is only useful if it feeds continuous identification of new functions, integrations, and exposure paths. AI features added through product updates should trigger the same scrutiny as a new application category. Teams should make capability drift visible in the control plane, not just in a report.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• That same survey found that only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• For a broader control lens, see NIST Cybersecurity Framework 2.0 for how identification and protection functions should adapt as software capability changes.

What this signals

Hidden AI changes the governance unit from application to capability. Teams that only watch for new app names will miss the more common pattern, which is an existing SaaS product absorbing AI features after it is already trusted. With 70% of organisations granting AI systems more access than a human employee would receive for the same job, per the 2026 Infrastructure Identity Survey, the problem is already structural rather than hypothetical.

Capability-aware discovery should become part of the identity control plane. The right operating model is to treat AI feature activation as a governance trigger for review, not just as a discovery update. That means procurement, SaaS management, and IAM teams need shared telemetry for embedded AI, connector changes, and data-path expansion.

Agent-ready tools deserve a separate watch list. Applications that support MCP or similar integration patterns should be monitored as future machine-action surfaces, even if no autonomous workflow exists yet. That is where hidden AI stops being a visibility problem and starts becoming an access-path problem.

For practitioners

• Add capability-drift review to SaaS governance Track when approved applications gain embedded AI features after procurement. Reconcile app category, feature flags, and release notes so policy decisions reflect the current behaviour of the tool, not the original vendor listing.
• Separate AI capability from application category Use a secondary metadata layer for AI-powered and MCP-supported apps so security and procurement teams can filter by function without losing ownership or budget context. Treat category and capability as different control dimensions.
• Inventory MCP-supported tools for downstream access paths Review which SaaS platforms can connect to models, data sources, and APIs, then map those connections to the entitlements already granted to the app. Focus on where a future agent could inherit access through existing integrations.
• Push label results into AUP and access review workflows When a tool is flagged as AI powered, route it into acceptable-use review, data handling checks, and access recertification. A capability change should create a governance event, not just a dashboard entry.

Key takeaways

• Hidden AI is a capability-drift problem because trusted SaaS can gain AI functions after approval without changing its category.
• Static discovery misses the operational risk if governance only tracks app names instead of current feature-level behaviour and integrations.
• Security teams should separate AI capability, MCP readiness, and business category so policy decisions reflect the real exposure surface.

Key terms

• Hidden AI: Embedded AI functionality inside an approved application that changes what the software can do without changing its original category. The governance risk is that the tool looks familiar in inventory while its data handling, output generation, or automation potential has quietly expanded.
• Capability Drift: The change in an application's functional behaviour after it has already been approved and placed in use. In identity governance, capability drift matters because policy, access, and acceptable-use decisions often rely on stale assumptions about what the application can do today.
• MCP Supported: A label for applications that can connect AI models or agents to tools, data sources, or actions through the Model Context Protocol. For security teams, this is a warning sign that the application may become part of an AI-to-system access path even if no agent is active yet.

Deepen your knowledge

AI capability drift and MCP-supported application governance are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already dealing with hidden AI inside approved SaaS, this is a practical place to build the control model.

This post draws on content published by JumpCloud: hidden AI labels for shadow AI discovery and MCP readiness. Read the original.