Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to find the shadow AI nobody told you about?

No single tool sees all of it. Shadow AI is found by combining discovery signals from network and gateway logs, single sign on and OAuth records, expense data, browser telemetry, DLP alerts and staff disclosure, each blind where another sees. An inventory built from one signal undercounts personal accounts, embedded AI features and internal integrations, and leaves found work ungoverned.

Enterprise discovery signals reveal a sequence of previously shadowed application cards.

No single tool sees all of it. Shadow AI is found by combining discovery signals from network and gateway logs, single sign on and OAuth records, expense data, browser telemetry, DLP alerts and staff disclosure, each blind where another sees. An inventory built from one signal undercounts personal accounts, embedded AI features and internal integrations, and leaves found work ungoverned. The signals that exist today are network and DNS logs, cloud access security broker and secure web gateway records, single sign on and OAuth grant inventories, expense and procurement data, endpoint and browser telemetry, data loss prevention alerts, and direct disclosure from staff. Each covers a different slice of use, and each misses a slice the others catch. The sections below compare those discovery methods, show where each one is blind, and set out how to turn a pile of signals into a defensible inventory. Keeping the found work visible afterward takes an AI Control Record of what each agent saw and did, so that newly governed work does not drift back into shadow. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Use is widespread before discovery begins: 78 percent of AI users brought their own AI tools to work (Microsoft, 2024), and a Salesforce survey found 55 percent of employees had used AI tools their employer had not sanctioned (Salesforce, 2024).
  • The UK NCSC states that security teams should not assume they are seeing the full picture of AI use in their organization (NCSC, 2026).
  • Microsoft documents that its Defender for Cloud Apps catalog includes over 35,000 discoverable cloud apps, which illustrates the scale of the catalog based discovery problem (Microsoft, 2025).
  • IBM reported that 20 percent of organizations in its study had a breach involving shadow AI, and that only a minority of organizations with AI policies regularly audit for unsanctioned use (IBM, 2025).
  • The NIST AI Risk Management Framework places inventory and context in the Map function, which must be completed before risks can be measured or managed (NIST, 2023).
  • No single discovery method covers personal accounts on personal devices, AI features embedded in approved software, and API integrations built by internal teams at the same time, and all three fall inside the NCSC definition of shadow AI (2026).

Where does shadow AI actually hide?

It helps to name the hiding places before choosing a detection method, because the method follows from the place. The first is the obvious one: an employee opens a consumer AI service in a browser, often through a personal account, and pastes work material into it. The second is less visible: an approved software product adds an AI feature, and staff begin using it under a contract that was assessed before the feature existed. The third is structural: a team connects a model API to a spreadsheet, a help desk, or an internal application, and the integration becomes part of normal operations without a separate AI approval.

The NCSC defines shadow AI as AI technology used outside an organization's approved systems and processes, and notes that it is a form of shadow IT (NCSC, 2026). That definition covers all three hiding places, which is why a discovery exercise framed only around chatbot websites will undercount. Research cited by the NCSC found that 71 percent of UK employees had used unapproved consumer AI tools at work (NCSC, 2026). That figure concerns consumer tools specifically, and it should not be read as a count of embedded features or internal integrations.

A fourth hiding place is the personal device. Work performed on a home computer or a personal phone may never cross the corporate network, may not be enrolled in device management, and may not appear in any log the employer is entitled to inspect. Discovery in that setting depends on disclosure, on policy, and on making the approved route easier than the personal one. Any inventory should record this blind spot explicitly rather than imply complete coverage.

What can network, DNS, and gateway logs reveal?

Network telemetry is usually the first source teams turn to, because it already exists. DNS queries, proxy logs, firewall records, and secure web gateway logs can show that devices on the corporate network reached a known AI service, how often, and in what volume. Microsoft documents catalog based discovery in which network activity is matched against a library of known cloud applications, with its Defender for Cloud Apps catalog covering over 35,000 discoverable apps (Microsoft, 2025). Catalog matching is what turns a raw domain list into a usable report.

The strengths are scale and passivity. Logs can be reviewed across the whole estate without asking anyone anything, and they provide dates, which matter when a team needs to know whether use started before or after a policy took effect. Volume signals also help prioritize: a service used daily by a department deserves earlier assessment than a service visited once.

The limits are equally clear. Encrypted traffic reveals the destination service but not the content of a prompt, so network logs can show that a tool was used without showing what data went into it. Personal devices off the network produce no records at all. New or obscure services may not be in the catalog, and a single domain can host both an approved enterprise product and a consumer tier with different data terms. Network discovery therefore answers the question of which services were reached, not the question of what was shared or under what terms.

What do identity, single sign on, and OAuth records show?

Identity systems reveal a different layer: accounts and permissions. Single sign on logs show which applications staff reach through the corporate identity provider, and application inventories built from those logs are usually more accurate than network estimates for sanctioned software. The more valuable record for shadow AI is the OAuth grant. When an employee connects a third party AI tool to a mailbox, a calendar, a drive, or a customer system, the authorization is recorded by the identity provider or by the connected platform, even if no one in IT was consulted.

OAuth records matter because they show continuing access rather than a single visit. A chatbot session ends when the tab closes. An OAuth grant can keep reading new documents or messages until it is revoked. Reviewing grants by scope, by the data they can reach, and by whether the account that granted them is still active is therefore one of the highest value discovery exercises available, and it aligns with the access control concern in IBM's research, which found that 97 percent of organizations reporting an AI related breach lacked proper AI access controls (IBM, 2025).

Identity records have their own blind spot, and it is a large one. A personal account created with a personal email address never touches the corporate identity provider. There is no sign on event, no grant to review, and no administrator who can change its retention settings. Salesforce's finding that 55 percent of employees had used unsanctioned AI tools suggests that a substantial share of use sits in exactly that unmanaged account category (Salesforce, 2024). Identity based discovery is strong on integrations and weak on personal accounts, which is the reverse of network discovery in some environments, and one reason the methods need to be combined.

How do expenses, procurement, and browser telemetry help?

Money leaves records. Expense claims, corporate card transactions, and procurement requests can reveal paid AI subscriptions that no technical control detected, including tools bought by a team and used for months before renewal brings them to attention. Finance data is also useful for a different reason: it identifies a budget holder, and a budget holder is usually the person who can explain the business case and sponsor an approved replacement.

Browser and endpoint telemetry cover the gap between network and identity. Managed browser reporting, endpoint agents, and browser extension inventories can show which AI extensions are installed, which accounts are signed in, and whether a paste or upload action involved a managed device. Extension inventories deserve particular attention, because an extension can read page content continuously and may have permissions far broader than the task the user installed it for. The NCSC warns that AI agents are complex software that can carry serious vulnerabilities, and that an attacker who exploits one may gain the same data and privileges the agent legitimately holds (NCSC, 2026).

Why do data loss prevention alerts find data rather than tools?

Data loss prevention, or DLP, answers a narrower and in some ways more important question: did sensitive content move? Microsoft describes Purview DLP as identifying sensitive items across services and endpoints and enforcing policies to protect data such as financial records, health information, and intellectual property (Microsoft, 2025). On onboarded Windows devices, Microsoft documents endpoint DLP policies that can warn or block users from sharing sensitive information with third party generative AI sites accessed through a browser (Microsoft, 2025).

That is a content signal, not an inventory. A DLP alert tells a team that a credit card number, a customer record, or a document with a sensitivity label was pasted or uploaded, and where it went. It does not list every AI tool in use, and it will not fire on the many sessions in which only non sensitive material was shared. Used well, DLP data prioritizes the inventory: tools that appear in alerts involving regulated data move to the front of the assessment queue.

DLP also illustrates a general principle from US government guidance on AI data security. Joint guidance from CISA, the NSA, the FBI, and partner agencies on securing data used to train and operate AI systems focuses on protecting data across its supply chain and lifecycle, rather than on any single application (CISA, 2025). Discovery framed around data, where it is, who can reach it, and where it can flow, tends to survive changes in which AI products are popular. Discovery framed around a list of product names does not.

How should separate signals be combined into one inventory?

Combining signals means building a register with consistent fields and accepting that confidence varies by entry. A practical register records the tool or feature, the form it takes, the owning team if known, the account type, the data categories involved, the discovery source, the date first seen, and an assessment status. Recording the discovery source is not bureaucracy. It tells the reader whether an entry rests on a log, an OAuth record, an expense claim, or a person's statement, and therefore how much weight it can bear.

The NIST AI Risk Management Framework offers the organizing logic. Map comes first: establish context, categorize the system, and understand its capabilities and impacts in the organization's own setting (NIST, 2023). Measure follows, applying assessment to the systems that Map identified. Manage then prioritizes responses by risk. Teams that skip Map and move straight to blocking tend to block what is visible and leave what is consequential.

The inventory also needs a maintenance rhythm. AI features appear inside approved products between assessments, and new consumer services reach staff faster than catalogs update. A quarterly refresh that re-runs the same queries, re-reviews OAuth grants, and re-opens a disclosure route will find less each time, and that declining yield is itself evidence that the process is working. IBM's observation that few organizations with policies regularly audit for unsanctioned AI use points to the gap this rhythm is meant to close (IBM, 2025).

Where does RedactSure sit?

Discovery alone leaves the found work still running on ungoverned tools. Once the inventory names the sensitive workflows, RedactSure gives them a governed home. Supervised AI co-workers run those browser workflows across the applications already in place, with no per-application integration and no change to user permissions. Policy selected values are replaced by consistent tokens at the render layer before any model reads the screen, so the model receives the task's fields with identifiers as SSN_001 or ACCT_001, and real values resolve only at approved destinations at the moment of an approved action. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy and approves every consequential action under Supervised Delegation.

Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM, which keeps newly found work visible instead of letting it drift back into shadow. Keys stay with the customer, and the model is swappable. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page rests on primary and vendor documentation read as of October 13, 2026: the NIST AI Risk Management Framework 1.0 (official guidance), the NCSC's guidance on the hidden risks of shadow AI (official guidance, 2026), IBM's Cost of a Data Breach Report 2025 (industry analysis), the Microsoft and LinkedIn Work Trend Index 2024 (industry survey), a Salesforce employee survey as published by Salesforce (industry survey), Microsoft Learn documentation for Purview DLP, endpoint DLP and Defender for Cloud Apps discovery (vendor documentation), and joint CISA and NSA guidance on AI data security (official guidance, 2025). Vendor documentation is described as the vendor states it and is dated.

No discovery tooling was run against any network for this reading, and no organization's inventory was examined. Method descriptions are therefore general and do not reflect a test of any specific product's detection accuracy; no hands-on testing of Defender for Cloud Apps, Purview DLP or any other named product was performed. Survey percentages come from different populations, years, and question wordings, and they are not combined into a single estimate. Vendor features and catalog sizes change; the page carries its date and is revised when the documentation changes. The examples of mailboxes, help desks and spreadsheets describe categories of use, not any organization; no customer or prospect is described.

Whether a given discovery method, inventory or monitoring practice meets an organization's legal, privacy and regulatory obligations is a determination for its counsel, assessor, privacy officer and security and compliance officers, not for this page. Employers considering content level monitoring should take legal and privacy advice for their jurisdiction.

What the record shows

Finding the shadow AI nobody mentioned is assembly work, not a single purchase. Network and gateway records show destinations, identity records show accounts and grants, expenses show payments, and disclosure shows what staff will admit, each view covering a blind spot in another. The defensible inventory sits where signals overlap and disagree, pointing at personal accounts, embedded features, and internal integrations no catalog lists. A team that relies on one signal will block what is visible and miss what is consequential. The test for any inventory is whether every entry names the signal it rests on, and whether entries exist that only a second or third signal could have produced.

Frequently asked questions

Which discovery signal should a team start with?

Start with whichever records the organization already keeps and can query today, most often gateway or DNS logs and the single sign on and OAuth grant inventory, since those two views cover bought tools and personal accounts reached from managed devices. Starting there is a practical choice, not a ranking: the point of the first pass is a rough list that later signals can correct. Expenses, browser telemetry, and disclosure then add the slices the first signals miss.

Can a cloud access security broker find all shadow AI on its own?

No. A broker works from traffic and from a catalog of known applications, and that misses AI features switched on inside already approved software, agents and integrations built by internal teams, and use from personal accounts on personal devices that never crosses managed infrastructure. A large catalog improves coverage of known services without changing that structural limit, which is why brokers sit alongside identity, expense, and disclosure evidence rather than replacing them.

How can anyone tell whether the inventory is complete?

They cannot, and treating completeness as unprovable is the safer working assumption. The UK NCSC warns security teams not to assume they are seeing the full picture of AI use in their organization. Cross checking one signal against another narrows the unknown: a tool appearing in expenses but not in gateway logs, or in staff disclosure but not in identity records, shows where coverage ends. Each gap found that way is a reason to add a signal, not to declare the search finished.

Do network logs show what data employees pasted into an AI tool?

No. Encrypted traffic reveals the destination service, the frequency and the volume, but not the content of a prompt or upload. Network logs establish that a tool was reached and when; they do not establish what was shared or under which data terms. The content question belongs to DLP, which fires on sensitive items such as card numbers or labeled documents moving to a generative AI site, and even DLP stays silent on sessions in which nothing sensitive was shared.

Why do OAuth grants matter more than chatbot visits?

Because a grant is continuing access rather than a single visit. A chatbot session ends when the tab closes, while an OAuth grant to a mailbox, calendar, drive or customer system can keep reading new material until someone revokes it. Reviewing grants by scope, by the data they can reach, and by whether the granting account is still active is one of the highest value discovery exercises available, and it addresses the access control gap IBM found in organizations reporting AI related breaches.

How often should the shadow AI inventory be refreshed?

Quarterly is a workable rhythm. AI features appear inside approved products between assessments, and new consumer services reach staff faster than discovery catalogs update. A refresh that re-runs the same log queries, re-reviews OAuth grants and re-opens a disclosure route will find less each time, and that declining yield is evidence the process is working. IBM's finding that few organizations with AI policies regularly audit for unsanctioned use shows the gap a fixed rhythm is meant to close.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.