The Legacy OAuth Detection Model Doesn't Survive AI Agents

On April 19, 2026, Vercel disclosed a security incident originating in a compromised third-party AI tool's Google Workspace OAuth app. This is the first high profile incident validating Material's research — OAuth-connected AI tools are an underappreciated but rapidly-emerging risk surface.

TL;DR

• MCP-connected agents (Claude, ChatGPT, IDE assistants) authorize into Workspace via OAuth. At the grant layer, they look identical to any other SaaS OAuth app.
• They aren't identical. A fixed-purpose app has predictable behavior; an agent's behavior is decided at inference time, driven by prompts and content the security team can't see.
• The attributes OAuth governance reasons about — scope, vendor, publisher — carry much less information when the client is a general-purpose agent. Grant-layer scoring loses signal.
• The signal has moved to the activity layer: what authorized apps actually do post-grant, scored per-user and per-agent rather than per-app. That's a detection-architecture problem you can address now, not a protocol problem to wait on.

drive.readonly granted to ChatGPT and drive.readonly granted to a PDF signing app are the same line in your Google OAuth audit log, but one of them is a programmable agent while the other is a deterministic app.

Most OAuth governance programs in Workspace and Microsoft 365 were built over the last decade to manage a specific kind of third-party access: fixed-purpose SaaS apps authorized by users and doing roughly predictable things. MCP-connected AI agents are the same access pattern at the grant layer, but a completely different thing at the behavior layer. The governance tooling built for the first model loses a lot of its signal against the second, and this is a near-term detection problem, not a future protocol problem.

This piece walks through what's actually changing, why the shift is invisible at the grant layer, and what it implies for how security teams watch third-party access to their tenant.

How OAuth governance works today

When a user authorizes a third-party app to their Workspace, the flow is OAuth 2.0. The app sends the user to Google's authorization endpoint with requested scopes. The user sees a consent screen and clicks through. The identity provider issues an access token and usually a refresh token. The app stores the tokens and calls Google APIs on the user's behalf until someone revokes access.

From a telemetry standpoint, this produces a few useful artifacts. An OAuth grant event in the admin audit log, with client ID, requested scopes, timestamp, and the authorizing user. An authoritative list of currently-authorized apps per user and per tenant, available via admin console or Admin SDK. And separately, activity logs showing what those apps actually do: Drive file reads, Gmail actions, Admin SDK events, and so on.

Most OAuth governance tooling is built on the grant layer. You enumerate authorized apps, score them by scope sensitivity (mail.readonly is lighter than full Gmail access, Drive full access is heavier than per-file grants), check publisher verification, look at tenant-wide prevalence, cross-reference client IDs against threat intel. Risky-looking apps get reviewed and revoked. SSPM products, allowlisting programs, periodic OAuth audits — all of these operate primarily on grant-layer data.

The approach has worked because the authorized client has historically been a fixed-purpose piece of software. A calendar app does calendar things. A backup tool does backup things. The vendor's identity told you a lot about what the app would do with its access, because the vendor wrote the software and the software's behavior changed on a release cycle.

Where MCP enters

MCP is the Model Context Protocol, a specification for connecting LLMs to tools and data sources. In the AI products most knowledge workers now use — Claude, ChatGPT, Cursor, various desktop and IDE assistants — MCP is how the model gets access to Drive, mail, calendar, Slack, Jira, and increasingly internal tooling.

For OAuth governance purposes, the important thing to understand is that MCP doesn't replace OAuth. It runs on top of it. When a user connects Claude to Gmail, there's an OAuth grant underneath. The client ID resolves to Anthropic. The requested scopes are the same ones any Gmail-integrated SaaS app would ask for. Google logs the grant as a normal OAuth authorization event.

At the grant layer, an MCP-mediated connection is indistinguishable from a traditional OAuth app authorization. Same event shape, same fields, same metadata. Monitoring for new OAuth grants and scoring them on static attributes doesn't raise any new signals when the authorized client is an agent.

What's different happens after the grant.

What actually changes

A SaaS app authorized via OAuth is bounded. When a user approves it, you can predict with useful accuracy what it will do with its access. A PDF signing app reads documents the user hands it, signs them, writes them back. A meeting scheduler polls availability and writes events. The behavior is defined by code the vendor wrote.

An agent isn't bounded. drive.readonly granted to Claude doesn't describe what the agent will read. It describes the ceiling of what the agent could read. What actually gets read is decided at inference time, turn by turn, based on prompts the security team doesn't see and content the agent ingests during its session.

That shift in client behavior changes what the OAuth telemetry can tell you.

Scope carries less information. A drive.readonly grant to a fixed-purpose app tells you roughly what files the app will read — the ones it needs for its function. The same grant to a general-purpose agent tells you the agent could read anything, on any schedule, in any sequence, driven by any prompt. The scope is the same. What it predicts isn't.

Vendor reputation answers a weaker question. "Is the vendor trustworthy?" was a useful question when the vendor defined the software's behavior. For an agent, the question that matters is "what is this agent being asked to do right now?" That isn't a vendor attribute. It's a session attribute, and it changes every prompt.

Client attestation is loose on the runtime side. When Claude Desktop authorizes a Drive scope, you know the runtime. You don't know which MCP servers that runtime has loaded, what tools are exposed, or what system prompt is in play. Two users on the same Claude Desktop, connected to the same Workspace, can have completely different tool configurations loaded, and the OAuth logs can't distinguish them. The trust boundary has moved onto the endpoint, where most Workspace security programs don't have visibility.

Cross-app behavior is the default. A traditional SaaS app does one thing. An agent is built to chain tools across whatever it's connected to. A single prompt can produce a session where the agent reads a calendar invite, opens the doc it links to, searches Drive for related files, pulls Slack threads with the attendees, and drafts a summary. Five API calls, three services, one session, one prompt. The agent is either doing exactly what the user asked or doing what an attacker asked via content the agent ingested along the way. The grants don't distinguish the two.

It's worth naming the bigger pattern: none of this is happening because anyone is using OAuth wrong. It's happening because OAuth is what MCP has to work with — no purpose-built alternative exists yet. The web wasn't built to be an operating system; we ended up with SQL injection and XSS when we pressed it into that role. The cloud-office access model wasn't built to be a real-time broker of access rights for autonomous agents. It's being used that way anyway, because the alternative is not using agents at all.

What this means for detection

If the grant layer is losing information, the detection signal has to come from somewhere else. The somewhere else is the activity logs: Drive API events, Gmail activity, Admin SDK login and token events. What authorized apps are actually doing, not what they were authorized to do.

This is a real shift in where detection teams have to look, and it changes the baselines. Traditional SSPM-style detection is often per-app: does this app's behavior fit its expected pattern. That baseline doesn't work well for agents, because an agent's expected pattern is "whatever the user's prompts induce." Better baselines for agent-heavy tenants are per-user and per-agent: does this user's agent session look like the user's other sessions; is this access pattern consistent with how this person works.

The signals that matter in that frame are behavioral. Bursty reads across unrelated resources. Semantically coherent sequences where the agent reads a doc, then searches for files matching terms from that doc, then reads those too. API calls timed to user sessions. Sudden access excursions outside the user's normal working surface. None of this is visible at the grant layer. All of it is visible at the activity layer if you're watching it.

Prompt injection fits into this picture as a new kind of credential abuse. If an agent reads a document containing instructions and then acts on them — forwards a sensitive thread, shares a file, exfiltrates data — the grant is legitimate, the authentication is legitimate, and nothing at the grant layer flags it. From the Workspace API's perspective, the agent is doing normal authorized things. The detection surface for this is anomalous action sequences from a legitimately-authorized client. That's the same detection surface as classic credential abuse and insider threat. It just has a new entry point: content the agent reads.

Where the industry is on this

Two recent pieces are worth reading alongside this one. Kane Narraway has written about the protocol-level gap: OAuth scopes are too broad for agents, and efforts like Cross-App Access and ID-JAG are attempting to fix this at the spec level, though adoption is probably two to three years out. Kevin Qiu has written about what security teams can do today: OAuth allowlisting in Workspace, treating OAuth apps with the same rigor as any third-party vendor, pressuring SaaS providers for narrower scopes and shorter token lifetimes.

Kane is looking at what the protocols need to become. Kevin is looking at what to do with the protocols we have. The detection shift is the thing in between: even with today's scopes and today's hygiene practices, an agent-heavy tenant looks different at the activity layer than the app-heavy tenants our tooling was built for. Better protocols will help eventually. Better hygiene helps now. Neither solves the detection problem, and the detection problem is already here.

What we built

When we designed the OAuth Remediation Agent we launched earlier this month, the decision we pushed hardest on was reading real-time activity logs — not just grant events, but what each authorized app is actually doing with the access it has. That makes it possible to classify apps by behavior rather than metadata, and to revoke or flag them on behavior that doesn't match how the user or organization actually operates. That same capability proved useful when we investigated the IOC Vercel published across Material’s own customer environments.

That architecture was the right call for the OAuth problem customers have today, before the agent shift makes it more urgent. It matters more every time one of those authorized clients is an agent. 

The grant event is still worth watching. It just isn't the event that tells you the most anymore.