Shadow AI Detection
Authored by Emmanuel Guilherme Jr. · Last reviewed 2026-05-01
Objective
Detect, triage, and remediate use of unsanctioned AI services and unauthorized AI tooling by employees, contractors, and other authorized users, with documented response and metrics.
Applicability
- AI types
- LLM, Agentic AI, Generative AI, Multi-modal, Traditional ML
- Deployment models
- SaaS, Self-hosted, Hybrid
- Lifecycle stages
- Operation & Monitoring
- Risk domains
- Governance, Data, People & Process
- Regulatory regimes
- EU AI Act, GDPR, ISO 42001, Banking, Healthcare
- Company size
- MidMarket, Enterprise
Rationale
Shadow AI is the #1 AI risk on most CISO desks: employees pasting sensitive data into consumer AI services, installing browser extensions, signing up for free tiers with personal accounts, or building API-based agents outside sanctioned environments. The combination of low friction and high productivity makes Shadow AI inevitable; the only viable response is detection-plus-graduated-response. Sectoral regulators (OSFI, NYDFS) and GDPR enforcement bodies are increasingly examining Shadow AI controls.
Control narrative
The organization maintains technical and process controls to detect Shadow AI use across managed endpoints, networks, and cloud-app activity. Detection sources include: network egress to consumer AI service domains, endpoint process / browser-extension telemetry, DLP triggers on data egress to AI services, CASB/SaaS-discovery for unsanctioned subscriptions, identity-provider analytics for newly authorized AI applications. Detections route through documented runbooks producing graduated response: first-occurrence comms (education + approved-tool path); repeat-occurrence escalation; confirmed sensitive-data egress incident response. Approved-tool launch communications precede enforcement to give users a constructive path. Program metrics (detection volume, time-to-respond, repeat rate, conversion to approved tools) are reported quarterly to the AI Governance committee. The control references the Shadow-AI-Defense detection library and runbooks for implementation depth.
Test of Design
Procedures
- Obtain the Shadow AI Detection standard and confirm detection sources, runbook coverage, and metrics.
- Confirm graduated response (education, escalation, incident) with documented criteria.
- Confirm approved-tool launch precedes enforcement (rollout sequencing).
- Confirm metrics, reporting cadence, and accountable owner.
- Confirm integration with the AI Acceptable Use Policy (AI-CTRL-016) and Incident Response (AI-CTRL-009).
Inquiries
- Who owns Shadow AI detection?
- How is the consumer-AI watchlist maintained as new services emerge?
- How are personal-device and BYO-API-key channels addressed where direct technical detection is limited?
- How are repeat offenders escalated?
Inspections
- Shadow AI Detection standard.
- Detection rule inventory.
- Runbook samples.
- Quarterly metrics reports.
- Approved-tool launch communications.
Test of Operating Effectiveness
Procedures
- For the audit period, obtain the population of Shadow AI alerts.
- Sample alerts and confirm runbook execution per the standard.
- Confirm communications were sent per the appropriate stage (first / repeat) within documented SLAs.
- For confirmed sensitive-data egress events, confirm escalation to AI-CTRL-009 IR runbooks.
- Confirm quarterly metrics reports are produced and reviewed.
- Independently corroborate detection completeness by sampling a small set of consumer AI services and confirming they appear on the watchlist.
Sample-size guidance
| Population | Shadow AI alerts in audit period |
|---|---|
| Low risk | 25 alerts |
| Moderate risk | 60 alerts |
| High risk | 150 alerts or 100% of high-severity / sensitive-data egress events |
Evidence requirements
Required
- Shadow AI Detection standard PDF/Word · At fieldwork
- Detection rule inventory and configurations System export · At fieldwork
- Runbook samples and execution records PDF/system · Per sample
- Quarterly metrics reports PDF/Excel · Quarterly
Supporting
- Consumer AI watchlist with last-updated timestamps CSV/JSON · Monthly
- Approved-tool launch communications Email/portal · Per launch
Retention: 7 years for regulated environments; 3 years otherwise
Framework mappings
| Framework | References |
|---|---|
| ISO 42001 | 8.2, 8.4 |
| NIST AI RMF | GOVERN-4.1, MANAGE-2.2, MANAGE-4.1 |
| EU AI Act | Article 4 |
| OWASP DSGAI | DSGAI20, DSGAI21 |
| SOC 2 | CC6.6, CC6.7, CC7.1 |
| MITRE ATLAS | AML.T0010 |
| osfi_e21 | Principle 1, Principle 4 |
| nydfs_500 | 500.02, 500.14 |
Related controls
Changelog
- v1.0.0 · 2026-05-01 · Initial publication.