OAuth the silent risk that turns permissions into access doors to your systems

The discussion of the risks of artificial intelligence in companies often focuses on the visible: employees hitting sensitive data on public chatbots. However, there is a less noisy and more pernicious threat that deserves priority: OAuth integrations that employees connect to critical applications (Google Workspace, Microsoft 365, Salesforce, etc.). Unlike a conversation with a LLM, an OAuth connection creates a persistent bridge between your environment and a third; that bridge does not disappear when the user stops using the app and can turn a gap into a supplier into a direct access door to your systems.

The recent case that affected Vercel is illustrative: a test of a productivity app with permissions on Google Workspace ended up being the link that allowed attackers to pivote after compromising the supplier. It's a practical demonstration of why it is not enough to control the data that are written in a chat: we must control the trust relationships that are created between systems. To read a technical analysis of the incident and how tokens and permissions were exploited, the research report published by security specialists is available: Unpacking the Vercel break.

This is not an isolated or exclusive case of "AI" applications. In recent years we have seen campaigns of tokens and OAuth-based attacks that hit thousands of organizations, and the arrival of AI tools that orchestrate flows between applications has only multiplied the attack surface. The attackers have made OAuth a reliable vector because a valid token is, in many cases, as much or more valuable than a credential.

The implications for corporate security are clear and operational: you need to treat application authorizations as critical assets. First, a restrictive default consent model should be adopted in your corporate identities and users should not be able to link new applications without approval. Google Workspace and other platforms allow policies to manage third-party access; the official guide on how to control third-party applications in Google Workspace is a good starting point for administrators: Manage third-party app access to Google Workspace data.

Operational hygiene also matters: regular audits of active integrations, reviews of the permits requested for each app, and ability to automatically revoke tokens against commitment indicators are measures that reduce exposure window. It is also critical to have response procedures that include the massive withdrawal of consensus and the rotation of keys and tokens when a supplier is compromised.

It is not enough to just control the identity provider. Many connections occur between SaaS and SaaS and are not visible from the main administration panel. This is why a combination of methods is needed: inventorizing computer-used applications, monitoring authentication and consensus from the browser and from the SSO, and deploying detection that identifies rare API traffic patterns or off-schedule access. In addition, endpoint controls and browser extension policies help to mitigate delivery vectors such as infostealers or phishing that end up in tokens theft.

At the tactical level, there are tools and practices that work best together: apply mandatory SSO with centralized consensus policies, require strong MFA (ideally with hardware keys) for high-permissions accounts, limit application scopes to the minimum necessary and require security reviews to suppliers before allowing integration. It is also useful to implement alerts that detect the creation of user-authorized applications and submit them to automatic review.

The evolution of the attack - from phishing campaigns that induce applications to gaps in suppliers that store tokens - requires a response that combines governance, technology and training. Security teams should stop thinking of these congestions as "small user choices" and see them as relationships of trust that must be actively managed. To expand the view on how browser-based attacks and OAuth are changing the picture, there are recent reports that analyze techniques such as vice-code phishing and other relevant vectors: Device code phishing: technical report.

If your organization does not yet have a clear policy on OAuth integration and AI use, the time to act is now. Small preventive defenses - block of unauthorized consent, regular audits, browser detection and IDP controls - significantly reduce the risk that an IA test or utility will become the access path for a larger gap. Treating OAuth as a critical surface and coordinating controls between identity equipment, endpoints security and application management is the strategic decision you can avoid the next supplier incident.