Reading OAuth grants: the shadow-AI map in your Workspace and Entra

Most people picture shadow AI as traffic — someone visiting a chatbot you'd rather they didn't, something a firewall could catch. That mental model is wrong, and it's why firewalls and DLP miss the real exposure. The AI that matters most didn't visit anything. It got a standing grant: a user clicked "Allow," and now a third-party application holds a live, revocable-only-by-you key to your calendars, your files, or your mail. It doesn't need to phone home through your network. It reaches in through an authorized connection you didn't know existed.

That's an access problem, not a traffic problem (see Shadow AI is an access problem not a traffic problem), and the good news is that access problems are auditable. Every one of those grants is recorded in your identity provider. If you run Google Workspace or Microsoft 365, the shadow-AI map is already drawn — you just have to open the console and read it. This playbook shows you exactly where to look and how to tell a benign grant from a dangerous one.

What an OAuth grant actually is

When an app says "Sign in with Google" or "Connect your Microsoft account," it's using OAuth to request scopes — named permissions like "read your calendar" or "read and write your Drive files." If the user (or an admin) consents, the identity provider issues the app a token: a durable credential the app can use to act on that access until the grant is revoked. The token doesn't expire when the user logs out. It persists. Which means a meeting note-taker a former employee connected in March can still be reading calendars in July unless someone pulled the grant.

Two things make a grant risky, and you read them off the console:

1. Scope — how much it can reach. Read-only calendar is one thing; read/write access to all of Drive or all of Mail is another entirely.
2. Breadth of consent — how many people it covers. A grant one user made for themselves is contained. A grant an admin made for the whole tenant exposes everyone at once.

Pulling the grants: Google Workspace

You need the right admin privilege — Reports/Audit & Investigation for the logs, and Service Settings or a security-admin role for the controls. Two views matter.

The live picture — who has what right now. In the Admin console, go to Security → Access and data control → API controls → App access control, then Manage Third-Party App Access. Click into any connected app to see the OAuth scopes it holds and which users authorized it (Google). This is your inventory: every third-party app with a foothold, and the reach of that foothold. From here you can mark an app Trusted, Limited, or Blocked.

The history — when grants happened. Go to Reporting → Audit and investigation → OAuth log events. This logs each time a third-party app was authorized to reach Contacts, Calendar, Drive, and more, with the user and the scopes (Google). Filter by scope to find the sensitive ones fast. The report covers up to the last 180 days; if you want a longer trail, the Reports API's Authorization Tokens activity report exposes the same data programmatically.

Newer Workspace tenants also let you restrict third-party apps to specific API scopes, so an app approved for calendar read can't silently escalate to Drive later. Turn that on once you've cleaned house.

Pulling the grants: Microsoft Entra ID

In Entra (formerly Azure AD), the equivalent concepts are enterprise applications and consent. You need at least Cloud Application Administrator to review, and higher to grant tenant-wide consent.

Go to Entra ID → Enterprise applications → All applications. Open an app and select Permissions. The Admin consent tab shows permissions granted for the entire organization; switch to see user-consented grants. The critical field is the consent type: `AllPrincipals` means someone granted it tenant-wide — every user is exposed through that one app — while individual consent is scoped to one person (Microsoft). Microsoft's own guidance is blunt that tenant-wide admin consent is a sensitive operation that can hand an app publisher "significant portions of your organization's data" (Microsoft).

For the when, use Audit logs (filter for "Consent to application" and "Add app role assignment grant") and Sign-in logs to see the service principal's activity. If you have Microsoft Defender for Cloud Apps, its OAuth app governance surfaces the same grants with risk scoring — but you don't need it to do this; the built-in Entra views are enough.

Reading a risky grant: the worked example

Here's the canonical find as it appears in the console, and how to read it:

> Otter.ai holds Calendar + Drive read access for 8 users since March; meeting recordings are retained; no SOC 2 on file.

Line by line:

• Otter.ai — a third-party AI transcription vendor. Not a Google or Microsoft first-party service; an outside company with a token.
• Calendar + Drive read — the scopes. Read access to calendars (who meets whom, about what) and to Drive files. Read-only is less alarming than write, but "read all Drive files" is still a broad reach into potentially sensitive documents.
• 8 users since March — breadth and dwell time. Eight separate grants, live for months. This isn't a one-time export; it's a standing connection that's been active the whole time.
• recordings retained / no SOC 2 — the two facts the console doesn't tell you, that you add from vendor diligence. The data leaves your tenant and sits on the vendor's systems, and you have no attestation about how it's protected.

Put together: a note-taker nobody vetted has been reading eight employees' calendars and files for months, keeping recordings, with no security attestation on file. High flag. That single row is often the most valuable output of an entire AI inventory.

The risk-reading rubric

For any grant, ask three questions in order:

1. What can it reach? Mail and full-Drive read/write are high. Calendar read and profile are lower. Anything with "read and write" to a data store outranks read-only.
2. How many does it cover? Tenant-wide / `AllPrincipals` grants and grants held by many users beat single-user grants.
3. Who is the vendor, and what do they do with the data? A named AI tool that retains and possibly trains on data outranks a well-known vendor with a clean DPA. This is where the research library behind every Discover report earns its keep — knowing what a vendor actually does with what it reads.

High on all three = revoke or restrict now. High on one = diligence it. Low on all = log and move on.

What to do about the risky ones

Three moves, and you document whichever you pick:

• Revoke. Kill the token. In Google, block or remove the app in App access control; in Entra, delete the service principal or revoke consent. Fastest way to remove exposure — do it for anything high-scope and un-vetted.
• Restrict. Narrow the scope (Workspace's per-scope controls) or convert a tenant-wide grant to named users only. Use when the tool is genuinely needed but over-permissioned.
• Diligence and approve. If it stays, it gets a dated diligence record and, for regulated data, a contract — see The AI vendor due-diligence questions that actually matter and, for RIAs, The Reg S-P service-provider oversight file step by step.

Whatever you choose, the dated note is the deliverable. A revoked risky grant with a timestamp is a clean finding at exam; the same grant left live and undocumented is the one that gets written up.

The honest part

Reading OAuth grants shows you every AI tool that connected through your identity provider — and only those. It will not catch a colleague pasting a member's file into a consumer chatbot on a personal phone (no grant is created, so nothing logs), an AI feature a vendor runs entirely on their own backend, or a tool authenticated with an API key instead of OAuth. It's a point-in-time read, too: new grants appear daily, so the value is in re-running it and diffing, not in one heroic afternoon. This is a map of one important territory, not the whole country. But it's the territory where the biggest, quietest exposures live, and almost nobody has looked.

Pulling grants across Workspace and Entra, reading scopes, cross-referencing each vendor against what it really does with data, and turning it into dated findings is exactly the read-only work a Discover scan does for you — the same console views above, done thoroughly and handed back as evidence. Read-only means read-only: we look, we report, we don't touch your data or your users.

Request your Discover scan — we run it with you. Then feed the findings into How to run an AI data call.