The shadow-AI field guide

01What an OAuth grant is

When an employee clicks “Sign in with Google” or “Connect to Microsoft 365” inside a third-party app and then clicks Allow, your identity provider issues that app a standing permission. That permission is the grant. It is recorded in your directory, it names exactly what the app may read or change (the scopes), and it keeps working until somebody revokes it.

Two things about a grant surprise most owners. First, it does not expire when the employee closes the tab, logs out, or goes home — most apps also ask for the right to keep working in the background without the person signing in again. Second, it does not expire when the employee leaves. A grant made three years ago by someone who no longer works for you is, as far as your provider is concerned, still valid today.

02The two doors apps come through

Apps get access in one of two ways, and the difference matters for how much they can reach.

• User consent. One person grants the app access to their own account: their mailbox, their files, their calendar. This is the everyday case — a notetaker, a scheduling assistant, a browser extension, an AI writing tool. No administrator is involved and, in many tenants, no administrator is told.
• Admin consent. An administrator grants the app access on behalf of the whole organization. Scopes that end in .All on Microsoft (Files.Read.All, Directory.Read.All) or that touch the admin API on Google are of this kind. One click extends the app to every mailbox, every drive, or the entire directory.
• A third path hides in plain sight: an app added for single sign-on (SAML or password-based) may hold no data scope at all — but it is still a place your people log into with a company identity, and it belongs on the inventory.

03Why nothing you already run can see it

Most small-business security spending goes to three places: the devices, the network edge, and the email filter. An OAuth grant lives in none of them.

• Endpoint agents watch what runs on a laptop. A grant is not a process on a laptop; it is a permission held by a cloud service.
• Firewalls watch traffic that crosses your network. When an AI tool reads a mailbox, the traffic runs between the vendor’s cloud and Google’s or Microsoft’s cloud. Nothing on your side sees a packet.
• Email filters watch inbound mail. An app reading the mailbox through the API generates no message to filter.
• The native admin consoles do record grants — but one app at a time, in a screen most owners have never opened, with the permissions listed as raw scope identifiers, and with no memory of what has changed since the last time anyone looked.

04What a grant record tells you

Every grant, on either provider, comes down to four facts. A useful inventory captures all four and keeps the history.

05The grants that matter most

Not every grant is a crisis. Most are a calendar tool that reads a calendar. The ones worth losing sleep over combine an AI product with a broad-read permission on data your regulator cares about.

• Mailbox read, held by an AI tool. Every message, every attachment, every thread with a client, a patient, or a bank. On Google this is gmail.readonly or the full mail.google.com scope; on Microsoft it is Mail.Read or Mail.ReadWrite.
• Organization-wide file read. Files.Read.All or Sites.Read.All on Microsoft reaches every OneDrive and SharePoint site in the tenant, not one person’s folder. Drive-wide scopes on Google do the same for that user.
• Directory read. Directory.Read.All hands the app your entire org chart: every user, every group, every app. It is the reconnaissance scope.
• Background access. offline_access is the quiet one: it lets the app keep working after the person signs out — which is what makes a forgotten grant a permanent one.
• Anything held by someone who has left. Severity is beside the point; there is no one to ask what it was for.

06What to do about it

Discovery is the easy half. The hard half is doing something with a finding without turning your workforce against the review.

• Get the inventory first, before any policy conversation. Arguing about AI policy without knowing what is already connected produces a policy that misses the real exposure.
• Translate every scope into plain English before it reaches anyone who has to make a decision. Nobody should have to google Files.Read.All to understand a finding.
• Decide per grant, not per app. The same tool can be acceptable on a sales rep’s calendar and unacceptable on a clinician’s mailbox.
• Revoke from the admin console, not by asking the employee to uninstall. Uninstalling the app does not revoke the grant; removing the grant does.
• Tell the employee in a note that does not accuse them of anything, names the sanctioned alternative where one exists, and explains the actual concern in one sentence.
• Write down the disposition — revoked, accepted, or replaced — with a date and a name. That record is what an auditor will ask for.

07Getting a first inventory

The native admin consoles can show you grants one app at a time, with the permissions listed as raw identifiers and no memory of what has changed since anyone last looked. For a small tenant that is an afternoon of clicking, and the result goes stale the day after.

ForgeWatch returns the complete picture from a single read-only authorization: every app holding access, whose account it can act within, what it may read in plain English, when it was first authorized, and whether it is an AI product — with nothing installed on anyone’s device and the history kept from the first scan on. The interactive demo shows the shape of that output against a sample tenant before you connect your own.