Shadow AI bypasses traditional gateways through NHI sprawl

At a glance

What this is: Shadow AI is bypassing traditional gateways because embedded AI features and agentic tools inherit non-human identity access inside trusted cloud and SaaS paths.

Why it matters: IAM, NHI, and human identity programmes now need identity-first visibility because the risk sits in permissions, tokens, and delegated access rather than in standalone apps.

By the numbers:

• 80%+ of employees use unapproved AI tools

👉 Read Orca Security's analysis of shadow AI detection in cloud environments

Context

Shadow AI is the use of AI features, assistants, or agents outside approved governance, often inside tools teams already trust. The identity problem is that these capabilities do not always appear as separate applications, so traditional gateway-based controls miss the access path entirely.

In practice, the exposure sits across non-human identities, OAuth apps, API keys, service accounts, and embedded AI features in SaaS and CI/CD systems. That makes shadow AI an IAM and NHI governance problem as much as a cloud security problem, because the permissions already exist before the AI use case is noticed.

Key questions

Q: How should security teams detect shadow AI hidden inside trusted cloud and SaaS tools?

A: Start with identity, not network traffic. Map OAuth apps, service accounts, API keys, IDE extensions, and pipeline steps that can invoke AI services, then trace what data each one can reach and what it can change. That approach reveals hidden AI use inside approved platforms, where CASB and DLP often have weak visibility.

Q: Why do non-human identities make shadow AI harder to control?

A: Non-human identities let AI tools inherit standing permissions that were issued for another purpose. Once a token or service account can reach sensitive data, the AI can process that data without passing through human session controls, making ownership, scope, and revocation the real control points.

Q: What breaks when AI features are embedded inside approved SaaS and CI/CD systems?

A: Traditional gateway controls lose their edge because the traffic looks like normal application use. The risk shifts into configuration files, feature toggles, extension settings, and build steps, where hidden AI functions can move data to external services without a distinct application boundary.

Q: Who is accountable when shadow AI uses corporate credentials to process sensitive data?

A: Accountability sits with the identity owners, the platform owners, and the governance function that approved the underlying access. If a service account or OAuth app can reach regulated data and an AI feature uses that path, the organisation is responsible for the resulting exposure and audit trail.

Technical breakdown

Non-human identities and inherited AI permissions

Shadow AI becomes difficult to detect when an AI assistant, MCP server, or embedded SaaS feature inherits access through OAuth tokens, service accounts, or API keys. Those identities are often persistent, broadly scoped, and weakly owned, so the AI activity looks legitimate to the platform even when the use case is not approved. This shifts the risk from a visible application install to hidden execution inside trusted identity paths. The real technical issue is not just data transfer, but delegated authority that outlives the human decision that created it.

Practical implication: map every non-human identity that can invoke or relay AI requests and review its scope, ownership, and revocation path.

Embedded AI in SaaS and CI/CD pipelines

Embedded AI is dangerous because it operates inside already-approved products and build systems rather than as separate traffic to block. A code assistant in an IDE, an AI step in GitHub Actions, or a model dependency in a pipeline can send data to external services while appearing normal to CASB or DLP tools. That creates a blind spot where authorised platforms become the delivery channel for unapproved AI processing. The attack surface expands through configuration drift, package dependencies, and hidden feature toggles, not just through user behaviour.

Practical implication: inventory AI-capable extensions, pipeline steps, and model dependencies as part of standard software supply chain review.

Data exposure and privilege depth in shadow AI

Not every shadow AI exposure carries the same risk. Read-only tools that summarise public information are very different from agents that can read source code, customer data, or infrastructure secrets, and then modify repositories or production systems. The meaningful control question is therefore twofold: what can the tool read, and what can it change. When those answers include regulated data or write access, the issue moves from governance concern to immediate exposure. This is why identity depth matters as much as model capability.

Practical implication: classify shadow AI by data sensitivity and action authority, then prioritise revocation where write access meets regulated data.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 problem before it is an AI problem. The most important failure mode is that approved identities are increasingly used as transport layers for unapproved AI behaviour. OAuth apps, service accounts, and API keys can all legitimise AI processing inside otherwise trusted environments. Practitioners should treat visibility into non-human identities as the first control plane, not a downstream audit step.

Embedded AI collapses the traditional gateway model. CASB and DLP were built to observe distinct applications and obvious data egress, not AI functions embedded inside SaaS features or CI/CD steps. When AI runs through an approved platform, the gateway sees a normal service interaction rather than a policy breach. That means the governance model must shift from blocking destinations to inventorying identity, data, and action pathways.

Shadow AI creates a new kind of privilege creep called AI inheritance sprawl. A developer may authorise a coding assistant for one task, but the underlying token can reach repositories, secrets, build systems, and production data. That is broader than classic application sprawl because the AI layer inherits permissions across multiple control domains at once. The implication is that identity ownership, scope review, and revocation discipline now need to cover AI-capable integrations as first-class NHI assets.

Continuous AI processing changes the blast-radius equation. Traditional shadow IT often creates a static, point-in-time exposure, but shadow AI can process, retain, and act on data repeatedly throughout the day. That increases the chance of data leakage, compliance failure, and unnoticed downstream reuse. Practitioners should re-evaluate their assumptions about how long a risk window stays open once AI is embedded in everyday developer and SaaS workflows.

Identity-first AI governance is now the practical baseline. The article’s strongest signal is that cloud and IAM teams can no longer separate AI governance from NHI governance. The controls that matter are discovery, ownership, scope, and revocation across every machine identity that can call an AI service. Security teams should assume that unmanaged AI will arrive through already-approved paths unless identity telemetry proves otherwise.

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, which shows how immature the visibility problem remains across machine identities.
• Read Top 10 NHI Issues for the control gaps that most often surface when identity sprawl outruns governance.

What this signals

Shadow AI governance will increasingly be measured by identity coverage, not by the number of blocked tools. When AI features are embedded inside existing platforms, the organisation that can enumerate OAuth apps, service accounts, and API keys will outpace the one relying on perimeter controls alone. That is why identity telemetry is becoming the operational backbone of AI governance.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance gap is structural rather than cosmetic. Security teams should expect more AI activity to enter through sanctioned accounts, not through obvious rogue apps.

AI inheritance sprawl: the hidden accumulation of permissions across OAuth, service accounts, extensions, and pipeline steps that lets AI operate beyond the intent of the original approval. Teams that do not track this sprawl will miss the point where a convenience feature becomes a control failure.

For practitioners

• Map every AI-capable non-human identity Inventory OAuth applications, service accounts, API keys, and bot identities that can route data to AI services. Record ownership, scope, last review date, and revocation path for each identity so you can see where unapproved AI use is already riding on legitimate credentials.
• Scan SaaS, IDE, and pipeline surfaces for embedded AI Review Slack, Notion, VS Code, Cursor, GitHub Actions, GitLab CI, and Jenkins for hidden AI features, extensions, or steps. Treat package manifests, extension configs, and model files as part of the discovery process because those locations often reveal AI use before network tools do.
• Separate read exposure from write authority Classify each shadow AI use case by what it can read and what it can change. Prioritise controls where tools can touch customer data, source code, secrets, or production systems, because write authority turns a visibility problem into an operational risk.
• Replace standing access with time-bound approvals Use just-in-time elevation for AI tools that need sensitive resources, and revoke access when the task ends. This limits persistent privilege on service accounts and reduces the chance that an AI assistant keeps broad access long after the original use case is over.
• Build a sanctioned AI path that developers will use Publish approved AI tools, fast-track security review for high-demand use cases, and make the secure option easier than personal accounts. That reduces shadow adoption without relying on blocking alone and gives teams a controlled route for legitimate experimentation.

Key takeaways

• Shadow AI is mostly invisible because it rides on legitimate non-human identities and trusted SaaS paths, not because it is technically novel.
• The scale of the problem is already material, with 80%+ of employees using unapproved AI tools and most organisations still lacking full OAuth visibility.
• Identity-first discovery, scope review, and time-bound access are the controls that matter when AI behaviour is hidden inside approved environments.

Key terms

• Shadow AI: AI tools, features, or agents that operate outside approved governance while still touching corporate data or systems. The risk is not only unauthorised use, but persistent processing through trusted identities and platforms that make the activity hard to see and harder to contain.
• Non-Human Identity: A machine or software identity used by services, workloads, API integrations, bots, or AI systems. In shadow AI scenarios, these identities matter because they often carry standing permissions, weak ownership, and broad access that can be reused by tools the business never explicitly approved.
• Identity Inheritance: The transfer of access rights from an authorised identity to an AI tool or embedded feature without a new approval decision. It is a hidden governance gap because the AI appears legitimate while operating inside the scope of access granted to another actor, often with broader reach than intended.
• Action Authority: The set of things a tool is allowed to change, not just read. For shadow AI, this distinction matters because read-only summarisation is a different risk from systems that can modify repositories, infrastructure, communications, or policies on behalf of users.

Deepen your knowledge

Shadow AI discovery, non-human identity inventory, and delegated access review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern embedded AI without slowing delivery, this is a relevant place to start.

This post draws on content published by Orca Security: The Bring Your Own AI crisis and shadow AI detection in cloud environments. Read the original.