El sábado 19 de abril, a media mañana, Vercel publicó un bulletin de seguridad: acceso no autorizado a sistemas internos, un subconjunto de clientes afectados. Cada equipo de desarrollo que usa Vercel — incluido el nuestro, nosotros deployamos ahí para clientes — abrió el dashboard y empezó a contar variables de entorno.

La parte que más te debe importar no está en la primera línea. Está en la segunda actualización del mismo bulletin: “The incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee.”

Traducido al lenguaje operacional: no fue Vercel. Fue una herramienta de IA de terceros con OAuth al Google Workspace de un empleado. Desde ahí el atacante caminó — cuenta de Google Workspace, ambiente interno de Vercel, variables de entorno de clientes que no estaban marcadas como “sensitive”. Guillermo Rauch, CEO de Vercel, lo publicó literal en X horas después: “A Vercel employee got compromised via the breach of an AI platform customer called Context.ai that he was using.”

Eso no es una brecha de Vercel. Es una brecha de gobernanza de vendors que terminó dentro de Vercel. Son cosas distintas y la diferencia importa para entender qué debes hacer tú esta semana.

Rauch hizo lo correcto y eso también importa

Antes de seguir con el patrón, un punto incómodo pero necesario: Vercel publicó el incidente el mismo día que lo detectó. Rauch escribió la nota larga con el origen del ataque, no esperó a que un reporter lo filtrara. Mencionó que trabaja con Mandiant y law enforcement. Publicó mejoras específicas al UI de variables sensitive como respuesta. Esa es la forma.

Comparado con el promedio de la industria, que tarda semanas o meses en confirmar públicamente lo que ya sabe internamente, la ventana entre “detectamos el incidente” y “el CEO lo escribió de cara al cliente” fue de horas. Eso no arregla el daño, pero sí define la diferencia entre un vendor con el que puedes seguir operando y uno del que debes salir.

Nuestra posición, con Vercel debajo de múltiples clientes nuestros, es clara: no movemos a nadie por esto. Movemos la gobernanza de OAuth, rotamos lo que tenía que rotarse y marcamos como sensitive lo que debía estarlo desde el principio. Lo que haríamos en cualquier plataforma que tenga la misma clase de superficie, que son todas.

El frame que ya estaba escrito

El caso de Vercel no es una sorpresa analítica. El paper AI Agent Traps de Google DeepMind — escrito por Matija Franklin, Nenad Tomašev, Julian Jacobs, Joel Z. Leibo y Simon Osindero — ya había mapeado este tipo exacto de ataque. Son 17 páginas. Lo analicé el 6 de abril, cuando un hilo viral en X inventó cifras sobre el paper y acumuló más de un millón de vistas.

La tesis del paper: todo el gasto de seguridad de IA va al modelo. Jailbreaks, prompt injection filters, alignment training, red-teaming del modelo base. El atacante pasa por el lado. No ataca el modelo. Altera el ambiente donde el agente opera.

El framework clasifica 18 vectores de ataque distribuidos en 6 categorías, según qué componente del agente atacan:

• Content Injection (percepción). Lo que el humano ve en una página no es lo que el agente parsea. Instrucciones maliciosas en comentarios de HTML, CSS oculto, metadata de imágenes, etiquetas de accesibilidad.
• Semantic Manipulation (razonamiento). Corromper el proceso de síntesis y juicio interno del agente.
• Cognitive State (memoria). Envenenar bases de conocimiento RAG, memoria persistente, aprendizaje en contexto. El agente queda comprometido después de la sesión.
• Behavioural Control (acción). Secuestrar las herramientas del agente para forzar acciones no autorizadas — exfiltración, transacciones ilícitas, uso legítimo de credenciales OAuth para escalar.
• Systemic (multi-agente). Sembrar el ambiente para disparar fallas correlacionadas en muchos agentes a la vez.
• Human-in-the-Loop (supervisor humano). Explotar los sesgos cognitivos del humano que aprueba salidas del agente. Fatiga de aprobaciones, resúmenes densos, recomendaciones que parecen útiles.

Lo que le pasó a Vercel cabe clarísimo en la categoría cuatro, Behavioural Control. No atacaron a Claude o GPT. Comprometieron Context.ai (un agente empresarial), usaron su acceso OAuth legítimo a Google Workspace como herramienta y desde ahí escalaron hacia adentro. El modelo se portó bien. El OAuth hizo exactamente lo que le pidieron.

Dos semanas antes de que pasara, el paper ya lo había descrito como vector. No como predicción — como clasificación. Esa es la parte que debería molestar.

Tres incidentes en un trimestre con el mismo patrón

Si miras solo este fin de semana, parece evento único. Si miras el trimestre, es el tercero.

El 24 de marzo, el grupo TeamPCP envenenó LiteLLM en PyPI comprometiendo primero Trivy, el escáner de seguridad de Aqua Security. La herramienta que se suponía debía proteger fue el vector de entrada. 97 millones de descargas mensuales de LiteLLM, credenciales recolectadas de AWS, GCP, Azure, Kubernetes y archivos .env. Se detectó por casualidad — el payload crasheó una máquina de desarrollador por consumo de RAM.

El 7 de abril, Anthropic publicó Project Glasswing con Claude Mythos Preview. El modelo encontró zero-days en cada sistema operativo y navegador importante, incluyendo bugs de 27 años en OpenBSD y 16 en FFmpeg. Lo que 27 años de humanos no vieron, la IA lo encontró. La consecuencia no es “ahora estamos seguros”. La consecuencia es: si los defensores lo tienen, los atacantes van a tener el equivalente pronto.

El 19 de abril, Vercel vía Context.ai. Tres vectores distintos:

• Supply chain de paquetes (LiteLLM).
• Descubrimiento automatizado de vulnerabilidades (Glasswing).
• OAuth de IA de terceros (Vercel).

Un patrón: el modelo no es el objetivo. El ambiente y la cadena de vendors sí. El paper de DeepMind describe el mapa, los tres incidentes son puntos en el mapa.

El moat se mueve a la gobernanza de vendors

Hace seis meses el argumento en todas las reuniones era “tenemos que adoptar IA rápido”. Esa conversación está cerrada — cada empresa va a tener una IA, lo escribí ayer. La conversación abierta es la siguiente: ¿sabes qué herramientas de IA tienen acceso a qué datos de tu empresa, y puedes apagar cualquiera en cinco minutos si hace falta?

El moat (ventaja competitiva) en 2026 deja de ser “el agente más inteligente” y pasa a ser “la gobernanza más limpia de OAuth y vendors”. Dos empresas pueden tener los mismos agentes encima, con los mismos modelos y las mismas integraciones. La que tiene inventario de quién tiene qué acceso y procedimiento de revocación documentado sobrevive al próximo Context.ai. La otra se entera por un bulletin.

Alex Turnbull, fundador de Groove, publicó en LinkedIn la guía de triage el mismo domingo. Incluye el OAuth Client ID específico del atacante como indicador de compromiso (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) para buscar en el admin console de Google Workspace. Eso es lo que significa gobernanza operacional: no un documento de políticas, un Client ID que puedes pegar en un buscador y revocar con tres clicks.

Qué debes hacer esta semana

Tres cosas concretas. No son opcionales si tienes Vercel, Supabase, Netlify o cualquier plataforma gestionada debajo de productos de cliente.

Para empezar, audita tus OAuth grants. En Google Workspace eso es Admin Console → Security → Access and data control → API controls → Manage Third-Party App Access. Revisa cada app conectada. Las que no reconozcas, revócalas. Las que requieren scopes amplios (Gmail, Drive, Calendar completos) sin justificación clara, restringelas o revócalas. Este es el ejercicio que nadie hace hasta que ya es tarde.

Asume además que lo que no estaba marcado como “sensitive” quedó expuesto. En Vercel específicamente, cualquier env var no marcada como sensitive fue potencialmente accesible durante la ventana del incidente. Rotalas. Pasa todas las que contienen secretos al modo sensitive. Esto aplica también a tus propios despliegues aunque no hayas recibido notificación directa — la práctica debió estar desde el día uno.

Por último, necesitas un inventario real de las herramientas de IA de terceros con acceso a tu infraestructura. No me refiero solo a las que tú contrataste. Me refiero a las que cualquier empleado conectó vía OAuth en el último año. Herramientas de notas, agentes de productividad, scrapers, integraciones de calendar, bots de Slack. Cada una es una superficie de ataque potencial. El inventario es el 80% del trabajo de gobernanza. El otro 20% es el proceso para mantenerlo actualizado.

Si los tres pasos te toman más de dos horas, es señal de que la gobernanza ha estado en modo reactivo por demasiado tiempo.

Qué hacemos en IQ Source

Somos transparentes sobre esto: deployamos clientes sobre Vercel. Las últimas 24 horas las dedicamos a tres cosas, no a una.

Auditamos todas las variables de entorno de cada proyecto de cliente, identificamos cuáles no estaban marcadas como sensitive, las marcamos y rotamos las que contenían secretos reales. Revisamos la lista de OAuth grants en nuestro propio Google Workspace, revocamos dos integraciones que habían quedado huérfanas y documentamos cuáles herramientas siguen activas con qué scopes. Llamamos a cada cliente con infraestructura sensible a explicar qué hicimos y qué deben hacer ellos en sus propios ambientes.

No vamos a mover a ningún cliente fuera de Vercel por este incidente. La razón operacional es simple: el vector no fue Vercel, fue OAuth de terceros en Google Workspace. Esa superficie existe en AWS Amplify, en Netlify, en Cloudflare Pages y en cualquier plataforma gestionada que tú contrates. Moverse es cambiar de marca, no cambiar de riesgo. Lo que sí cambiamos es el proceso interno de auditoría de OAuth, que pasa de anual a trimestral.

Para clientes nuevos lo que ofrecemos en Operación de IA ahora incluye explícitamente un inventario de OAuth de terceros y un procedimiento de revocación antes de que cualquier agente entre a producción. No es un upsell cosmético — es la parte del trabajo que seis meses atrás era opcional y este trimestre dejó de serlo.

Lo que no hacemos: vender pánico. Si tu operación no tenía auditoría de OAuth antes del 19 de abril, no la necesita porque Vercel fue noticia. La necesita porque llevaba tiempo siendo un hueco. El incidente solo te dio el permiso político para priorizar lo que ya debía estar priorizado.

La ventana corta

Tienes una ventana corta, tal vez dos semanas, donde la auditoría de OAuth y vendors tiene atención ejecutiva automática. Después el ciclo de noticias se mueve, la conversación vuelve a roadmap y features, y este trabajo vuelve a competir por prioridad contra todo lo demás.

Si tu stack incluye al menos una plataforma gestionada con acceso a datos de clientes y al menos una herramienta de IA de terceros con OAuth activo en tu Google Workspace, escríbenos esta semana. No buscamos vender una auditoría formal. Lo que sí hacemos gratis es revisar contigo el admin console de tu Google Workspace, identificar las tres apps más riesgosas y decirte qué revocar antes del lunes. Treinta minutos. Si después de eso quieres una auditoría completa, conversamos. Si no, te ahorramos la brecha de la semana que viene.

Es el tipo de conversación que en 2025 se hubiera sentido excesiva. En 2026, después de LiteLLM, Glasswing y Vercel en un trimestre, se siente tarde.