Shadow AI is exposing cloud identities faster than governance can track

At a glance

What this is: Shadow AI is the use of AI tools or features without IT or security approval, and the key finding is that unmanaged use is already spreading across cloud workflows and exposing data, permissions, and decision-making to unseen risk.

Why it matters: It matters because IAM, NHI, and human identity programmes all lose control when AI is adopted outside governed access paths, making visibility, policy, and entitlement boundaries harder to enforce.

By the numbers:

• 78% of organizations now use AI in cloud systems, with 72% using it in daily operations.
• (38%) of employees admit to sharing sensitive work, sensitive work information with AI tools without their employer's permission.
• 80% of AI tools operating within companies are unmanaged by IT or security teams.

👉 Read Orca Security's analysis of Shadow AI risks and cloud governance

Context

Shadow AI is what happens when AI tools, models, or embedded features are used without the knowledge or approval of IT and security teams. The problem is not only policy drift. It is that cloud identity, data access, and workflow automation now intersect in places security teams cannot easily see.

In practice, Shadow AI shows up when employees paste code into public LLMs, upload customer data into external tools, or rely on AI features buried inside SaaS platforms that were never formally reviewed. That makes AI governance an IAM problem as much as a data and application problem, because access decisions now extend to prompts, integrations, and output handling.

Key questions

Q: How should security teams govern Shadow AI in cloud environments?

A: Start by tying AI usage to the identities, SaaS accounts, and APIs that actually move the data. Then define approved tools, permitted data classes, review requirements for outputs, and logging for prompt and integration activity. Without those controls, Shadow AI becomes a hidden extension of ordinary cloud access rather than a separate risk domain.

Q: Why does Shadow AI matter to IAM and NHI programmes?

A: Because AI tools frequently inherit access from existing human and workload identities, which means the identity layer can look compliant while the data path is not. That creates unreviewed delegation, hidden exfiltration routes, and unclear accountability. IAM and NHI teams need to govern the AI interaction, not only the login or API key.

Q: What breaks when employees use AI tools without approval?

A: Visibility breaks first, followed by data handling control and output trust. Security teams lose sight of where sensitive information is sent, how long it is retained, and whether the results are accurate enough for business use. In practice, that makes policy enforcement and audit response reactive instead of preventive.

Q: How do you know if Shadow AI controls are working?

A: Look for a shrinking set of approved AI services, visible logs for prompt and integration activity, clear data-class restrictions, and documented review steps for outputs. If employees still rely on unofficial tools for core work, the programme is not yet governing behaviour, only issuing guidance.

Technical breakdown

Why Shadow AI creates a cloud identity blind spot

Shadow AI becomes a governance problem when approved identities are used to reach unapproved AI services, or when embedded AI features inherit access from SaaS accounts without a security review. The identity layer may still look normal, but the data path and retention model are not. That breaks the assumption that every materially sensitive service interaction is visible to security, logged, and subject to policy. In cloud environments, this is amplified by API-driven workflows, shared tokens, and permissions that were never scoped for AI-assisted data exchange.

Practical implication: map AI usage to the identities and service connections already present in your cloud estate, not just to standalone AI tools.

How Shadow AI expands the attack surface

AI tools often need broad prompts, integrations, or data access to be useful, which means unmanaged usage can create new exfiltration paths and permission sprawl. A public chatbot, browser extension, or embedded SaaS feature may receive source code, customer records, or internal plans and then process that information outside enterprise controls. The technical risk is less about the model itself and more about the access path around it. Once those paths are established, they can persist as unofficial data channels that bypass established identity and access controls.

Practical implication: treat AI integrations as part of your attack surface review, including API permissions, SaaS connections, and data egress points.

Why decision quality is part of security

Shadow AI is not only a confidentiality issue. AI-generated summaries, code suggestions, and recommendations can alter decisions even when the underlying data was never intended for use in that way. If employees treat outputs as validated facts, errors and bias can flow into operational, financial, or security decisions. That creates a control problem because governance has to cover not just what data goes in, but how outputs are reviewed, trusted, and documented before they influence action.

Practical implication: define review requirements for AI outputs in regulated or high-impact workflows before they are allowed to drive decisions.

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

Shadow AI is an identity governance problem before it is an AI adoption problem. The article shows that unmanaged AI use is spreading through ordinary work patterns, which means access is being extended outside approved review, logging, and policy paths. That is a control boundary failure, not just a user-behaviour issue. The practitioner conclusion is that AI governance must be joined to identity governance from the start.

Cloud identities are now carrying unreviewed AI traffic. When employees use sanctioned SaaS accounts, browser tools, or embedded features to reach external models, the identity may be known even when the AI relationship is not. That creates a hidden permission layer around prompts, uploads, and API calls. The implication is that visibility must move from application inventory to identity-to-AI interaction mapping.

Unmanaged AI use creates policy drift faster than central standards can catch up. The article’s examples across engineering, analytics, strategy, and sales show that adoption is happening by function, not by architecture. That makes point-in-time approvals insufficient because the real risk is local workarounds becoming normal operating practice. Practitioners should treat Shadow AI as a recurring governance condition, not a one-time exception.

Shadow AI widens the gap between permitted access and trusted access. A user or workload may be authorised to reach a system, but not necessarily to feed that system into an external model or reuse the output without validation. That distinction matters across human IAM, NHI controls, and agentic workflows. The field needs to recognise that access approval no longer tells the whole story once AI becomes embedded in everyday execution.

Shadow AI as uncontrolled delegated processing: The specific failure mode is not merely unsanctioned tool use, but delegated handling of sensitive data and decisions outside the governed chain of accountability. That premise was built for environments where tooling choices were known and reviewed in advance. It fails when employees and embedded features can route work through external AI on demand. The practitioner conclusion is that approval models must account for where processing is delegated, not just who logged in.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 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, according to the same report.
• For lifecycle and access-control context, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and Top 10 NHI Issues.

What this signals

Shadow AI is forcing security teams to extend governance from identities to interactions. Once AI becomes embedded in day-to-day workflows, the question is no longer only who has access, but what that access is allowed to do through prompts, integrations, and outputs. The practical programme shift is toward identity-to-data-path mapping, control review for embedded AI features, and policy that users can actually follow.

With 38% of employees admitting they share sensitive work information with AI tools without permission, the gap is already behavioural as well as technical. That means awareness alone will not close it. The control model has to combine approved alternatives, simple usage rules, and enforcement that is visible in the systems people already use.

Shadow AI sits in the same governance family as unmanaged NHIs. Both create trusted access paths that operate outside the organisation’s intended review cycle, and both become hard to recover once they are woven into normal work. That makes unified visibility across human identities, workloads, and AI-enabled services a programme-level requirement, not a niche control.

For practitioners

• Map AI usage to identity and data paths Inventory where employees, SaaS platforms, browser extensions, and APIs are sending prompts or content, then tie each path back to the identity that initiated it. This is the only practical way to see Shadow AI as part of the cloud estate rather than as a separate productivity trend.
• Publish approved AI use rules by data class Define which data types may be entered into external AI tools, which tools are approved, and which outputs require review before reuse. Make the policy simple enough that teams can follow it without inventing their own workarounds.
• Review SaaS and browser integrations for hidden AI features Many Shadow AI cases come from features embedded in tools already approved by IT. Reassess permissions, API scopes, and retention settings whenever a vendor adds AI functionality, and disable model training on corporate inputs where possible.
• Add review gates for AI-generated outputs Require human validation for AI-generated code, summaries, customer communications, and analytical outputs in regulated or high-impact workflows. The goal is not to ban AI, but to stop unverified output from becoming operational truth.

Key takeaways

• Shadow AI turns ordinary employee productivity choices into an access-governance problem because data, identities, and AI services now intersect outside approved control paths.
• The article’s evidence shows this is already widespread, with AI use embedded in daily cloud operations and employees admitting to unapproved sharing of sensitive information.
• The practical response is to govern where AI is used, what data it can touch, and how its outputs are reviewed before they influence business decisions.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, models, or embedded features without security, governance, or IT approval. The risk is not only the tool itself, but the hidden data flows, retained prompts, and unreviewed outputs that can alter security, compliance, and decision-making.
• Governed AI: Governed AI is AI usage that sits inside approved policy, visibility, and accountability boundaries. It has defined data handling rules, reviewed integrations, and clear ownership for outputs, so security teams can trace how information moves and how decisions are made.
• Identity-to-data path: An identity-to-data path is the route an authenticated user, workload, or service takes to reach sensitive information through applications, APIs, and integrated tools. In Shadow AI cases, the path often matters more than the login because the identity may be approved while the downstream data use is not.
• Embedded AI feature: An embedded AI feature is AI capability built into a SaaS product or platform that was previously approved for another purpose. These features can change retention, sharing, or processing behaviour without a separate governance review, which makes them a common source of hidden risk.

Deepen your knowledge

Shadow AI governance and cloud identity visibility are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for embedded AI features and unmanaged tools, it is worth exploring.

This post draws on content published by Orca Security: Shadow AI risks, governance, and mitigation in cloud environments. Read the original.