The control you deployed and the risk you have
The usual response to shadow AI is a URL category block and an acceptable-use memo. Both are aimed at a picture of the problem in which an employee opens a chat window and pastes a customer list into it. That does happen, and the block stops some of it. It is no longer where the volume is. The larger exposure is an OAuth grant: a user clicked "Continue with Google" or "Add to Microsoft 365" on an AI product, approved a consent screen, and handed that vendor a durable credential to read mail, files, calendars, tickets or CRM records through the API. From that moment the data leaves through your SaaS provider's servers, on the vendor's schedule, over a connection your egress stack never sees.
This is why the two numbers in most companies disagree so badly. The proxy report says a few dozen AI domains were blocked last month. The tenant's app inventory, when somebody finally exports it, lists two or three hundred third-party applications with active grants, a meaningful share of them AI products, most authorized by individual users with no review. Neither number is wrong. They are measuring different things, and only one of them describes where the data is going.
The distinction matters to a director because it changes what to buy and what to build. Network controls are the wrong layer for a risk that does not traverse the network. The controls that work are identity controls, and they live in places most security programs have not yet staffed: the consent policy in Entra ID or Google Workspace, the connected-app registry in Salesforce, the installed-app list in Slack, and whatever governs API tokens in your ticketing system.
Where AI data access actually originates — our observed ordering
Our ordering of where AI data access originates, drawn from tenant inventories we have been asked to review. An ordering of frequency, not a survey.
What a consent screen actually grants
The consent dialog is designed to be approved. It appears at the moment a user is trying to accomplish something, it is written in product language rather than security language, and the button is blue. Behind it sits a scope list with properties most approvers do not know they are agreeing to.
A grant is durable. The refresh token issued at consent typically survives password changes and often survives the user's next login, which means a credential rotation does not revoke it. A grant is broad by construction, because scopes are coarse: an AI assistant that needs to read the thread you are looking at usually asks for mail.read across the mailbox, since there is no scope for one message. A grant is offline. The vendor holds a token it can use at three in the morning with nobody signed in. And a grant is frequently transitive, because the AI vendor's own backend calls a model provider, so the data path has a second hop your consent screen never mentioned.
Put those four properties together and the practical statement is this: a single click by a sales engineer can create a standing, off-hours, full-mailbox read capability held by a company whose security posture nobody assessed, feeding a model provider nobody named. That is not a policy violation. Under default settings in most tenants it is the product working as designed.
Why the proxy cannot see any of it
Worth being precise about the mechanism, because leadership often assumes the existing stack covers this. When a user pastes text into a chat window on a managed laptop, the traffic goes device to AI vendor, and a proxy or CASB in that path can inspect it. When a user grants OAuth access, the traffic goes AI vendor to Microsoft or Google, server to server. Your device is not in the path. Your network is not in the path. The only witnesses are the audit log of the SaaS tenant and the app registry of your identity provider.
Data loss prevention has the same blind spot for the same reason. DLP inspects egress it can intercept. A vendor pulling files through the Graph API using a token you issued is not egress from your network at all. It is an authorized API read from a Microsoft data center, and it appears in your logs as a successful, legitimate access, because that is exactly what it is.
Endpoint tooling misses it as well. Nothing is installed. Nothing runs on the laptop. The user's involvement ended months ago with a click, and the ongoing data flow has no local footprint to detect.
The inventory that takes a week and settles the argument
Before designing controls, get the list. This is a bounded exercise, usually one engineer for five to ten working days across a mid-size estate, and it converts an anxious conversation into a spreadsheet with owners.
Pull enterprise applications and service principals from Entra ID with their granted permissions and consent type, separating admin-consented from user-consented. Pull the equivalent from Google Workspace under app access control, including which OAuth clients hold restricted scopes. Then do the same for every major SaaS tenant on its own terms, because each keeps a separate registry: connected apps in Salesforce, installed apps in Slack, OAuth apps and personal access tokens in GitHub, add-ons in Atlassian, and the app directory in your HR and finance systems. Add browser extension inventory from your management console, filtered to extensions that read page content.
For each entry record five fields: the vendor, the scopes granted, who consented and when, last-used timestamp, and how many users are attached. Last-used is the field that does most of the work. In every inventory of this kind a large share of grants have not been exercised in months, which makes them free to revoke and shrinks the list needing real judgment down to something a governance group can review in one sitting.
Sorting the list without stopping the business
Three buckets, sorted by what the grant can reach rather than by how the vendor markets itself.
Revoke on sight covers dormant grants, duplicates of a tool you already license, anything holding write or send scopes it does not need for its function, and anything from a vendor with no discoverable security documentation. Send scopes deserve particular attention because they turn a data-exposure problem into a fraud problem: a token that can send mail as your users is a business email compromise waiting for the vendor to have a bad day.
Sanction and govern covers tools people genuinely rely on. The work is to move them from individual user consent to admin consent with a scoped, documented grant, ideally attached to a group rather than the whole directory, and to put the vendor through diligence proportionate to what it reads. Our piece on enterprise AI vendor due diligence covers what to demand in writing.
Replace covers the cases where the demand is real and the answer is an internal build. If four teams have independently authorized transcription tools against the same meeting corpus, the requirement is not a policy. It is a product you have not built yet, and the OAuth inventory just did your requirements gathering for free.
The permission changes that stop the next hundred
Cleaning the list without changing the default recreates it within two quarters. Four settings carry most of the weight, and all four are configuration rather than procurement.
Turn off unrestricted user consent. In Entra ID, move to consent limited to verified publishers and low-impact scopes, or disable it entirely. In Google Workspace, set third-party access to restricted scopes as admin-controlled. This is the single highest-value change on the list and it is a checkbox with a communications plan attached.
Stand up an admin consent request workflow at the same time. Without one, the checkbox creates a wall and users route around it with personal accounts on unmanaged devices, which is strictly worse than what you had. With one, a request lands in a queue with a named reviewer and a service level, and the usual pattern is that most requests are approved with narrowed scopes inside a few days. The queue is also the best intake signal you will ever get about what your workforce actually needs.
Set expiry and re-attestation. Grants should not be permanent. An annual re-attestation in which the owning team confirms the tool is still in use, and everything unconfirmed is revoked, keeps the inventory from silently growing back. Automate the report even if the review stays human.
Alert on the events that matter: a new grant carrying broad read scopes, any grant of send or write permission, admin consent given outside the workflow, and any application whose permission set changes after approval. That last one is the quiet risk. A vendor can request additional scopes in a later version, and in some configurations existing users are re-prompted in a flow that looks routine.
Control impact relative to engineering effort
Editorial ranking of risk reduction per unit of effort. The last row is low because it addresses a path that carries a small share of the data.
Where this becomes a regulatory problem
For a director whose company touches government work or regulated data, the OAuth question stops being hygiene and becomes a finding.
If you handle controlled unclassified information, NIST SP 800-171 requires you to control connections to external systems and to limit access to authorized users and processes. A user-consented AI application holding a token into a repository inside your CUI boundary is an unauthorized external system connection, and an assessor who knows to ask for the app registry will ask for it. If you sell to federal agencies, the FedRAMP boundary question is adjacent: your authorized service inherits nothing from a third-party integration your customers' users authorized on their side.
Under NIST SP 800-53, the relevant families are access control and system and information integrity, and the specific gap is that the grants are not enumerated anywhere in your system security plan. Auditors increasingly ask for the third-party application inventory by name. On the AI side, both the NIST AI Risk Management Framework and ISO/IEC 42001 expect an inventory of AI systems in use, which by any reasonable reading includes AI applications holding production data through an API. A company that cannot produce that list cannot claim alignment with either.
The commercial consequence arrives sooner than the regulatory one. Customer security questionnaires now routinely ask which AI tools process the customer's data and under what terms. Every unsanctioned grant is a question you cannot answer truthfully and quickly, and in enterprise sales that delay has a price.
The prompt injection angle nobody budgets for
One more mechanism, because it converts a privacy issue into a security issue. Many AI integrations do not just read. They act. An assistant with calendar write access schedules meetings. A ticket triage bot with write scope updates and closes tickets. A mail assistant with send scope replies.
Any of those reads content that outside parties control. Prompt injection sits at the top of the OWASP Top 10 for LLM Applications, and MITRE ATLAS catalogs the techniques by name. The failure is that text arriving in an inbound email or an attached document can carry instructions aimed at the model rather than the reader, and the model acts using the authority in your token. The vendor's security is now part of your attack surface, but the authority being abused is yours, and the audit log will show your organization's token performing the action.
This is the concrete reason send and write scopes deserve a different bar than read scopes. A read grant risks disclosure. A write grant risks action taken in your name, at machine speed, triggered by anyone who can get text in front of the assistant. If you are designing systems on the other side of this problem, we wrote about what an enterprise security review asks of agent architectures.
What the work costs
The inventory and first cleanup pass runs one engineer for one to two weeks on a mid-size estate, call it fifteen to thirty thousand dollars of effort, and it is the cheapest risk reduction available to most companies because a large fraction of grants revoke without a single support ticket.
The governance build, meaning consent policy changes, the request workflow wired into your existing ticketing system, automated inventory collection across tenants, and the alerting, is typically four to eight weeks and lands between sixty and a hundred and fifty thousand dollars depending on how many tenants and whether the workflow needs custom integration. That is a one-time cost against a control that keeps working.
Building the sanctioned internal alternative is the variable. A transcription and summarization service running inside your own boundary, with your retention rules and your identity model, is a three to five month build. Whether it is worth it depends on how many teams independently authorized the same category of tool, and the inventory answers that question with data rather than opinion.
Bottom line
Shadow AI is not primarily a browsing problem and the controls aimed at browsing are measuring a small share of the exposure. The data leaves through tokens your own identity provider issued, used server to server, invisible to the proxy, the CASB and the endpoint agent. The fix is not another network appliance. It is an inventory across every SaaS tenant, a consent default that stops the next hundred grants, a request workflow so people do not route around it, and a real decision about which tools to sanction, which to revoke, and which demand is large enough to build for. That work is measured in weeks, and it produces the list you will need the first time a customer, an assessor, or your board asks what AI is touching your data.
Frequently asked questions
It reduces one path, paste into a chat window on a managed device. It has no effect on OAuth grants, because that traffic runs between the AI vendor and your SaaS provider and never crosses your network. Treat it as a small part of the control set, not the control set.
Enterprise applications and service principals in Entra ID, app access control in Google Workspace, then each SaaS tenant separately: connected apps in Salesforce, installed apps in Slack, OAuth apps and personal access tokens in GitHub, add-ons in Atlassian. There is no single console, which is why the inventory has to be assembled deliberately.
For dormant grants, which are usually a large share of the list, no one notices. For active tools, revocation forces a re-authorization prompt, so pair the cleanup with a communications note and a request workflow. The last-used timestamp tells you which category each grant is in before you touch it.
Under NIST SP 800-171 an unreviewed third-party application holding a token into a CUI repository is an external system connection you have not controlled, and assessors do ask for the app registry. For FedRAMP-authorized services the issue is boundary discipline: an integration authorized by users is not covered by your authorization.
Send and write scopes, ahead of read. A read grant risks disclosure. A send or write grant lets an injected instruction inside content the assistant processes cause action taken under your organization's authority, which is why OWASP ranks prompt injection first for LLM applications.