Shadow AI 2.0: ya no es ChatGPT, son los OAuth scopes que nadie revisó

El 19 de abril, Vercel publicó un comunicado raro. No dijeron "nos han hackeado". Dijeron que un proveedor —Context.ai— había sufrido una brecha y que algunos datos de Vercel estaban implicados.

Lo extraño: Vercel no era cliente de Context.ai.

Un empleado se había registrado por su cuenta. Con su email corporativo. Y al hacerlo, dio permisos OAuth con scope amplio a su Google Workspace y a entornos internos de Vercel.

Dos meses después, una infección con Lumma Stealer en un equipo de Context.ai expuso esos tokens. Resultado: 580 registros de empleados de Vercel comprometidos, API keys filtradas, base de datos a la venta en BreachForums por 2 millones de dólares.

Ningún CISO de Vercel aprobó nunca el uso de Context.ai. Su inventario de SaaS no lo tenía. No estaba en ninguna evaluación de proveedor. Y aun así, fue el vector.

Lo que llamábamos Shadow AI ya no es lo que es

La definición tradicional de shadow AI: un empleado pegando información confidencial en ChatGPT desde su navegador personal. Solución clásica: bloquear ChatGPT en el firewall. Educar. Repetir.

Eso era 2024. Hoy el problema ha mutado.

Shadow AI 1.0 (lo que tu política sigue cubriendo):

• Un empleado pega un documento confidencial en ChatGPT
• Un comercial usa Claude desde su móvil personal con datos de clientes
• El equipo de soporte mete tickets en una IA externa para resumir

Tu defensa: bloquear, formar, monitorizar tráfico saliente. Funciona regular, pero al menos sabes qué buscas.

Shadow AI 2.0 (lo que está pasando ahora y casi nadie tiene en el radar):

• Un empleado se registra en una herramienta IA externa con su correo corporativo
• La herramienta pide OAuth con scopes amplios: drive.full, mail.full, calendar.full, admin.read
• El empleado da clic en "Allow All" porque la herramienta es legítima en apariencia
• A partir de ese momento, esa app puede leer (y a veces escribir) en tu Google Workspace o Microsoft 365 sin que tu IDP haga ruido

El empleado de Vercel hizo exactamente esto. Context.ai era una herramienta legítima, conocida en el mundo del producto, con un caso de uso real. La empresa proveedora no era maliciosa. Pero los tokens OAuth quedaron expuestos cuando un equipo de su personal se infectó con un infostealer. Y esos tokens daban acceso a información de Vercel.

Por qué tu inventario no lo ve

El problema técnico es sencillo. Cuando alguien revisa qué SaaS usa una empresa, mira:

1. Lo que ha contratado el equipo de Compras
2. Lo que ha desplegado IT central
3. Lo que tiene SSO corporativo configurado

Una app que un empleado autorizó por OAuth desde su cuenta personal —pero usando el correo corporativo— no aparece en ninguna de las tres listas. No está contratada. No está desplegada. No tiene SSO. Pero tiene un token activo con scope drive.readonly a tu Google Workspace.

Los datos del estudio Lenovo Work Reborn 2026 (publicado el 1 de mayo) lo dejan claro:

• 31% de los empleados que usa IA no recibe ninguna formación de su empleador
• 70% usa IA varias veces por semana y espera usarla más en los próximos 12 meses
• 80% de los responsables de IT reconoce que NO tiene visibilidad completa de las herramientas IA en uso
• Los ejecutivos son el segmento que más shadow AI usa (datos UpGuard)

Ese 80% sin visibilidad no es despreocupación. Es que las herramientas tradicionales —CASB, DLP, firewall outbound— no están diseñadas para detectar autorizaciones OAuth otorgadas a apps no conocidas. Detectan tráfico, no consentimientos.

Lo que pasó en la línea de tiempo de Vercel

Reconstruyendo lo que la propia empresa publicó y lo que Trend Micro y Push Security analizaron después:

Cuándo	Qué pasó
~febrero 2026	Empleado de Vercel se registra en Context.ai con email corporativo. Da OAuth con scopes amplios a su cuenta de Google Workspace.
febrero 2026	Un equipo en Context.ai se infecta con Lumma Stealer. Se filtran tokens de sesión, cookies y secretos —incluyendo el OAuth token que daba acceso a recursos de Vercel.
febrero–abril 2026	Atacantes acceden silenciosamente a recursos de Vercel a través del token OAuth filtrado. Sin alarmas en Vercel: la actividad parecía legítima del propio empleado.
~16 abril 2026	Aparece anuncio en BreachForums: base de datos de Vercel a la venta por 2 M USD.
19–20 abril 2026	Vercel publica el incidente. Context.ai confirma la brecha. Identifican la app OAuth maliciosa: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.

Lo que importa de la línea de tiempo es que Vercel no fue el objetivo del ataque. El objetivo fue Context.ai. Vercel fue el daño colateral porque uno de sus empleados había firmado un OAuth meses antes.

Esto va a ser el patrón dominante. Cualquier herramienta SaaS de IA que tenga clientes con OAuth scopes amplios es ahora un trampolín hacia esos clientes.

Qué hacer esta semana

No te propongo un programa de transformación de seis meses. Te propongo cuatro cosas que puedes empezar el lunes y tener listas en una semana.

1. Inventario forzado de OAuth grants en tu tenant

Si usas Google Workspace: Admin Console → Security → API controls → Domain-wide delegation y App access control. Lista de aplicaciones de terceros con acceso. Filtra por scopes con full, admin, mail, drive.

Si usas Microsoft 365: Entra ID → Enterprise applications → All applications. Mira columna "Permissions" y enseña las que tengan Mail.ReadWrite, Files.Read.All, Directory.Read.All, etc.

El tiempo total de esta tarea es de unos 30 minutos. Y vas a llorar con lo que encuentres.

2. Política de allowlist para apps OAuth

Por defecto, permite que los empleados den consentimiento solo a apps que pasen revisión. En Google Admin → "Restrict access to Google services". En Entra ID → "User consent settings: Do not allow user consent". Las apps que tu empresa quiera usar entran por allowlist explícita.

Esto rompe algunas cosas el primer día. Pero es la única forma de pasar de visibilidad a control.

3. Alertas de OAuth grants nuevos con scope amplio

Configura alerta en cualquiera de los dos tenants para "nueva app OAuth autorizada con scope > X". En Google: Cloud Identity audit logs → filtro por oauth_grant. En Microsoft: Defender for Cloud Apps → app discovery + alertas. La regla mental: si aparece un consent nuevo, alguien del equipo de seguridad lo mira en menos de 24h.

4. Comunica antes de aplicar

Lo último que quieres es romper el flujo de trabajo del equipo de producto sin avisar. Manda un email interno explicando:

• el riesgo concreto,
• el cambio que vas a hacer,
• cómo pedir aprobación de una herramienta nueva.

Tres párrafos. Si lo justificas con el caso de Vercel, casi nadie lo discute.

Lo que viene

El ecosistema de herramientas IA SaaS está creciendo más rápido que tu capacidad de evaluarlas como proveedor. La media de apps en un Microsoft 365 corporativo este año ha pasado de 200 a más de 400 según Push Security. La mayoría son shadow.

Y aquí es donde el problema se acelera: las apps de IA tienden a pedir scopes más amplios que las apps SaaS tradicionales. No porque los desarrolladores sean malos, sino porque el caso de uso es "darle contexto al modelo" — y "contexto" en la práctica significa drive.full, mail.full, calendar.full.

Si tu organización va a permitir agentes IA en producción —y todas lo van a permitir— el primer trabajo no es construir agentes seguros. Es cerrar el grifo de los OAuth no aprobados. Cualquier inversión en gobernanza IA que no empiece por ahí, está construyendo sobre arena.

Y este inventario OAuth no es opcional: es el Paso 1 de cualquier auditoría del EU AI Act. Si quieres ver el plan completo (los 7 pasos para auditar el cumplimiento antes de diciembre 2026), te lo cuento aquí: Auditoría EU AI Act paso a paso para CISOs.

El otro lado del mismo problema — qué pasa cuando un actor de amenaza usa IA para descubrir fallos en SaaS de IA que tienes integrados sin saberlo — lo cuenta Google con datos esta semana: el primer zero-day generado con IA que GTIG cortó antes de explotación masiva.

Y hay una capa más reciente todavía, que muchos inventarios SaaS no ven porque ni siquiera está en el catálogo de proveedores aprobados: las aplicaciones internas que tus propios empleados están construyendo y desplegando con herramientas tipo Lovable, Base44 o Cursor en modo agente. Lo desarrollo en los riesgos del vibe coding y su triángulo mortal — datos verificables y plan CISO incluidos.

La pregunta para tu próximo comité: "¿Cuántas aplicaciones SaaS de IA tienen OAuth activo en nuestro tenant ahora mismo, y cuántas pasaron por el proceso de evaluación de proveedor?"

Si las dos cifras no coinciden —y no van a coincidir— ya tienes el primer trabajo.

Si quieres profundizar en algún control específico, puedes contactar conmigo en hola@enriquemaza.com o por LinkedIn.

Fuentes

• Vercel KB — Vercel April 2026 Security Incident
• TechCrunch — Vercel confirms security incident, customer data stolen via Context.ai breach (20 abr 2026)
• Trend Micro Research — Vercel breach: OAuth as supply chain (abr 2026)
• Push Security — Unpacking the Vercel breach (abr 2026)
• Help Net Security — Lenovo Work Reborn 2026: shadow AI risks & IT oversight (1 may 2026)
• Cybersecurity Dive — Executives are the worst shadow AI offenders (UpGuard data)