Ask a security team to name the AI applications running inside their company and most will get four or five right without looking anything up. That is not a failure of attention; it is what the data looks like. Akamai’s Enterprise AI Usage Risk Report 2026, built on browser telemetry from the LayerX platform Akamai acquired, found that the top four AI applications in a typical organization are each used by more than 20% of employees, and then the curve falls off a cliff. After the tenth application, usage drops below 5% of the organization, and by the thirtieth it approaches zero. The report’s own description of what sits in that tail is worth quoting: “a vast ‘long tail’ of shadow AI apps operates just below the surface, often used by small, isolated teams without corporate oversight.”
That shape is the entire detection problem. Every method for finding shadow AI keys off some signal, whether that is traffic volume, a billing record, an identity grant, or a content match, and the long tail is precisely the region where each of those signals is weakest. A program that finds the apps everyone already knows about has not produced an inventory; it has produced a confirmation. The gap matters beyond hygiene, because an inventory is now an explicit control obligation: NIST’s AI Risk Management Framework states under GOVERN 1.6 that “mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” An auditor will ask what the mechanism is, and “we monitor the network” is a mechanism with a known coverage boundary that most teams have never written down.
Below are the six approaches enterprises actually deploy to find unauthorized AI. Each one genuinely works on some part of the problem, each has a blind spot that is structural rather than a missing feature, and the last one is ours, held to the same standard.
1. Network and Proxy Monitoring
Secure web gateways, cloud access security brokers, and DNS logging see every device on the corporate network without installing anything on it. For a first pass at discovery this is the right move and often the fastest one available: the egress logs already exist, nobody has to ship an agent, and a weekend of querying domain requests against a list of known AI services will produce a defensible starting inventory. CASB products extend this by inspecting sanctioned applications through vendor APIs, which adds real depth on the platforms a company has already licensed.
The structural limit is that a domain is not a person and a request is not a prompt. Without TLS inspection the logs resolve to a hostname and a timestamp, so the record says someone reached a chat service, not who they were or what they sent. TLS inspection closes part of that gap but is expensive to run and politically difficult to justify, and it still breaks against certificate pinning in native clients. More decisively, the network only sees what crosses it. An employee on a home network, a personal laptop, or a tethered phone is outside the sensor entirely, and that is not an edge case now that AI use has drifted onto whatever device is nearest.
2. Identity and OAuth Grant Logs
Mining the identity provider for third-party application grants is the highest-precision discovery method available, and the most underused. When an employee connects an AI tool to their corporate account, the grant is recorded with the scopes it requested, so the log tells you not just that an app exists but what it can reach. An AI meeting assistant holding calendar and mailbox scopes is a materially different risk from one holding nothing, and the identity log is the only source that distinguishes them. It is retroactive, needs no deployment, and finance and security can read it without a project.
The blind spot is the sign-up path. An employee who registers with an email address and a password never creates an OAuth grant, so the most common way into an AI tool leaves no trace in the place you are looking. The Akamai research sizes this directly: nearly half of all enterprise AI conversations, 47.11%, take place through personal identities rather than corporate-managed accounts. The more troubling finding is the one that looks governed and is not. 14.4% of AI conversations on corporate email addresses were linked to personal freemium subscriptions rather than enterprise licenses, which means, as the report puts it, “the data going into those accounts was being used by the LLM for public model training.” The identity log shows a corporate address behaving normally. The contract governing that data is a consumer click-through.
3. Endpoint and DLP Agents
Endpoint agents and data loss prevention tooling are the only approach on this list that is content-aware and device-wide at the same time. The agent travels with the laptop, so it keeps working off the corporate network, and it sees native desktop applications that a browser-based sensor cannot. For organizations that already run endpoint detection everywhere, extending the existing policy to AI destinations is incremental work rather than a new program, and it is the closest thing available to a complete view of a managed device.
The limit is that the detection model was built for a different shape of data. Akamai’s report makes this argument against the category’s own history: traditional DLP “assumes that sensitive information moves through relatively well-defined channels” and relies on “exact matching, fingerprints, regular expressions, dictionaries, and predefined data classifications.” AI does not move complete files. It moves prompts, pasted snippets, screenshots, conversational context, and iterative follow-ups, so that “sensitive information has become fragmented across dozens of interactions that individually may appear harmless but collectively expose valuable business context.” A rule tuned to catch a spreadsheet leaving the building does not fire on the twentieth question in a conversation that has reconstructed the same spreadsheet. There is also a reporting mismatch: DLP produces exfiltration events, which is not the same artifact as an application inventory, and a queue of events will not answer the auditor’s question about mechanisms.
4. Expense, Procurement and SaaS Management
Reading the card statements is the oldest shadow IT technique and it remains the only one that sees money. SaaS management platforms automate it, reconciling expense feeds and vendor invoices into a subscription list with renewal dates, seat counts, and duplicate purchases attached. It is owned by finance, needs no security deployment, and it surfaces a class of problem the technical approaches miss entirely, which is the team that bought a paid tier through a departmental card and has been renewing it annually ever since. It is also the only discovery path that arrives with a cost attached, which is why we treat shadow AI discovery as a spend problem as much as a security one.
The limit is arithmetic. Shadow AI begins free, and a free tier generates no invoice, no expense line, and no procurement record. The Akamai freemium figure is the measurement of exactly this gap: usage that reaches corporate email addresses, carries business data, and never once appears in a financial system. By the time a tool shows up on a statement it has usually been in production use for months, which makes expense data an excellent record of what was purchased and a poor record of what is being used.
5. Browser Extensions
A managed browser extension sees the interaction rather than the connection. Where a gateway records that a host was reached, the extension records which application was used, by which identified user, at what time, and in some cases what was actually sent. That is the difference between an inventory of domains and an inventory of behavior. It deploys through existing browser policy in minutes rather than quarters, and critically it works regardless of which account the employee signed in with, which is the one failure mode that defeats identity-based discovery.
The structural limit is in the name. A browser extension sees the browser, so desktop clients, IDE assistants, and anything calling a provider API from a server are outside it. We have argued this against ourselves before: browser-only detection is listed as one of the shadow AI mistakes that make the problem worse, and that remains true. There is a second-order problem worth naming too, because the same Akamai research found that nearly three quarters of installed AI browser extensions request high or critical permission levels, 56.4% high and 16.7% critical. An extension is a powerful access channel by construction. What separates a governance sensor from a liability is not how little it can do, but who deployed it, under what policy, and whether what it collects is written down.
6. Olakai
Olakai Assistive discovers shadow AI through a browser extension that is force-installed by policy rather than chosen by the user, across Chrome, Edge, and Firefox, using standard enterprise deployment through Intune, Jamf, or Workspace ONE. Capture runs at two depths and we state the boundary plainly: full prompts and responses on a named set of major applications including ChatGPT, Claude, Gemini, Microsoft Copilot, and Perplexity, and metadata only, meaning application, user identity, and timestamp, across the 800-plus other AI sites in the long tail. Three managed integrations supplement the extension for Microsoft 365 Copilot, Gemini in Google Workspace, and Claude, read from the vendor rather than the browser. Google supplies activity for its surfaces but never prompt content, so that integration tells you who used which feature and when, and nothing about what was said.
The part that answers the long tail is not the extension. Olakai analyzes each detected application’s published terms of service, privacy policy, and licence agreement, and scores it from 0 to 100% across five categories: whether the vendor trains models on customer data, what content licence it claims, how long it retains data, whether it shares data with third parties, and how it treats intellectual property. Each score carries the excerpt from the vendor’s own document that produced it, and a comparison against every other application in the catalog, so an app in the riskiest fifth for data retention is labelled as such. Because this reads the vendor’s public legal documents rather than the traffic, it works on applications we only ever see as metadata, which is exactly where the other five approaches go dark. Pairing that with the app catalog and policy alerts is what turns a list of domains into an audit-ready record, and it is the reason a CISO can answer a question about a tool nobody has inspected by hand.
The structural limit is that Olakai observes; it does not block. The extension reports an interaction after the model has finished responding, so it is an audit and early-warning system rather than a prevention control, and acceptable use policies it presents are advisory, meaning an employee can decline the notice and keep using the application while monitoring continues. Enforcement requires integrating our control endpoint into your own application code, which by definition cannot cover a third-party web tool. Classification is also human work: discovery is automatic, but until someone assigns an approval state to a newly found app you cannot enforce policy against it, attribute its cost, or flag sensitive data leaving through it. And our discovery is browser-based, with no gateway and no identity-log component, so anything in the first four categories above belongs underneath Olakai rather than instead of it. We would rather say that than have a customer discover it in month three. The argument for why blocking shadow AI fails is the same argument for why observation is the right default, and what the extension does and does not collect is documented rather than described.
The Pattern: Everyone Counts Apps, Nobody Counts Exposure
Line the blind spots up and they stop looking like six separate gaps. Network monitoring sees domains rather than people. Identity logs see grants rather than sign-ups. DLP sees events rather than an inventory. Expense data sees invoices rather than usage. Browser extensions see the browser rather than the device. Every one of them is counting applications, and the application count is a proxy for the thing that actually matters. Akamai puts the reframe in a single sentence: “The biggest AI security risk is no longer employees who access AI, it is employees who share sensitive business data with AI.”
That is a different question, and it has three parts that no app inventory answers. Which data left the organization. Whose account it left through, corporate or personal. And what the receiving vendor’s terms permit them to do with it once it arrives. A program built to answer those will tolerate an incomplete app list, because a tool nobody has sent anything sensitive to is a low-priority row. A program built to produce a complete app list will keep adding sensors and still be unable to tell a board whether anything of value walked out. This is also why prohibition makes measurement worse rather than better, a pattern we have tracked as shadow AI has gotten worse rather than better under blocking-first policies: each ban removes a surface from the sensors without removing the behavior.
The practical sequence is unglamorous. Start with whichever sensor you already own, because partial coverage you can read beats complete coverage you are still procuring. Write down what it cannot see, since an undocumented coverage boundary is the thing that turns into an incident report. Then close the largest gap deliberately rather than buying another overlapping tool, and run the whole thing as AI governance with a named owner rather than as a security project with an end date. If you have never produced the first inventory, the AI visibility audit is the version of this that fits in a week.
Shadow AI is not a list of applications to eliminate. It is evidence of demand that arrived faster than governance, and the organizations handling it well are the ones that can say, with a number, what their people are sending where and under whose terms. That is a measurement problem before it is a security problem, which is the whole reason Olakai exists. Talk to an expert and we will show you what the first week of detection actually surfaces, including the parts we cannot see.