Shadow AI discovery finds AI tools, accounts, integrations and workloads operating outside your approved scope. Before migrating vendors, reconcile identity, endpoint, network and billing evidence. Confirm owners and permissions, preserve necessary workflows and document the blind spots that prevent a claim of complete coverage.
This guide covers broad AI-tool discovery. Use the MCP server discovery guide for its narrower server and client-configuration workflow.
Last verified: October 27, 2026. Product capabilities follow the linked documentation; the register and reconciliation method are our proposed assessment workflow.
Disclosure: ASCENDING Inc develops Jarvis Crosswalk for AI tool migration assessments. Confirm current collection coverage and delivery scope before relying on a particular capability.
Shadow AI discovery needs several evidence sources
A licensed-seat export describes approved purchases. It may miss an engineer’s personal account, a local assistant or a service using an API key.
Conversely, an AI-related network event may be routine browsing rather than a production dependency. Treat observations as evidence to investigate, then confirm the workflow and approval state.
| Evidence source | Useful signal | Important blind spot |
|---|---|---|
| Identity and SSO | Managed users, applications and sign-ins | Personal accounts or unmanaged authentication |
| Endpoint inventory | Installed clients, extensions and local processes | Unmanaged devices and inactive installations |
| Network telemetry | Observed destinations, users and traffic within coverage | Offline models, bypass routes and ambiguous shared domains |
| Procurement and billing | Paid seats, reimbursements and API spend | Free tools, shared invoices and unused purchases |
| Repository and integration review | SDK dependencies, MCP configuration and credential references | Uncommitted local settings and dormant code |
| Owner interviews | Actual purpose, critical workflows and manual steps | Incomplete recall or undocumented dependencies |
Microsoft’s Global Secure Access documentation describes network-based discovery of AI applications, model-provider APIs and SaaS MCP servers. Its visibility depends on the traffic analyzed by that service.
Use the signal alongside other sources. Don’t turn the capabilities of one sensor into a statement about every device and account in your organization.
Build a shadow AI discovery register
Shadow AI discovery starts with a bounded population
Write down the departments, managed devices, repositories, accounts and observation period included in the assessment. Name the systems you couldn’t inspect.
For example, an engineering review might cover company-managed laptops and two GitHub organizations during the preceding month. Personal devices and a recently acquired subsidiary could remain explicitly outside coverage.
Agree on collection access, retention and permitted fields before exporting evidence. Most inventory work starts with metadata; collecting full prompts or source files isn’t necessary for every discovery question.
Keep an observation separate from the asset it describes
One application can appear in many logs. One vendor can also contain several tenants, personal accounts and API projects with different owners and controls.
Use separate identifiers for the vendor, service, tenant or account, workflow and observation. Keep the original evidence reference so a reviewer can trace the match.
| Register field | Purpose |
|---|---|
| Asset and account identifier | Distinguishes a company tenant from personal use of the same vendor |
| Workflow and owner | Explains the work and assigns accountability |
| Observed source and time | Shows where the finding came from |
| Approval scope | Records approved purpose, data and users |
| Data and permissions | Identifies classification and reachable resources |
| Integration references | Links connectors, repositories, tools and credential identifiers |
| Confidence and open question | Separates confirmed use from an ambiguous observation |
| Disposition and reviewer | Tracks retain, replace, retire or investigate |
Store credential references rather than secret values. Where a field is unknown, preserve that status instead of filling it with an assumed owner.
Reconcile observed use with approved scope
Normalize vendor and service names, then join observations using stable account, application, device or repository identifiers where available. A fuzzy domain match should remain reviewable.
Classify each finding:
- Approved and in scope: the account, workflow and data use match the recorded approval.
- Approved tool, different use: the vendor is allowed, but a personal account, new integration or broader data use needs review.
- Unapproved use: an owner confirms activity outside current approval.
- Unresolved observation: evidence is insufficient to establish the account or workflow.
This avoids treating “we approved Vendor A” as approval for every account and integration using that vendor.
Microsoft Defender for Cloud Apps documentation notes that apps outside its catalog aren’t discovered by default. Record catalog coverage and custom-app handling when assessing a discovery tool.
GitHub’s OAuth-app review guide provides a complementary account-level check for authorized applications. Review the permission grant and owner, rather than inferring access from an application name.
A worked example: one vendor, two different workflows
Suppose an approved coding-assistant tenant has fifty licensed users. Network records also show the same vendor used from five additional managed laptops.
Interview the owners and inspect the relevant account metadata. Three users may have unassigned personal accounts, one event may be a documentation visit, and one device may run a team-owned API integration.
Those findings need different actions. The personal accounts need an approval and data-handling review. The documentation visit may require no migration action. The integration needs an owner and replacement plan.
These counts are illustrative, not observed customer data. The example shows why subtracting seat counts from network users doesn’t produce a reliable shadow-AI total.
Prioritize exposure and preserve needed workflows
Review findings with the data owner and technical operator. Prioritize reachable sensitive data, broad permissions, external actions and missing ownership.
An unused extension and a scheduled job writing customer records shouldn’t receive the same response solely because both are unapproved.
| Finding | Next action | Migration implication |
|---|---|---|
| Useful workflow with narrow access | Review and approve or propose a replacement | Add acceptance criteria for the replacement |
| Broad connector grant | Confirm owner and reduce or revoke access through the proper process | Rebuild least-privilege access before cutover |
| Unknown owner | Escalate to the accountable system or department owner | Keep the dependency unresolved |
| Retired tool still active | Verify jobs, sessions and credentials | Complete removal tests and preserve required records |
| Local skill or rule library | Review files and actual activation | Map behavior, references and installation paths |
The NIST AI Risk Management Framework supplies a broader structure for governing and managing AI risk. This register is a practical assessment aid, not a certification or a validated risk score.
Use AI identity governance when a discovered workload has independent credentials. Use Cursor rules vs AGENTS.md when a required workflow depends on local instructions.
Measure shadow AI discovery coverage
Report the denominator alongside the findings: managed devices reporting, identity sources connected, repositories reviewed and departments whose owners responded.
Keep those denominators separate. Device coverage isn’t the same as employee coverage, and neither proves you observed every account or offline workload.
Useful outputs include confirmed assets with owners, unresolved accounts, high-impact permission gaps and workflows requiring a migration decision. Repeat collection after remediation to check for continued activity.
Don’t report “100% of AI discovered” unless you can define and independently enumerate that population. A defensible result says what was observed, where, during which period and with which gaps.
Where Jarvis Crosswalk fits
A migration assessment should turn confirmed findings into an inventory of workflows, proposed replacements, blocked items and acceptance tests. Discovery evidence establishes what needs assessment; it doesn’t establish automatic portability.
We build Jarvis Crosswalk at ASCENDING Inc. Confirm its current collection sources, outputs and delivery scope through our contact page. Don’t assume a universal scanner or automatic migration.
Continue with the coding-agent migration readiness assessment for the cutover plan. If GitHub Copilot is a candidate, use the Copilot readiness assessment to define the repository and feature scope of its pilot.
References
- Microsoft Entra: shadow AI discovery in Global Secure Access
- Microsoft Defender for Cloud Apps: discover and manage shadow IT
- GitHub: review authorized OAuth apps
- NIST AI Risk Management Framework
Shadow AI discovery questions before switching tools
What is shadow AI discovery?
It's the process of finding AI tools, accounts, integrations and workloads used outside an organization's approved scope. Reconcile several evidence sources, confirm owners and permissions, and document what your collection method can't observe.
Can SSO logs find every AI tool employees use?
No. They cover the identity paths you manage. Personal accounts, local software, direct API keys and activity outside those paths can require endpoint, network, billing or owner-confirmation evidence.
Does a connection to an AI domain prove sensitive data was uploaded?
No. A network event establishes observed communication within the sensor's coverage. Content, account, purpose and data classification need additional evidence before you conclude that a disclosure occurred.
How do we inventory AI tools before switching vendors?
Define the population and observation period, collect approved identity, endpoint, network and spend records, join them to the approved inventory, then confirm unmatched use with owners. Classify each workflow for retention, replacement, retirement or further investigation.
