Caso Vercel x Context.ai: cuando tu herramienta de IA es el atacante

El 19 de abril de 2026, la empresa estadounidense Vercel -una plataforma de cloud hosting para aplicaciones web modernas- publicó un boletín reconociendo acceso no autorizado a sistemas internos. La compañía, responsable de Next.js y proveedora de infraestructura frontend para una porción enorme de la web moderna, confirmó que el incidente afectó a un subconjunto limitado de clientes y recomendó la rotación inmediata de credenciales.

Lo más interesante no es el evento en sí, sino el camino que tomó el atacante. El punto de entrada no fue una vulnerabilidad en Vercel, ni un phishing dirigido, ni un zero-day en Next.js. Fue una herramienta de IA de terceros que un empleado había integrado a su cuenta corporativa de Google Workspace.

Este caso marca un incidente público más de gran impacto donde una plataforma agéntica de IA funciona como vector de escalada hacia infraestructura productiva. Vale la pena diseccionarlo.

Reconstrucción técnica del ataque

La cadena de compromiso, según los detalles confirmados por Vercel, su CEO Guillermo Rauch y la propia Context.ai, sigue cinco eslabones:

1. Infección inicial por infostealer. En febrero de 2026, un empleado de Context.ai con privilegios sensibles fue infectado con Lumma Stealer. Según la investigación posterior de Hudson Rock, el vector probable fue la descarga de scripts maliciosos asociados a exploits de juegos. El infostealer extrajo credenciales corporativas, incluyendo accesos a Google Workspace, Supabase, Datadog, AuthKit y la cuenta support@context.ai.

2. Compromiso de Context.ai. En marzo de 2026, Context.ai detectó acceso no autorizado a su entorno AWS y contrató a CrowdStrike para investigar. Cerraron el entorno comprometido, pero no identificaron en ese momento que el atacante también había comprometido tokens OAuth de usuarios de su producto consumer, el AI Office Suite.

3. Pivot vía OAuth a Google Workspace de Vercel. Un empleado de Vercel se había registrado al AI Office Suite de Context.ai usando su cuenta enterprise de Google Workspace y había otorgado permisos "Allow All" durante el flujo OAuth. Cuando Context.ai fue comprometida, ese token OAuth quedó en manos del atacante, junto con los scopes amplios que le permitían operar sobre la cuenta corporativa del empleado.

4. Toma de control del Workspace y acceso a Vercel. Con control del Google Workspace del empleado, el atacante accedió a entornos internos de Vercel. Desde ahí enumeró variables de entorno marcadas como "non-sensitive" en proyectos productivos, una funcionalidad de Vercel que permite designar variables como no sensibles para mostrarse en la interfaz sin cifrado adicional.

5. Exfiltración y monetización. El 19 de abril, un usuario bajo el alias ShinyHunters publicó en BreachForums una oferta de venta del dataset por dos millones de dólares, incluyendo claves de acceso, código fuente y credenciales de empleados con acceso a deployments internos, tokens de NPM y de GitHub.

Cinco eslabones, tres organizaciones distintas comprometidas, y un único error de configuración inicial: un permiso OAuth demasiado amplio otorgado a una herramienta de IA sin revisión de seguridad.

Por qué este vector es estructuralmente nuevo

Las brechas vía cadena de suministro no son novedad. Lo que diferencia este caso es la naturaleza del eslabón intermedio.

Las plataformas agénticas de IA como Context.ai funcionan como capas de orquestación entre herramientas SaaS. Para entregar valor (automatizar flujos, generar documentos, ejecutar acciones en nombre del usuario) requieren scopes OAuth amplios sobre Google Workspace, Microsoft 365, repositorios de código, plataformas de despliegue y bases de datos. Ese acceso es el producto.

El problema es que esos scopes, generalmente no se evalúan con el rigor que se aplicaría a un proveedor SaaS tradicional. Un empleado puede integrar una herramienta de IA a su cuenta corporativa en menos de un minuto, sin pasar por el equipo de seguridad, sin revisión de proveedor, sin contrato firmado. El consentimiento OAuth se vuelve un canal de provisión paralelo, fuera de los controles de gobernanza tradicionales.

A esto se suma una segunda capa: muchas plataformas agénticas son startups jóvenes con prácticas de seguridad aún inmaduras. Context.ai sufrió la infección inicial vía un empleado descargando ejecutables sospechosos. La detección posterior llegó tarde y la notificación a clientes fue parcial. Cuando el atacante alcanzó Vercel, ya tenía visibilidad operativa profunda sobre el ecosistema de víctimas.

El resultado es una nueva clase de ataque a la cadena de suministro de IA: el atacante no compromete tu infraestructura, compromete el agente que tu empleado autorizó para operarla.

Los puntos de fallo no fueron solo de Context.ai

Es tentador leer este incidente como una falla aislada de un proveedor pequeño, pero la cadena se sostuvo gracias a decisiones tomadas en los tres lados.

Del lado de Context.ai: higiene básica de endpoints insuficiente, ausencia de controles que detecten descargas de ejecutables no firmados en máquinas con acceso privilegiado, y notificación parcial tras detectar el compromiso inicial.

Del lado del empleado de Vercel: otorgamiento de permisos "Allow All" a una herramienta de terceros sobre una cuenta enterprise. Este patrón de consentimiento OAuth amplio es común y suele pasar desapercibido para los equipos de seguridad.

Del lado de Vercel: dos puntos relevantes. Primero, la configuración OAuth interna de Google Workspace permitió que esa concesión amplia se materializara sin restricciones a nivel de tenant. Segundo, la funcionalidad de variables "non-sensitive" funcionó como una superficie de enumeración. En palabras de Rauch, la variable estaba pensada para contener información no sensible, pero la enumeración masiva permitió al atacante extender privilegios.

Ningún eslabón solo habría producido la brecha. La combinación sí.

Qué deberían validar los equipos de seguridad esta semana

Para cualquier organización que use Google Workspace o Microsoft 365 con integraciones de IA, hay tareas concretas que no admiten demora.

Auditar aplicaciones OAuth de terceros. En Google Workspace: Security > Access and Data Control > API Controls > Manage Third-Party App Access. En Microsoft 365: Enterprise Applications en Entra ID. El objetivo es enumerar toda aplicación con scopes amplios (Mail.ReadWrite, Drive.Full, Workspace admin) y validar que cada una corresponda a un proveedor aprobado.

Buscar el IOC publicado por Vercel. El identificador de cliente OAuth asociado a la herramienta comprometida es 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Si aparece en los logs de aplicaciones autorizadas, hay que asumir compromiso y rotar credenciales del usuario afectado.

Restringir consentimientos OAuth a nivel de tenant. Por defecto, muchos workspaces permiten que cualquier usuario otorgue permisos a aplicaciones externas. Configurar admin consent workflows reduce drásticamente la superficie de ataque vía OAuth no supervisado.

Revisar variables de entorno en plataformas de despliegue. En Vercel específicamente, marcar como "sensitive" toda variable que contenga claves, tokens o secretos. La diferencia entre las dos clasificaciones es operativa: las sensibles no son legibles desde la UI tras su creación.

Rotar credenciales en cualquier sistema integrado con plataformas agénticas de IA. Si la organización usa herramientas similares a Context.ai (suites ofimáticas con IA, agentes que orquestan acciones cross-SaaS) y no hay certeza sobre el estado de seguridad del proveedor, asumir compromiso y rotar es la postura conservadora.

Implementar detección de exfiltración vía OAuth. Las herramientas agénticas legítimas generan patrones de tráfico distintos a los de un atacante operando con tokens robados. Volúmenes anómalos de lectura masiva, accesos fuera de horarios típicos del usuario, y enumeraciones secuenciales sobre proyectos enteros son señales accionables si el SIEM las correlaciona.

Por qué el modelo de validación tradicional no detecta esto

Un pentest anual sobre la infraestructura de Vercel no habría encontrado este vector. El compromiso no estaba en el código de Vercel, no estaba en su perímetro, no estaba en sus dependencias open source. Estaba en una decisión de configuración tomada por un empleado meses antes, sobre una herramienta de terceros que en el momento del pentest ni siquiera existía en el inventario formal.

Este es exactamente el tipo de superficie que la validación continua pretende cubrir. Cuando los activos cambian todos los días, cuando los empleados integran herramientas nuevas todas las semanas y cuando los atacantes operan con cadenas de tres y cuatro eslabones cross-organización, la foto anual deja de ser informativa.

Acá es donde la combinación de agentes ofensivos autónomos con hackers éticos expertos toma sentido. Los agentes pueden mapear continuamente la superficie real, incluyendo aplicaciones OAuth conectadas, scopes otorgados, variables expuestas en interfaces administrativas y rutas de pivote entre identidades humanas y no humanas. La revisión humana experta interpreta el contexto de negocio: cuál de esos hallazgos representa riesgo real explotable y cuál es ruido. En Strike trabajamos sobre esa lógica, validando de forma continua que la postura defendida coincida con la postura real, no con la postura asumida.

Qué viene después

El caso Vercel x Context.ai no va a ser un incidente aislado. Las plataformas agénticas de IA están en explosión de adopción y las prácticas de gobernanza sobre integraciones OAuth no avanzan al mismo ritmo. La combinación es un terreno fértil para más cadenas de compromiso similares en los próximos meses.

Tres lecturas que se desprenden del análisis y que conviene tener presentes:

Primero, el inventario de proveedores tiene que incluir explícitamente las herramientas de IA conectadas vía OAuth, con la misma seriedad que se aplica a un proveedor SaaS pago. Hoy la mayoría de las organizaciones no las trackean.

Segundo, las identidades no humanas (tokens OAuth, service accounts, claves de API entregadas a agentes) son la nueva frontera del control de acceso. Los marcos de IAM tradicionales fueron diseñados para humanos y no escalan al volumen ni a la velocidad con que las identidades agénticas se crean y mueren.

Tercero, la validación continua deja de ser una preferencia metodológica y pasa a ser un requisito operativo. Las cadenas de compromiso modernas atraviesan tres organizaciones en cuarenta y ocho horas. El control que se valida una vez al año es un control que llega tarde.

El incidente de Vercel le puso nombre y fecha a un riesgo que el sector venía advirtiendo en abstracto. La pregunta para cada equipo de seguridad ahora es concreta: ¿qué herramienta de IA, autorizada por qué empleado, con qué scopes, está hoy mismo dentro del perímetro?

‍