Shadow AI is a visibility problem before it becomes a technology problem
Employees adopt AI to work faster. The control gap appears when the organization cannot identify the service, data, integration, output, owner or business consequence associated with that use.
Shadow AI rarely begins as a deliberate attempt to bypass policy. It often begins with a legitimate objective: summarize a document, improve a presentation, debug code, translate content, analyze a spreadsheet or accelerate research. The user sees a productivity tool. The organization may see only an encrypted web session to a rapidly changing service.
The resulting risk is broader than information leakage. Unapproved AI use can create unmanaged supplier relationships, unknown retention, excessive OAuth consent, weak records, unreviewed outputs, intellectual property exposure, regulatory uncertainty and decisions made without reliable evidence.
A defensible response combines governance and technical control. Governance defines permitted uses, accountable owners and approval criteria. Technical visibility identifies services, users, devices, data movement and integrations. Together they enable proportionate action: approve, configure, coach, restrict, investigate, contain or retire.
What changes with AI
- Prompts can contain business data.
- Services may retain or reuse inputs.
- Connectors can reach enterprise systems.
- Outputs may influence decisions or actions.
- Features can appear inside approved platforms.
Leadership decision
Decide which AI uses require approval, which data is prohibited, which controls are mandatory and who can accept residual risk.
Risk follows the complete path from source data to business action
The prompt is only one control point. A useful assessment traces what enters the service, what the service can reach, what it produces and how the output is used.
A user may paste confidential information into a public AI service, upload a file into an enterprise tenant, connect an assistant to a mailbox, invoke a model through an application programming interface, or use an agent that can act on external systems. These are materially different risk profiles even when the visible user experience looks similar.
Source data
Public, internal, confidential, personal, regulated or customer owned information.
User and device
Identity, account type, endpoint, browser and business purpose.
AI service
Provider, tenant, model, retention, region and training use.
Integration
Mailbox, file store, repository, plugin, API or autonomous action.
Output
Generated code, content, analysis, recommendation or record.
Business action
Communication, decision, change, customer outcome or operational effect.
Control implication
Protect the source data, constrain the submission path, assess the provider and tenant, limit integrations, review consequential outputs and preserve records and ownership.
Common entry points
- Public chat and search tools
- Browser extensions and AI assistants
- Embedded AI in SaaS platforms
- Code assistants and repositories
- Meeting, transcription and translation tools
- Custom agents, plugins and APIs
- What information can enter?
- What can the service retrieve?
- Where is data retained or processed?
- Can the output trigger action?
- Who approves the use?
Prioritize the scenarios that can create material business harm
Shadow AI risk should be sized through business consequence and likelihood. A technically novel scenario is not automatically the most important scenario.
A practical risk assessment begins with a scenario, not a generic concern. For example: an employee uploads customer records to an unapproved service; a plugin receives broad access to a mailbox; generated code introduces a vulnerability; an AI summary omits a material contractual obligation; or a business team relies on an unreviewed output to make a customer decision.
Move first on high consequence scenarios with realistic likelihood and weak controls.
01 Customer data disclosure
Restricted customer information entered into an unapproved service.
02 Broad mailbox connector
Excessive OAuth permissions expose mail and files beyond the intended purpose.
03 Unsafe generated code
Unreviewed code reaches development or production workflows.
04 Unreviewed decision output
AI output influences a material customer, legal or operational decision.
Consequence dimensions
- Confidentiality and privacy
- Intellectual property
- Legal and regulatory exposure
- Customer commitments
- Operational reliability
- Decision quality and safety
- Records and accountability
- Reputation and trust
- Define a scenario.
- Identify the service and data.
- Estimate consequence.
- Assess realistic likelihood.
- Record controls and gaps.
- Assign an owner.
- Approve treatment or residual risk.
Correlate existing enterprise signals to reveal unsanctioned AI use
Most organizations already collect fragments of the required evidence. The challenge is to connect identity, web, endpoint, data, SaaS and provider signals into an explainable view.
Discovery should combine declared information with observed evidence. Declared information includes approved services, owners, purposes and permitted data. Observed evidence includes domains, application use, OAuth consent, process activity, file movement, browser behavior, cloud audit events and provider administration logs.
Identity and access
Authentication, account type, federation, privilege, tokens and consent.
Network and secure web
Destinations, categories, proxy events, DNS and approved routes.
Endpoint and browser
Applications, extensions, processes, file activity and device posture.
SaaS and cloud audit
Administrative events, service use, connectors and configuration changes.
Data classification and DLP
Sensitive content, uploads, destinations, sharing and policy indicators.
Provider administration
Tenant, model, retention, training use, regions, plugins and incidents.
Correlation, policy evaluation and case management
Join user, device, service, data, integration, owner, policy and recommended action into a single explainable case.
What discovery should answer
- Which services and features are used?
- Who uses them and from which devices?
- What data types are involved?
- Which integrations have been granted?
- Is use approved, restricted or unknown?
- What action is required and who owns it?
Important limitation
No single product or log source answers every question. Coverage gaps and lawful monitoring constraints should be documented explicitly.
Create a fast route for approved use and accountable exceptions
Governance should enable safe adoption, not force every use case through the same process. Tiering and clear decision rights keep review proportionate.
Governance begins with a usable policy. The policy should define approved channels, prohibited information, required reviews, accountability, supplier expectations, integration rules, output verification, records and incident reporting. It should distinguish personal experimentation from business use and clarify whether personal accounts or unmanaged devices are permitted.
AI use case governance lifecycle
| Stage | Decision content |
|---|---|
| 1. Request | Purpose, owner, users, data, provider and intended output. |
| 2. Assess | Tier, consequence, privacy, security, supplier and legal review. |
| 3. Approve | Controls, terms, exception, residual risk and decision authority. |
| 4. Operate | Configuration, access, monitoring, output review and records. |
| 5. Review or retire | Changes, incidents, assurance, expiry, deletion and exit. |
Tier 1: Pre approved
Low consequence productivity use with public or non sensitive data and no external integration.
Tier 2: Controlled
Business use requiring approved tenant configuration, data rules, named ownership and monitoring.
Tier 3: High consequence
Regulated data, autonomous action, privileged access or consequential decisions requiring multidisciplinary approval.
Decision rights
- Business owner: purpose and consequence
- AI governance: policy, tier and exception authority
- Security and privacy: controls and assurance
- Technology owner: configuration and operation
- Procurement and legal: supplier terms
- Records: evidence and retention
Exception standard
An exception should state the business need, duration, affected data, compensating controls, accountable owner, residual risk and expiry review.
Apply proportionate controls across data, identity, services, outputs and operations
Controls should be selected for the scenario and integrated into existing security, privacy, procurement and records processes.
The control model should cover the full AI use case rather than adding a standalone AI policy beside existing controls. Identity controls determine who can use the service and whether privilege is temporary. Data controls determine what information may enter and how outputs are handled. Provider controls address configuration, retention and training.
| Control domain | Minimum design expectation |
|---|---|
| Inventory and ownership | Record approved and observed services, models, features, agents, owners, purposes, users, data and integrations. |
| Identity and access | Use enterprise identity, strong authentication, least privilege, controlled administration and rapid revocation. |
| Data protection | Define permitted, restricted and prohibited information; apply classification, DLP, encryption and retention controls. |
| Provider and tenant | Assess terms, model use, retention, training, regions, subprocessors, auditability, incident support and exit. |
| Integrations and agents | Limit OAuth scopes, plugins, APIs, repositories, destinations, tools and autonomous actions. |
| Output assurance | Match source checking, validation, disclosure, human approval and record keeping to consequence. |
| Monitoring and response | Detect deviations, investigate cases, revoke access, contain integrations, preserve evidence and improve controls. |
Control objectives
- Know what is used
- Limit what can be accessed
- Protect what is submitted
- Constrain integrations and actions
- Review consequential outputs
- Detect misuse and failure
- Preserve evidence
- Respond and improve
Do not isolate AI governance
Use existing identity, data protection, supplier assurance, security architecture, monitoring, incident response and records processes wherever possible.
Baseline, control and operate in three delivery phases
The roadmap should produce measurable visibility and approved alternatives quickly, then mature through targeted controls and operating evidence.
Days 0 to 30 — Discover and assess
Name the sponsor and accountable owner. Publish interim data and acceptable use rules. Inventory approved and observed services. Identify restricted data and critical processes. Define the initial tiering and exception route.
Days 31 to 60 — Govern and protect
Configure approved enterprise tenants. Review priority providers and integrations. Implement identity, web, endpoint and data controls. Create role based user guidance and awareness. Pilot higher consequence use case assessments.
Days 61 to 90 — Monitor and improve
Reconcile declared and observed use. Implement metrics and case playbooks. Test realistic disclosure and integration scenarios. Integrate AI risk into procurement, privacy, records and incident processes. Refine policy and close the highest priority gaps.
Delivery gate
Each phase should produce current evidence, an accountable owner and management decisions, not only completed activities.
Success indicators
- Material use cases have owners.
- Approved alternatives are usable.
- Restricted data exposure is reduced.
- High risk integrations are reviewed.
- Cases and exceptions close on time.
Implementation principle
Do not wait for perfect enterprise coverage. Protect the highest consequence services and data while coverage expands.
Measure coverage, exposure, adoption, response and enablement
The objective is not to maximize alerts. It is to show whether material AI use is known, controlled and improving.
Inventory
Approved and observed services, features, agents, connectors and named owners.
Control adoption
Approved tenant use, SSO, managed browser, retention and data controls.
Response
Case aging, containment time and repeat exposure.
Enablement
Approval turnaround, approved patterns, training and migration from unsanctioned tools.
- Which AI services and features are in use across the business today?
- What restricted or regulated data could reach an unapproved service?
- Which integrations, connectors or agents hold excessive permissions?
- How are consequential outputs reviewed before they drive a decision?
- Which use cases can trigger autonomous actions or critical operations?
- Who owns each material use case and who can accept an exception or residual risk?
- What are our monitoring blind spots across unmanaged devices, encrypted traffic and unsupported services?
- Can we revoke access, tokens, connectors or agent actions quickly and preserve evidence?
- Are approved alternatives usable enough to reduce the incentive for Shadow AI?
- What changed this quarter in providers, models, terms, integrations, use cases or regulation?
Confirm the minimum evidence for defensible AI use
A checked item should be supported by current evidence, an accountable owner and a defined review cadence.
| Readiness area | Minimum evidence |
|---|---|
| Governance | Sponsor, forum, policy, tiering, risk appetite, exceptions and decision authority. |
| Inventory | Services, models, features, agents, suppliers, owners, purposes, users, data and integrations. |
| Data rules | Permitted, restricted and prohibited information rules aligned to classification, privacy, records and contracts. |
| Approved services | Identity, least privilege, logging, retention, model use, sharing, connectors, regions and administration. |
| Supplier assurance | Security, privacy, subprocessors, incident support, deletion, auditability, service change and exit. |
| Technical discovery | Identity, web, endpoint, browser, SaaS, cloud, data and provider signals with documented limits. |
| Use case assurance | Proportionate AI, privacy, security, legal, records and business assessment for higher consequence use. |
| Output controls | Source checking, validation, disclosure, approval and retention matched to consequence. |
| Incident response | Playbooks for disclosure, unsafe output, compromised integration, excessive permissions and unauthorized action. |
| Metrics and review | Coverage, exposure, control adoption, response, exceptions and enablement reviewed on cadence. |
Priority order
- Material business services
- Privileged or autonomous use
- Restricted or regulated data
- External integrations and agents
- Customer or employee decisions
- Unresolved incidents and exceptions
Evidence standard
Evidence should identify the source, date, owner, scope and result. Screenshots alone may not demonstrate ongoing control operation.
Recognized guidance and practical interpretation
This advisory applies established AI risk, security, privacy and cloud control principles to the specific challenge of unsanctioned enterprise AI use.
01 NIST AI Risk Management Framework
AI RMF 1.0 and supporting playbook. Organizes AI risk work through Govern, Map, Measure and Manage.
02 NIST AI 600 1
Generative Artificial Intelligence Profile, July 2024. Cross sector guidance addressing risks unique to generative AI and corresponding actions.
03 NCSC and CISA secure AI guidance
Guidelines for Secure AI System Development, covering secure design, development, deployment, operation, monitoring, data and prompt documentation, supply chain and user responsibility.
04 ICO AI and data protection guidance
Guidance addressing lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, security and accountability.
05 Cloud Security Alliance AI Controls Matrix
Vendor neutral framework for AI governance, security, privacy and cloud controls.
06 NIST SP 800 218A
Secure Software Development Practices for Generative AI and Dual Use Foundation Models.
07 OWASP LLM guidance
Addresses prompt injection, sensitive information disclosure, excessive agency, insecure output handling and related application risks.
Core interpretation
Shadow AI is not a formal risk category in every standard. The term is used here for AI services, features, agents and integrations operating outside approved governance, configuration, ownership or monitoring.
Advisory scope
This publication provides general, vendor neutral information. Controls should be tailored to the organization's jurisdiction, sector, data, service architecture, threat exposure and risk appetite.