Shadow AI: discover and govern unsanctioned AI use
Shadow AI can expose data and create uncontrolled workflows. Discover tools, assess use-case risk and give employees secure, practical alternatives.
- AUTHOR
- Karol Rapacz / Penetration Tester (OSCP, PNPT)
- PUBLISHED
- 29 June 2026
- READING TIME
- 9 min read
- TOPIC
- AI Governance
Shadow AI is the use of models, assistants and AI features outside an organisation’s approved process. Examples include a free chatbot receiving customer data, an API key bought on a team card, a browser extension or AI silently enabled by a SaaS supplier.
Blocking domains alone does not solve the issue. Employees use these tools because they help complete real work. A programme must discover risk while providing a safer route.
What to discover
Combine secure web gateway, DNS, CASB, SSO, OAuth catalogue, repository, expense and DLP signals. Look for model API calls, document uploads, new extensions and supplier tokens in code.
No source is complete. Traffic may pass through an AI feature in an approved application, a personal device or an intermediary backend. Supplement telemetry with anonymous surveys and team interviews.
Assess the use case, not the logo
The same tool may be acceptable for public copy and prohibited for medical records. For each use, determine:
- input data and expected output;
- retention, training use and region;
- owner and people affected by decisions;
- integrations, tools and autonomy;
- impact of an incorrect result or leak;
- available logs, deletion and account controls.
Record the outcome in the AI model registry.
Four possible decisions
Approve when terms and risk are acceptable. Restrict the tool to named data or users. Migrate work to a managed alternative. Block when high risk cannot be controlled.
Document the reasoning and review date. Suppliers change models and terms, so approval cannot be permanent.
A safe alternative beats a ban
Provide an approved assistant with SSO, contractual terms, retention controls, clear data categories and support. Add a simple intake route for new uses and a rapid pilot path.
Training should use concrete examples: code containing secrets, customer data, non-public documents and HR decisions. “Do not enter sensitive data” is hard to apply without classification.
Technical controls and privacy
DLP can warn or block uploads of defined data. OAuth governance constrains excessive consent, while egress controls manage API keys. Do not capture every prompt without a legal basis, access boundaries and retention.
Use graduated responses: education, warning, restriction and high-risk blocking. False positives need a fast review path.
What to measure
Measure discovery-to-decision time, activity migrated to approved tools, sensitive-data upload cases, active keys without owners and time to assess a new use case. A raw number of blocked requests does not show risk reduction.
Shadow AI signals a gap between user needs and organisational controls. The strongest programme uses that signal to build approved services as convenient as bypassing the process.
Discover use without reading employee content
Start with SaaS domains and applications, proxy and SSO logs, spend data and team interviews. The goal is a flow and data-class map, not reading every prompt. Record the use-case owner, provider, model, input data, output consumers, retention and whether submitted data may be used for training.
A blanket ban pushes use out of sight. A safer programme offers approved tools, clear data classes and a fast review path. Test export, integrations, service accounts and deletion procedures. Risk changes with service configuration, so review must recur.
Define an exit path: configuration export, data deletion, token revocation and identification of model-dependent processes. The business owner confirms purpose and output quality; security confirms data and integration boundaries. Approval for one use does not approve the provider for every data class.
Sources: NIST AI RMF, NIST GenAI Profile, OWASP GenAI Data Security.
