En marzo de 2026, atacantes irrumpieron en Context.ai’s entorno AWS y robaron tokens OAuth que su ahora descontinuado “AI Office Suite” había acumulado de usuarios. Uno de esos tokens pertenecía a un empleado de Vercel que se había registrado con su cuenta de Google Workspace corporativa y había concedido permisos amplios. El atacante usó ese token para entrar al Google Workspace de Vercel como el empleado, pivotó hacia los sistemas internos de Vercel y exfiltró un subconjunto de variables de entorno no sensibles de clientes, que luego fueron anunciadas en venta en BreachForums por $2M por un usuario que se identificó como ShinyHunters. Ambas compañías publicaron boletines el 19 de abril de 2026. El fallo en común no es inyección de prompts, ni un bug en un LLM, ni una falla en el protocolo MCP: es el patrón de décadas de una aplicación OAuth de terceros que almacena del lado del servidor tokens de usuario de larga duración con permisos amplios, convirtiéndose en una bóveda de tokens de alto valor cuyo compromiso se propaga hacia cada tenant conectado.

Como empresa con un rol central en la seguridad agéntica, en Arcade hicimos un análisis profundo para entender cómo se desarrolló todo. Aquí está el desglose

Qué falló

Vercel: Un empleado había conectado el “AI Office Suite” de Context.ai a su cuenta corporativa de Google Workspace con consentimiento amplio (“Permitir todo”). Cuando el entorno AWS de Context.ai fue comprometido, el atacante tomó el token OAuth de ese empleado, se autenticó como él en el Workspace de Vercel, luego escaló a entornos internos de Vercel y leyó variables de entorno que los clientes no habían marcado como “sensibles”. Las variables de entorno sensibles de Vercel (almacenadas de forma que no pueden leerse) no muestran evidencia de haber sido accedidas.

Context.ai: Los atacantes obtuvieron acceso no autorizado al entorno AWS que ejecutaba el AI Office Suite descontinuado, un producto de consumo que permitía a los usuarios conectar agentes de AI a aplicaciones SaaS externas mediante una capa de integración de terceros. Ese entorno contenía tokens OAuth de usuarios del Office Suite, y al menos algunos fueron robados. Context.ai inicialmente notificó a un cliente en marzo de 2026 y solo supo que el radio de impacto era mayor cuando la investigación interna de Vercel lo reveló. Context.ai no ha divulgado el vector de intrusión inicial al AWS. CrowdStrike fue contratado para el análisis forense, pero al 21 de abril no se ha publicado ningún informe. El entorno AWS afectado, el hospedaje y la aplicación OAuth del Office Suite fueron dados de baja tras el incidente.

Clase común: Acaparamiento de tokens por un delegado confundido en una integración de AI multi-tenant. Un servicio de AI de terceros acumuló tokens OAuth de producción para los proveedores de identidad principales de muchos usuarios, los almacenó del lado del servidor y, al ser comprometido, se convirtió en un pivot de un solo salto hacia cada tenant que alguna vez había autorizado la app. El componente “AI” es incidental a la explotación; la vulnerabilidad es un clásico compromiso de bóveda de credenciales en la cadena de suministro SaaS, amplificado por permisos OAuth demasiado amplios.

Modelo de auth que falló:

  • En Vercel: autorización OAuth 2.0 de Google Workspace con flujo de código de autorización y consentimiento de permisos amplios desde una identidad empresarial. The Register citaa Context.ai afirmando que las “configuraciones internas de OAuth de Vercel parecen haber permitido que esta acción otorgara esos permisos amplios en el Google Workspace empresarial de Vercel”. En otras palabras, los controles de administrador del Workspace no restringían qué apps de terceros podían autorizar los empleados con identidades corporativas, y no había ninguna restricción de permisos por app.

  • En Context.ai: almacenamiento del lado del servidor de tokens de actualización OAuth 2.0 de larga duración (y probablemente tokens de acceso de corta duración) para un IdP de terceros, en un entorno AWS multi-tenant compartido, combinado con una UX de consentimiento que aceptaba permisos amplios (“Permitir todo”). El estado de cifrado en reposo de los tokens no fue divulgado; el hecho de que los tokens fueran utilizables tras la exfiltración implica que el cifrado no cubría los tokens o que la clave de descifrado también era accesible desde el entorno comprometido.

IOC (textual de Vercel): OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.comLos administradores de Google Workspace deben revisar el uso de inmediato. Vercel dice que la app “potencialmente afect[ó] a cientos de sus usuarios en muchas organizaciones”.

Participación de AI / MCP / tool-calling: El producto comprometido eraun producto de agentes de AI (Context.ai AI Office Suite) que usaba OAuth para llamar a SaaS externos en nombre de los usuarios. Sin embargo, la explotación real no usó el modelo de AI, no usó inyección de prompts y no requirió el protocolo MCP. El producto de AI fue relevante solo porque fue quien solicitó y almacenó el token OAuth con permisos amplios. No se ha asignado ningún CVE a la fecha de este reporte; no se espera ninguno porque no se explotó ninguna vulnerabilidad de software en Vercel ni en Google.

El fallo en común

Acaparamiento centralizado de tokens OAuth con permisos excesivamente amplios en una plataforma de agentes de terceros, combinado con un radio de impacto cross-tenant en el plano de control cloud de la plataforma.

Mecánicamente, el patrón es:

  1. Una plataforma de AI/agentes de terceros solicita consentimiento OAutha la identidad principal del usuario (Google Workspace, Microsoft 365, etc.) con permisos lo suficientemente amplios para ser útiles en muchas llamadas futuras a herramientas, a menudo porque el producto no sabe de antemano qué herramientas invocará el usuario.
  2. Los tokens de actualización se almacenan del lado del servidor, de forma centralizada, por la plataforma, porque el agente corre de forma asíncrona o en un loop del lado del servidor y debe poder llamar a las APIs del proveedor sin que el usuario esté presente.
  3. El entorno cloud de la plataforma es un dominio de confianza único. Una brecha en ese entorno produce una bóveda de tokens: una sola intrusión, muchas víctimas, a nivel del IdP, no solo a nivel de la plataforma.
  4. El token robado es indistinguible de una sesión legítima ante el proveedor. No hay ningún mecanismo de atestación fuera de banda que confirme que la llamada provino de la plataforma y no de un atacante reutilizando el token, porque el proveedor emitió el token a la plataforma desde el principio.
  5. La política del IdP empresarial no restringía qué apps de terceros podían vincularse a identidades corporativas, ni con qué permisos. La configuración de administrador de Vercel permitía “Permitir todo” a una app que Context.ai describe como emisora de tokens que reflejaban “el alcance de acceso que tenía esa cuenta”.

Esto es de la misma clase que el incidente OAuth de GitHub con Heroku/Travis-CI en 2022 y el incidente de CircleCI en 2023. Es no nuevo con la AI. Lo que la AI cambia es el volumen y amplitud de los permisos: una plataforma de agentes que puede “enviar emails, crear documentos, leer Drive, gestionar calendario, publicar en Slack” solicita una unión de permisos mucho más grande que una integración de propósito único, y por lo tanto se convierte en una bóveda de tokens más valiosa.

Lo que hace la arquitectura de Arcade para mantener seguros tus agentes

Arcade.dev es el único runtime de MCP para despliegues de agentes de AI seguros y confiables.

Aislamiento de tokens OAuth por usuario. Arcade vincula cada autorización a un usuario específico: la herramienta declara requires_auth=Reddit(scopes=["read"]), y Arcade inicia un desafío OAuth para ese usuario, el proveedor emite un token que Arcade almacena asociado a ese usuario, y el token se inyecta en la herramienta Context solo durante la invocación de ese usuario.

Permiso por herramienta, no por app. Cada herramienta declara sus permisos mínimos. Gmail.SendEmail solicita gmail.send, no una unión de permisos de todo el Workspace. Esto le da al usuario control detallado sobre qué datos pueden acceder los servicios de terceros y qué acciones pueden realizar en sus cuentas. Un token de herramienta única comprometido tiene un radio de impacto reducido por diseño.

El LLM y el cliente MCP no ven el token. Arcade está diseñado para manejar cuidadosamente los tokens OAuth cuando los agentes invocan una herramienta. El token OAuth es obtenido por el Engine e inyectado en un Context objeto del lado del servidor en tiempo de ejecución. La función de la herramienta realiza la llamada HTTP saliente del lado del servidor. Esto cierra la ruta de inyección de prompts a filtración de tokens que existe cuando herramientas mal diseñadas cargan tokens en el mismo proceso que el modelo.

Aplicando límites de seguridad correctos. Como lo explicamosen nuestra guía de autorización de servidores MCP, Arcade respeta los límites de seguridad entre el cliente MCP (no confiable), el servidor MCP (confiable) y el proveedor de auth (confiable). Esta es la inversión arquitectónica del patrón de Context.ai, donde el runtime del agente era también la bóveda de tokens y una sola brecha colapsó ambos.

Verificador de usuario. Cuando un usuario autoriza una herramienta por primera vez, Arcade realiza una verificación de identidad del usuario “para confirmar que el usuario que está autorizando la herramienta es el mismo que inició el flujo de autorización, lo que ayuda a prevenir ataques de phishing”. Se espera que los despliegues en producción implementen un verificador personalizado para que los usuarios se autentiquen contra el sistema de identidad propio de la aplicación, no el de Arcade.

Hooks de Acceso Contextual. Arcade ofrece tres puntos de enganche(acceso, pre-ejecución, post-ejecución) que permiten al operador inyectar webhooks para rechazar una llamada a una herramienta, eliminar PII de una respuesta, escanear salidas en busca de inyección de prompts o registrar cada invocación. Los hooks se encadenan tanto a nivel de organización como de proyecto; el comportamiento ante fallos (fail-closed vs fail-open) es configurable. Este es el mecanismo para “auditar cada interacción” y para detectar patrones de exfiltración en tiempo de ejecución.

Self-hosting como reducción del radio de impacto. Arcade publica documentación de despliegue de servidores MCP on-premises y un Engine self-hosted («leer docs»). Ejecutar Arcade en el propio cloud del cliente reduce el riesgo cross-tenant demostrado en el caso Context.ai a un riesgo de un solo tenant.

Logs de auditoría. El plano de control de Arcade es totalmente auditable y proporciona un registro automático e inmutable de cada acción administrativa tomada en el runtime del agente.

Conclusión

Llamar a esto “una brecha de AI” es impreciso de una forma que oscurece la lección. Ningún modelo fue jailbreakeado. No se explotó ninguna falla en MCP. No se activó ninguna inyección de prompts. Lo que ocurrió fue que una pequeña empresa de AI construyó un producto que requería tokens OAuth amplios y de larga duración para ofrecer comportamiento agéntico útil, los almacenó de forma centralizada, fue hackeada y le entregó a un atacante una sesión corporativa lista para usar contra el empleador de uno de sus usuarios. El ángulo de AI importa porque los productos agénticos sistemáticamente solicitan uniones de permisos más grandes que las integraciones de propósito único, lo que hace que sus backends sean objetivos de mayor valor. Sin embargo, en este caso la técnica de explotación es un pivot OAuth de terceros de la era de los 2010s.

La arquitectura de Arcade ataca directamente las dos propiedades más dañinas de ese patrón: acota los tokens por herramienta en lugar de por app, y mantiene los tokens fuera del proceso LLM/cliente para que un compromiso de la superficie orientada al agente no implique un compromiso del token. Claro, no hace el plano de control invencible, no adivina lo que los usuarios consideran permisos razonables y no corrige la política del IdP empresarial. Lo que sí hace es cambiar la matemática del radio de impacto: una brecha en una bóveda de tokens estilo Arcade produce tokens más acotados y auditables, y los despliegues self-hosted eliminan el vector cross-tenant que convirtió la intrusión única de Context.ai en un incidente multi-organización. La conclusión correcta para líderes de ingeniería es más concreta que “cambiar de proveedor”: es “auditar cada app OAuth de terceros vinculada a tu IdP corporativo, aplicar permisos mínimos en la capa de administrador del Workspace y tratar cualquier plataforma de agentes que acapare refresh tokens como un almacén de credenciales de producción”. Vercel ya cambió un comportamiento por defecto como respuesta: la creación de variables de entorno ahora es sensible por defecto. El cambio de fondo que aún falta está antes que ambas compañías, en la UX de consentimiento OAuth.

El equipo de Arcade.dev lleva años reforzando la autenticación en Okta, Stormpath y Redis. Aplicamos esas lecciones para hacer que la infraestructura de AI esté lista para producción. Mira estos principios en acción en nuestro blueprint para una alternativa segura a OpenClaw usando Arcade y Claude Code.

¿Quieres construir agentes de AI que funcionen de verdad en producción? Mientras esperamos que la autorización llegue a MCP, Arcade ya implementa auth segura para más de 100 integraciones. Sin bot tokens, sin pesadillas de seguridad: solo flujos OAuth reales que funcionan.

Empieza a construir con Arcade → Regístrate.