Your new workforce won't be all human. Join the
conference to learn the new workforce OS.
request invite
TL;DR: Most shadow-AI hunts look in the wrong place. The strongest signal is not network traffic; it is the OAuth consent grants your identity provider already logged. When we pointed a read-only AI Coworker at a Google Workspace, it read every user's grants, found 27 connected apps across 5 people, flagged 6 as AI, and produced a ranked executive report on the ticket. The standout: an AI email client (Shortwave) holding full Gmail access for one user, and Read AI able to read Google Meet meeting media. It reviews and recommends; a human revokes.
Related reading: Your CMDB is lying to you.
Most teams go looking for shadow AI in the wrong place. They pull firewall logs, they check the web proxy, they buy a blocklist of AI domains. And they miss almost all of it, because the risky part of shadow AI is not someone visiting a chatbot in a browser tab. It is the AI tool an employee connected to their work account: the meeting notetaker that reads the calendar and joins every call, the "summarize my inbox" extension that holds a mail-read token, the AI assistant that was granted access to the whole Drive. None of that shows up cleanly in network traffic. All of it shows up in one place you already own: the OAuth consent grants in your identity provider.
Network and DNS monitoring catch a person typing a prompt into a website. That matters, but it is the least dangerous form of shadow AI, because a copy-pasted prompt does not hold a standing credential to your data.
The dangerous form is delegated access. When an employee clicks "Continue with Google" or "Sign in with Microsoft" on an AI product and approves the consent screen, they hand that product an OAuth token with specific scopes: read my email, read and write my files, see my calendar, act on my behalf offline. That token keeps working after the browser closes. It survives password changes. Many third-party tokens never expire unless someone explicitly revokes them. And it is completely invisible to a web proxy, because the AI vendor's servers call Microsoft or Google directly, machine to machine, never touching your network. So the question is not who visited an AI site. The question is which AI apps are holding live keys to our data right now, and what can they reach. That question has an exact answer, and it is sitting in your identity logs.
Each identity provider records third-party access in a slightly different place. A good detector reads all of them.
Microsoft Entra ID (Azure AD) is the richest source. Through Microsoft Graph, a read-only audit pulls servicePrincipals (every application registered or consented in the tenant), oauth2PermissionGrants (delegated permissions granted on behalf of users), and appRoleAssignments (application-level permissions). For each app it can read the exact scopes, whether the grant was per-user or tenant-wide, and the verifiedPublisher field, since an app from an unverified publisher is a higher risk profile than a verified one.
Okta records OAuth 2.0 token grants in the System Log: when an app is granted an access token, the event captures the client ID, the subject, the scopes, and the grant type. Google Workspace keeps an OAuth Token audit log that records the app name, the user, and the APIs the app accesses; for automation, the Admin SDK Reports API exposes a tokens resource that returns display name, scopes, and client ID per user.
The point of reading all three is coverage. An AI tool connected through a personal-looking Google login, an Entra enterprise app consented by one power user, and an Okta-brokered integration are three different blind spots. One system alone misses two of them.
Reading the grants is the easy part. The value is in the analysis, and that is the part no one has time to do by hand across three consoles. The Shadow AI Detection Coworker runs a read-only pass and does five things in order. It enumerates every third-party grant across Entra, Okta, and Google Workspace. It normalizes them into one list, because the same AI vendor often appears under three different app identities across the three systems. It classifies which apps are AI, using the vendor identity, the app metadata, and the scope pattern of a typical AI tool, rather than a static blocklist that is stale the day it ships. It scores each app by combining scope sensitivity, publisher verification, how many users authorized it, and whether it is actively used or dormant-but-still-authorized. And it attributes each grant to a named owner and, where an admin consented tenant-wide, says so explicitly.
Then it writes the report a human can act on: ranked by risk, each entry naming the app, the scopes it holds, the number and names of users who consented, and a recommended action. Crucially, when it cannot read a source, it says so and names the exact permission needed, instead of quietly returning a shorter list and letting you believe the coverage was complete.
In the recorded run across a five-person Google Workspace, the Coworker read 27 connected third-party apps and flagged six as AI, five of them holding sensitive scopes. Top of the list was Shortwave, an AI email client one salesperson had connected with full Gmail access, plus calendar and contacts. Next was Read AI, able to read Google Meet meeting media, not just the calendar. Then Otter, already on two people including an admin, and Fathom and Fireflies, each reading a user's calendar to auto-join meetings. Retell AI showed up too, but with sign-in scope only, so it was ranked lower.
The scan did not stop at AI. It also surfaced heavier non-AI grants that had piled up on the admin account: a connected Azure AD app with directory-write access, the Google Cloud SDK holding full cloud-platform access, and e-signature and design tools carrying Drive and Gmail add-on scopes. Every one of these apps announced itself the moment it asked for permission, and the grant sat in the identity provider waiting to be read.
This is a detector, not an enforcer. It reads. It reasons. It recommends. It does not revoke a single grant. Revoking an OAuth grant can break a tool someone genuinely relies on, so the decision to revoke belongs to a human who can see the business context. The Coworker's job is to make that decision fast and well informed: here is the app, here is what it can reach, here is who uses it, here is why it is risky, here is the revoke path. A person clicks the button.
OAuth consent grants are the strongest single signal, but they are not the only one. A CASB adds discovery across generative-AI apps with risk scoring. Data classification and DLP tools add visibility into what actually flows into AI tools. Network and DNS logs still add value for the browser-tab usage that never involved a consent screen. Endpoint signals catch locally installed models and browser extensions that never touched your identity provider at all.
How is this different from a CASB? A CASB is broad and excellent at discovery and policy enforcement across many app categories. This Coworker is narrow and deep on one question: which AI apps hold delegated access to corporate data, analyzed across Okta, Entra, and Google Workspace together, attributed to owners, and turned into a ranked action list.
Can the Coworker revoke access itself? No, and that is intentional. It is read-only. It surfaces the risky grant, explains the blast radius, names the owner, and hands over the revoke path. A human makes the revoke decision.
What about employees using AI through personal accounts? Delegated access through a personal account will not appear in your corporate identity logs. Those cases are where secondary layers earn their place: network and DNS signals, endpoint detection, and CASB discovery.
Does it need agents installed on devices? No. The identity-grant analysis is entirely API and log based against Okta, Entra, and Google Workspace. It installs nothing.
What can it not see? Anything that never created a consent grant or a log entry in a system it can read: personal-account usage, fully offline local models with no network calls, and any source where it was not granted read access.
You do not have a shadow-AI visibility problem because the data is missing. You have one because the data is spread across three identity consoles, written in three different formats, and nobody has time to read it. The consent grants are already there. Every AI tool your people connected announced itself the moment it asked for permission. A read-only AI Coworker reads all three sources, tells you which AI apps are holding keys to your data and who let them in, and stops at the line where a human should decide what to revoke.
See how read-only AI Coworkers surface shadow AI at atomicwork.com.
