AI-powered inbox tools promise massive productivity gains, but every connected application expands your enterprise attack surface. Recent incidents involving OAuth abuse, token theft, and third-party vendor compromises show why security teams are paying closer attention to integration vulnerabilities.
For years, corporate cybersecurity advice was relatively straightforward: use strong passwords, enable multi-factor authentication (MFA), and be careful what you click. Most enterprise users understand these baseline rules.
At the same time, millions of users now routinely grant third-party applications deep access to their inboxes with little hesitation. AI assistants, meeting copilots, inbox organisers, relationship intelligence platforms, and productivity tools are rapidly becoming part of the modern email ecosystem.
Most of these services are legitimate, and many provide significant organisational value. But every new integration introduces a foundational question companies are only beginning to take seriously:
What happens when a trusted application quietly becomes part of your attack surface?
The Vercel Wake-Up Call
In April 2026, web infrastructure platform Vercel disclosed a security incident involving a third-party AI tool called Context.ai.
According to public reporting and threat intelligence analysis, investigators believe the intrusion may have involved credentials associated with a trusted third-party integration after the vendor was reportedly compromised by infostealer malware. Rather than attacking Vercel’s core infrastructure directly, attackers appear to have leveraged an existing trusted relationship to gain access to internal resources.
While the precise technical details continue to be examined, the broader lesson reflects a growing trend in enterprise security:
Attackers don’t always break in anymore.
Sometimes they log in through software your organisation has already trusted.
As reported by Tom’s Hardware, the incident demonstrates how trusted integrations can become attractive attack vectors when third-party security controls fail.
Every Connected App Expands Your Perimeter
OAuth was originally designed to improve security by eliminating the dangerous practice of password sharing, and in many ways it has been a massive success. The hidden challenge is that every connected application effectively becomes another trusted insider within your corporate environment.
When users connect modern applications to Gmail or Microsoft 365, they routinely grant permissions that can include:
- Reading full email content and historical metadata
- Accessing and downloading attachments
- Viewing internal contact directories
- Mapping communication networks
- Modifying inbox organisation
- Sending email on the user’s behalf
To be fair, many modern AI assistants legitimately require broad access to deliver meaningful value. Features such as inbox summarisation, meeting preparation, relationship intelligence, workflow automation, and contextual search often depend on visibility across email, calendars, contacts, and historical communications. The challenge is not whether access is needed. The challenge is ensuring the level of access granted remains proportional to the business value being delivered.
In many cases, the risk is not only whether an application is eventually compromised, but whether it was granted significantly more access than it actually needed in the first place.
A tool that only requires access to email headers should not necessarily receive permission to read, modify, delete, or send messages. These overprivileged applications create unnecessary risk and increase the potential impact of any future compromise.
Individually, broad permissions are often requested to complete a specific task. Collectively, they create a sprawling network of third-party dependencies that many organisations struggle to inventory or monitor.
For administrators, the challenge is often visibility rather than outright prevention. Many organisations discover hundreds, or even thousands, of OAuth grants spread across departments and business units. Without centralised inventory and governance, security teams may struggle to understand which applications have access, what permissions they hold, and whether those permissions are still justified.
Why MFA Is No Longer the Whole Story
Passwords and MFA remain critical baseline controls, but OAuth fundamentally changes the threat model.
Once a user authenticates and grants consent, applications may receive authorisation tokens that allow continued access according to the organisation’s token and session policies, often without requiring repeated user authentication.
That persistent background access is exactly why threat actors are increasingly focusing on OAuth abuse, token theft, and consent phishing.
The target is no longer always the user’s credentials.
Sometimes the target is the trusted relationship itself.
In May 2026, the FBI issued an official Internet Crime Complaint Center (IC3) Public Service Announcement warning organisations about Kali365, a rapidly growing Phishing-as-a-Service (PhaaS) platform.
Rather than stealing passwords directly, the campaign abuses legitimate Microsoft device login workflows. Victims are tricked into entering a verification code on a genuine Microsoft domain. Once the authorisation process is completed, attackers can gain access through the resulting Microsoft 365 authorisation tokens, enabling access without needing the victim’s password.
It is a reminder that even strong authentication controls can be undermined when attackers successfully exploit legitimate authorisation workflows. Organisations can also review Microsoft’s guidance on protecting against consent phishing to better understand how OAuth abuse campaigns operate.
The AI Blast Radius
The rapid adoption of artificial intelligence is making this visibility problem significantly harder to ignore.
Unlike traditional SaaS applications that may only need access to a single function, many modern AI assistants derive their value from aggregating data across multiple systems, including email, calendars, contacts, documents, and communication history.
This concentration of access creates an exceptionally large blast radius.
If an authorised AI vendor experiences a security breach, attackers may gain access not just to a single application but to a centralised view of an organisation’s communications, relationships, workflows, and institutional knowledge.
As we recently covered in Gmail Launches AI Inbox and Gemini-Powered Features the future of email is becoming increasingly tied to deeper integrations and broader access to user data.
That leaves security teams facing a difficult operational challenge:
How do you build smarter inboxes without handing permanent, high-privilege access to a growing number of third parties?
We’ve Seen This Pattern Before
The Vercel incident is not an isolated case.
Last year, we covered a wave of data-theft operations targeting Salesforce customers. In many of those incidents, attackers focused on connected applications and third-party authorisation workflows rather than attempting to compromise Salesforce infrastructure directly.
The strategy is simple:
Trust the application → Authorise the application → Compromise the application → Inherit the trust
Attackers have learned that compromising the platform itself is often much harder than compromising something connected to it.
We explored a similar pattern in Wave of Salesforce Data-Theft Hits Google, Cisco, Chanel, Pandora .
The Forgotten Apps Problem
Want to see this risk for yourself?
Open your Google or Microsoft account settings and review your connected applications dashboard.
Ask yourself:
- How many apps still have access?
- How many are actively used?
- How many would you recognise immediately?
For many organisations, the answers are surprisingly unclear.
A productivity tool connected three years ago for a one-time project may still retain access to sensitive communications. A startup approved by an employee years ago may still have valid permissions today.
An application that was carefully vetted three years ago may no longer have the same security posture today. Ownership can change, vendors can be acquired, security teams can shrink, and products can be abandoned altogether. Yet the permissions granted years earlier often remain active unless someone intentionally reviews and revokes them.
That may be the biggest risk of all:
Not the application you connected yesterday. The application you forgot existed.
Google provides guidance on reviewing connected applications in its Manage Third-Party Apps & Services With Access to Your Account documentation.
How Organisations Can Reduce OAuth Risk
To navigate the integration boom safely, organisations should treat third-party applications with the same rigor they apply to internal access controls.
1. Audit Connected Applications Regularly
Maintain a complete inventory of OAuth-connected applications across Google Workspace and Microsoft 365 environments.
2. Enforce Least-Privilege Access
Restrict users from approving applications that request unnecessarily broad permissions. Require vendors to justify access scopes.
Organisations using Microsoft 365 can implement administrative consent workflows to prevent users from independently approving high-risk applications.
3. Review and Revoke Inactive OAuth Grants
Regularly identify and remove applications that are no longer in use or no longer provide business value.
4. Conduct Security Reviews for AI Vendors
Before approving AI tools with inbox access, assess:
- Data retention and deletion policies
- OAuth scope requirements
- Token storage and protection mechanisms
- Logging and audit capabilities
- Third-party subprocessors
- Security certifications and compliance programs
- Incident response and breach notification procedures
5. Monitor OAuth Activity
Use SIEM, CASB, or native platform controls to identify unusual token usage, anomalous access patterns, and unexpected data movement.
6. Limit User Consent Where Appropriate
Consider requiring administrator approval for applications requesting high-risk permissions.
The Bottom Line
AI inbox assistants, meeting copilots, and productivity tools are rapidly becoming standard business software.
The opportunity is clear. The challenge is understanding the trust relationships that come with them.
As organisations adopt more AI-powered tools, security teams must look beyond passwords and devices. They will need to pay closer attention to the growing network of connected applications operating behind the scenes.
Because every OAuth grant is ultimately a trust decision.
And every connected application inherits a portion of that trust.
The question is whether organisations are managing those trust relationships as carefully as they’re granting them.
