Start with inventory. Identify installed AI-enabled apps, browser extensions, SaaS features, and OAuth-connected services in each tenant, then compare them against approved software and consent settings. That gives you a practical discovery baseline and shows where unreviewed AI may already have access to client data.
What “shadow AI” looks like in an MSP client estate
For an MSP, shadow ai is usually not one thing, it is a mix of unsanctioned apps, embedded AI features, unmanaged browser extensions, and third-party services connected through OAuth or API grants. The practical question is whether the client environment contains AI capabilities that were not approved, reviewed, or recorded in the service desk, procurement, or security baseline.
The discovery problem is wider than just named chatbots. A tenant may already contain AI-enabled SaaS features that were turned on by users, browser add-ons that can read page content, or integrations that can reach mail, files, tickets, or CRM records. The inventory therefore has to cover the software layer and the consent layer together, because one without the other misses the access path.
That is why discovery works best when you classify what is present, where it runs, and what it can reach. In practice, that means mapping installed software, sanctioned app catalogs, identity consent records, and network or endpoint telemetry into one view. Shadow AI and AI Agent Discovery Guide is the clearest starting point for that workflow because it ties discovery to OAuth grants, API keys, endpoint signals, and governance follow-up.
How to build a repeatable discovery baseline
Start with a tenant-by-tenant inventory, then compare each finding against approved software lists, user consent settings, and admin-approved AI services. That comparison is what turns a raw list of tools into a usable shadow AI baseline, because it separates sanctioned use from unreviewed use and shows where the client has already accepted exposure without meaning to.
Use multiple discovery paths, not one. Endpoint and browser visibility will surface locally installed apps and extensions, but SaaS admin portals and identity logs often reveal AI features or connected services that never appear on the endpoint itself. In cloud and SaaS-heavy environments, the consent record is often the strongest signal because it shows which services already hold delegated access.
Look specifically for gaps between “installed” and “authorised.” A tool may be blocked on paper but still reachable through a browser extension, a personal account, or a user-granted OAuth connection. Vercel Context.ai OAuth Supply Chain Breach is a useful reminder that a single unmanaged third-party grant can become the real exposure point, even when the application itself seems ordinary.
For MSP operations, the baseline should be normalised across tenants so you can compare clients without losing local context. One client may only need app inventory and browser inspection, while another also needs SaaS consent review, mailbox add-ins, and cloud app governance. The more consistent the collection model, the easier it is to spot outliers that deserve escalation.
Which signals matter most when you are hunting shadow AI
The strongest signals are usually not the AI brand name itself, but the access pattern around it. OAuth consent to unfamiliar apps, unusual API token creation, newly installed browser extensions with broad read permissions, and SaaS features that forward content to external AI services are all more actionable than a generic list of “AI tools” in use.
Watch for services that can reach client data but sit outside the approved software estate. That includes note-taking tools, productivity suites with built-in copilots, file summarisation add-ons, customer support plugins, and AI assistants embedded in collaboration platforms. When those services are connected by delegated access, they can silently expand the blast radius of a single user decision.
Shadow AI also appears in the form of data leakage, not just unauthorised installation. Prompt content, uploaded files, copied meeting notes, and connected inboxes can expose confidential material even when the user believes they are only “trying out” a helpful feature. OmniGPT breach claim 2025 illustrates why MSPs should treat chat platforms and connected credentials as a discovery target, not only as a policy issue.
Risk and Threat Considerations
Shadow AI becomes risky when it can ingest tenant data, retain it outside approved controls, or hold delegated access that outlives user intent. The main exposure is not just unsanctioned software, it is unmanaged authority over mail, documents, tickets, and other business records that clients assume remain inside approved boundaries.
Failure mechanism: Users connect AI-enabled tools or extensions through OAuth, API keys, or embedded SaaS features that bypass normal procurement and review, then those connections persist after the initial test or pilot.
Impact: Client data can be copied into external services, retained in conversation history, or exposed through overbroad delegated access, creating confidentiality, compliance, and incident-response problems that are difficult to unwind quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Shadow AI detection starts with identifying installed and approved software across client tenants. |
| CIS-6 — Access Control Management | OAuth grants and consent settings determine which AI services can reach client data. | |
| Recommendation — Inventory software assets continuously and flag unapproved AI-enabled apps and extensions. Review and revoke excessive delegated access for AI-connected services. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Are Inventoried | Client-side discovery of AI apps and extensions depends on a current asset inventory. |
| PR.AA-05 — Access Permissions and Authorizations Are Managed, Incorporated, and Updated as Needed | Shadow AI often appears through overbroad OAuth consent and app authorizations. | |
| Recommendation — Maintain a current inventory of endpoints, browsers, and SaaS-connected assets. Review and update app authorizations and consent scopes for AI-connected services. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud tenants expose shadow AI through app consent, delegated access, and service permissions. |
| Recommendation — Govern cloud app consent and delegated access for AI-enabled services. | ||
Practitioner Guidance
What to verify: Confirm three things for every tenant: what AI-capable tools are present, which ones have delegated access, and whether the consent was approved by an authorised owner. If any of those three is missing, treat the item as unreviewed rather than merely “unlisted.”
What to prioritise: Start with identities and consents that can reach sensitive data, then work outward to browser extensions and local apps. A low-friction tool with broad OAuth scope is usually a higher-priority issue than a visible chatbot with no data access.
Decision rule: If the tool can read mail, files, tickets, or CRM data, do not wait for proof of misuse before escalating. Revoke or narrow access first, then validate whether the use case is acceptable and whether the client wants it sanctioned under policy.
Practitioner takeaway: The best shadow AI detection program is a consent-aware inventory, not a point-in-time app scan, because delegated access is often where the real exposure begins.
Related resources from NHI Mgmt Group
- How should MSPs discover shadow IT across client environments?
- How should MSPs govern device, SaaS, and AI sprawl across client environments?
- How should MSPs standardise identity controls across multiple client environments?
- How should MSPs govern technician access across multiple client environments?