Not in the middle: why a Context AI–style breach against Caiioo would yield nothing useful

Esta es una traducción automática del documento original en inglés. En caso de cualquier discrepancia entre esta traducción y la versión original en inglés, prevalecerá la versión en inglés. Leer la versión original en inglés

No estamos en el medio: por qué una brecha al estilo de Context AI contra Caiioo no produciría nada útil

2026-04-22 · Caiioo Team

El 19 de abril de 2026, Vercel reveló que la herramienta de IA de terceros de un solo empleado había sido comprometida, y que el token de OAuth comprometido se había utilizado para pivotar hacia los entornos internos de Vercel. Un subconjunto limitado de clientes sufrió la exposición de variables de entorno no sensibles. Las variables de entorno cifradas/sensibles no se vieron afectadas.

La herramienta era Context AI. El empleado le había otorgado un acceso amplio de "Permitir todo" a su Google Workspace corporativo. Esa única concesión de OAuth, alojada en los servidores de Context AI, fue el punto de apalancamiento para todo lo que siguió.

Un actor de amenazas en BreachForums ha listado por separado lo que afirma son 580 registros de empleados de Vercel a la venta por $2M. Vercel no ha verificado esa lista.

El incidente no ha terminado. Pero la lección arquitectónica ya está clara, y es útil para cualquiera que evalúe un espacio de trabajo de IA.

La forma del ataque

El modelo SaaS-AI coloca a un proveedor en medio de cada concesión de OAuth que usted le otorga.

Cuando instala una herramienta de productividad de IA de terceros y hace clic en la pantalla de consentimiento de OAuth, el token de acceso y el token de actualización emitidos por Google (o Microsoft, o cualquier proveedor de identidad) no permanecen en su dispositivo. Se entregan a los servidores del proveedor, porque la IA que los necesita se ejecuta en la nube del proveedor. La infraestructura del proveedor mantiene un conjunto de tokens continuamente actualizados para cada uno de sus usuarios, con el alcance de los permisos de "Permitir todo" en los que la mayoría de los usuarios hicieron clic sin leer.

Ese almacén centralizado de tokens es precisamente lo que los atacantes buscan. Comprometer al proveedor una vez les da acceso al Workspace de miles de clientes. El propio boletín de Vercel advierte que los efectos derivados podrían afectar a "cientos de usuarios en muchas organizaciones".

Los informes rastrean la cadena original hasta un empleado de Context AI cuyo dispositivo personal fue comprometido en febrero de 2026, supuestamente a través de un exploit de un juego de Roblox descargado que contenía el malware infostealer Lumma Stealer. Ese malware exfiltró las credenciales de Google Workspace y AWS del empleado, lo que a su vez desbloqueó la bóveda de tokens OAuth. Un dispositivo personal infectado, una bóveda SaaS corporativa, cientos de Workspaces afectados.

Tres razones arquitectónicas por las que una brecha al estilo de Context AI contra Caiioo no arrojaría nada útil

Caiioo es un espacio de trabajo potente y centrado en la privacidad con un orquestador agéntico e interfaz de chat que se ejecuta en un panel lateral. "Privacidad primero" describe una postura arquitectónica específica, no una frase de marketing. Hay tres propiedades concretas en funcionamiento.

1. Sus tokens OAuth de Workspace se almacenan cifrados en su dispositivo, no en nuestros servidores

Cuando conecta una cuenta de Google o Microsoft en Caiioo, verá la pantalla de consentimiento OAuth estándar de Google con los permisos que está otorgando. Hasta aquí, esto parece idéntico a autorizar Context AI.

La diferencia estructural radica en lo que sucede con los tokens que resultan de ese flujo de consentimiento. El access token y el refresh token que emite Google se almacenan cifrados en su dispositivo: en el Keychain en macOS e iOS, en el Keystore de Android en Android, y en el almacenamiento seguro del navegador en la extensión. No se almacenan en la base de datos central de caiioo. No tenemos una bóveda de tokens que los guarde en su nombre.

Cuando el orquestador agéntico necesita leer su calendario o buscar en su bandeja de entrada, la llamada a la API va desde su dispositivo directamente a Google, con el token del almacenamiento seguro de su dispositivo adjunto. Nuestra infraestructura no está en la ruta de datos de ninguno de sus contenidos de Workspace.

Puede verificar esto usted mismo en el código fuente: src/shared/auth/connections-manager.ts es donde se persisten las conexiones OAuth de Google/Microsoft. Los registros de OAuthConnection, incluidos los campos accessToken y refreshToken, se escriben a través del adaptador de almacenamiento local, no se transmiten a un almacén de tokens central.

2. El bus de mensajes del relay está cifrado de extremo a extremo

Cuando los componentes de Caiioo en diferentes dispositivos necesitan coordinarse —su extensión de navegador hablando con su aplicación de escritorio, su teléfono hablando con su servidor doméstico, la interfaz del panel lateral invocando una herramienta que se ejecuta de forma nativa en macOS— lo hacen a través de un relay que alojamos en relay.pebbleflow.ai. El relay es el punto de encuentro que permite que sus dispositivos se encuentren entre sí a través de las redes.

Ese relay está cifrado de extremo a extremo. Los dispositivos de cada usuario realizan un intercambio de claves a través del sobre del relay y, a partir de ese momento, los mensajes entre sus dispositivos son texto cifrado desde la perspectiva del relay. El relay puede enrutarlos pero no puede leerlos.

Esto no es una aspiración. El Durable Object que maneja las conexiones WebSocket, cloud/relay/src/user-relay.ts, está documentado como: "Gestiona las conexiones WebSocket para un único usuario. Maneja mensajes cifrados E2E (opacos para el relay) e intercambio de claves". Las rutas de código que manejan el tipo de mensaje ENCRYPTED están explícitamente comentadas: "Mensaje cifrado para un cliente específico (no podemos leerlo)". El relay no es arquitectónicamente capaz de inspeccionar el contenido de los mensajes que reenvía.

3. El relay es de inquilino único por usuario, por construcción

El relay de Caiioo está construido sobre Cloudflare Durable Objects. Cada usuario recibe su propia instancia de UserRelay: una pieza de cómputo y almacenamiento separada y aislada en tiempo de ejecución. No hay una base de datos multi-inquilino compartida que contenga el estado de la sesión en vivo de cada usuario, porque no existe ninguna base de datos multi-inquilino para esa función. El relay de cada usuario es un objeto separado.

Esto es importante porque elimina el modo de fallo de objetivo único compartido. Incluso si un atacante encontrara una manera de comprometer el Durable Object de un usuario, no obtendría acceso lateral a los datos de ningún otro usuario; no hay un almacén de respaldo compartido a través del cual pivotar. Cada usuario es, estructuralmente, su propio inquilino.

Qué hay y qué no hay en nuestra base de datos central

Operamos una base de datos central (Cloudflare D1) para las cosas que deben ser centrales. La honestidad es importante aquí. La base de datos almacena:

Identidad de la cuenta: tu correo electrónico, tu contraseña con hash si usas inicio de sesión por correo/contraseña, el ID de proveedor devuelto por Google/Apple/Microsoft si usas un botón de inicio de sesión social.
Estado de facturación: tu ID de cliente de Stripe, nivel de suscripción, clave de licencia y estado de la suscripción.
Claves de API por usuario para proveedores de inferencia de IA (específicamente OpenRouter). Estas son credenciales del proveedor de inferencia, distintas de tus tokens de OAuth de Workspace. Existen para el flujo de créditos gestionados y para los usuarios que desean traer su propia clave de OpenRouter para usar en las funciones de IA de Caiioo.
Lista de activación de dispositivos para el cumplimiento de licencias.
Registros de auditoría, mantenidos para los requisitos de evidencia SOC 2.
Una tabla de enrutamiento para webhooks entrantes opcionales (WhatsApp, Telegram, etc.), utilizada solo si has configurado esas integraciones de mensajería.

La base de datos no almacena:

Tus tokens de OAuth de Workspace (Gmail, Calendar, Drive, Microsoft 365). Esos están solo en tu dispositivo.
El contenido de tus conversaciones. El orquestador de agentes se ejecuta en tu panel lateral; las conversaciones viven en tu almacenamiento local.
Tus datos de Workspace: correos electrónicos, eventos de calendario, archivos de Drive. Estos se leen directamente de Google/Microsoft a tu dispositivo, sin pasar nunca por nuestra infraestructura.
El contenido de cualquier mensaje que fluya a través del relevo WebSocket. El relevo solo ve texto cifrado.

Una brecha en nuestra base de datos central expondría la identidad de la cuenta/facturación, los registros de auditoría y la columna de claves de inferencia de OpenRouter. No produciría tokens de Workspace, contenido de conversaciones ni datos de Workspace, porque no están allí para ser tomados.

Las advertencias honestas

Este es un modelo de amenaza diferente, no un escudo mágico. Aquí hay algunas precisiones que preferimos que escuche de nosotros antes de que las descubra más tarde.

El intercambio de código OAuth toca brevemente nuestro relay. Google (y Microsoft, GitHub, Slack) requieren que el client_secret de OAuth se presente en el paso de intercambio de tokens, y ese secreto no puede enviarse en el código del cliente. Por lo tanto, nuestro relay sin estado adjunta el client_secret y reenvía su código de autorización a Google a cambio de los tokens reales. Los tokens regresan a través del relay y se devuelven inmediatamente a su dispositivo para su almacenamiento. No se persisten en nuestra infraestructura. Esta es la misma razón por la que cada aplicación nativa integrada con Google que haya usado tiene algún componente de servidor; es una restricción de Google, no una elección de diseño de caiioo.

Los endpoints personalizados le permiten omitir nuestro cliente OAuth por completo. Caiioo admite la configuración de endpoints OAuth personalizados, lo que significa que un usuario dispuesto a aprovisionar su propio cliente OAuth en Google Cloud Console (o el equivalente de Microsoft Entra) puede evitar los alcances de OAuth de Caiioo y el paso de intercambio de nuestro relay por completo. Una vez configurado, el flujo de autenticación es entre su dispositivo y Google sin Caiioo en ninguna parte del ciclo. No presentamos esto como una configuración orientada al consumidor porque la mayoría de los usuarios no lo necesitan y la arquitectura predeterminada ya mantiene sus datos de Workspace fuera de nuestros servidores. Pero existe, y la implementación será familiar para cualquiera que haya configurado un cliente OAuth en Google Cloud Console anteriormente.

El compromiso del dispositivo sigue siendo importante. Si su computadora portátil es vulnerada, sus tokens son vulnerados. El enfoque local-first traslada la superficie de ataque de la "bóveda del proveedor" a "su endpoint". Esa es una superficie más pequeña y defendible, pero no es cero.

El "Sign in with Google" de nivel de inicio de sesión es independiente del acceso a Workspace. Si inicia sesión en Caiioo mismo con Google o Apple, ese flujo es solo de identidad y crea una conexión básica vinculada a su cuenta. No es la misma ruta que el flujo de acceso a Workspace descrito anteriormente y no otorga a la AI acceso a su bandeja de entrada o calendario.

Los ataques a la cadena de suministro contra Caiioo mismo siguen siendo concebibles. Un canal de actualización comprometido podría, en principio, enviar código que exfiltre tokens de su dispositivo. Mitigamos esto con la firma de código y la notarización en cada plataforma en la que operamos, pero la mitigación es diferente del modelo de bóveda del proveedor, al igual que la economía de los atacantes.

Cómo verificarlo usted mismo

La respuesta honesta es que la afirmación de privacidad de un proveedor en una página de marketing no puede demostrarse ante un escéptico. Por lo tanto, aquí le explicamos cómo confirmar lo que hemos afirmado utilizando sus propias herramientas.

Ejecute un monitor de red mientras usa caiioo. Little Snitch en macOS, GlassWire en Windows o Wireshark en cualquier sistema. Use Caiioo normalmente durante una hora. El tráfico que verá, con el significado de cada conexión, es el siguiente:

Destino	Cuándo	Qué significa
`oauth2.googleapis.com`, `gmail.googleapis.com`, `calendar.googleapis.com`, `www.googleapis.com`	Siempre que el agente lee sus datos de Workspace	Su dispositivo hablando directamente con Google con su token local. Nosotros no intervenimos en esta ruta.
`login.microsoftonline.com`, `graph.microsoft.com`	Si ha conectado Microsoft 365	Misma estructura, de su dispositivo a Microsoft.
`api.anthropic.com`, `openrouter.ai`, `api.openai.com`, `generativelanguage.googleapis.com`, `localhost:11434` (Ollama)	Cuando envía un chat o ejecuta una herramienta que usa un LLM	Su dispositivo hablando con cualquier proveedor de AI que haya configurado. Nosotros no intervenimos en esta ruta.
`relay.pebbleflow.ai` (HTTPS)	Brevemente, durante la configuración inicial de OAuth de Workspace y durante la actualización periódica de tokens	El intercambio de código OAuth sin estado. Los tokens pasan a través, pero no se persisten en el servidor.
`relay.pebbleflow.ai` (HTTPS)	Periódicamente	Validación de licencia, obtención de notas de lanzamiento / contenido de la guía del usuario, datos de inteligencia del modelo, comprobaciones del estado de la suscripción.
`relay.pebbleflow.ai` (HTTPS)	Cuando carga el sitio web o consulta el estado de la cuenta conectada	Tráfico estándar de API.
`relay.pebbleflow.ai` (WebSocket)	Continuamente, si tiene múltiples componentes de Caiioo instalados (extensión + aplicación de escritorio, o móvil + escritorio)	El puente de capacidad que permite que sus dispositivos hablen entre sí. Cifrado de extremo a extremo. Solo vemos texto cifrado.
`relay.pebbleflow.ai/api/messaging/...`	Solo si ha configurado integraciones de mensajería (WhatsApp, Telegram, Slack entrante)	Enrutamiento de Webhook para mensajes entrantes.

Lo que no verá, nunca:

Sus datos de Workspace (correos electrónicos, eventos de calendario, archivos de Drive) fluyendo hacia relay.pebbleflow.ai. Esas llamadas van desde su dispositivo directamente a *.googleapis.com.
El contenido de su conversación fluyendo hacia relay.pebbleflow.ai. El orquestador se ejecuta en su panel lateral; el historial de chat se encuentra en su almacenamiento local.
Sus claves de API de proveedores de AI fluyendo hacia relay.pebbleflow.ai. Residen en su dispositivo. (La excepción: si utiliza el flujo de créditos gestionados, estará usando una subcuenta de OpenRouter asignada por el servidor, y la llamada de inferencia se seguirá realizando desde su dispositivo).

Si alguna vez ve una solicitud desde su dispositivo a nuestra infraestructura que no encaje en la tabla anterior, eso es un hallazgo. Infórmenos y lo explicaremos o lo corregiremos.

Qué hacer si es cliente de Vercel o Context AI

La guía publicada por Vercel, Context AI y la comunidad de investigación de seguridad ha convergido en una lista de verificación consistente:

Rote cada secreto almacenado como una variable de entorno de Vercel no cifrada. Se informó que las variables cifradas/sensibles no se vieron afectadas, pero la rotación es económica.
Audite las concesiones de OAuth de terceros de su equipo en Google Workspace (y Microsoft 365, si corresponde). Revoque cualquier cosa que no reconozca y trate cualquier herramienta a la que haya otorgado alcances amplios de "Permitir todo" como una credencial que debe reemplazar.
Refuerce el consentimiento futuro. Prefiera herramientas que soliciten alcances de mínimo privilegio y prefiera espacios de trabajo cuya arquitectura no requiera que entregue tokens de larga duración en absoluto.

El tercero es el movimiento estructural, y el que este incidente sigue recomendando silenciosamente.

Prueba Caiioo

Si la lección del incidente de Vercel/Context AI es que la ubicación de tus tokens de OAuth determina el radio de impacto cuando el proveedor sufre una brecha, la respuesta es elegir un espacio de trabajo que no los guarde.

Caiioo es un espacio de trabajo potente y centrado en la privacidad con un orquestador de agentes e interfaz de chat que se ejecuta en un panel lateral. Disponible como extensión de navegador, aplicación nativa para macOS, iOS, Android y aplicación de escritorio para Windows y Linux. Comienza GRATIS.

Fuentes: