Every AI assistant, workflow automation, sales tool, calendar helper, and productivity app that employees connect to Google Workspace or Microsoft 365 leaves something behind: an OAuth grant.
That grant may be useful. It may also be persistent, broadly scoped, and largely invisible to the controls security teams rely on every day. Password resets do not necessarily remove it. MFA does not stop it once the token is already valid. When an attacker gets hold of a usable token, the attacker does not need to log in the way a person does.
That is the uncomfortable part of OAuth risk. The integration can be legitimate. The user can be legitimate. The original approval can be legitimate. The attack path still exists.
OAuth was built to let applications act on behalf of users without sharing passwords. That model made sense when a small number of approved applications needed access to email, files, calendars, or CRM data. It is under far more pressure now that employees can connect new AI tools and SaaS applications on their own, often faster than security teams can review them.
The result is not always a misconfiguration. In many cases, it is OAuth working as designed in an environment that has changed around it. The security gap is operational: many organizations do not have continuous visibility into which apps are connected, what they can access, how they behave after approval, and how quickly a risky grant can be revoked.
Why OAuth Grants Create a Different Kind of Security Problem
OAuth grants are easy to underestimate because they do not look like traditional credentials. They are not passwords in a vault. They are not interactive logins that pass through the usual user-facing authentication flow. They are permissions that allow an application to access specific resources on behalf of a user.
That distinction matters. A security team may force a password reset, require MFA, tighten conditional access rules, or disable a user account after an incident. Those steps are important, but they do not automatically solve every token-based exposure scenario. A valid token may continue to represent trusted application access until it is revoked, expires, or is invalidated by the platform or administrator action.
For attackers, that changes the economics of access. A stolen password has to survive MFA, login risk scoring, location checks, and other front-door defenses. A stolen OAuth token may allow access through an already approved integration path. From the perspective of some systems, the request may not look like a suspicious login at all. It can look like an application doing what it was previously authorized to do.
That is why OAuth risk cannot be treated only as a shadow IT inventory issue. Knowing that employees connected unapproved tools is useful, but it is not the whole problem. The harder question is whether any approved or semi-approved integration is now behaving in a way that suggests compromise, misuse, or excessive access.
Security leaders appear to understand the concern. Material Security has reported that a large majority of security leaders view unmanaged OAuth grants as a critical or significant risk. The more revealing point is the gap between awareness and operational capability. Many organizations still rely on manual reviews, spreadsheets, ad hoc checks, or employee reports to understand their OAuth exposure.
Those methods can help document risk, but they are not a reliable response mechanism. At best, they provide a partial snapshot of an exposure problem that may already have changed by the time someone reviews it.
The Drift Incident Showed Why Trusted Apps Need Ongoing Review
The Salesloft Drift incident made the OAuth issue more concrete for many security teams. Drift, a sales engagement platform acquired by Salesloft, had OAuth integrations with Salesforce environments across many customer organizations. Public reporting connected the campaign to a threat actor tracked as UNC6395 and described the abuse of valid OAuth refresh tokens to access Salesforce data at scale.
The important lesson is not simply that a third-party application was involved. Security teams already know third parties create risk. The sharper lesson is that the integration itself was trusted. The attackers did not need to convince each victim organization to install an obviously malicious app. They abused access tied to a legitimate business application.
That structure is what makes OAuth-driven incidents difficult to detect with older controls. The token is valid. The application is known. The access path has already been approved. MFA is not the decisive control because the attacker is not necessarily attempting a fresh user login. The attacker is presenting authorization that the environment already accepts.
In the Drift case, reports described data being exported from Salesforce environments and searched for sensitive material such as cloud keys, passwords, and other credentials. Organizations including Cloudflare, PagerDuty, and others disclosed exposure connected to the broader incident. The full details varied by organization, but the pattern was consistent enough to change how many teams think about SaaS integrations.
The right conclusion is not that organizations should ban OAuth integrations. That would be unrealistic for most companies and would likely push employees toward less visible workarounds. AI tools, workflow platforms, support systems, CRM extensions, and productivity applications all depend on delegated access. OAuth is now part of how work gets done.
The conclusion is that trust at installation is not enough. A grant that looked reasonable when approved can become risky later if the vendor is compromised, the token is stolen, the app changes behavior, the user’s access expands, or the organization loses track of who depends on the integration.
Point-in-Time OAuth Reviews Are No Longer Enough
Many OAuth security programs still focus heavily on the moment an app is installed. They check the requested scopes. They look at the vendor. They may flag broad permissions, unknown publishers, or applications with poor reputations. That work matters, but it only answers one question: did this grant look acceptable when it was created?
The Drift-style problem appears later. A legitimate app can become an attack path after approval. A token can be stolen. A vendor can be breached. An application can start making unusual API calls. A user account connected to the app can accumulate more sensitive access over time.
A static permission review cannot see those changes. It can tell a security team what an app could do, but not always what it is actually doing today.
Effective OAuth security needs to move from inventory to behavior. Security teams need to know which applications are connected, which users approved them, what scopes were granted, what data those users can reach, and whether the application’s activity still fits the expected pattern.
That shift is especially important as AI adoption grows. AI tools often need access to email, documents, calendars, chat, code, tickets, or CRM records to be useful. Employees may connect these tools quickly because the productivity benefit is immediate. The security review, if it happens at all, may come later.
A useful OAuth program therefore has to answer practical questions, not just compliance questions:
- Which third-party and AI applications currently have OAuth access to the environment?
- Which grants are tied to executives, administrators, finance teams, engineers, sales leaders, or other high-impact users?
- Which apps have broad read, write, mailbox, file, or directory permissions?
- Which connected apps are making unusual API calls compared with their normal behavior?
- Which grants should be revoked automatically, and which require human review because the app is business-critical?
The last question is where many programs struggle. Security teams do not only need detection. They need a response model that is fast enough to matter and careful enough not to break important workflows without context.
What Continuous OAuth Monitoring Should Include
A mature OAuth security program is not just a list of connected apps. It combines inventory, behavioral analysis, user context, and remediation. The goal is to understand both the likelihood that a grant is dangerous and the potential impact if it is abused.
1. Continuous Behavioral Monitoring
The key question is what the application does after approval. Does it access the same type of data at the same rhythm it always has? Does it suddenly query large volumes of records? Does it begin touching data types it never used before? Does activity appear at unusual hours or from unexpected infrastructure?
Behavior matters because many dangerous scenarios are invisible at the permission layer. A broad permission may sit unused for months. A narrow permission may still expose sensitive data if tied to the wrong user or abused at scale. Monitoring actual API activity gives security teams a better chance of detecting the moment risk changes.
2. Blast Radius Assessment
Not every OAuth grant carries the same impact. The same application connected to a test account is different from the same application connected to the CFO, general counsel, head of sales, or a senior engineer with access to sensitive repositories and documents.
Risk scoring should account for the user behind the grant. What mailboxes, files, drives, groups, tickets, records, and systems can that user reach? Is the account privileged? Does the user handle regulated data, customer records, source code, contracts, security reports, or financial information?
Without blast radius context, teams may spend too much time chasing low-impact grants and too little time on the integrations that could expose the most sensitive data.
3. Graduated Response
OAuth remediation cannot be one-size-fits-all. Some grants should be revoked immediately. An unknown app with broad permissions, suspicious behavior, and no clear business owner should not wait in a ticket queue while data is being accessed.
Other cases require judgment. A major vendor’s business-critical integration showing mild anomalies may need investigation before revocation. Breaking that connection could disrupt sales, support, finance, or engineering workflows. Security teams need enough context to decide quickly and defensibly.
That usually means response policies should support multiple outcomes:
- Automatic revocation for clearly malicious or high-risk grants.
- Security review for uncertain cases involving important applications.
- User verification when the business purpose is unclear.
- Ongoing monitoring when the risk is low but the access remains sensitive.
This is where OAuth security becomes an operational discipline. The tooling has to reduce noise, but it also has to preserve control for decisions that affect the business.
How Material Security Positions Its OAuth Remediation Agent
Material Security’s OAuth Remediation Agent is designed around the idea that OAuth risk needs continuous monitoring rather than one-time approval checks. The product is positioned for Google Workspace environments and focuses on discovering, classifying, and remediating risky OAuth-connected applications.
Material describes the agent as evaluating connected applications across several dimensions. Vendor trust and scope analysis provide the baseline. Behavioral monitoring looks at the actual API activity of the app over time. Blast radius assessment considers the access level and data exposure of the user accounts connected to the app.
Those signals are then combined into a risk view that is meant to help security teams decide what to do next. In high-risk cases, the agent can revoke tokens. In lower-certainty cases, it can surface context for human review, including what the app is, what it has been doing, which accounts it is connected to, and why the grant appears risky.
The commercial value proposition is straightforward: security teams get a way to monitor OAuth grants continuously without turning every app approval into a manual investigation. That matters because the volume of SaaS and AI connections is likely to keep rising. A process that depends on analysts manually reviewing every grant will not scale well in an organization where employees can connect new tools faster than tickets can be triaged.
For buyers, the more important question is not whether OAuth visibility sounds useful. It is what level of response the organization is prepared to automate. Some companies will be comfortable revoking high-risk grants immediately. Others will want security approval before any action affects a user’s workflow. Mature products in this category need to support both risk tolerance and business continuity.
What Security Teams Should Ask Before Buying OAuth Security Tooling
OAuth security is becoming crowded because the problem is real. That also means buyers need to be specific. A dashboard of connected apps is not the same thing as threat detection. A permissions report is not the same thing as remediation. A vendor reputation check is not the same thing as behavioral monitoring.
Before choosing a tool or expanding an existing SaaS security program, teams should ask direct questions:
- Does the tool monitor existing grants continuously, or only evaluate new grants at approval time?
- Can it observe actual API behavior and detect abnormal access patterns?
- Does it understand the sensitivity and reach of the user account behind each grant?
- Can it distinguish between low-risk shadow IT and high-impact token exposure?
- Can it revoke tokens automatically when risk is clear?
- Can it route uncertain cases to security teams or users with enough context to make a decision?
- Does it support the platforms the organization actually uses, including Google Workspace, Microsoft 365, Salesforce, and other high-value SaaS systems?
- Can it produce useful audit trails for revoked grants, user decisions, and policy actions?
These questions keep the conversation grounded. The goal is not to buy another inventory screen. The goal is to reduce the time between OAuth risk appearing and the organization doing something about it.
The Practical Path Forward
OAuth grants are not going away. They are the standard way third-party applications connect to enterprise workspaces, and they are becoming even more important as AI tools need access to business data to provide useful results.
Trying to eliminate OAuth usage entirely is not a realistic strategy for most organizations. It may also create worse visibility problems if employees turn to unsanctioned accounts, personal tools, or manual data transfers. The better approach is to make OAuth access observable, measurable, and reversible.
Security teams can start with a simple operating model:
- Build a current inventory of OAuth-connected applications and the users behind them.
- Prioritize grants tied to sensitive users, privileged accounts, and broad data access.
- Remove stale, unused, and clearly unnecessary grants.
- Monitor app behavior after approval, not just the requested scopes at installation.
- Create revocation policies that distinguish between obvious threats and business-critical uncertainty.
- Review OAuth risk as part of normal identity, SaaS, and incident response operations.
None of this requires treating every third-party app as hostile. It requires accepting that trusted integrations can become attack paths and that static approval does not equal permanent safety.
The organizations that handle this well will not be the ones with the longest spreadsheet of connected apps. They will be the ones that can see when a grant changes from useful to risky, understand what data is exposed, and revoke access quickly when the evidence is strong.
OAuth gave businesses a cleaner way to connect applications without sharing passwords. That benefit still matters. But the same mechanism now sits in the middle of AI adoption, SaaS sprawl, token theft, and third-party compromise.
Security teams do not need to close the door on productivity. They do need to stop leaving persistent OAuth access outside the reach of monitoring and response.