“Allow All” is the new SQL injection — and shadow AI is the multiplier turning a known structural risk into the most consequential attack surface of 2026.
By Thorsten Meyer — May 2026 · Software Security · Part 4
The Vercel breach piece documented the technical chain: Lumma Stealer → Context.ai employee compromise → OAuth tokens → Google Workspace → Vercel employee account → environment variable exfiltration → $2M BreachForums listing. Each step in isolation looked harmless. The composition produced one of the most consequential supply-chain breaches of 2026.
The structural failure was OAuth permission grant. A Vercel employee installed Context.ai with their corporate Google Workspace account and granted it “Allow All” permissions — broad read access to the entire Workspace, including Google Drive content, Gmail, calendar, contacts. When Context.ai’s OAuth tokens were stolen, the attacker inherited those permissions. Not because OAuth was broken, but because OAuth was deployed in a way where one click on a consent screen could grant enterprise-wide access without admin review.
This piece is the read on why that pattern is the structurally most consequential attack surface of 2026, why it has direct historical analogue (SQL injection sat at OWASP #1 from 2003 to 2017 for the same reason — ubiquitous deployment of vulnerable patterns + slow industry-wide remediation), why shadow AI is the multiplier turning a known structural risk into a cascade event, and what the platforms (Google, Microsoft, Okta, Salesforce) need to do operationally to close the gap.
The headline finding: OAuth as a protocol is fine. OAuth as deployed across enterprise productivity stacks is structurally broken. The “Allow All” consent pattern is the SQL-injection-equivalent of 2026 — a well-known risk class with well-understood mitigations that nonetheless remains the dominant attack surface because deployment defaults favor permissiveness over security. Shadow AI is the consequence multiplier: the average enterprise user now connects 50+ third-party apps to corporate identity, of which a growing fraction are AI productivity tools that require broad data access by design. One click. One token theft. One supply chain attack. 700+ organizations.
The 2025 Drift/Salesloft breach (UNC6395, 700+ organizations, 1.5 billion records, 70+ lawsuits, FBI advisory CSA-2025-250912) was the precedent. The 2026 Vercel breach was the recapitulation. The next instance is already being staged. The question is whether structural intervention happens before the next instance lands at scale.
The OAuth permission
apocalypse.
“Allow All” is the new SQL injection. Shadow AI is the multiplier turning a known structural risk into the most consequential attack surface of 2026.
OAuth as a protocol is fine. OAuth as deployed across enterprise productivity stacks is structurally broken. The “Allow All” consent pattern has the same anatomy that made SQL injection OWASP #1 from 2003-2017 — well-known risk, ubiquitous deployment, slow remediation. Average enterprise user connects 50+ third-party apps to corporate identity. One click. One token theft. 700+ organizations.
SQL injection sat at OWASP #1 for 14 years. Same structural anatomy.
Both vulnerabilities have a protocol that’s fine in isolation and a deployment pattern that favors exploitability. Both have well-known mitigations. Both persist because deployment patterns spread faster than remediation. OAuth permission abuse is on year 3-4 of its dominance.
14 years of SQL injection at OWASP #1 is the historical baseline. OAuth permission abuse is on year 3-4 of dominance. Without structural intervention, expect another decade as the dominant supply-chain attack vector.
enterprise OAuth permission management tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Same pattern. Different vendors. Recurring.
Drift/Salesloft was the precedent. Vercel was the recapitulation. LiteLLM was the parallel. The structural pattern — OAuth supply chain compromise leveraging “Allow All” permission grants — produces breach after breach across vendors and attack methods.
OAuth token security monitoring software
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Shadow AI is not shadow IT. Three structural differences make it worse.
Shadow IT has been a known governance problem for two decades. Shadow AI is categorically different in three ways that turn a manageable problem into the dominant supply-chain attack pattern.
Architecting Solutions with SAP Business Technology Platform: An architectural guide to integrating, extending, and innovating enterprise solutions using SAP BTP
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
The platforms are responding. Incrementally.
Google and Microsoft both shipped meaningful improvements in 2026. But the default deployment behavior remains permissive. Until platform defaults change, individual employees can grant enterprise-wide access without admin review.
- Google granular OAuth consent · web apps Jan 7 · Chat apps Jan 20 · checkbox scopes
- Microsoft Agent 365 GA May 1 · Shadow AI page · prompt injection blocking · Entra controls extended to Copilot Studio
- Okta adaptive MFA for OAuth grants · centralized OAuth grant management
- ITDR vendor maturation · Push Security, Permiso, Reco AI, Obsidian, AppOmni, Nudge Security, Adaptive Shield
- Google Admin API controls · Trusted/Limited/Specific/Blocked categories
- Default platform behavior favors permissiveness. Google Workspace + M365 still ship with user-level OAuth consent enabled by default
- Granular consent applies only to new grants. Pre-existing grants unaffected
- Developer opt-in required. Many apps don’t yet support granular consent
- No automatic scope minimization for AI tools at platform layer
- No OAuth token rotation enforcement · tokens valid indefinitely
- No default audit logging surfaced in security dashboards
- No periodic re-consent requirement · forgotten grants persist
“Most Google Workspace and Microsoft 365 environments are still configured to let any employee grant third-party apps access to their enterprise account. Move to admin-managed consent. New apps get reviewed before they can touch corporate data. That one change would have blocked a Vercel employee from granting Context.ai enterprise-wide scopes in the first place.”
SafeNet IDProve 110 6-digit OTP Token for Use with Amazon Web Services Only
OTP token that provides secure remote access with strong authentication
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Six priorities. Highest-leverage first.
Don’t wait for platform defaults to change. The single highest-leverage configuration change is admin-managed consent. Each enterprise that switches removes their employees from being the next Vercel-style entry vector.
LEVERAGE
SELECTION
gmail.readonly · gmail.send · drive · calendar + contacts · Salesforce api · Slack users:read.email + channels · GitHub repo · cloud broad-scope service accounts. Each represents a potential Drift-style or Vercel-style blast radius.REVIEW
AWARENESS
PLAYBOOKS
OAuth as a protocol is fine. OAuth as deployed is structurally broken. Same anatomy as SQL injection. Same multi-year dominance ahead unless platform defaults change. One configuration change blocks the entire Vercel attack chain.
I · The SQL injection analogy · why this comparison is structural, not rhetorical
SQL injection held OWASP’s #1 spot on the web application vulnerability rankings continuously from 2003 through 2017 — 14 years dominant. It dropped to A05 only in the 2025 OWASP Top 10, still with 14,000+ CVEs in the category. The mitigations have been well-understood throughout: parameterized queries, prepared statements, input validation, ORM frameworks that handle escaping automatically. None of these were secret. The vulnerability persisted because deployment patterns were faster to spread than remediation patterns.
The structural anatomy of SQL injection:
- A protocol that’s fine in isolation. SQL itself is not vulnerable. The vulnerability arises from how applications compose queries with user-supplied input
- Default patterns that favor exploitability. String concatenation of queries was the easiest way to write database access for two decades. Parameterized queries required more code and conscious effort
- Distributed deployment surface. Every database-backed web application was a potential exposure. The fix had to happen at every individual application
- Asymmetric remediation cost. A single bug took minutes to introduce; auditing an entire codebase for similar patterns took weeks. The discovery-to-exploitation pipeline was much faster than the discovery-to-remediation pipeline
- Industry-wide pattern failure. Educational materials, framework tutorials, code examples — all reinforced the vulnerable pattern for years before correction propagated
OAuth “Allow All” replays each of these structural characteristics:
- OAuth as a protocol is fine. RFC 6749 and OAuth 2.0 are not the vulnerability. The vulnerability arises from how applications and enterprise environments compose OAuth permissions
- Default patterns favor permissiveness. Most OAuth integrations request broad scopes because granular scope design is harder. Most user consent flows present “Allow All” as a single button. Most administrators leave user-grant capability enabled by default in Google Workspace and Microsoft 365
- Distributed deployment surface. Every third-party SaaS integration is a potential exposure. Each employee in a typical enterprise can authorize new integrations independently
- Asymmetric remediation cost. Granting a permission takes seconds; auditing existing grants across an enterprise of 10,000 employees takes weeks. Most enterprises have never done it.
- Industry-wide pattern failure. AI productivity tool onboarding flows actively encourage broad permission grants. Developer documentation across the ecosystem treats “Allow All” as the expected user flow. Educational materials about scope minimization are sparse
This is the same structural failure mode replayed at a different layer. The difference is the multiplier. SQL injection per-app exposure affected one application’s data. OAuth “Allow All” exposure affects the entire enterprise identity context the user authorized from. The blast radius is categorically larger.
The 14-year persistence of SQL injection at OWASP #1 is the historical baseline for how long structurally similar patterns can dominate the threat landscape. OAuth permission abuse is on year 3-4 of its dominance. Without structural intervention, expect another decade of being the dominant supply-chain attack vector.
II · The 2025-2026 cascade · what the data shows
The empirical evidence for “OAuth is the dominant attack surface” is substantial and accelerating. Documenting it concretely:
The headline 2025 breach · Drift/Salesloft
August 2025: Threat cluster UNC6395 (also tracked as GRUB1) exploited stolen OAuth tokens from Salesloft’s Drift chatbot integration to access Salesforce environments at 700+ organizations over a ten-day exploitation window (August 9-17, 2025). Verified victims include Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, SpyCloud, Tanium, Zscaler, Cloudflare, Zscaler, BeyondTrust, and many others.
The attack chain:
- March-June 2025: Salesloft GitHub repositories compromised (the foothold operation)
- August 2025: OAuth tokens for Drift’s Salesforce integration extracted from compromised Salesloft infrastructure
- August 9-17: Mass SOQL queries against 700+ Salesforce organizations exfiltrating Accounts, Opportunities, Cases, and embedded secrets (AWS keys, Snowflake tokens, other credentials stored in CRM data)
- August 20: Drift tokens revoked, AppExchange listing removed
- September 3: Drift taken offline entirely for security hardening
- October 7: Salesforce refused ransom demand from extortion group
- October 9-10: FBI and French authorities seized BreachForums infrastructure
- Total impact: 1.5 billion records affected, 70+ lawsuits filed
FBI Cybersecurity Advisory CSA-2025-250912 specifically warned that attackers like UNC6395 are actively targeting Salesforce instances via compromised SaaS integrations for data theft and extortion. The advisory is operational guidance, not theoretical risk assessment.
The 2026 recapitulation · Vercel
April 2026: The Vercel breach (documented in Part 2) follows essentially the same pattern with different vendors:
- February 2026: Lumma Stealer infected a Context.ai employee (Hudson Rock investigation, reportedly via Roblox cheat lookup)
- Lumma Stealer harvested Context.ai’s OAuth tokens: Google Workspace, Supabase, Datadog, Authkit
- Attacker used stolen Context.ai Google Workspace OAuth token
- Vercel employee had granted Context.ai “Allow All” permissions to enterprise Google Workspace
- Attacker accessed Vercel employee’s Workspace → pivoted to Vercel account
- Enumerated and decrypted non-sensitive environment variables for Vercel customers
- Database posted on BreachForums for $2M
Structurally identical to Drift/Salesloft except: shorter chain, AI productivity tool instead of marketing automation tool, individual employee consent instead of admin integration. The fundamental attack pattern — OAuth supply chain compromise leveraging “Allow All” permission grants — is unchanged.
The broader 2026 supply chain wave
The pattern is not isolated to two high-profile breaches. The same March-April 2026 window produced:
- March 24, 2026: LiteLLM PyPI supply chain compromise. Malicious versions 1.82.7 and 1.82.8 published using stolen CI/CD publishing credentials from Trivy (Aqua Security’s vulnerability scanner). Threat actor TeamPCP (UNC6780) embedded SANDCLOCK credential stealer in build environments. 3.4 million daily downloads of LiteLLM — affecting essentially every enterprise that uses an LLM proxy
- March 27, 2026: Google removed Context.ai’s Chrome extension from the Chrome Web Store (extension ID: omddlmnhcofjbnbflmjginpjjblphbgk), confirming the supply-chain dimensions of the Vercel attack chain
- TeamPCP/UNC6780 broader campaign: Multiple GitHub supply chain compromises (Trivy, Checkmarx, LiteLLM, BerriAI) using credential theft and malicious pull requests. AWS keys and GitHub tokens extracted from build environments and monetized through ransomware partnerships
- Drift-style replays: Several Salesforce-adjacent OAuth supply chain campaigns continued through 2026 as ShinyHunters and adjacent groups operated against the same attack pattern with new compromised vendors
The empirical metrics
Synthesizing across the security industry’s 2026 reporting:
- 50+ third-party applications connected to corporate identity per average enterprise user (CrowdStrike 2026 Global Threat Report, Reco AI, Vectra)
- 37x year-over-year increase in device code phishing attacks (the OAuth-equivalent of phishing) — multiple PhaaS kits in active circulation
- 98% of organizations report unsanctioned AI use (CrowdStrike 2026)
- 97% of organizations that experienced AI-related breaches lacked basic access controls (industry aggregate)
- 49% of organizations expect shadow AI incidents within 12 months
- $670,000 average additional cost for shadow AI breaches vs. traditional incidents
- 247 days average detection time for shadow AI breaches (vs. 241 for traditional)
- 65% of shadow AI breaches affect customer PII; 40% affect intellectual property
- 223 AI-related data policy violations per month at the average enterprise (Netskope 2026)
- Gartner: 40% of enterprise applications will feature task-specific AI agents by end of 2026 (up from <5% in 2025)
The aggregate signal is clear: OAuth-supply-chain attacks are no longer an emerging threat. They are the dominant supply-chain attack pattern in enterprise environments, accelerated by shadow AI adoption, with measurable cost and detection-time premiums over historical breach categories.
III · Why shadow AI is the multiplier · structural analysis
Shadow IT has been a known governance problem for two decades. Shadow AI is structurally different in three ways that make it more consequential:
Difference 1 · AI productivity tools require broad permissions by design
Traditional shadow IT was about employees using unsanctioned software for narrow purposes — a different file-sharing tool, an unapproved project management app, a personal note-taking application. The blast radius was bounded by the narrow use case.
AI productivity tools are categorically different. To function as designed, they need broad access to the data they’re supposed to enhance:
- AI scheduling assistants need access to calendar, contacts, email (to read meeting context)
- AI writing assistants need access to documents, drafts, email history
- AI meeting summarizers need access to recordings, transcripts, attendee data
- AI research tools need access to drive contents, search history, documents
- AI sales tools need access to CRM data, communications, contacts
- AI coding assistants need access to repositories, build environments, deployment configurations
The use cases require broad data access. Granting narrow scopes makes the tool less functional. Users (correctly, given the constraints) grant broad scopes. The breadth of permission is not a configuration mistake — it’s a fundamental requirement of the AI productivity tool category.
This is structurally different from traditional SaaS, where most applications could function with narrow API scopes if users restricted themselves to specific use cases. AI productivity tools by their nature require holistic data access — and the more useful the tool, the broader the access required.
Difference 2 · The proliferation rate is unprecedented
Traditional shadow IT grew incrementally over years. Shadow AI is proliferating at an exponential rate:
- Less than 5% of enterprise applications featured AI agents in 2025 (Gartner)
- Projected 40% of enterprise applications will feature AI agents by end of 2026 (Gartner)
- 8x increase in 18 months
Every new AI productivity tool that ships becomes a potential shadow AI deployment. The OAuth consent screen is the deployment mechanism. Employees install these tools through the consent flow before security review can occur because there is no security review. Google Workspace and Microsoft 365 default to allowing user-level consent for most third-party app integrations. The deployment happens silently from the IT perspective.
The aggregate effect: the attack surface grows faster than security visibility, faster than governance can adapt, faster than policy can be applied. The structural pressure is to “Allow All” by default because that’s what enables the productivity gains the workforce is asking for.
Difference 3 · The tools themselves become attack infrastructure
This is the most important structural difference. Traditional shadow IT was used as a tool that could be compromised. Shadow AI tools become part of the attack infrastructure when compromised, because they have legitimate persistent access to corporate data.
The Drift/Salesloft and Vercel/Context.ai breaches both demonstrate this. The compromise was not “attackers stole credentials and used them.” The compromise was “attackers inherited the legitimate OAuth token of a trusted AI tool and operated as the tool.” From the perspective of Salesforce or Google Workspace logging, the malicious activity looked exactly like legitimate Drift or Context.ai activity. Until correlation with external indicators identified the anomaly, the activity was invisible to the victim organization’s security tooling.
This is the OAuth-token-as-attack-infrastructure pattern. Once obtained, OAuth tokens:
- Bypass MFA entirely. OAuth tokens, once issued, do not require re-authentication
- Persist across credential changes. Rotating passwords does not invalidate OAuth tokens
- Look identical to legitimate use. Logging shows the expected app accessing expected data
- Scale with the breadth of permissions granted. “Allow All” permissions enable enterprise-wide impact
The combination is uniquely problematic. Compromised AI productivity tools become persistent, MFA-bypass-equipped, logging-invisible access channels into enterprise data. No traditional attack surface produces this combination of properties at this scale.
IV · The structural fixes · what platforms need to do operationally
The 2026 platform response is real but incremental. Documenting what’s shipping and what’s still missing:
What Google has shipped
Granular OAuth consent screens rolled out across Google Workspace through 2025-2026:
- May 2025: HTTP Workspace add-ons
- November 2025: Web apps and Workspace add-ons
- January 7, 2026: Web apps and Workspace add-ons (extended rollout)
- January 20, 2026: Chat apps using Apps Script
The change: Users see checkboxes next to individual permissions instead of one “Allow” button. They can grant partial consent — accepting some scopes while declining others.
The limitations:
- Applies only to new OAuth grants. Pre-existing grants are unaffected. The 50+ apps already connected to corporate identity are not retroactively re-prompted
- Developer opt-in required. Apps must support granular consent. Many do not, and existing apps have until incremental deadlines
- The default user behavior is still “click through and accept.” Granular consent enables better decisions; it does not enforce better decisions
- Admin controls remain unchanged. “There is no admin control for this feature” — the Google Workspace Updates blog explicitly notes this for each granular consent rollout
Google does provide robust admin controls separately via API controls in the Admin console: Trusted / Limited / Specific Google data / Blocked categories for third-party apps, plus the ability to block all third-party API access for specific OAuth scopes. But these admin controls are opt-in for the administrator. Default Google Workspace deployments allow user-level consent without admin review.
What Microsoft has shipped
Microsoft’s response has been more comprehensive through Agent 365 (GA May 1, 2026):
- Shadow AI page in Agent 365 admin center — discovery of unsanctioned AI agent usage including OpenClaw, GitHub Copilot CLI, Claude Code
- Network-level prompt injection blocking via Entra network controls extended to Copilot Studio agents and local agents
- Agent 365 registry sync with AWS Bedrock and Google Cloud connections — discovery of cloud agents across multi-platform environments
- Synced passkeys + Windows Hello integration — phishing-resistant auth at scale
- Entra Backup and Recovery — automated directory object backup for rapid recovery
- Entra Tenant Governance — shadow tenant discovery, consistent policy enforcement
Microsoft’s positioning is correct: agents need governance like human identities need governance. Agent 365 is the operational implementation of that thesis.
The limitations:
- Requires Microsoft 365 E7 ($99/user/month with Cowork) for full Agent 365 capabilities
- Bundled in E5 for baseline Security Copilot but not all Agent 365 features
- Requires deliberate operationalization — most organizations have not configured the relevant policies
- Discovery requires Defender + Intune which not all organizations deploy
What Okta and the identity vendors have shipped
Okta has expanded OAuth governance through its 2025-2026 product updates:
- Workflow Connector marketplace with vetted third-party integrations
- Adaptive MFA for OAuth grants — requires step-up authentication for sensitive scopes
- Risk-based session policies — OAuth tokens get shorter lifetimes for high-risk contexts
- Centralized OAuth grant management — admin visibility into all OAuth grants across the workforce
Plus the broader Identity Threat Detection and Response (ITDR) category — Push Security, Permiso, Reco AI, Obsidian Security, AppOmni, Nudge Security — all of which have expanded their OAuth governance capabilities through 2025-2026. The capability layer is maturing rapidly.
What’s still missing structurally
The biggest gap is the default deployment behavior. Google Workspace and Microsoft 365 still ship with user-level OAuth consent enabled by default for most third-party app categories. Until the platform defaults change, individual employees can grant enterprise-wide access to third-party tools without admin review. This is the structural pattern that produces every Drift-style and Vercel-style breach.
The platform-level fixes that would close the gap:
- Default to admin-managed consent. Move the platform default from “users can grant” to “users must request, admins must approve.” This is the Jaime Blasco (Nudge Security CTO) recommendation explicitly mentioned in Dark Reading post-Vercel: “Move to admin-managed consent. New apps get reviewed before they can touch corporate data. That one change would have blocked a Vercel employee from granting Context.ai enterprise-wide scopes in the first place.”
- Automatic scope minimization for AI tools. Identify AI productivity tool categories at the platform level and apply automatic scope limitations that require explicit admin override. This is a major engineering effort but the technical capability exists
- OAuth token rotation enforcement. Require time-bounded OAuth tokens (24-72 hour maximum lifetime) with automatic refresh that runs through MFA. This breaks the “OAuth bypasses MFA forever” property that makes OAuth tokens uniquely valuable to attackers
- Default audit logging for all OAuth grants. Make OAuth grant activity logged and surfaced in security dashboards by default. Most enterprises have no visibility into the OAuth grants their employees have made
- OAuth grant expiration without refresh. Require periodic re-consent (90-180 days) for any OAuth grant. This forces decay of the long-tail of forgotten grants that accumulate across enterprise identity environments
None of these are technically infeasible. All of them require platforms to choose to make security defaults more restrictive than productivity defaults. That trade-off has historically been made in favor of productivity. The Drift/Salesloft and Vercel breaches are the empirical data points arguing the trade-off should be reconsidered.
V · What enterprise security leaders need to operationalize · concretely
For CISOs and security teams facing the OAuth-supply-chain attack surface without waiting for platform defaults to change:
Priority 1 · Inventory what’s already connected
Most enterprises have no inventory of OAuth grants by their workforce. This is the prerequisite for everything else. The path:
- Google Workspace: Admin console → Security → API controls → Manage Third-Party App Access. Review configured apps list AND accessed apps list (apps that have accessed Google data even if not formally configured)
- Microsoft 365: Microsoft 365 admin center → Settings → Integrated apps. Plus Microsoft Entra → Enterprise applications for the broader OAuth inventory
- Okta: Admin → Applications → Browse App Catalog AND Custom apps inventory
- Salesforce: Setup → Connected Apps → Manage Connected Apps
Audit each connected app against the principle of least privilege. If the app has scopes broader than its use case requires, restrict or revoke. Most enterprises will discover dozens to hundreds of long-forgotten OAuth grants in this audit.
Priority 2 · Switch to admin-managed consent
This is the single highest-leverage configuration change. Move from “users can grant any third-party app access” to “users must request, admins must approve.” The configuration paths:
- Google Workspace: Admin console → Security → Access and data control → API controls → App access control. Set unconfigured app behavior to “Don’t allow users to access any third-party apps.” Configure trusted apps explicitly
- Microsoft 365 / Entra: Microsoft Entra admin center → Identity → Applications → Enterprise applications → Consent and permissions. Set user consent to “Do not allow user consent” or “Allow user consent for apps from verified publishers, for selected permissions”
- Okta: Implement explicit approval workflows for new application integrations
- Salesforce: Setup → Connected Apps → OAuth Connected App Policies. Set “Permitted Users” to “Admin approved users are pre-authorized”
This single change blocks the Vercel attack chain from being possible. A Vercel employee attempting to grant Context.ai enterprise-wide scopes would have hit an admin approval requirement instead of being able to click through.
Priority 3 · Implement OAuth-specific monitoring
The OAuth governance vendors mentioned in section IV provide capability here. Specifically:
- Anomaly detection on OAuth grants — unusual times, unusual users, sensitive scopes, unverified vendors
- OAuth token usage monitoring — flag tokens that suddenly access more data than historical patterns
- OAuth grant inventory dashboards — visibility into the current state of OAuth across the enterprise
- Automated revocation workflows — when an employee leaves, or when an integration is identified as risky, programmatic revocation across all OAuth grants
The vendors operate at different price points. Nudge Security, Push Security, and the ITDR category typically run $10-30/employee/month. Comprehensive SaaS security posture management platforms (Reco AI, AppOmni, Obsidian, Adaptive Shield) run $50-200/employee/month for full deployments. Pick based on existing security tool integration and budget.
Priority 4 · Specific high-risk OAuth audit
Some scope categories deserve particular attention:
- “Read all email” /
gmail.readonly— full read access to mailbox - “Send email as you” /
gmail.send— ability to impersonate the user - “Manage Drive files” /
drive— full Drive read and write - “Read calendar” + “Read contacts” — combined enables comprehensive professional context exfiltration
- “Read all Salesforce data” /
apiscope — full CRM read access - Slack
users:read.email+ channels access — communication mining - GitHub
reposcope — full repository access including private repos - AWS / GCP / Azure cloud broad-scope service accounts — infrastructure access
Any OAuth grant with these scopes should be reviewed individually. Each represents a potential Drift-style or Vercel-style blast radius if the grantee organization is compromised.
Priority 5 · Train the workforce on shadow AI specifically
The workforce has not yet internalized that “trying a new AI productivity tool” can result in $670K average breach cost when the tool is compromised. The training is not technical — it is risk awareness.
Specifically: every employee should understand that clicking “Allow” on a Google or Microsoft OAuth consent screen for an AI productivity tool grants that tool access to their corporate data, that the tool’s vendor security posture becomes the employee’s organizational risk, that the consent can typically be revoked but the data already exfiltrated cannot, and that “trying it just for productivity” is a security event, not a productivity event.
The Drift/Salesloft and Vercel breaches are concrete teaching examples. Both started with a single employee’s reasonable productivity decision. The training cost is low; the risk reduction is substantial.
Priority 6 · Plan for the next instance
The Drift/Salesloft and Vercel breaches are not the last. The structural pattern continues:
- Some fraction of the 50+ AI productivity tools your employees have connected will be compromised in 2026-2027
- Some fraction of those compromises will cascade through OAuth tokens to your environment
- Your detection-and-response infrastructure needs to handle the cascade event when it lands at your organization
Build incident response playbooks specifically for OAuth-supply-chain compromise scenarios. What’s the response if a vendor you depend on announces an OAuth token theft? Who decides whether to revoke all grants from that vendor immediately or to assess scope first? What’s the credential rotation playbook for the cloud services accessed via the compromised path? Most enterprises have not war-gamed these scenarios.
VI · What policymakers need to address
The structural intervention requires policy in addition to platform changes and enterprise practice:
Regulatory framework updates
The EU Cyber Resilience Act and NIST 800-218 SSDF are the primary regulatory frameworks affecting enterprise software security. Neither currently addresses OAuth permission governance explicitly. Updates needed:
- Require OAuth grant inventory as part of mandatory enterprise security posture documentation
- Require admin-managed consent for organizations meeting certain criticality thresholds (critical infrastructure, regulated industries, government contractors)
- Standardize OAuth grant audit logging requirements across vendors
- Specify minimum OAuth security defaults for SaaS providers serving enterprise customers
Liability framework
Currently, when an OAuth-supply-chain breach occurs, liability allocation is contested:
- Does the AI productivity vendor bear liability for failing to secure their OAuth tokens?
- Does the platform provider (Google, Microsoft) bear liability for defaults that enable user-level enterprise-wide consent?
- Does the enterprise customer bear liability for failing to configure admin-managed consent?
The legal precedents are unclear. The 70+ lawsuits following the Drift/Salesloft breach are testing these questions in court. Policymakers should establish clearer liability frameworks before the lawsuits produce decade-long inconsistent case law that fails to drive structural change.
Disclosure requirements
The 90-day coordinated disclosure framework documented in Part 2 applies to vulnerability disclosure. There is no equivalent for OAuth token theft. When a vendor’s OAuth tokens are stolen, the disclosure timeline to affected customers is currently a matter of vendor choice and contractual obligation, not regulatory requirement.
The Context.ai compromise (February 2026) was disclosed to Vercel in April 2026 — two months of dwell time during which the attacker operated against Vercel’s systems. A standardized OAuth-token-theft disclosure framework would compress that window structurally.
Public-interest OAuth governance infrastructure
The current OAuth governance ecosystem operates entirely through commercial vendors. Public-interest infrastructure analogous to CVE databases, CISA KEV catalog, or coordinated disclosure programs does not exist for OAuth supply chain risks. Specifically:
- No public registry of OAuth-token-compromised vendors — equivalent to CISA’s KEV catalog for vulnerabilities
- No public scoring system for OAuth integration risk — equivalent to CVSS scoring for vulnerabilities
- No public coordinated response framework for OAuth supply chain incidents — equivalent to CERT coordination for vulnerability disclosures
These public-interest infrastructures could be built. Government coordination through CISA, NIST, or sector-specific ISACs is the natural path. The current commercial-vendor-only landscape leaves significant gaps in defensive coordination.
VII · The structural close · why this matters more than it looks
OAuth permission abuse is not the most technically sophisticated attack surface in 2026. It is the most structurally consequential for three reasons:
Reason 1 · The attack surface compounds with shadow AI adoption. As AI productivity tools proliferate (8x increase from 5% to 40% of enterprise applications in 18 months per Gartner), every new tool is a potential supply-chain attack vector. The structural pressure is for the attack surface to grow faster than defensive infrastructure can adapt. This is not a problem that gets smaller over time without structural intervention.
Reason 2 · The blast radius scales with enterprise interconnection. Modern enterprise stacks are deeply interconnected through OAuth. A compromised AI productivity tool with broad permissions can cascade through:
- Email and calendar (mining for context)
- Cloud storage (exfiltrating documents)
- CRM data (Drift/Salesloft pattern)
- Code repositories (Vercel pattern)
- Cloud infrastructure credentials (the environment-variable pattern)
- Internal communications (Slack, Teams, etc.)
One compromised tool can cascade across the entire enterprise data substrate if scopes are sufficiently broad. The blast radius is bounded only by the breadth of permissions granted, which is structurally pressured to be broad.
Reason 3 · The defensive infrastructure is structurally behind. The Defender’s Counter-Cascade piece documented that defensive AI security tooling at the memory-safety layer is 25+ years mature. OAuth governance defensive tooling is perhaps 5 years mature. The gap is wide and the attack surface is growing faster than the defensive maturity curve.
This is the SQL injection of 2026. Same structural anatomy. Same default-deployment-favors-exploitability dynamic. Same industry-wide pattern failure. Same multi-year window of dominance ahead unless platform defaults change.
The intervention path is clear: admin-managed consent as platform default, mandatory granular consent for new OAuth grants, time-bounded OAuth tokens, default audit logging, public-interest infrastructure for OAuth supply chain coordination. None of these are technically infeasible. All of them require choosing security defaults over productivity defaults at the platform layer.
That trade-off is the structural question of the next 18 months. Until it’s made, expect the dominant supply-chain attack pattern of 2026 to continue producing Drift-class, Vercel-class, and (eventually) larger incidents on a recurring basis.
The OAuth permission apocalypse is operational. The platform response is incremental. The enterprise governance work is the binding constraint on closing the gap. Each enterprise that switches to admin-managed consent removes their employees from being the next Vercel-style entry vector. The work is individual and aggregate simultaneously.
That’s the read on where we are. The next piece in the series will look at the critical infrastructure patch lag — what AI-driven vulnerability discovery means for power grid, water utilities, healthcare, and financial systems where patch cycles run months to years rather than days.
About the Author
Thorsten Meyer is a Munich-based futurist, post-labor economist, and recipient of OpenAI’s 10 Billion Token Award. He spent two decades managing €1B+ portfolios in enterprise ICT before deciding that writing about the transition was more useful than managing quarterly slides through it. More at ThorstenMeyerAI.com.
Related Reading · the software security franchise
- 732 Bytes to Root · the cost-curve collapse · Part 1
- The 90-Day Window Closed · the disclosure collapse · Part 2
- The Defender’s Counter-Cascade · the deployment gap · Part 3
- The Coding Singularity Outside Read · the capability that makes this possible
- The State of AI Replacing Jobs in 2026 · empirical labor consequences
Sources
- The Hacker News · Salesloft Takes Drift Offline After OAuth Token Theft Hits Hundreds of Organizations · September 2025
- Google Threat Intelligence Group · UNC6395 / GRUB1 attribution for Drift/Salesloft breach
- FBI Cybersecurity Advisory CSA-2025-250912 · Salesforce instances targeted via SaaS integrations
- Anomali · Reviewing the Salesforce–Salesloft Drift OAuth Supply Chain Breach · December 2025
- AppOmni · Salesloft Drift–Salesforce Breach (UNC6395): Why Salesforce OAuth Integrations are a Growing Risk
- CSO Online · Salesforce’s glaring Dreamforce omission · October 2025 · 1.5 billion records, 70+ lawsuits
- BleepingComputer · Learning from the Vercel breach: Shadow AI & OAuth sprawl · April 2026
- Dark Reading · Vercel Employee’s AI Tool Access Led to Data Breach · Jaime Blasco (Nudge Security CTO) on admin-managed consent
- CybelAngel · The Vercel Breach Flash Report · Shadow AI as faster-moving cousin of shadow IT
- Trend Micro · The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables · April 21, 2026
- OX Security · Vercel Breached via Context AI Supply Chain Attack
- Hudson Rock · Context.ai Lumma Stealer compromise · February 2026
- Reco AI · AI & Cloud Security Breaches: 2025 Year in Review · 97% lacked access controls · $670K cost premium
- Vectra AI · Shadow AI explained: risks, costs, and enterprise governance · 98% unsanctioned AI use · 49% expect incidents
- Gartner · 40% enterprise applications featuring task-specific AI agents by end of 2026 (up from <5% in 2025)
- CrowdStrike 2026 Global Threat Report · 90+ organizations with adversary AI tool exploitation · 550% ChatGPT mention increase
- Netskope 2026 · 223 AI-related data policy violations per month at average enterprise
- Healthcare Brew 2026 · 89% unauthorized AI use drop when enterprise alternatives provided
- ISACA · audit methodology for shadow AI inventory
- Medium · SaaS-to-SaaS OAuth Worms: The “Consent” Virus · February 2026
- Google Workspace Updates · Granular OAuth consent rollout · January 7, 2026 web apps · January 20, 2026 Chat apps
- Google Workspace · Admin API Controls documentation · Trusted/Limited/Specific/Blocked third-party app access
- Microsoft · Agent 365 GA · May 1, 2026 · M365 E7 Frontier Suite $99/user/month
- Microsoft Entra · Enterprise applications consent and permissions settings
- OWASP Top 10:2021 · A03 Injection · SQL injection 94% application detection rate
- OWASP Top 10:2025 · A05 Injection · 14,000+ CVE category
- LiteLLM PyPI supply chain compromise · March 24, 2026 · TeamPCP / UNC6780
- Chrome Web Store · Context.ai extension removal · March 27, 2026 (extension ID omddlmnhcofjbnbflmjginpjjblphbgk)
- Nudge Security · Jaime Blasco CTO commentary on Vercel post-mortem
- Push Security · Permiso · Obsidian Security · AppOmni · Adaptive Shield · ITDR / SSPM vendor landscape
- Salesforce Connected Apps OAuth policies documentation
- Okta Workflow Connector marketplace + adaptive MFA capabilities · 2025-2026
