Back to the CIO and CSO starting point Security and GRC hub
Shadow AI: How to Find It and What to Do About It
Shadow AI is AI technology that staff use outside an organization's approved systems and processes. Lightbridge treats it as a visibility problem before a policy problem. Security teams find it through six signals: identity grants, CASB logs, network egress, browser extensions, spend records, and endpoint DLP. Each signal sees only part of the picture.
This page walks a CIO or CSO from the six signals to a 30-day discovery sequence, then to the approved-tool list, account rules, and evidence that follow. Vendor and standards statements are attributed and linked in the sections below, and the FAQ answers draw on the same sources. Vendor documentation was reviewed on 2026-11-03. Lightbridge does not recommend a vendor here.
How Lightbridge defines shadow AI, and what counts.
The UK NCSC describes shadow AI as AI technology not captured in an organisation's approved systems and processes, a form of shadow IT (NCSC blog, 7 September 2026). Its shadow IT guidance names unmanaged AI services, such as chatbots used with corporate data, as one case.
In practice, four things qualify. A personal account on a public AI service. An AI app that an employee connected to company data through OAuth. A browser extension that reads page content. An AI feature switched on inside a licensed product nobody reviewed. The NCSC blog warns that sensitive information sent to consumer AI services may be stored, retained, or used to improve the service unless specific privacy controls are in place, which reduces the organisation's visibility and control.
The same NCSC blog says that when policy lags, staff reach for tools the organisation has not approved. That is the useful insight for a CIO. Most shadow AI is a sign of unmet demand, and a good response treats it that way.
The discovery signals Lightbridge uses, and what each can and cannot see.
No single signal finds everything. The table lists six, with the admin feature or log each vendor documents and the limits the vendor or the NCSC states. Cells say what the source states. Where we found no primary documentation, the cell says so.
| Signal | Documented admin feature or log | What it can see | What it cannot see |
|---|---|---|---|
| SSO and OAuth grants | Microsoft Entra: Enterprise apps, All applications, Permissions (Admin consent and User consent tabs), plus Graph queries on oauth2PermissionGrants and appRoleAssignments (source). Defender for Cloud Apps: OAuth apps page (source). Google Admin console: Manage App Access, Accessed apps, and Reporting, OAuth log events (source, source). Okta ISPM with the Secure Access Monitor plugin (source, source). | Microsoft states the Defender page shows which user-installed OAuth apps hold access to Microsoft 365, Google Workspace and Salesforce data, with permissions and who authorized them. Google states Accessed apps lists user counts and requested OAuth2 scopes, with details typically 24 to 48 hours after authorization. Okta states its plugin captures grants users make in managed browsers and tags AI-related grants. | Microsoft states Defender identifies only apps requesting delegated permissions, on connected platforms, and that revoking a grant does not stop re-consent unless the user-consent setting blocks it. Google states the default for unconfigured third-party apps lets users sign in to any app. Okta states the plugin works only on managed browsers. Lightbridge's reading: AI use with personal credentials is likely outside the Entra and Defender views, because they report on grants within the organization's tenant and connected platforms. |
| CASB and SWG category logs | Defender for Cloud Apps Cloud Discovery (source). Netskope Skope IT Transaction Events and Page Events, and the Cloud Confidence Index (source, source). Zscaler ZIA Shadow IT Report, under Data Security, Inline CASB, Shadow IT (source). | Microsoft states Cloud Discovery analyzes traffic logs against a catalog of over 31,000 cloud apps scored on more than 90 risk factors, updated four times a day for continuous reports. Zscaler states its report breaks apps down by sanctioned, unsanctioned, unclassified or under review status and includes an AI and ML Applications category. Netskope states its Cloud Confidence Index scores apps from 0 to 100. | Microsoft states Defender cannot discover apps outside its catalog by default. Netskope states Application Events under Risk Insights are limited for lack of data to detect app activities. The NCSC states CASBs, without intercepting encrypted connections, cannot identify unapproved use of approved services such as personal accounts. Netskope's documentation we reviewed does not name a specific shadow AI category. |
| Firewall and proxy egress logs (DNS: not documented) | Firewall and proxy logs forwarded to Defender for Cloud Apps through a log collector or supported gateway (source). Named DNS query logs: Not stated in the documentation we reviewed. | Microsoft publishes a per-appliance table of which log fields each firewall or proxy source supplies, such as Target App URL, Target App IP, Username, and Uploaded bytes. | Microsoft's table shows some sources supply IP only. For example, Check Point supplies Target App IP and Origin IP but not Target App URL or Username, and Cisco ASA over Syslog supplies no Target App URL or Username. Lightbridge's inference: IP-only sources limit app and user attribution. DNS-specific visibility limits: Not stated in the documentation we reviewed. |
| Browser extension inventory | Google Admin console: Devices, Chrome, Reports, Apps and extensions usage (source). Microsoft Edge and Intune extension inventory: Not stated in the documentation we reviewed. | Google states admins can see apps and extensions installed on enrolled Chrome browsers and ChromeOS devices, with install type, Chrome Web Store status, install counts, and the permissions requested. From the report an admin can block an app or force install it. | Google states reporting must be turned on, data can take up to 24 hours to appear, and only enrolled browsers and devices are covered. Unenrolled browsers are outside the report. |
| Expense and procurement data | Card, expense-report, and accounts-payable feeds: Not stated in the documentation we reviewed. | Not stated in the documentation we reviewed. The NCSC lists "not being able to request assets or services through a corporate system" as a cause of shadow IT, but does not describe expense data as a detection signal. | Not stated in the documentation we reviewed. Lightbridge treats this signal as a cross-check for paid tools only, and has no vendor documentation to cite for its limits. Lightbridge's suggestion: export card merchant names and accounts-payable vendor names, then match them against the AI apps found through the other signals. |
| Endpoint DLP and endpoint network telemetry | Microsoft Purview Endpoint DLP, with allowed and unallowed service domain lists (source). Defender for Endpoint integration with Defender for Cloud Apps, under Settings, Endpoints, General, Advanced features (source). | Microsoft states Endpoint DLP can detect, and block, warn or audit, an upload to a restricted service domain and a paste to a restricted service domain. It states the Defender for Endpoint integration uses network transaction logs for discovery across Windows devices and needs no extra traffic routing. | Microsoft states devices must be onboarded, so unmanaged devices are outside both. It states Endpoint DLP cannot scan data never saved to a file on the device, and that macOS coverage for the integration audits only TCP connection close events, so UDP is not covered. |
Vendor documentation reviewed 2026-11-03. The sources we reviewed state no detection accuracy, false positive, or false negative rates for any signal. Treat every signal as a partial view and compare two or more against each other.
The first 30 days: a discovery sequence Lightbridge advises security teams to run.
This sequence uses tools most security teams already license. Several of the signals above lag, so start the slow ones first.
- Days 1 to 3: set the stance and the owner. Name one accountable owner and write down who approves tools, who grants exceptions, and who reports to the board. Announce a no-blame approach, as the NCSC advises, because punishing early adopters makes peers stop reporting. Tell staff discovery is under way and an approved route is coming.
- Days 1 to 5: switch on the slow signals. Turn on Chrome Apps and extensions reporting (Google says data can take up to 24 hours). Enable the CASB or gateway discovery you already license. If you run Defender for Endpoint, enable the Defender for Cloud Apps integration (Microsoft says data can take up to two hours).
- Days 3 to 10: pull the grants. Export OAuth grants from your identity provider: Entra enterprise app permissions, Google Accessed apps as CSV, or Okta ISPM. Sort by number of users and by scope breadth. Flag every AI-related app.
- Days 8 to 14: check the consent settings. Look at what your tenant lets users approve. Microsoft states revoking a grant does not stop re-consent, and Google states the default for unconfigured third-party apps is permissive. Decide whether to restrict consent now or after the approved list exists.
- Days 10 to 18: classify what you found. Sort each AI tool into approved, approve-with-conditions, replace, or block. Record the data each tool touches. Zscaler's sanctioned, unsanctioned, unclassified, and under review statuses are one workable vocabulary.
- Days 14 to 22: find the embedded AI. List the licensed products with AI features and read each admin console. Record which are on by default and which can be switched off by group.
- Days 20 to 26: talk to the heaviest users. Take the top five apps from the grant export and interview the teams behind them. Ask what job the tool does and what data goes into it. The NCSC says understanding why staff use shadow AI lets you offer a secure alternative.
- Days 26 to 30: publish and report. Publish the first approved-tool list and the request path. Brief the board from one page: AI apps found, how many are approved, how many closed, and which signals still have no coverage.
The timings are Lightbridge's planning judgment. They are not drawn from a vendor or standards source.
The policy side: what Lightbridge puts in place alongside discovery.
An approved-tool list and a request workflow
Policy sources reviewed 2026-11-03.
NIST AI 600-1 (July 2024) action GV-6.1-007 recommends inventorying all third-party entities with access to organizational content and establishing approved generative AI technology and service provider lists. GV-6.1-010 recommends updating acceptable use policies to cover proprietary and open-source generative AI and the contractors, consultants, and other third-party personnel who use it.
Washington State's 2023 interim guidelines describe one gate. Where non-public data is involved, agencies should not acquire generative AI services, sign vendor agreements, or use open-source generative AI without a Security Design Review and prior written authorization (WaTech, adopted August 8, 2023). The same document encourages leaders to keep a list of their generative AI uses and use cases. Beyond these statements, we found little primary guidance on intake forms, review timelines, or tiering by data class. WaTech's AI resources page now links a statewide Artificial Intelligence Policy (DATA-04, December 2025) that we did not fetch or review, so the 2023 guidelines may be superseded. Check the newer policy first. Lightbridge designs intake, review timelines, and data-class tiers per client.
Personal accounts versus enterprise accounts
Harvard's security guidance says to use the institution-offered version of a service rather than a personal or consumer account, and to avoid personal or consumer AI accounts for institutional business unless explicitly permitted (Harvard). Vendor terms explain the reason. OpenAI states it may use content from its individual plans (Free, Plus, Pro) to train its models unless the user opts out, and that on those plans, submitting thumbs up or down feedback means the whole conversation may be used for training even after opting out. It states that by default it does not use inputs or outputs from ChatGPT Business, Enterprise, Edu, or its API to improve its models (OpenAI). For ChatGPT Enterprise, Edu and Healthcare, OpenAI states workspace admins control retention and can reach an audit log through the Enterprise Compliance API (OpenAI).
Consumer-tier terms for Google Gemini apps and Microsoft consumer Copilot: Not stated in the documentation we reviewed. Check them before you write a rule that depends on them. Lightbridge reviews terms by vendor and tier, then sets the policy by data class.
Embedded AI that is on by default
Licensed SaaS can add AI without a procurement event. Google states the default setting for Gemini features in Workspace services is on, and that admins on supported editions can turn Gemini on or off per service under Generative AI, Gemini for Workspace, Feature access, scoped by organizational unit or group. Google also states that turning Gemini off in one app does not stop users reaching that app's data through Gemini in other apps, and that the Gemini app toggle has no effect on other AI features in Workspace services (Google).
Microsoft states admins can decide whether to use third-party models from Anthropic and OpenAI to power Copilot experiences, and can select which agents are allowed in the organization from the Integrated apps section of the Microsoft 365 admin center. It also states that if connected experiences that analyze content are off on devices, Copilot features will not be available in Excel, OneNote, Outlook, PowerPoint, and Word (Microsoft). Admin steps for other embedded AI, including Salesforce, Slack, Zoom, Atlassian and Notion: Not stated in the documentation we reviewed.
NIST AI 600-1 adds two policy hooks. GV-1.6-002 suggests defining inventory exemptions for generative AI embedded in application software, and GV-6.1-009 suggests updating acquisition due diligence for solutions that rely on embedded generative AI. Lightbridge's advice: decide on purpose whether embedded features are in the inventory. An unwritten exemption is a gap.
How the shadow AI question reaches Lightbridge clients through questionnaires and audits.
Sources reviewed 2026-11-03. We did not review customer security questionnaires for this page, so Lightbridge makes no claim about what any specific one asks. What the guidance does show is where the underlying controls sit. NIST AI 600-1 places the approved-provider list at GV-6.1-007, the AI inventory at GV-1.6-001, and acceptable use at GV-6.1-010. ISACA, in an author article and not a formal standard, describes an AI usage audit as a way to build tools that detect shadow AI use through cloud services (ISACA, 26 September 2025). CISA's TIC 3.0 Cloud Use Case lists Shadow IT Detection as a capability and says agencies should detect unsanctioned services and unsanctioned use inside sanctioned ones (CISA, December 2023). We found no CISA page that names shadow AI specifically.
Lightbridge's view, offered as judgment: if you can show a current inventory, an approved list with review dates, and an acceptable-use policy, you hold the evidence most questionnaire and audit requests for this topic would need.
Evidence and metrics Lightbridge suggests keeping, and where the guidance runs thin.
Sources reviewed 2026-11-03. The sources support a short list of records. NIST AI 600-1 points to an inventory of generative AI systems (GV-1.6-001), an approved provider list (GV-6.1-007), and continuous monitoring policies for third-party systems in deployment (GV-6.2-004). WaTech points to a maintained list of AI uses and use cases, and warns that using a generative AI system may create a public record. The vendor reports above natively produce user counts, byte volumes, sanctioned status, risk scores, and OAuth scopes per app.
- Dated exports of each discovery report, so you can show change between runs.
- The approved-tool list, with owner, data class allowed, and last review date.
- A log of access requests and decisions, including denials and reasons.
- Screenshots or exports of embedded-AI settings, by product and by group.
- The consent settings in force at your identity provider.
For metrics, Lightbridge suggests trending the counts these reports already give you: AI apps found, share approved, users on unapproved tools, and open requests past their target. The sources we reviewed set no benchmark or target for any of them, and none states what a good number looks like. Guidance on shadow AI metrics is thin. Treat any figure a vendor or consultant offers as a starting point for your own baseline.
How Lightbridge advises on shadow AI.
Lightbridge is an independent advisory and program-management firm. We help a CIO or CSO design the discovery plan, choose which signals fit the licenses already in place, write the approved-tool and request process, and run the program through delivery. Where hands-on configuration or tooling is needed, vetted partners deliver under Lightbridge's program management. Lightbridge does not sell discovery tooling.
Discovery tells you which AI tools staff use. A second question is how your AI workloads reach models: through a vendor API, a cloud platform, or your own infrastructure. Lightbridge compares those routes on AI access paths. This guide is part of Lightbridge's security and GRC advisory hub. For wider strategy, see Lightbridge's AI advisory.
Lightbridge Automation, a sibling practice in the Lightbridge group, offers AI governance consulting and publishes explainers on AI policy and the NIST AI RMF. If a recommendation here points to work a sibling practice would deliver, Lightbridge discloses that upfront and you remain free to take the work elsewhere.
Shadow AI: frequently asked questions answered by Lightbridge
What is shadow AI?
The UK NCSC defines shadow AI as AI technology not captured in an organisation's approved systems and processes, and describes it as a form of shadow IT. Its shadow IT guidance lists unmanaged AI services, such as chatbots used with corporate data, as one example. Lightbridge uses the same working definition: any AI tool, account, extension, or feature that security has not seen and approved.
Can we block shadow AI entirely?
The NCSC recommends reducing the risk rather than assuming shadow AI can be eliminated, and says that understanding why staff use it lets an organisation provide secure alternatives. It also notes that where policy lags behind business need, employees are likely to adopt new AI services before approved alternatives exist. Lightbridge advises pairing discovery with a fast approved-tool path, so blocking is the exception and not the whole plan.
Which discovery signal should we start with?
Start with what you already own. For most organizations that is the identity provider's OAuth and consent view and the CASB or secure web gateway category logs, because Lightbridge's view is that both need no new deployment. Add browser extension reporting and endpoint telemetry next. No source we reviewed ranks the signals by accuracy: vendor documentation does not state detection accuracy, false positive, or false negative rates for any of them.
Does a CASB see employees using personal AI accounts?
Not reliably. The UK NCSC states that CASBs aim to identify cloud service use by monitoring network traffic, and that without breaking or intercepting encrypted connections they cannot identify unapproved use of approved cloud services, such as personal accounts, or give visibility into what users do inside approved services. That is why Lightbridge pairs CASB data with identity, endpoint, and policy controls.
Is AI built into our existing SaaS licenses also shadow AI?
It can be. NIST AI 600-1 suggests defining inventory exemptions in policy for generative AI embedded in application software (GV-1.6-002) and updating procurement due diligence for solutions that rely on embedded AI (GV-6.1-009). For example, Google states the default setting for Gemini features in Workspace services is on. Lightbridge recommends listing embedded AI features in the inventory with an owner and a decision, even when the vendor is already approved.
Should we punish staff who used unapproved AI tools?
The NCSC advises a positive, no-blame approach to staff who adopted shadow IT, because blaming or punishing them makes peers reluctant to report their own practices and reduces visibility. Lightbridge applies the same reasoning to AI: a discovery finding should start a conversation about the underlying need, and the answer should usually be an approved route.
Do customer security questionnaires ask about shadow AI?
We did not review questionnaires as part of this page, so we make no claim about specific ones. As a practical matter, Lightbridge expects the topic to arrive through controls an approved-application inventory and an AI acceptable-use policy can answer, which NIST AI 600-1 covers under GV-6.1-007 and GV-6.1-010. Treat that as Lightbridge's view, not a sourced finding.
Start with a clear view: talk to a Lightbridge advisor.
Bring your identity provider, CASB, and endpoint stack. Lightbridge will help you plan a 30-day discovery that your board and your legal team can both read.