The Problem: 140 Doors, and You Only Know About 30
Imagine your office building has 140 doors, and each door has a key that also opens doors at other buildings you do business with. You know about maybe 30 of these doors because you installed them yourself. The other 110 were added by various contractors and vendors without telling you. Now imagine one of those doors gets broken into. Because all the keys are connected, the burglar does not just get into one room; they get into every room in your building and then walk into your partners' buildings using the same connected keys.
That is what is happening right now with AI-enabled software in every organization. This is not a theoretical risk. It is a documented, measured, and actively exploited vulnerability affecting 100% of companies analyzed in the largest study of its kind.
To understand what is at stake, you need to know three things: what "shadow AI" is, what OAuth tokens are, and why the numbers behind this problem are so alarming.
What Is Shadow AI?
Shadow AI refers to artificial intelligence capabilities that software vendors have quietly added to tools your company already uses, without anyone in your IT or security department knowing about it. Your company may have purchased a project management tool three years ago. It was reviewed, approved, and considered safe. But since that purchase, the vendor has embedded AI features into the product: automated summaries, predictive analytics, AI-powered search, or chatbot assistants. These AI capabilities were never part of the original security review. They were never assessed for risk. They simply appeared in the background, and now they are processing your company's data in ways nobody anticipated or approved.
This is different from employees secretly signing up for ChatGPT or other AI tools on their own. Shadow AI in SaaS is more insidious because it arrives inside software your organization has already trusted and approved. The AI capabilities inherit the access permissions of the host application. If your CRM has access to customer records, the AI feature embedded inside it now has access to those same records. If your collaboration tool can read internal documents, the AI feature added to it can read those documents too. Nobody made a conscious decision to give AI access to that data; it simply happened as a side effect of a vendor update.
What Are OAuth Tokens (The Connected Keys)?
OAuth tokens are digital credentials that allow one software application to access another on your behalf. When you connect your CRM to your email marketing platform, or when your chatbot tool connects to your customer database, OAuth tokens are the mechanism that makes that connection work. Think of each token as a key that one application holds, granting it access to data and actions in another application.
The problem is that these tokens are designed to be trusted. When a token is presented, the receiving system treats it as a legitimate, pre-approved connection. There is no firewall to pass through, no password to enter, no multi-factor authentication to complete. The token itself is the proof of authorization. This makes OAuth tokens extraordinarily efficient for legitimate use; it also makes them extraordinarily dangerous when stolen.
A stolen OAuth token is not like a stolen password. A password can be changed. A stolen token grants silent, persistent, trusted access to every system that token connects to. The attacker does not need to hack their way in; they walk in through the front door with a legitimate key.
The 490% Spike: Why This Is Urgent Now
Attacks targeting SaaS applications have increased by 490% in recent years. That is not a gradual uptick; it is an explosion. Attackers have recognized that SaaS applications are both highly connected and poorly monitored. Traditional security tools were built to protect network perimeters, endpoints, and on-premises servers. They were not designed to monitor the web of OAuth connections between cloud applications. This gap in visibility is what attackers are exploiting, and the addition of AI capabilities to these already-connected applications has dramatically expanded the attack surface.
Every AI feature added to a SaaS application introduces new data processing, new API connections, and new potential pathways for an attacker to exploit. When those AI features are added silently, without security review, the risk compounds invisibly until something breaks.
AI capabilities embedded inside approved SaaS applications create invisible attack pathways that bypass every traditional security control.
Why This Matters to You
If your organization uses any cloud-based software (and every organization does), you are almost certainly running AI-embedded SaaS applications that were never reviewed for AI-specific risks. Your vendors have added AI features to tools you approved years ago. Those AI features are processing your data and connecting to other systems through OAuth tokens that your security team may not even know exist.
The 490% increase in SaaS attacks means threat actors are actively hunting for exactly this kind of blind spot. The question is not whether your organization has shadow AI; the question is how many shadow AI connections you have and which ones are exposed.
What Happened: The Largest Shadow AI Study and a Real-World Cascade
The evidence comes from two directions: a massive analytical study that quantified the scope of the problem, and a real-world breach that demonstrated exactly how the attack unfolds in practice. Together, they paint a picture that should concern every executive, board member, and security leader.
A single vendor compromise can cascade through hundreds of organizations via the web of OAuth token connections between SaaS applications.
Finding A: The Scale of Shadow AI Is Universal
Grip Security, a SaaS security firm, conducted the most comprehensive analysis to date, examining 23,000 SaaS environments across organizations of all sizes and industries. The headline finding was staggering: 100% of companies analyzed were running AI-embedded SaaS applications. Not most companies. Not a majority. Every single one.
The average organization had 140 AI-enabled environments. These are not 140 separate AI tools that employees chose to install; they are 140 existing SaaS applications where the vendor has added AI capabilities. Many of these applications were originally approved and purchased before AI features existed. The AI was added through routine software updates, new product tiers, or backend infrastructure changes that required no action from the customer.
Of those 140 AI-enabled environments, the majority were never subjected to a security review that accounted for their AI capabilities. The original vendor risk assessment evaluated the tool as a CRM, a project manager, a communication platform, or a document editor. It did not evaluate the tool as an AI system that ingests data, processes it through machine learning models, and potentially shares insights or data with third-party AI providers.
Consider what this means in practice. A marketing team uses an email automation platform that was approved in 2022. In 2025, the vendor added AI-powered content generation, predictive send-time optimization, and automated audience segmentation. These features process customer behavioral data, email content, and engagement patterns through AI models. The marketing team is delighted by the new features. The security team has no idea these features exist, let alone that customer data is now flowing through AI processing pipelines that were never assessed.
Multiply that scenario by 140, and you begin to understand the scope of the shadow AI problem. Each of these 140 applications has OAuth connections to other systems. Each AI feature processes data that may be sensitive. Each one represents an attack surface that no one is monitoring.
Finding B: The Salesloft-Drift Breach (A Real-World Cascade)
The Grip Security study quantified the risk. The Salesloft-Drift breach showed exactly how that risk materializes. This incident is a textbook example of how a single compromise cascades through the interconnected web of SaaS applications, and it affected some of the most security-conscious organizations in the world.
Attackers Compromised Salesloft's Code Repositories
The breach began when attackers gained access to Salesloft's internal code repositories. Salesloft is a widely used sales engagement platform that connects to CRMs, email systems, and communication tools across thousands of organizations. By compromising the code repositories, attackers gained visibility into how Salesloft's integrations worked, what credentials were stored, and how data flowed between connected systems. This initial foothold gave them a roadmap of every downstream connection.
Pivoted from Salesloft into Drift's Cloud Infrastructure
From Salesloft's repositories, the attackers identified connections to Drift, a conversational AI and chatbot platform. Because Salesloft and Drift were integrated (as many SaaS tools are), the attackers were able to pivot laterally from one vendor's infrastructure to another. This is the SaaS equivalent of moving between floors in a building using connected stairwells. The attackers did not need to breach Drift separately; the integration between the two platforms provided the pathway.
Stole Active OAuth Tokens from Drift's Chatbot Connections
Inside Drift's infrastructure, the attackers found the real prize: active OAuth tokens. Drift's chatbot platform connected to customers' Salesforce instances to pull customer data, update records, and log conversations. Each of these connections was authenticated with OAuth tokens that had been approved by the customer organization. These tokens were live, valid, and granted broad access to Salesforce data. The attackers harvested these tokens, giving them authenticated access to every Salesforce instance that Drift connected to.
Used Legitimate Tokens to Access Salesforce at 700+ Organizations
Using the stolen tokens, the attackers logged directly into Salesforce instances at over 700 organizations. Because the tokens were legitimate and pre-approved, every security system treated the access as authorized. There were no failed login attempts to trigger alerts. There were no unusual authentication patterns to flag. The access looked exactly like Drift's chatbot doing its normal job. The only difference was that a threat actor, not the chatbot, was using the connection.
Major Security Companies Were Among the Victims
The affected organizations included some of the most well-known names in cybersecurity: Cloudflare, Palo Alto Networks, Zscaler, and CyberArk. These are companies whose entire business is security. They have world-class security teams, advanced threat detection, and sophisticated access controls. Yet their defenses were bypassed because the attack did not come through a network vulnerability, a phishing email, or a software exploit. It came through a trusted OAuth connection that their own teams had approved. This detail alone should give every organization pause.
The Breach Bypassed Every Traditional Security Measure
Firewalls did not stop it because OAuth tokens do not pass through firewalls. Endpoint detection did not catch it because no malware was installed on any endpoint. Multi-factor authentication did not prevent it because the tokens were already authenticated. Intrusion detection systems did not flag it because the access patterns looked identical to normal, approved activity. The tokens were trusted by design, and every security tool honored that trust. This is the fundamental problem: the entire security model assumes that approved integrations are safe, and that assumption is wrong.
The OAuth Cascade: Assumptions vs. Reality
"Our perimeter defenses will stop unauthorized access."
"Our vendors are secure; we vetted them during procurement."
"We know what software we have and what it connects to."
OAuth tokens bypass all perimeter defenses entirely; they are pre-authorized access that never touches your firewall.
One vendor breach cascaded to 700+ organizations; vendor security is only as strong as the weakest link in the chain.
110 of your 140 AI-enabled applications were never reviewed for AI-specific risk; vendors added capabilities without notification.
The security model most organizations rely on was designed for a world where software lived inside a network perimeter. SaaS and OAuth have moved the trust boundary, and most security programs have not caught up.
Financial Impact: Why This Keeps CFOs and CISOs Awake
The financial consequences of shadow AI and OAuth-based breaches extend far beyond the immediate cost of incident response. Three interconnected factors drive the true cost: the skeleton key problem, the exponential blast radius, and regulatory fragmentation.
Financial Impact
OAuth tokens bypassing perimeter defenses, cascading compromise across every connected AI-enabled system, and shadow AI creating unmonitored attack surface.
OAuth Tokens as Skeleton Keys
Traditional breaches are contained by the systems the attacker can access with the credentials they steal. OAuth token theft is fundamentally different. A single stolen token can provide access to an entire ecosystem of connected applications. In the Salesloft-Drift case, tokens stolen from one vendor's infrastructure opened doors to Salesforce instances across 700+ organizations. Each of those Salesforce instances likely contained years of customer data, sales pipelines, contracts, pricing information, and internal communications.
The cost of remediating a breach that spans 700 organizations is not 700 times the cost of a single breach. It is exponentially worse because of the coordination required, the legal complexity of multi-party incidents, and the cascading notification requirements when customer data crosses organizational boundaries. Each affected organization must conduct its own investigation, notify its own customers, and engage its own legal and regulatory response.
The Exponential Blast Radius
In a traditional breach, the blast radius is limited to the systems the attacker can reach from their initial access point. In an OAuth cascade breach, the blast radius grows with every connected application. If Organization A uses Drift, which connects to Salesforce, which connects to a data analytics platform, which connects to a business intelligence tool, then a single breach of Drift potentially exposes data flowing through the entire chain.
Now multiply that chain by 140 AI-enabled environments, each with its own set of OAuth connections. The interconnection graph is not linear; it is a web. Every node in that web is a potential entry point, and every connection is a potential pathway for lateral movement. When AI features are added to applications in this web, they add new data flows and new processing pathways that further expand the potential blast radius.
Regulatory Fragmentation Multiplies Compliance Costs
A breach that cascades across hundreds of organizations inevitably crosses regulatory boundaries. Customer data from European organizations is subject to GDPR. Healthcare data is governed by HIPAA. Financial data falls under SOX, PCI-DSS, and sector-specific regulations. California residents' data is covered by CCPA. Each regulatory framework has its own notification requirements, timelines, and penalty structures.
When a single breach triggers obligations under multiple regulatory regimes simultaneously, the compliance cost does not simply add up; it multiplies. Legal teams must coordinate across jurisdictions. Notification letters must be tailored to each regulatory requirement. Regulatory investigations proceed on different timelines with different standards of proof. Fines accumulate across each applicable framework.
For a mid-sized organization caught in a cascade breach, the total cost of regulatory compliance, legal defense, customer notification, credit monitoring, and reputational damage can easily reach seven figures. For the vendor at the center of the cascade, the exposure is measured in tens or hundreds of millions of dollars, plus existential reputational damage.
What You Can Do: Six Steps to Contain the Risk
The scope of this problem is daunting, but it is not unsolvable. The organizations that will weather this storm are the ones that take action now, before they become the next case study. Here are six practical steps that any organization can begin implementing immediately, regardless of size or budget.
Effective defense starts with visibility: you cannot protect what you cannot see, and you cannot manage what you have not discovered.
Discover every SaaS application in use, including shadow IT and free-tier tools
You cannot protect what you cannot see. The first and most critical step is building a complete inventory of every SaaS application your organization uses. This includes officially procured tools, free-tier applications that employees signed up for with corporate email addresses, trials that were never cancelled, and tools embedded within other tools. Many organizations discover 3 to 5 times more SaaS applications than their IT department knows about when they conduct a thorough discovery exercise.
Use SaaS discovery tools that analyze network traffic, SSO logs, browser extensions, and OAuth grants to build this inventory. Pay special attention to applications that have been granted OAuth access to critical systems like your CRM, email, file storage, and financial platforms.
Audit, scope, rotate, and expire OAuth tokens regularly
Treat each OAuth token as a potential master key to your organization. Conduct a full audit of every active OAuth grant in your environment. For each token, document what application holds it, what data and actions it can access, when it was created, and when it was last used. Revoke tokens that are no longer needed, scope active tokens to the minimum permissions required, and implement automatic expiration for all tokens.
Establish a regular rotation schedule for OAuth tokens, similar to how you rotate passwords and API keys. Tokens that sit unchanged for months or years represent the highest risk because they provide persistent access that attackers can exploit long after an initial compromise.
Treat AI-enabled SaaS as managed third-party risk
Any SaaS application that contains AI capabilities should be subject to the same rigorous third-party risk management process as your most critical vendors. This means conducting AI-specific risk assessments that evaluate how the AI processes data, where that data is sent, what models are used, and whether the vendor sub-contracts AI processing to third parties.
Update your vendor risk assessment questionnaire to include AI-specific questions. Ask about data retention policies for AI training, model transparency, data residency for AI processing, and whether AI features can be disabled. Reassess vendors that have added AI capabilities since their last review, even if the contract has not changed.
Require vendors to disclose when they add AI capabilities
Add contractual clauses that require vendors to notify you before or when they add AI capabilities to their products. This is not an unreasonable ask; it is a basic transparency requirement that aligns with emerging regulatory expectations under the EU AI Act and similar frameworks. Without this disclosure requirement, you are flying blind as vendors silently expand the AI surface area inside your environment.
Make this a standard clause in new procurement contracts and negotiate it into renewals. Some vendors will push back, but the organizations that establish this expectation early will be far better positioned to manage AI risk than those that discover new AI features only after an incident.
Map your OAuth interconnections and model blast radius scenarios
Create a visual map of how your SaaS applications are connected through OAuth grants. For each vendor, model what would happen if that vendor were breached. Which of your systems would be exposed? What data could an attacker access? How many downstream organizations could be affected? This blast radius modeling exercise often reveals surprising dependencies that are invisible in day-to-day operations.
Prioritize remediation based on the results. Connections that create the largest potential blast radius should be addressed first, whether through token scoping, network segmentation, or removing unnecessary integrations entirely. Revisit this model quarterly, as the SaaS interconnection landscape changes rapidly.
Have an incident response plan specifically for SaaS vendor compromise
Your existing incident response plan likely focuses on breaches of your own infrastructure. SaaS vendor compromises are fundamentally different: you do not control the breached system, you may not receive timely notification, and remediation depends on revoking OAuth tokens and rotating credentials across dozens of connected applications simultaneously.
Build a dedicated playbook for SaaS vendor compromise scenarios. Include procedures for rapidly identifying all OAuth tokens associated with the compromised vendor, revoking those tokens within hours (not days or weeks), notifying affected internal teams, assessing whether downstream systems were accessed, and communicating with customers if their data may have been exposed through the cascade. Run tabletop exercises using the Salesloft-Drift scenario as a template; it is the most realistic and well-documented example available.
The Bottom Line
Every connected SaaS application is a door, and every OAuth token is a key. Right now, the average organization has 140 of these doors, and the majority were installed without the security team's knowledge. The keys to those doors are shared across vendors, partners, and customers in a web of connections that no one fully understands.
The Salesloft-Drift breach proved that this is not a theoretical concern. A single vendor compromise cascaded into 700+ organizations, including some of the most security-advanced companies on the planet. Their firewalls, their endpoint protection, their multi-factor authentication; none of it mattered because the attack came through trusted, pre-approved OAuth tokens.
If you do not know how many doors you have or who holds the keys, you cannot defend the building. Start by counting the doors. Audit every SaaS application, map every OAuth connection, and treat every AI-embedded tool as a critical third-party risk. The organizations that act now will be the ones that survive the next cascade breach. The ones that wait will become the next case study.
This article is part of our incident analysis newsletter series. Subscribe to receive complete analyses with timeline tables, risk matrices, governance checklists, and actionable recommendations.
