AI governance gaps are widening as shadow AI enters enterprise stacks

At a glance

What this is: This analysis argues that AI governance must start with continuous discovery because shadow AI, embedded AI features, and third-party AI connections are widening the enterprise attack surface.

Why it matters: For IAM and NHI practitioners, the core issue is that autonomous and embedded AI behaviors can create unmanaged access paths that conventional oversight misses.

👉 Read Wing Security's analysis of AI governance, shadow AI, and SaaS risk

Context

AI governance is the discipline of controlling where AI is used, what data it can reach, and who is accountable when it changes. The security gap is that AI adoption now happens through employee tools, SaaS features, and third-party integrations faster than most governance programs can inventory them.

For IAM and NHI teams, that turns AI into an access problem as much as a data problem. The post frames a familiar failure mode for practitioners: once permissions, APIs, and data flows spread across unmanaged tools, the organisation loses the control layer needed for auditability and least privilege.

Key questions

Q: How should security teams govern shadow AI in enterprise environments?

A: Security teams should govern shadow AI by discovering every AI tool, mapping the data it can access, and assigning an owner for approval and revocation. The critical step is to connect discovery to enforcement, because visibility without policy control still leaves unmanaged data exposure and untracked access.

Q: What is the difference between shadow AI and embedded AI in SaaS?

A: Shadow AI is unsanctioned AI adoption by users or teams outside central control. Embedded AI is when a trusted SaaS platform adds AI functions that change how the application processes data or permissions. Both create governance risk, but embedded AI is harder to spot because it hides inside approved software.

Q: Why do AI tools create NHI governance risk?

A: AI tools create NHI governance risk because they often act with execution authority, data access, and delegated permissions that outlive a single user interaction. Once an AI service can read, write, or route enterprise data, it behaves like a non-human identity that needs ownership, scope limits, and lifecycle review.

Q: How can organisations reduce risk from AI tools without banning them?

A: Organisations can reduce risk by approving specific tools, limiting the data classes they may access, and enforcing scope restrictions for high-risk integrations. That approach supports productivity while keeping sensitive data out of unmanaged systems. The objective is controlled enablement, not unrestricted adoption.

Technical breakdown

Shadow AI and unmanaged access paths

Shadow AI refers to AI tools adopted without central approval, visibility, or policy enforcement. From an identity perspective, these tools often request OAuth scopes, API keys, or delegated access that is broader than the task requires. The security issue is not only unsanctioned software, but unmanaged non-human identity behavior: the application can read, write, export, or transform data outside normal governance workflows. Once users connect corporate data to an AI service, that service effectively becomes another privileged actor that may persist beyond the original user session.

Practical implication: Discover and inventory AI tools as identity-bearing actors, not just as software, before they accumulate standing access.

Embedded AI in SaaS and permission drift

Embedded AI features inside SaaS platforms create a quieter version of the same problem. A vendor can add model-driven summarization, search, or automation without security teams immediately seeing how the feature changes data handling, retention, or API scope. This creates permission drift, where the effective access profile of a known application changes after deployment. In practice, the risk is not the AI label itself. It is the hidden expansion of data processing boundaries, especially where the feature can train on customer content, call external endpoints, or chain into other services.

Practical implication: Treat new AI features in SaaS as change events that require re-review of scopes, retention, and downstream integrations.

Continuous discovery as a governance control

Continuous discovery is the control that keeps AI governance from becoming a point-in-time inventory exercise. Security teams need to identify sanctioned AI tools, hidden embeddings in SaaS, and unmanaged employee adoption as a single governance surface. That requires correlating application telemetry, consent grants, and data access patterns over time. The technical point is straightforward: without continuous discovery, policy cannot keep pace with the rate at which AI features appear, evolve, and expand their reach into corporate systems.

Practical implication: Build governance around ongoing discovery and monitoring, then enforce policy changes when AI tools or scopes change.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

AI governance is now an identity governance problem, not a sidecar to it. The article describes a control failure that begins when AI tools gain access to corporate data through normal user behavior and ends when those tools operate outside formal oversight. That is fundamentally an IAM and NHI issue because the risk sits in access grants, delegated permissions, and persistent data reach. Practitioners should treat AI tools as governed identities with scope limits and review cycles.

Shadow AI creates a governance gap that looks like shadow IT but behaves more like NHI sprawl. Unlike traditional unsanctioned software, AI tools can read content, generate outputs, and call APIs on the user's behalf. That means the control problem extends beyond asset discovery into authorization, logging, and revocation. The practical conclusion is that inventory alone is not enough unless it is tied to policy enforcement and lifecycle management.

Embedded AI changes the attack surface because the permission model can shift after deployment. A SaaS application that adds AI features may suddenly process more data, retain more content, or connect to more services than the security team originally approved. This is a classic trust expansion problem, and it demands change detection on the application, not just annual review on the contract. Practitioners should revalidate permissions whenever AI capabilities appear in a trusted platform.

AI governance requires continuous auditability, not periodic approval gates. The article is clear that manual oversight cannot keep up with the pace of adoption. That is the same lesson many NHI programs have already learned with service accounts and tokens: once access is distributed, control must become continuous. The practitioner takeaway is to operationalize visibility, revocation, and alerting as part of the access model itself.

Governance programs will need to separate acceptable experimentation from uncontrolled data exposure. Employees are adopting AI tools for productivity reasons, so blanket prohibition is rarely durable. The better answer is to define approved patterns, constrain data classes, and make high-risk integrations visible before they become normal. Teams that do this well will be able to enable AI without surrendering control over corporate data.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 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.
• The next step is to pair discovery with lifecycle controls, as outlined in Top 10 NHI Issues.

What this signals

Shadow AI will force security teams to treat application discovery and access review as a single programme. If an AI tool can appear through a browser extension, a SaaS feature, or a delegated integration, the control model must follow the access path rather than the app category. That is why visibility must be tied to revocation and review. The underlying problem is not experimentation, it is unmanaged trust expansion across identity boundaries.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the governance gap is structural. That figure, from The State of Non-Human Identity Security, shows why AI adoption will keep outpacing manual approval workflows. For practitioners, the implication is to build continuous consent monitoring and scope validation into the operating model now.

The strongest programmes will align AI governance with NIST AI Risk Management Framework governance principles and with identity controls already used for service accounts and tokens. That creates a clearer path for deciding which AI use cases are acceptable, which need tighter constraints, and which should be blocked until they are observable.

For practitioners

• Discover all AI-connected access paths Inventory standalone AI tools, embedded SaaS AI features, and employee-driven integrations in the same control plane. Map what data each tool can reach, which users approved it, and which OAuth grants or API keys keep it alive.
• Reclassify AI tools as identity-bearing actors Assign owners, scopes, review dates, and revocation criteria to every AI service that can touch enterprise data. Treat each integration like a non-human identity with lifecycle controls, not like a simple software feature.
• Enforce policy on data classes and scopes Block high-risk content from being routed into unapproved AI systems, and require explicit approval for broad API scopes or training retention. Tie policy enforcement to the moment a tool requests access, not after adoption spreads.
• Monitor for embedded feature changes Set alerts for SaaS permission drift, new AI capabilities, consent changes, and external endpoint use. Revalidate access whenever a vendor adds model-driven functionality that changes how the application handles data.

Key takeaways

• AI governance fails when tools can reach data faster than security teams can discover, classify, and revoke them.
• The main evidence point is not just adoption, but visibility collapse across AI-connected access paths and embedded SaaS features.
• Practitioners should manage AI as a lifecycle and authorization problem, not as an awareness campaign.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, features, or integrations without formal approval or visibility from security teams. In practice, it creates unmanaged access paths, data exposure, and accountability gaps because the organisation cannot reliably see what data is being shared or which permissions have been granted.
• Embedded AI: Embedded AI is model-driven functionality built into an otherwise trusted SaaS or business application. The governance risk comes from hidden changes to data handling, retention, training, or API reach after deployment, which can expand the effective access surface without a separate procurement event.
• AI governance: AI governance is the set of policies, controls, and monitoring practices that keep AI use aligned with business intent and security requirements. It combines discovery, risk assessment, enforcement, and auditability so AI tools do not create blind spots in identity, data, or compliance controls.
• Permission drift: Permission drift is the gradual mismatch between the access a tool was originally approved for and the access it actually has after updates, integrations, or feature changes. With AI-enabled SaaS, drift can happen quietly when new model features change what data is processed or where it is sent.

Deepen your knowledge

AI governance and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already facing shadow AI and embedded AI drift, it is worth exploring.

This post draws on content published by Wing Security: Bringing Order to AI Chaos, the case for AI governance by Lia Ciner. Read the original.