Your employees connect AI writing tools, meeting assistants, browser extensions, and automation agents to inboxes, drives, calendars, CRMs, and code repositories faster than any security team can review them. Each click of an “Allow” button creates a standing trust relationship, and the relationship can outlive the task, the user, and sometimes the vendor’s security posture.
Your OAuth inventory is now part of your attack surface. The good news: you can audit it, and the first pass rarely takes as long as you fear.
Why an OAuth Grant Is a Persistent Liability, Not a One-Time Click
OAuth solved a genuine problem. Instead of handing an app your password, you grant it scoped, delegated access to a defined slice of data. Microsoft’s Entra documentation describes consent as the process where a user grants an application permission to reach a protected resource, and it uses the example of an app requesting permission to read a signed-in user’s mailbox. The model is sound. A tool receives a token, not your credentials, and the token names exactly what the tool may touch.
Here is where the trouble starts. Consent arrives in two forms. A user can approve an app for a single account, and an administrator can approve an app for the whole tenant at once. Once consent gets recorded, users usually do not approve again on later sign-ins to the same app. The prompt vanishes after one click. The authorization does not.
A grant approved during a Tuesday afternoon demo can keep reading mail a year later, long after the person who approved it changed teams and the tool fell out of use. No fresh login shows up in your sign-in logs, because the app already holds a refresh token and mints new access tokens on its own schedule. Nobody sees a prompt. Nobody receives an alert. The access simply persists, quiet and fully legitimate on paper.
The risk is not OAuth. Password sharing would be worse. The risk is durable, under-reviewed, third-party access sitting in an inventory nobody reads.
Why AI Tools Changed the Math
SaaS sprawl is an old problem. What changed is the speed and the surface. AI assistants and agent-style workflows ask users to connect email, documents, calendars, chat logs, ticketing systems, CRM records, and code repositories, because reaching your data is how the tools deliver value. A summarizer needs your meetings. A drafting assistant needs your documents. An enrichment agent needs your CRM. Access is the product.
Every new tool multiplies the count of live grants, and the approvals happen at the edge, one employee at a time, usually without security in the loop. A marketer wires up a note-taker. An engineer connects an AI code reviewer to the repository. A sales rep links an enrichment tool to Salesforce. Each request looks reasonable in isolation. In aggregate, they build a web of standing access nobody has mapped.
The blast radius of any single grant depends on five variables: the scope it holds, the lifetime of its tokens, the privilege of the user who approved it, the security posture of the vendor behind it, and whether anyone monitors the integration after approval. Get all five wrong on one high-scope grant, and a forgotten productivity app becomes a standing export pipe out of your most sensitive systems.
The problem is access expansion, not AI magic. Naming it plainly keeps the audit focused on permissions and tokens, not on whether AI is friend or foe.
The Salesloft Drift Breach: A Backdoor With Valid Credentials
The clearest recent example of the risk carries a name. Google’s Threat Intelligence Group reported an actor tracked as UNC6395 used compromised OAuth tokens tied to the Salesloft Drift application to reach Salesforce customer instances between August 8 and at least August 18, 2025. Over roughly ten days, the actor systematically queried and exported large volumes of records from more than 700 organizations, a list reported to include Cloudflare, Palo Alto Networks, Proofpoint, Zscaler, and others.
The method is the lesson. The attacker did not break Salesforce. Google stated the incident did not stem from a vulnerability in Salesforce’s core platform. The intruder held valid OAuth tokens for a trusted, already-approved integration, and used them to run automated queries and bulk exports through legitimate Salesforce APIs, complete with custom user-agent strings to blend in. To most monitoring, the traffic looked like a sanctioned app doing sanctioned work.
The intent made it worse. Inside the exported data, UNC6395 searched for secrets: AWS access keys, passwords, and Snowflake-related tokens. A CRM export became a hunting ground for credentials into other systems. Google advised Drift customers to treat any authentication token stored in or connected to the platform as potentially compromised, because the exposure reached beyond Salesforce into other integrated services. On August 20, 2025, Salesloft and Salesforce revoked all active access and refresh tokens for the Drift application.
Read the sequence again with your own environment in mind. A trusted third-party integration, holding tokens your users approved, quietly exporting your data to look for keys into everything else. No firewall was breached. The door was already installed, and someone stole the key.
What the 2026 Data Says About Third-Party Trust
The Drift case is not an outlier. Verizon’s 2026 Data Breach Investigations Report found vulnerability exploitation now begins 31% of breaches, up from 20% the year before, overtaking stolen credentials as the single top initial-access vector for the first time in the report’s history. The report analyzed more than 22,000 confirmed breaches, and it noted attackers using automation to shrink the window between a disclosed flaw and a working exploit.
The supply-chain signal is just as sharp. Google Cloud’s H1 2026 Cloud Threat Horizons report found 21% of tracked cases involved compromised trusted relationships with third parties. The report named the Drift OAuth tokens and the theft and abuse of Salesforce Gainsight tokens as specific examples. Its recommendation to defenders is worth quoting in spirit: govern OAuth and third-party application access by auditing and restricting the scopes granted to external integrations, because compromised tokens let attackers exfiltrate data through the SaaS supply chain without tripping standard login alerts.
Two large, independent 2026 reports, pointing at the same seam. The rest of this guide turns the warning into a repeatable process. Six steps, run every quarter.
Step 1: Discover Every Connected App and Token
You cannot govern what you cannot see, and the first inventory is always the hardest because grants hide in many places at once. Start by pulling everything you can from the systems of record.
Check Microsoft Entra Enterprise Apps, and query Microsoft Graph for application permissions and OAuth2 permission grants, including service principals. Pull Google Workspace API controls from the Admin Console, and export the OAuth Token Audit logs, which record when a third-party app gets authorized to reach Google Account data such as Contacts, Calendar, and Drive files. Add identity-provider logs from Okta, Ping, Entra, or whichever IdP you run. Layer in CASB, SSPM, or SaaS security tooling where you have it. Finish with browser-extension and shadow-SaaS discovery as a secondary sweep, because a fair share of grants start with an employee signing up through a browser.
One warning shapes the whole step: every discovery tool has blind spots. Some see IdP-authenticated apps but miss direct OAuth grants. Some catch browser sign-ups but skip backend API tokens created server to server. Some cover Microsoft and Google well and lose smaller SaaS apps entirely. No single console holds the full picture, so keep the process tool-agnostic and assume your first inventory is incomplete. An incomplete inventory still beats none, and the gaps become the roadmap for your next pass.
Capture more than app names. For each grant, record the vendor, the user or admin who approved it, the connected system, the scopes held, the token type, and the last observed activity. The metadata is where the audit gets its teeth.
Step 2: Map Scopes to Actual Need
A grant’s danger lives in its scope, not its logo. A well-known vendor with a broad scope can leak more than an obscure vendor with a narrow one. Sort every grant by what it can reach, then compare the permission against the job the tool performs.
| Risk tier | Permission pattern | Example | Action |
| Low | Sign-in only, basic profile identity | “View basic profile” | Pre-approve if the vendor is known |
| Medium | Read-only access to limited business data | Calendar read, selected Drive file read | Approve if tied to a real workflow |
| High | Broad read across mailbox, Drive, CRM, tickets, chat | Read all email or all files | Require security review and a named owner |
| Critical | Write, delete, send, export, or admin-level access | Send mail, modify files, export CRM, manage users | Default deny unless business-critical and monitored |
Google’s own scope documentation gives you a ready-made vocabulary here. It separates non-sensitive scopes, sensitive scopes, and restricted scopes, and it defines restricted scopes as requests for highly sensitive user data such as email content. Start your review by sorting grants into the same three buckets. Email, files, calendars, CRM exports, tickets, and code repositories all deserve heavier scrutiny than a sign-in scope.
To decide whether a scope is justified, run a three-question test on each tool. First, what task does the tool perform? Summarize meetings, draft email, enrich CRM records, automate tickets. Second, what minimum data does the task require? Calendar metadata, one selected document, one CRM object, one ticket queue. Third, what action does the tool need to take: read, write, send, delete, export, or administer? A meeting assistant needs calendar metadata and meeting details, not full Drive access. An AI writing tool needs one selected document, not every file in a shared drive. A CRM enrichment tool needs read access to selected objects, not a bulk export across every account, opportunity, and case.
Understand the risk ladder behind those actions. Read-only is safer than read-write, but a broad read scope can still leak enormous volumes of data, as the Drift case proved. Write access creates integrity risk, because the tool can alter records. Send access creates impersonation and phishing risk, because the tool can email as your users. Delete access creates operational and evidence-destruction risk. Admin access creates tenant-level risk, the widest blast radius of all. Refresh tokens sit underneath every rung, extending the window of exposure long after the initial grant.
One rule carries the whole step. Access should match the job, not the product’s wish list.
Step 3: Evaluate the Vendor Before You Trust the Token
A token is only as safe as the company holding it. A tool with a modest scope still routes your data through the vendor’s infrastructure, staff, and subprocessors. Before approving a high-impact integration, run a short but real vendor review rather than a logo check.
Ask for a SOC 2 Type II report, not a trust badge on a marketing page. Request the subprocessor list and data-residency terms, so you know where your data physically lives and who else touches it. Read the data-retention rules, and confirm whether customer data trains the vendor’s models by default. Check the breach-notification commitments, the token storage practices, and support for scoped access, tenant restrictions, and IP allowlisting. Confirm whether the vendor offers audit logs you can consume, and whether it supports SCIM, SSO, and role-based access control. A public trust center and a visible record of recent security advisories are good signs, because they show a vendor willing to be measured in daylight.
One caution keeps teams honest here, and it matters enough to state carefully. A SOC 2 Type II report is an attestation about the design and operating effectiveness of controls over a period of time, commonly several months, unlike a Type I snapshot at a single point. The report raises confidence for higher-risk vendors. It does not tell you whether a requested OAuth scope is appropriate. It reports something about controls. It says nothing about whether an app genuinely needs mailbox write access. Read the report, then still question the scope. Treat the two judgments as separate decisions, because a well-controlled vendor can still ask for far more access than the job requires.
Step 4: Revoke Orphaned and Post-Offboarding Tokens
Most dangerous grants are not new. They are forgotten. The highest-value targets in your inventory are the ones nobody owns anymore, and they cluster in predictable places.
Hunt down grants tied to disabled, suspended, or departed users. Flag grants approved by people who changed roles, because the access rarely changes with the job. Pull grants for tools no longer in use, vendors with stale contracts, and pilots that ended without cleanup. Watch for grants attached to personal accounts or unmanaged domains, and grants with broad scope and no recent activity. Any grant with no identifiable business owner belongs at the top of the review pile.
Revocation needs an operational path, not a spreadsheet of risky apps. Microsoft’s Entra guidance shows administrators how to review and revoke permissions granted to enterprise applications, covering both admin-granted and user-granted consent, with methods through the portal, Microsoft Graph, and PowerShell. Build the same muscle in Google Workspace and every other core platform, so a flag in the audit turns into a revocation the same day.
One detail trips up teams who assume a click ends the risk. Revocation is not instant. Microsoft warns there can be a period between initiating revocation and access actually stopping, because existing tokens may stay valid for a window. Your offboarding process must cover SaaS grants and refresh tokens, not the user account alone. Disabling a login while leaving live refresh tokens in place is a half-measure, and the missing half is where the damage happens.
Refresh tokens deserve their own paragraph, because they are the long tail of exposure. OWASP’s OAuth 2.0 Cheat Sheet explains a refresh token lets a client obtain new access tokens after the current one expires, and recommends rotation or sender-constrained tokens to limit the danger. IETF RFC 9700, published in January 2025, sets the current best practice for OAuth 2.0 security and is worth a read for the team designing your token policy. Audit refresh tokens with the suspicion you reserve for privileged credentials, because a stolen refresh token can keep an attacker inside long after you think you closed the door.
Step 5: Move From Static Inventory to Behavioral Baselines
Inventory answers one question: what app has access? It cannot answer the harder and more urgent one: what is the app doing right now? A legitimate integration turns dangerous the moment the vendor gets breached, a token leaks, or an attacker hijacks the app, and none of it changes the entry in your grant list. The Drift tokens looked perfectly valid the whole time they were exporting data.
NIST’s SP 800-228 guidance for API protection points toward the controls that close the gap: real-time monitoring to catch traffic spikes, hard limits on third-party API consumption, and enough telemetry to judge whether policies hold. The guidance notes monitored data such as payload patterns and anomaly scores can support real-time containment, which is the difference between reading about an export next quarter and stopping one this hour. SaaS security vendors such as Obsidian and AppOmni make a parallel case from the field: inventory alone leaves attackers in blind spots, because a static list never shows abuse in motion. Attribute the framing to guidance and practice rather than treating it as gospel, and the point still stands.
Decide what normal looks like for each integration, then watch for departures from it. Unusual API call volume. Mass or bulk export patterns. Access from new geographies or unfamiliar user agents. Failed token use, impossible-travel patterns, and sudden reads of sensitive objects the tool never touched before. Activity outside normal business hours. Inventory tells you what exists. Behavioral monitoring tells you when a trusted integration suddenly starts acting like a vacuum cleaner in the document store.
Step 6: Automate Policy Without Blocking the Business
An audit you run once decays by the next quarter. The point of the first five steps is to earn a system, not a one-time cleanup. Turn the findings into standing policy so governance holds without heroics, and so the business does not route around a security team it sees as a bottleneck.
Pre-approve low-risk apps with sign-in-only or basic-profile scopes, so common tools clear without friction. Require a named business owner’s approval for read-only access to sensitive systems. Require a security review for anything involving broad read, write, delete, send, export, admin, or restricted scopes. Auto-expire grants unused for 60 or 90 days, so dormant access dies on its own instead of waiting for a human to notice. Re-review high-risk grants every quarter, and document every exception with an owner, a reason, an expiry date, and a compensating control.
Route the approvals through a workflow instead of a helpdesk queue. Microsoft’s admin consent workflow lets users request access to apps that need admin approval, sending the request to designated reviewers who can approve, block, or deny it. High-risk asks land in review while pre-approved low-risk tools clear on their own. Keep a known-good catalog of approved AI tools and integrations, so employees reach for a sanctioned path rather than a shadow one. A good catalog does more for your risk than a dozen blocked requests, because it gives people a fast yes instead of a slow no.
The Quarterly OAuth Audit Checklist
Use the following as a boxed, repeatable routine. Run it every quarter, and fold the same steps into offboarding and incident response.
- Export all third-party app grants from Microsoft Entra, Google Workspace, and every other core SaaS platform.
- Include user-granted consent, admin-granted consent, application permissions, delegated permissions, service principals, API keys, and refresh tokens wherever available.
- Tag each grant by owner, vendor, app category, connected system, scope tier, business purpose, and last activity.
- Flag grants with broad read, write, delete, send, export, mailbox, Drive, CRM, ticketing, repository, or admin-level access.
- Compare each scope against the actual workflow, and reduce broad access to narrower scopes where the vendor supports it.
- Revoke grants tied to departed users, role-changed users, inactive apps, expired contracts, unknown owners, and abandoned pilots.
- Review vendor risk for high-impact tools, especially AI tools reaching sensitive data.
- Add behavioral alerts for unusual API volume, mass exports, new geographies, new user agents, and access to sensitive objects.
- Route future high-risk consent requests into admin review.
- Document every exception with an owner, a reason, an expiry date, and a compensating control.
Run the First Audit With Imperfect Data
Do not wait for perfect tooling or a complete inventory. Your first pass will be messy, and it will still surface the worst problems fast: the departed admin’s live token, the writing tool with full mailbox access, the enrichment app exporting the whole CRM, the pilot nobody shut down. The rough version delivers most of the risk reduction, and it does it in days.
The mature version comes later, built from automated consent workflows, pre-approved catalogs, owner-based exceptions, quarterly reviews, and behavioral alerts that notice when a trusted integration starts behaving like a burglar with a keycard. AI tools are not the villain here, and neither is OAuth. The villain is forgotten trust, and forgotten trust is the one part of your attack surface you can revoke the moment you decide to look.
The post How to Audit Your SaaS OAuth Grants Before an AI Tool Becomes a Backdoor appeared first on .
