Shadow AI discovery checklist
- Use layered visibility across network/API traffic, SaaS and browser audits, identity/OAuth, endpoint/DLP, expenses, employee reports, and specialized discovery tools.
- Network and API traffic monitoring
- SaaS, browser-extension, and embedded-feature audits
- Identity-provider, SSO, and OAuth review
- Endpoint telemetry and DLP monitoring
Discover shadow AI through layered visibility: monitor network and API traffic, audit SaaS and browser extensions, review identity/OAuth logs, inspect endpoint/DLP signals, analyze expenses, and use employee surveys or specialized tools.
Shadow AI includes AI applications, agents, browser extensions, APIs, local models, and embedded SaaS features used without appropriate organizational approval, monitoring, or security involvement. The goal is not to assume that every unapproved use is harmful. First identify and validate the activity, then assess its exposure and decide whether to approve, restrict, or remove it.
Use layered visibility to discover Shadow AI
No single control provides complete visibility. Network monitoring may miss personal devices or encrypted activity. Expense records may miss free services, while SaaS reviews may not reveal local models, browser extensions, or AI functionality embedded in an approved application. For broader context on the risks, detection, and governance challenges involved, see our Shadow AI security guide.
Combine these discovery channels:
- Network and API traffic monitoring
- SaaS, browser-extension, and application audits
- Identity-provider, SSO, OAuth, and authorization reviews
- Endpoint and DLP telemetry, where available and authorized
- Expense, procurement, and subscription analysis
- Employee surveys, interviews, and sanctioned reporting
- Specialized Shadow AI discovery tools, selected according to your security-stack coverage
Compare the results across sources and investigate discrepancies. A specialized platform may consolidate findings, but it should supplement—not replace—the underlying technical, financial, identity, and employee signals.
1. Define the discovery scope
Do not limit Shadow AI discovery to browser-based chatbots. Include any AI capability used without appropriate organizational approval, monitoring, or security involvement:
- Standalone AI applications and browser-based assistants
- Coding assistants and developer tools
- Browser extensions, plug-ins, and installed AI software
- Local models running on employee or developer workstations
- AI agents with access to business applications
- External APIs, API keys, service accounts, and connected applications
- OAuth grants and other AI-related authorizations
- Model Context Protocol (MCP) connections, where used
- Embedded AI features, add-ons, and integrations inside sanctioned SaaS
- AI-to-application connections and related data flows
- AI capabilities introduced through vendors or supply-chain dependencies
For example, a finding might involve an unapproved chatbot, a coding assistant, an AI transcription service connected to a CRM, an embedded feature in a sanctioned SaaS product, or an agent with broad application access. Each is an investigation signal, not automatic proof of unacceptable use.
2. Build an approved-AI baseline
Start with an inventory of approved AI tools, vendors, use cases, and expected accounts. This gives security, IT, identity, procurement, finance, legal, and business teams a shared comparison point. For a detailed process for structuring and maintaining this inventory, see our AI asset inventory guide.
For each approved capability, record:
- The tool, model, feature, vendor, or connected service
- The business owner and technical owner
- Expected users, accounts, applications, and environments
- The approved business use case
- Permitted data types and relevant restrictions
- Existing identity, endpoint, network, DLP, or SaaS controls
- Known integrations, agents, APIs, and connected applications
This inventory is a baseline, not a detection method by itself. Compare it with observed network connections, installed software, OAuth grants, SaaS configurations, financial records, and employee reports. An item outside the baseline is a candidate for validation, not automatically a policy violation.
3. Monitor network, DNS, gateway, and API activity
Use available and authorized network telemetry to identify connections to AI services, API activity, traffic patterns, data transfers, and associated users. Relevant sources include:.
- DNS and network records
- Proxies, gateways, and firewalls
- Cloud access security broker (CASB) and secure-access telemetry
- API traffic and application-connection records
This layer can reveal direct access to an external AI service or an application sending data to an AI API when the activity does not appear in procurement or SSO records. Treat network results as signals that require confirmation. They do not necessarily reveal prompts, uploads, activity from personal devices, encrypted interactions, or AI functionality embedded in another service.
Look for agent and API behavior
For AI agents and integrations, review API consumers, connected accounts, service accounts, and sequences of calls to business applications. Unexpected consumers, repeated calls, new connections, or multi-step activity can identify an agent or integration that does not appear as a conventional chatbot session. Confirm the agent’s provenance, owner, permissions, and business purpose before taking action. For a structured way to register agents, owners, integrations, and permissions, see our AI agent inventory process.
4. Audit endpoints, browsers, SaaS, and embedded features
Review managed endpoints and browsers
Examine authorized endpoint and browser telemetry for:
- Installed AI applications and local models
- Coding assistants and developer tools
- Browser extensions and plug-ins
- Permissions associated with extensions and applications
- Endpoint and DLP signals for AI-related applications, uploads, prompt activity, or sensitive-data transfers, where available
Endpoint and browser audits can identify local tools and extensions that are not connected to the organization’s identity provider. They still cannot provide complete visibility into unmanaged or personal devices.
Review SaaS applications and embedded AI
An approved SaaS subscription does not mean every feature inside it has been reviewed. Examine sanctioned applications for:
- Embedded AI features and add-ons
- AI agents and automated workflows
- New integrations and AI-to-application connections
- External APIs and connected services
- Data flows between the SaaS platform and AI functionality
- Vendor or supply-chain dependencies that introduce AI capabilities
Review each feature’s permissions, data access, owner, and relationship to the approved use case. This step prevents discovery from overlooking embedded SaaS AI.
5. Review identity, SSO, OAuth, and authorization data
Identity reviews can expose AI access that is missing from ordinary application inventories. Examine authorized records for:. For guidance on governing AI identities, credentials, and authorization throughout their lifecycle, see our AI application identity management.
- Identity-provider and SSO activity
- OAuth grants and connected applications
- Tokens, API keys, and service accounts
- Applications with access to business data or workflows
- Permissions granted to external AI services and integrations
Compare these connections with the approved-AI baseline. An unfamiliar OAuth grant, service account, or API connection should be validated with the user and application owner before access is removed. Determine what the connection can access and whether that access is necessary. For more detail on evaluating scoped access tokens and OAuth grants used by agents, see our guide to OAuth for autonomous AI agents.
6. Analyze expenses, procurement, subscriptions, and email signals
Review corporate-card transactions, procurement records, reimbursements, subscriptions, and other expense data for AI services missing from the approved inventory. These records can reveal paid tools, personal or free-tier accounts used for work, and purchases that bypass SSO or centralized application management.
Authorized email-related discovery can add historical context, including service signups, welcome messages, password-reset messages, or MFA notifications. It will not reveal every use: personal email, nonregistered services, and activity without a corporate payment or account trail may remain outside coverage.
Correlate financial and email evidence with technical and identity findings. A payment or message may not show who used a service, what data it handled, or whether the use was approved.
7. Use employee reporting and specialized discovery tools
Use nonpunitive employee surveys, interviews, sanctioned reporting channels, and authorized user feedback to identify tools and workflows missed by technical or financial telemetry. Employee input can reveal emerging tools, business needs, and gaps in approved alternatives.
Specialized Shadow AI discovery tools may help inventory AI applications, connections, and usage across the organization. Their value depends on the devices, identities, SaaS applications, and other parts of the security stack they can cover. No platform should be treated as a complete answer.
Keep the purpose clear: improve visibility and enable safer work, not automatically punish employees. Any email or user-data review should be authorized, proportionate, and consistent with applicable requirements.
8. Record and validate each finding
A detection signal is not the same as confirmed organizational use. Before classifying a finding as Shadow AI or removing access, record:
| Inventory field | What to capture |
|---|---|
| Finding and evidence | Tool, feature, agent, integration, source, timestamp, and observed signal |
| Owner and purpose | User, team, application owner, vendor, and stated business need |
| Access and data | Permissions, connected applications, data types, and observed transfers |
| Status | Approved, pending validation, restricted, remediated, or false positive |
| Decision | Approval, control change, sandboxing, removal, or escalation |
Confirm which user, team, application, account, or vendor is involved; whether the activity was work-related; whether it is current or historical; and whether the capability is already approved. Then assess its permissions, connected applications, data movement, and business purpose.
Do not inspect prompt contents unless doing so is legally authorized, necessary, and proportionate. Use the least intrusive evidence that can answer the investigation.
9. Assess risk and choose a proportionate response
After validation, consider:
- Data exposure: What information was accessible or transferred?
- Permissions: What can the tool, agent, integration, or account access?
- Activity: What use occurred, and is it ongoing?
- Business purpose: Is there a legitimate workflow that needs support?
- Vendor practices: What is known about the service and its handling of organizational data?
- Control gaps: Which approval, identity, endpoint, SaaS, or monitoring controls were missing?
Use those factors to decide whether to:
- Approve the use case and document its controls
- Restrict permissions or reduce access
- Place the capability in a controlled sandbox
- Remove an unnecessary integration or authorization
- Provide a sanctioned alternative for the business need
- Escalate the finding for additional security, legal, or business review
For example, an unfamiliar OAuth grant might be confirmed as a legitimate team integration with excessive permissions. The appropriate response could be to document the owner, reduce the grant, and monitor the approved use—not remove access without validation. A confirmed transfer of sensitive data to an unapproved service would require a more urgent review and remediation.
Discovery should precede governance and remediation. Use the findings to make informed decisions rather than blocking indiscriminately.
10. Make Shadow AI discovery continuous
AI tools, integrations, agents, and employee workflows change over time. Establish recurring:
- Network, endpoint, browser, SaaS, identity, and authorization reviews
- Expense, procurement, subscription, and reimbursement checks
- Investigations for new or unusual findings
- Updates to the approved-AI inventory
- Risk reassessments when permissions, vendors, or use cases change
- Employee reporting and formal AI intake or escalation routes
Document coverage limitations involving personal accounts, personal or remote devices, encrypted traffic, and embedded functionality. Keep monitoring proportionate, respect employee privacy and applicable requirements, and apply appropriate access controls.
Shadow AI discovery coverage checklist
| Discovery source | What it can reveal | Likely blind spot |
|---|---|---|
| Network and API telemetry | Connections to AI services, API activity, and some data transfers | Personal devices, encrypted traffic, and embedded services |
| Endpoint and browser audits | Installed AI software, coding tools, local models, extensions, and plug-ins | Unmanaged devices and incomplete endpoint coverage |
| Identity, OAuth, and SaaS reviews | External access, connected applications, embedded AI, agents, and integrations | Non-SSO accounts and undocumented vendor functionality |
| Financial and procurement records | Paid services, subscriptions, reimbursements, and purchases | Free services and activity without a corporate payment trail |
| Employee input and discovery tools | Unreported tools, workflow needs, and usage missed by telemetry | Incomplete reporting or limited platform coverage |
The practical sequence is: discover broadly, validate the finding, assess data and access risk, then govern or remediate it. Layered visibility provides stronger coverage than any single tool while keeping monitoring privacy-aware and proportionate.






