Shadow AI is an access problem not a traffic problem

For twenty years, "shadow IT" meant a network question. Someone signed up for a tool you didn't sanction, and the way you found out — the way the whole security industry was built to find out — was by watching traffic. Firewalls logged the domains. A CASB flagged the unsanctioned SaaS. DLP watched for sensitive strings leaving the building. The mental model was a perimeter, and the discovery method was traffic that crossed it.

That model still works for what it was built for. It does not work for shadow AI, and the reason is worth stating plainly because most of the tools being sold to solve shadow AI are quietly still solving the old problem.

Shadow AI is not primarily about where your people go. It's about what your people — and your vendors — have *granted.* It's an access problem wearing a traffic problem's clothes. And if you go looking for it in your network logs, you will find a comforting, incomplete, and slightly dangerous picture.

What the traffic model misses

Here's the shape of the miss. Picture a staff member who connects an AI assistant to their work Google Workspace. They click "Allow." A screen appears asking for permission to read and manage your email, see and download all your Google Drive files, read your calendar. They click through it the way everyone clicks through those screens. Done.

Now ask your firewall to tell you about it.

The firewall sees a connection to `google.com` and `an-ai-vendor.com`. Both are almost certainly on your allowlist — they're mainstream services. No policy fired. No sensitive string crossed the wire in that moment, because nothing sensitive moved in that moment. What happened instead is that a third-party AI now holds a standing grant to read that person's entire Drive and mailbox, exercisable any time, from the vendor's servers, without generating any further traffic through your perimeter at all. The data exposure isn't an event your network sees. It's a permission that already left the room.

This is the structural break. Traffic-based tools detect sessions — a person, at a keyboard, sending something now. AI increasingly reaches your data through delegated, persistent access: OAuth grants, app connections, and the newer connector standards (like MCP, which we unpack for a compliance audience in MCP — Model Context Protocol explained for people who get audited) that let an AI act with someone's authority long after they've closed the tab. You cannot see a standing grant by watching for a moment of traffic, because the whole point of the grant is that the moment already passed.

The inventory that actually answers the question

So the discovery method has to change to match. The artifact that tells you the truth about shadow AI isn't a traffic report. It's a grant inventory — the list, pulled from your identity provider, of every third-party application your people have authorized against your Google Workspace or Microsoft Entra, what scopes each one holds, and who approved it.

That list is unglamorous and it is devastating the first time you read it. It's where you find the AI tool three people connected to your Drive during a free trial that ended eight months ago — the trial's gone, the grant isn't. It's where you find the meeting assistant with calendar and email read access that nobody remembers authorizing. It's where "we don't really use much AI" quietly becomes a two-page list. The whole how-to lives in Reading OAuth grants — the shadow-AI map in your Workspace and Entra, and it's the single highest-yield hour a small compliance team can spend right now.

The reframe is the entire point: stop asking "what did my people visit" and start asking "what did my people grant." The first question is a traffic log. The second is a governance document. Only the second one maps to what an examiner is actually going to ask, and only the second one survives the fact that the risky access is invisible to your perimeter.

Why this maps to your obligation, not just your security

This isn't a security-team preference dressed up as compliance. The regulatory framing points the same direction, if you read it literally.

If you're an RIA or broker-dealer, the amended Reg S-P rule (17 CFR 248.30(a)(5)) requires ongoing oversight and monitoring of service providers. An AI holding a standing OAuth grant against your systems is a service provider with access to your data — whether or not anyone signed a contract with it. A grant inventory is how you'd even know it exists to oversee. If you're a credit union, NCUA's proportional diligence framework (07-CU-13 / SL 07-01) asks for reasonable procedures scaled to a vendor's access and criticality — and access is the exact word the grant list quantifies. In both cases the compliance question and the security artifact turn out to be the same list. That's rare and it's convenient. Use it.

The honest part — what a grant inventory is not

If I stopped here it would read like a firewall replacement, and it isn't. An OAuth-grant inventory is powerful precisely because it's narrow, and a trust brand has to say where the narrow edges are.

It shows you access, not payloads. The grant tells you an app can read your Drive. It does not tell you what it read, or when, or what the AI did with it. That's a different, harder question — and for some tools you can't answer it even if you want to. Audit-log export for the ChatGPT product line, for instance, is gated to the Enterprise and Edu tiers with 30-day retention; a team on ChatGPT Business simply can't produce those records. The grant list finds the door. It doesn't hand you the security-camera footage behind it.

It's point-in-time. People grant new access every week. An inventory is true the day you run it and starts drifting the day after, which is why the honest version of this is re-run on a cadence, not solved once.

And it has blind spots the perimeter tools were actually good at. A grant inventory does not catch someone pasting member data into a personal ChatGPT account on their phone — no OAuth grant, no corporate identity, nothing to inventory. It doesn't catch AI features baked inside a SaaS product that don't use a separate OAuth connection. It doesn't watch outbound content. For those, network and DLP controls still earn their keep. The point was never that traffic tools are useless. It's that they were built for a different question, and shadow AI is mostly not their question.

So the honest definition of shadow AI discovery is this: it's a read-only, point-in-time map of the standing access your people have granted to AI — the single biggest, most invisible piece of the problem, and explicitly not the whole of it. Anyone who tells you one scan makes shadow AI "handled" is selling the old perimeter dream in a new font.

That map is the first thing a Discover scan assembles — the grant inventory, read against your identity provider, turned into a list you can actually govern and hand to an examiner. We run it with you, we tell you in the report itself what it doesn't cover, and we'd rather you know your blind spots than believe you don't have any.

If "we don't really use much AI" is the sentence you've been telling yourself, request your Discover scan and let's read your grant list together. It's usually the most useful surprise a compliance team gets all year.