When Vercel published an indicator of compromise for the security incident it disclosed on 19 April 2026, the indicator it published was a Google Workspace OAuth client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. The accompanying instruction to the wider community was that Google Workspace administrators and account owners should check for usage of that app immediately.

That is a particular kind of IOC, and it implies a particular kind of detection surface. A file hash asks whether something is present on your disks. A client ID asks whether an authorization exists in your directory, and who issued it. The second question is harder for most organisations to answer quickly, because the grants in question were issued one employee at a time, through consent screens, by people who understood themselves to be installing a helpful AI tool rather than onboarding a vendor.

Authorization is where an AI tool actually integrates

An AI assistant is rarely dangerous because of what the model says. It is dangerous because of what it is authorized to reach. The integration is not the model — it is a token with a scope, sitting in someone else's database, valid until a specific person explicitly withdraws it.

Vercel's bulletin describes the chain plainly. The incident "originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee." The attacker used that access to take over the employee's individual Vercel Google Workspace account, which led to that employee's Vercel account, then a pivot into a Vercel environment, and from there the enumeration and decryption of environment variables that were not marked as sensitive. Vercel characterises the origin as "a small, third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise, potentially affecting its hundreds of users across many organizations." Working with GitHub, Microsoft, npm and Socket, Vercel's security team confirmed that no npm packages published by Vercel had been compromised. Google Mandiant and law enforcement were engaged.

As Vercel tells it, the chain begins outside Vercel's own systems, at an authorization that had been legitimately granted.

The pattern has a precedent, and the precedent left a receipt

This shape is not new. Salesloft's trust centre carries Mandiant's findings on the 2025 Drift intrusion, and the operative sentences are almost clinical: the threat actor "accessed Drift's AWS environment and obtained OAuth tokens for Drift customers' technology integrations," then "used the stolen OAuth tokens to access data via Drift integrations." An earlier Salesloft update dates the resulting exfiltration from customer Salesforce instances to 8–18 August 2025; Mandiant places the wider intrusion between 22 March and 5 September 2025.

The remediation instruction is the part worth reading twice. For grants Salesloft controlled centrally, it acted on its customers' behalf: it "rotated all centrally managed client keys, which invalidated all affected tokens." For the integrations customers managed themselves via API key, the guidance was that customers could "see a list of your current connected integrations within the Drift Admin settings," and that "these actions will need to be taken directly within the third-party provider's application."

There is the architectural tell, stated by the vendor in the middle of its own incident. Where a chokepoint existed, revocation was one operation performed once, centrally. Where it did not, revocation was a list, a browser and a person working through third-party consoles while the incident was still open.

Why offboarding ranks first among non-human identity risks

The OWASP Non-Human Identities Top 10 — an OWASP incubator project, published for 2025 and ranked on exploitability, prevalence, detectability and impact — puts NHI1: Improper Offboarding in first position, defining it as "the inadequate deactivation or removal of non-human identities (NHIs) such as service accounts and access keys when they are no longer needed." Third on the same list is NHI3: Vulnerable Third-Party NHI, which describes the Context.ai shape directly: a third-party integration that, once compromised, can be "exploited to steal these credentials or misuse the granted permissions."

That ranking follows from a structural asymmetry rather than from severity alone. Human offboarding works because it has a trigger — a termination date, a ticket, a directory deprovisioning job that fires on a status change. An OAuth grant issued to an AI tool produces no equivalent event. The employee who authorized it may still work there. The tool may still be in daily use by another team. The grant does not age out on its own, ownership of it is often unassigned, and in the two incidents above the signal that it should be withdrawn arrived as a security bulletin from a vendor that a security team had not necessarily catalogued.

That is the uncomfortable version: for grants issued this way, the revocation trigger tends to be somebody else's disclosure.

What a chokepoint changes, and what it does not

The web got API gateways. Traffic got web application firewalls. Identity got identity-aware proxies. Each of those shifts happened for the same reason: integrations scaled faster than per-integration governance could keep up, so the industry built a chokepoint. Agent tool access is scaling the same way — many agent clients against many tool servers, each connection authenticated separately, each credential stored separately, each call invisible to the security team by default.

A chokepoint does not make a compromised vendor safe, and it does not undo an exfiltration. What it changes is the cost of the three questions you have to answer under time pressure: which grants exist, who issued them, and how quickly they can be withdrawn. Those are inventory and revocation questions rather than detection questions, which means they can be answered in advance, calmly, before a client ID shows up in somebody's bulletin.

How Waxell handles this

The Waxell MCP Gateway is one governed MCP endpoint per tenant that agent clients point at instead of configuring upstream servers individually. Its product page names the problem in the same terms this post has been using: "offboarding requires chasing credentials across 5–15 SaaS admin consoles," and "no central list of which MCP servers your team has connected."

Two mechanics matter for the failure mode above. The first is attribution: each tool call brokered by the gateway is resolved to a real user identity rather than a service account, with per-upstream auth modes that include on-behalf-of OAuth, where the gateway brokers the flow and stores a KMS-encrypted refresh token that is never returned to the agent client; a shared service account configured at the org level; or a bring-your-own token held in the credential broker. The second is revocation: deactivating a person's Waxell account withdraws the per-upstream OAuth grants that user held through the gateway, in one transaction rather than a per-tool chase, and the audit log records the revocation event, the timestamp, the actor and the list of upstreams unwound.

Alongside that, the policy engine evaluates a brokered call before dispatch and evaluates the result again on the way back, using documented policy actions grouped into access control, data protection, budget and abuse, and supply-chain defence, with a fixed deny > require_approval > redact > allow precedence. The audit log is durable, exportable to CSV, and stores no payload values.

One honest boundary, because it is the difference between a governance claim and a marketing claim. The Vercel incident travelled through a Google Workspace OAuth grant to a SaaS application, not through an MCP tool call, and the gateway governs the calls that traverse it. Agents holding direct upstream credentials, locally registered MCP servers and unconfigured clients bypass it; coverage is something you configure rather than something that arrives by default. What the gateway offers is narrower and more useful than a guarantee: for the tool access you do route through it, the inventory exists before the incident, and the revocation is one operation instead of fifteen.

FAQ

Why would an OAuth client ID be published as an indicator of compromise?

Because in this incident the attacker's access derived from a granted authorization rather than from malware resident on a victim's systems. Vercel published the client ID of the third-party AI tool's Google Workspace OAuth app and recommended that Google Workspace administrators and account owners check for usage of that app immediately. The detection question that poses is a directory question, not an endpoint question, and most incident-response muscle memory is built for the latter.

Is an AI tool OAuth grant different from any other SaaS OAuth grant?

Technically, no — it is the same protocol and the same token lifecycle. Operationally, the difference is provenance. Vercel's own description is of "a third-party AI tool used by a Vercel employee," which is the adoption pattern that makes these grants hard to inventory: they are frequently authorized by an individual during self-service adoption rather than through a procurement or security review. That is a governance gap rather than a protocol gap.

Does revoking a grant undo the damage?

No. Revocation stops continued access; it does not un-exfiltrate data. In the Vercel case the recommended follow-up was to treat environment variables that were not marked as sensitive — API keys, tokens, database credentials, signing keys — as potentially exposed and rotate them as a priority. Vercel also noted that deleting projects or accounts is not sufficient, because compromised secrets may still provide access to production systems.

What does OWASP say the top non-human identity risk is?

Improper offboarding, ranked NHI1 in the OWASP Non-Human Identities Top 10 for 2025. The project is an OWASP incubator project and ranks its entries on exploitability, prevalence, detectability and impact. Vulnerable third-party non-human identities rank third on the same list.

Where should a team start if it cannot inventory its AI tool grants today?

Start with the directory rather than with the tools. Third-party app access reporting in your identity provider will enumerate which applications hold grants and which users issued them — the same question an IOC like Vercel's forces you to answer under pressure. From there, deciding which categories of agent tool access should be routed through a single governed endpoint is a scoping exercise you get to do once, on your own schedule.

Does routing tool calls through a gateway create a single point of failure?

It concentrates a control point, which is the intended trade, and the failure mode is worth understanding before you make it. On the Waxell gateway the process is stateless — approvals, policy rules and OAuth grants live in the control plane, and multiple instances run behind a load balancer, so a failing instance is handled by another with the same policy and approvals state.

Sources

• Vercel, "Vercel April 2026 security incident" (Vercel Knowledge Base), bulletin updated 19–24 April 2026.

• Salesloft, "Update on Mandiant Drift and Salesloft Application Investigations" (Clari/Salesloft Trust Center), update as of 6 September 2025.

• Salesloft, "Summary of the Mandiant Investigation of Drift Applications" (Clari/Salesloft Trust Center), posted 17 April 2026.

• Salesloft, "Drift/Salesforce Security Update" and "Notice: Drift Temporarily Offline Effective Friday, September 5, 2025" (Clari/Salesloft Trust Center).

• OWASP Foundation, "OWASP Non-Human Identities Top 10" (owasp.org), 2025 edition.

• Waxell, "MCP Gateway — Governed AI Tool Access" (waxell.ai).

• Waxell, "Policies & Approvals" (waxell.ai docs).

Your agents are already holding tokens that somebody granted them. Start free with the Waxell MCP Gateway and one governed MCP upstream at waxell.dev/signup — the free workspace includes 10,000 traced executions per month, two seats and one governed upstream, so the inventory exists before you need it.