Shadow AI is the use of artificial intelligence systems, services or features for organizational work without the visibility, approval or governance required by the organization, including employee use of public AI accounts, embedded assistants, extensions, local models and autonomous agents.
The employee may be trying to summarize a document, write code, transcribe a meeting or automate a repetitive task. The activity becomes shadow AI when it bypasses a required assessment, approved account, data-handling rule or system inventory. It does not have to be malicious.
Shadow AI can operate in a browser, a desktop or mobile application, an extension, an application programming interface (API), or a feature added to software the organization already uses. A tool does not need to be installed on a company device to affect company data or decisions.
The concept is a form of shadow IT, but AI adds distinct concerns. Prompts and uploads may expose data, generated output may enter a business process without validation, and an AI agent may use connected files, credentials or tools to take actions. Agentic AI security explains the wider controls needed when an AI system can act through an endpoint.
Why shadow AI matters
Shadow AI creates an unknown path between organizational work and an AI provider, model or agent. When the path is missing from inventory, teams may not know which data entered the system, which identity authorized access, what provider terms apply, where output was used or how to end the connection.
The immediate risk is not merely that an employee used an unapproved brand. The relevant questions are what the system could access, what data it received, what it produced, whether a person checked the result and whether it could act. The United Kingdom's National Protective Security Authority warns that non-malicious use of unknown AI tools can weaken security and harm an organization in its NPSA guidance.
Unsanctioned AI can create several kinds of exposure:
- Data exposure. A prompt, file, image, source-code fragment or meeting transcript may contain personal, confidential or regulated information.
- Identity exposure. Employees may authorize an assistant with a personal account, reuse credentials or grant broad access to cloud storage and business applications.
- Unreviewed output. Generated text, code or analysis may be inaccurate, insecure or unsuitable for the context in which it is used.
- Untracked dependency. A team may quietly build a recurring process around a service whose availability, behavior, terms or model can change.
- Unbounded action. An extension or agent may read files, call APIs, send content or change records with the employee's authority.
- Incomplete evidence. Incident responders may lack the prompts, tool calls, policy decisions and account records needed to reconstruct an event.
These risks vary greatly. Using an unapproved public chatbot to rephrase nonsensitive text is not equivalent to connecting an autonomous agent to customer records. A useful governance process distinguishes them instead of treating every AI interaction as the same event.
How shadow AI develops
Shadow AI usually begins with a legitimate work need and an approval path that is absent, unclear or slower than the task. The employee finds an accessible tool, gets a useful result and repeats the workflow. Over time, an experiment can become an undocumented business process.
The typical lifecycle has six stages:
- A work need appears. An employee wants faster research, drafting, coding, transcription, translation or analysis.
- The employee selects an AI capability. This may be a public service, personal subscription, extension, local model or AI feature embedded in approved software.
- Data and authority cross a boundary. The employee enters a prompt, uploads a file, connects an account, grants an extension permission or supplies an API key.
- The AI system processes the task. Processing may occur locally, in a provider's cloud or across several connected services.
- The result enters company work. Generated content, code, decisions or actions may be copied into a document, application, repository or customer interaction.
- The workflow persists without ownership. The organization may not record the provider, purpose, data class, responsible owner, access scope, review status or retirement plan.
The governance gap can exist even when the base application is approved. A newly enabled AI feature, third-party plug-in or personal account can introduce a model and data flow that the original assessment did not cover.
Common forms of unsanctioned AI
Shadow AI includes more than public chatbots. The important distinction is whether the specific use, account, capability and data flow have passed the organization's required process.
| Form | Example work use | Main visibility gap |
|---|---|---|
| Public AI service | Summarizing a company document through a personal account | Provider, account, uploaded data and retention settings may be unknown |
| Embedded assistant | Activating an AI feature inside an approved productivity application | The new capability and its data path may not have been assessed |
| Browser extension | Drafting replies from pages or web applications | Permissions may expose more page content than the employee expects |
| Coding assistant | Generating or reviewing proprietary source code | Repository access, code handling and output review may be unclear |
| Local model | Processing files on a laptop | Model provenance, runtime, storage and local permissions may be absent from inventory |
| Connected agent | Reading files and updating tickets or records | Delegated identity, tools, action limits and audit evidence may be unknown |
| Departmental API | Building a workflow with a team-purchased key | Cost, credentials, data movement and operational ownership may bypass central review |
An approved AI service can also be used outside its approved boundary. For example, the organization may permit a writing assistant for public marketing copy but not for personnel records. Approval attaches to a defined use and configuration, not just a product name.
How organizations discover and govern shadow AI
The goal is to make employee AI use visible, assess it proportionately and provide safer ways to meet legitimate needs. A blanket ban may suppress disclosure without removing demand, while unrestricted adoption leaves the organization unable to evaluate risk.
Establish a clear intake path
Employees need a short, understandable route to check whether a service is approved, request a review and report an experiment without concealing it. Policy should define which data, accounts, integrations and actions require approval. Training should use realistic tasks rather than assume that employees can identify every AI feature by name.
Build an AI use inventory
The inventory should describe the system and its actual organizational use: owner, purpose, users, provider, model or service, account type, execution location, data classes, connected resources, permissions, output destination, human review, logging and retirement path. The NIST Playbook recommends mechanisms to inventory AI systems and assign responsibility for maintaining that inventory.
Discovery signals may include employee disclosures, procurement and expense records, identity-provider applications, approved browser or application inventories, API-key issuance, network service categories and data-protection events. These signals are incomplete and can affect employee privacy. Monitoring scope, notice, access, retention and permitted use require qualified review for each applicable jurisdiction.
Assess the use, not only the tool
A proportionate review asks what business purpose the AI serves, which information it receives, whose identity it uses, what resources it can reach, whether it can change state and how a person validates the result. The same provider can support a low-risk drafting task and a high-impact decision workflow.
The GenAI Profile recommends documenting generative AI systems, their risks, human oversight and third-party considerations. It also emphasizes that governance applies across the lifecycle rather than at procurement alone.
Decide and enforce
The organization can approve the use, constrain it, move it to an enterprise account, replace it with an approved alternative, require further testing or stop it. Controls may restrict data classes, accounts, extensions, model sources, local runtimes, connected applications, tool permissions and external destinations. Consequential outputs and actions may require independent validation or human approval.
Review and retire
AI capabilities and provider behavior change. Owners should review material model, feature, permission, data-flow and purpose changes, then remove unused accounts, tokens, extensions, local runtimes and integrations. A retired tool may still leave copied output, stored data or a business dependency that needs handling.
Once shadow AI becomes an endpoint inventory and policy concern, device management can help identify managed devices, approved applications and assigned configurations. Organizations evaluating that endpoint layer can consider Swif UEM. Separate AI governance, provider assessment, identity, data protection and agent authorization controls remain necessary.
An employee AI use example
Northstar Benefits, a fictional company, permits an enterprise writing assistant for general internal content but requires privacy review before customer information enters any AI service. An account manager needs to summarize a long customer call before a deadline.
The manager installs a free transcription extension in a browser on a managed Windows laptop and grants it access to the meeting page. The extension captures names, contact details and benefit questions, then sends the transcript to a service purchased through the manager's personal account. The starting intent is ordinary productivity, but the unapproved extension, personal identity and customer data make the workflow shadow AI.
An application inventory flags the new extension. The security team does not assume that installation alone proves disclosure. It confirms the extension's permissions and asks the manager what task was performed. The privacy team then determines what data was transmitted and follows the organization's incident and provider-assessment processes.
The company removes the extension, revokes its access and gives the team an approved transcription route with defined data handling and human review. It also shortens the intake process for new AI use cases. The result addresses both the immediate exposure and the work need that caused it.
Benefits of managing shadow AI
Effective shadow AI governance turns hidden experiments into explicit decisions. It can provide several operational benefits:
- More complete risk decisions. Teams evaluate the actual data, identity, permissions and purpose instead of judging a tool by its name.
- Safer employee experimentation. A visible intake path lets useful ideas reach testing and approval before they become dependencies.
- Clearer accountability. Each accepted use has an owner, review record, permitted scope and retirement path.
- Stronger data boundaries. Employees know which information may enter which AI systems and under what account or configuration.
- Faster response. Inventory and identity records help teams find affected users, devices, credentials and integrations.
- Better purchasing decisions. Repeated shadow use can reveal unmet needs that justify an approved organization-wide capability.
The benefit comes from a functioning governance system, not surveillance alone. Discovery without a practical approval path can drive employee AI use further out of view.
Shadow AI risks and limitations
No single control can produce a complete shadow AI inventory or eliminate every unsafe use.
- Browser and cloud use can evade endpoint inventory. A personal device or account may leave little evidence on a managed computer.
- Embedded AI changes the boundary. A familiar application may add features or data flows after its initial approval.
- Detection can be ambiguous. Visiting an AI domain does not prove that company data was uploaded or that policy was violated.
- Blocking can disrupt legitimate work. Broad restrictions may affect approved services or encourage workarounds when alternatives are poor.
- Monitoring creates privacy risk. Prompt, browser and application telemetry can contain employee or customer information.
- Approval can become stale. Models, terms, integrations, permissions and business purposes can change after review.
- An approved tool can still be misused. Sanctioned status does not make every input, output or action acceptable.
- Local execution is not automatically safe. A local model may reduce one external data path while introducing unreviewed software, files, permissions and model provenance.
Shadow AI governance also cannot guarantee correct output. Evaluation, secure development, data controls and human oversight remain necessary after a use becomes approved.
Shadow AI and related concepts
Shadow AI describes an approval and visibility gap. Related concepts address different parts of the system.
| Concept | Primary question | Boundary from shadow AI |
|---|---|---|
| Shadow IT | Which technology is used outside required IT visibility or approval? | Covers all unsanctioned technology; shadow AI is the AI-specific subset |
| AI governance | Who sets AI policy, ownership, risk tolerance and oversight? | Provides the organizational process that discovers and decides shadow AI uses |
| Agentic AI security | How are an agent's identity, permissions, data and actions constrained? | Applies whether the agent is approved or unsanctioned |
| Prompt injection | Can untrusted content redirect a model or agent? | Is a threat technique, not the reason a system is classified as shadow AI |
| Data loss prevention | Which sensitive data may move through a channel or action? | Can restrict data movement but does not approve the AI system or validate its output |
| AI agent identity | Which software actor is requesting access or taking an action? | Supports authorization and evidence after an agent is known |
Prompt injection is one risk that both approved and shadow AI systems may face. AI governance establishes the decision process, while data loss prevention can enforce some data-handling boundaries.
The practical objective is governed employee AI use. Organizations need to understand the work people are trying to complete, inventory the AI capability and its connections, assess data and action risk, provide an explicit decision and retain a reliable way to change or end access.




























.png)





