AI governance gaps are exposing shadow AI and embedded app risk

At a glance

What this is: This is an analysis of why AI governance must cover discovery, context, data protection, policy enforcement, and continuous monitoring for shadow AI and embedded AI apps.

Why it matters: It matters to IAM and NHI practitioners because AI tools and agents often introduce new identities, permissions, and data-sharing paths outside existing approval and review models.

👉 Read Wing Security's analysis of AI governance pillars for shadow AI

Context

AI governance is the control problem that appears when employees, embedded features, and autonomous tools can reach data and systems faster than review processes can classify them. For IAM and NHI teams, the issue is not only who signed in, but what the application, service account, or AI agent can now do once it is connected. That makes discovery and control-plane visibility part of identity governance, not a separate AI project.

The article argues that modern AI usage bypasses traditional software intake because apps can be installed quickly and may already contain generative features. That is a familiar pattern in shadow IT, but the AI version is harder to manage because the tool can also move data, call other systems, and shift behaviour after approval. For practitioners, the starting position described here is increasingly typical, which means governance has to assume hidden AI usage first and prove it safe second.

Key questions

Q: How should security teams govern shadow AI without slowing adoption?

A: Start with continuous discovery, then classify tools by data access, system connectivity, and provider trust. Use policy thresholds that allow low-risk use cases quickly while forcing review, restriction, or blocking for tools that can reach sensitive systems. The control objective is to make safe adoption fast and unsafe adoption expensive.

Q: What is the difference between AI discovery and AI governance?

A: AI discovery answers what exists in the environment, while AI governance decides what should be allowed, restricted, or blocked. Discovery is an inventory control. Governance adds context, policy, enforcement, and monitoring so the organisation can manage AI risk after the first finding is made.

Q: Why do AI tools create NHI risk for IAM teams?

A: AI tools often act through service accounts, tokens, delegated access, or embedded identities that are not visible in traditional user-centric reviews. That expands the NHI footprint and creates new paths for over-privilege, data exposure, and unmanaged access. IAM teams need to govern the identities behind the tool, not just the user who clicked enable.

Q: When should organisations block an AI app instead of approving it?

A: Block an AI app when its access scope, data handling, or downstream integrations exceed the organisation's risk tolerance and cannot be constrained with policy. If the app touches sensitive systems, lacks credible security posture, or can widen access dynamically, approval should wait until controls can be enforced at runtime.

Technical breakdown

AI discovery and shadow AI visibility

AI discovery is the process of continuously identifying applications, embedded AI features, and autonomous tools across the environment. In practice, this is closer to asset and identity discovery than to a one-time software inventory because AI can appear inside approved apps, browser extensions, or third-party services with delegated access. The main failure mode is blind trust in procurement records, which miss unsanctioned adoption and hidden connections. When discovery is incomplete, every later control rests on an incomplete map of access and data flow.

Practical implication: Security teams should treat AI discovery as a continuous control, not a quarterly review, and tie it to identity and SaaS inventory workflows.

Contextual risk assessment for AI-connected apps

Contextual risk assessment asks not just whether an app uses AI, but what it can reach, what data it handles, and how trustworthy the provider is. That context usually includes vendor reputation, breach history, compliance posture, and downstream system connections. This matters because an AI grammar helper and an AI tool linked to CRM or file storage create very different blast radii. Without context, policy decisions become blunt allow or block choices that either miss real risk or slow safe adoption.

Practical implication: Classify AI tools by data sensitivity and system connectivity before granting access or approving use cases.

Policy enforcement and continuous oversight

Policy enforcement in AI governance means applying rules in real time when tools request access, data, or scope changes. Continuous oversight is the monitoring layer that detects unusual behaviour after approval, such as broader permissions, sensitive file transfers, or unexpected system interactions. The architecture matters because static approvals do not match AI behaviour, which can change after deployment or compromise. This is where identity, token control, and data policy need to converge.

Practical implication: Use real-time controls that can block, revoke, or re-authenticate when AI tools change scope or behaviour.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 is an identity governance problem before it is an application problem. When AI features can be added in a few clicks, the real risk is that access appears faster than governance can record it. That means organisations are not simply missing apps, they are missing the identities, tokens, and data paths those apps create. Practitioners should treat undocumented AI usage as unmanaged identity infrastructure, not as a separate policy exception.

Context is the control that turns discovery into decision-making. Discovery alone tells you something exists, but not whether it should touch business systems or sensitive records. A useful AI governance program has to enrich findings with vendor trust signals, system connectivity, and data classification so teams can decide whether to allow, restrict, or block. Security teams should judge AI risk by blast radius, not by novelty.

Continuous monitoring must replace one-time approval for AI-enabled tools. AI applications and agents can request broader scopes, change behaviour, or become compromised after they are approved. That makes static sign-off a weak control unless it is paired with runtime enforcement and alerting. The governance lesson is simple: if the tool can act dynamically, the control model must be dynamic too.

Data protection is now an access control issue, not just a content policy issue. When users feed sensitive information into AI tools, that data can be exposed through retention, downstream processing, or breach scenarios. The policy boundary therefore has to sit at the point where identity meets data, including who is allowed to share what, through which tools, and under what conditions. Practitioners should align data governance with identity governance instead of running them as separate programs.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which suggests recurrence is a governance failure rather than a one-off event.
• For a broader pattern view, compare this with The 52 NHI breaches Report to see how identity sprawl and access paths turn into repeatable breach conditions.

What this signals

Identity blast radius: AI governance programmes should now measure how far an AI app or agent can extend access after approval, not just whether it was approved. With 72% of organisations already experiencing or suspecting an NHI breach, the underlying problem is structural rather than exceptional, and it belongs in access governance, not a separate AI exception queue.

The practical signal for security leaders is that static policy libraries will age quickly if they are not paired with runtime enforcement and identity review. Teams should connect AI discovery to their SaaS, token, and service-account inventories, then use NIST Cybersecurity Framework 2.0 to anchor governance, protection, and response activities around the same control plane.

Organisations that can map AI tools to specific identities and data classes will be better positioned to spot scope creep, policy bypass, and unmanaged integrations before they become incidents. That is the operational line between AI adoption and AI sprawl, and it should drive next-quarter governance planning rather than next-year strategy.

For practitioners

• Implement continuous AI discovery Continuously scan approved SaaS, shadow IT, and browser-installed tools for embedded or generative AI features, then feed findings into your inventory and access review process.
• Classify AI tools by blast radius Score each AI tool by vendor trust, breach history, compliance posture, connected systems, and data sensitivity before deciding whether to allow, restrict, or block it.
• Enforce runtime policy controls Apply policy at the moment an AI tool requests broader access, sensitive data sharing, or new integrations, and make revocation or re-authentication an automated response.
• Bind AI governance to identity workflows Map each AI app or agent to the user, service account, or delegated token behind it so access reviews cover both human and non-human identities.

Key takeaways

• AI governance fails when discovery, context, and enforcement are treated as separate tasks instead of one control model.
• Shadow AI and embedded AI features expand the NHI surface because they introduce hidden identities, tokens, and data paths.
• Practitioners should move to continuous monitoring and runtime policy enforcement because AI behaviour can change after approval.

Key terms

• Shadow AI: Shadow AI is AI software, embedded model features, or autonomous tooling that operates without formal visibility or approval. In identity terms, it creates unmanaged access paths that may use tokens, delegated permissions, or service accounts the security team never reviewed.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and permissions exposed when an identity is compromised or over-extended. For AI tools and agents, the concept matters because a single token or delegated account can reach far beyond the original use case.

Deepen your knowledge

AI discovery, contextual risk assessment, and runtime policy enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern shadow AI with identity-first controls, it is worth exploring.

This post draws on content published by Wing Security: AI without governance is a breach waiting to happen. Read the original.