Shadow AI and shadow IT need different governance controls

At a glance

What this is: Protecto argues that shadow AI creates a different control problem from shadow IT because the risk sits in prompts, model interactions, and data leakage rather than only in unauthorised applications.

Why it matters: For IAM, NHI, and security teams, the distinction matters because governance has to shift from simple asset discovery to monitoring AI usage, protecting data before prompt submission, and controlling access to AI workflows.

By the numbers:

• 75% of knowledge workers use AI at work, according to Microsoft’s 2024 Work Trend Index cited by Protecto.

Context

Shadow AI and shadow IT both describe technology used outside approved governance, but they fail in different ways. Shadow IT is usually about unauthorised applications and weak asset visibility, while shadow AI adds model interaction, prompt handling, and data exposure risks that conventional SaaS controls do not fully cover.

That difference matters because the security boundary is no longer just the application estate. When employees place customer records, source code, or regulated information into external AI services, the control problem becomes one of data governance, usage monitoring, and delegated access across AI workflows.

Key questions

Q: How should organisations govern AI usage when employees use unapproved tools?

A: Organisations should start with visibility, not enforcement. If teams cannot see which apps, agents, or workflows are being used, they cannot assess data exposure or apply meaningful controls. Once usage is mapped, policy can shift from blanket bans to context-based decisions that reflect sensitivity, role, and business purpose.

Q: What breaks when shadow AI is treated as ordinary SaaS sprawl?

A: Teams miss the real control problem, which is not the app itself but the data it can access and the identities it uses. Shadow AI can transform, summarise, and share sensitive information in ways traditional inventories do not capture, so an app-centric model understates exposure and delays remediation.

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Q: What is the difference between governance visibility and data loss prevention for AI?

A: Governance visibility shows what already happened, while data loss prevention stops or shapes the action before it happens. For AI tools, that difference matters because the dangerous moment is often the paste or upload itself. Teams need both, but only one of them reduces immediate exposure.

Technical breakdown

Why shadow AI is not the same as shadow IT

Shadow IT is primarily a visibility and approval problem: an unauthorised application or service appears outside the sanctioned stack. Shadow AI is different because the risk sits in the interaction layer, where a user can send sensitive information into a model and receive output that may be reused in business processes. That makes the exposure harder to see with standard CASB, SaaS discovery, or network inventory alone. The control objective is not just to find an unsanctioned app, but to understand what data entered the model, how it was processed, and whether the resulting output created compliance or IP risk. See the AI risk assessment guide. See the AI Risk Assessment Guide.

Practical implication: Classify AI usage separately from shadow IT so discovery, data protection, and governance controls are designed for prompt-level risk.

How prompt monitoring changes the detection model

Traditional shadow IT monitoring looks for unknown services, unusual outbound destinations, and unsanctioned subscriptions. Shadow AI detection has to add prompt content analysis, because the most material risk is often what a user submits to the model rather than the application they visit. That means teams need visibility into AI traffic patterns, prompts, and embedded AI features in business applications. It also means detection has to account for context, because the same model can be harmless in one workflow and risky in another if regulated data is involved. The governance question shifts from app approval to content-aware monitoring. See the Shadow AI and AI Agent Discovery Guide.

Practical implication: Extend detection to prompt and content inspection so you can spot sensitive data before it leaves the enterprise boundary.

Why access control alone does not solve shadow AI

Role-based access control can tell you who may use a system, but it does not decide whether a prompt, a dataset, or an output is appropriate for a given AI interaction. That is why the article points toward context-based access control and data protection controls rather than relying on conventional entitlements alone. In AI workflows, purpose, data sensitivity, and runtime context matter as much as identity. For identity teams, the lesson is that authorisation has to move closer to the moment of use, especially when AI systems are handling regulated or confidential material. See the AI Governance Guide.

Practical implication: Treat AI access as a context problem, not just an entitlement problem, and pair identity controls with data-layer enforcement.

Threat narrative

Attacker objective: The practical objective is to obtain sensitive organisational data through unmanaged AI interactions and turn routine productivity use into an exposure path.

1. Entry occurs when employees adopt public AI tools or embedded AI features outside approved governance, often because sanctioned alternatives are too limited or unavailable.
2. Credential or data exposure follows when users paste customer records, source code, or regulated information into the model during prompt submission.
3. Impact occurs when sensitive data is retained, inferred, or reused in ways that create privacy, IP, or compliance exposure for the enterprise.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI creates a governance gap that shadow IT controls do not close. Visibility into applications is necessary but no longer sufficient when the risk is the prompt, the model interaction, and the downstream reuse of output. That means the control plane has to expand from asset discovery to data-aware governance across AI workflows. Practitioners should treat this as a distinct control domain, not a subcategory of software sprawl.

Context-aware access control is the right response to AI workflow risk. The article is strongest when it moves beyond simple approval models and into identity, purpose, and runtime context. That is the right direction because AI systems can be used legitimately in one workflow and dangerously in another. Identity programmes should therefore connect authorisation decisions to data sensitivity and intended use, not just user role.

Prompt-level exposure is the named risk that security teams still under-estimate. The specific failure mode is not only unsanctioned tooling, but the act of submitting confidential content into an external model where existing DLP and SaaS monitoring may not see the full context. That is why AI governance has to be content-aware and workflow-aware, not just inventory-aware. Practitioners should govern the submission path as tightly as the application itself.

Shadow AI governance belongs at the intersection of IAM, data protection, and AI risk management. This is where the article intersects most clearly with identity security: the user identity may be known, but the decision space now includes purpose, model boundary, and data sensitivity. AI risk assessment becomes relevant because the organisation needs a repeatable way to score those interactions. Security teams should build controls that follow the data into the AI workflow.

Unmanaged AI integrations are becoming a third-party governance problem as much as a user problem. When AI features appear inside business tools, the organisation inherits new data paths that may not be visible in traditional approval workflows. That shifts accountability toward vendor review, integration scoping, and data-handling controls. Practitioners should review AI-enabled services with the same scrutiny they apply to other sensitive third-party access paths.

From our research library:

• Organisations with high levels of shadow AI faced an average of $670,000 in additional breach costs compared with those with little or none, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Prompt-level exposure is becoming the defining shadow AI control gap. Organisations that only monitor applications will miss the moment users submit regulated or proprietary data into external models. The practical shift is toward controls that understand content, purpose, and workflow context, not just service usage.

Shadow AI governance is converging with third-party risk and identity governance because AI-enabled tools now sit inside ordinary business workflows. The next control question is not whether a tool is approved, but whether the data path, retention terms, and access context are acceptable for the task.

As AI adoption spreads, security teams will need one operating model for approved AI, embedded AI features, and unsanctioned use. That is the only way to keep governance aligned with how people actually work without forcing every decision back to a blunt allow-or-block model.

For practitioners

• Define a separate shadow AI control set Create governance criteria that distinguish AI tools, AI-enabled applications, and generic shadow IT so teams do not apply the wrong detection and approval model.
• Add prompt and content monitoring Extend monitoring to prompt submissions, AI traffic patterns, and embedded AI features so sensitive data use can be detected before it leaves approved boundaries.
• Protect data before AI submission Use tokenisation, masking, or controlled de-tokenisation for sensitive fields that are likely to enter public or unmanaged AI systems.
• Review AI-enabled vendors as third-party risk Assess business applications with embedded AI features for data handling, retention, and access paths before they are allowed to process sensitive content.
• Build context-based access decisions Tie approval to identity, purpose, and data sensitivity so access to AI workflows is governed by context rather than role alone.

Key takeaways

• Shadow AI is a distinct governance problem because the material risk often sits in the prompt and model interaction, not only in the application being used.
• The article highlights that workers are already using AI heavily, which makes visibility, data protection, and context-aware access decisions more urgent.
• Teams that rely only on shadow IT controls will miss the specific exposure path created when sensitive information is submitted to external AI systems.

Related NHI Mgmt Group resources: Shadow AI and AI Agent Discovery Guide · AI Risk Assessment Guide · AI Governance Guide · Third-Party AI Risk Guide

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
• Prompt Analysis: Prompt analysis is the inspection of user inputs sent to AI systems to identify sensitive data, policy violations, and risky intent. It is a governance control because the prompt often reveals the real exposure path, not just the fact that an AI tool was used.
• Context-based access control: A policy model that authorizes access using the request’s identity, payload, origin, and intended action together. It is designed for systems where risk changes at runtime, especially AI agents and other NHI workloads that move through multiple tools and data sources.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes that govern modern AI and non-human access.