Security team reviewing Shadow AI discovery signals across organizational systems

How to Discover Shadow AI in Your Organization: A Practical Checklist

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 fieldWhat to capture
Finding and evidenceTool, feature, agent, integration, source, timestamp, and observed signal
Owner and purposeUser, team, application owner, vendor, and stated business need
Access and dataPermissions, connected applications, data types, and observed transfers
StatusApproved, pending validation, restricted, remediated, or false positive
DecisionApproval, 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 sourceWhat it can revealLikely blind spot
Network and API telemetryConnections to AI services, API activity, and some data transfersPersonal devices, encrypted traffic, and embedded services
Endpoint and browser auditsInstalled AI software, coding tools, local models, extensions, and plug-insUnmanaged devices and incomplete endpoint coverage
Identity, OAuth, and SaaS reviewsExternal access, connected applications, embedded AI, agents, and integrationsNon-SSO accounts and undocumented vendor functionality
Financial and procurement recordsPaid services, subscriptions, reimbursements, and purchasesFree services and activity without a corporate payment trail
Employee input and discovery toolsUnreported tools, workflow needs, and usage missed by telemetryIncomplete 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.