Las aplicaciones de IA convierten la confianza de Google Workspace en una cadena de ataque moderna

La seguridad de Google Workspace ha llegado a un punto de conflicto, pese a años de contraseñas más robustas, autenticación multifactor y mejores controles contra el phishing. Las últimas noticias de Google para los equipos de seguridad se centran en accesos que los atacantes no necesitan robar directamente. Pueden heredarlos mediante una aplicación de IA aprobada, una sesión de navegador comprometida o un token OAuth abandonado.

Esta distinción cambia el problema defensivo. Tradicionalmente, los programas de seguridad se concentran en detener a un atacante en la pantalla de inicio de sesión. Los ataques modernos comienzan cada vez más con accesos que Google ya considera autorizados.

Las herramientas de IA intensifican esta tensión porque necesitan conexiones amplias para ofrecer respuestas útiles y ejecutar acciones. Un asistente podría leer Gmail, buscar en Drive, revisar Calendar y transferir conclusiones a otro servicio. Cada conexión crea una relación de confianza que puede sobrevivir a los cambios de contraseña y mantenerse activa sin una interacción evidente del usuario.

La lección inmediata no es que todas las herramientas de IA sean maliciosas. Es que la autorización se ha convertido en parte del perímetro empresarial. Un análisis reciente de Material Security, difundido por BleepingComputer, sostiene que muchas organizaciones aún la tratan como ruido administrativo de fondo.

El incidente de Vercel de abril de 2026 demuestra por qué ese enfoque ya no es suficiente. Según las divulgaciones relacionadas con la brecha, los atacantes comprometieron primero a un proveedor externo de IA. Después utilizaron su conexión autorizada para acceder a la cuenta de Google Workspace de un empleado de Vercel.

El ataque no encajaba en la historia habitual de alguien que derrota las defensas de inicio de sesión de Vercel. La confianza cruzó fronteras organizativas a través de una integración que un usuario había aprobado previamente.

Las noticias de Google pasan de contraseñas robadas a accesos heredados

El cambio importante no es una nueva vulnerabilidad de Google, sino una forma más eficaz de explotar accesos legítimos.

OAuth es un marco de autorización que permite a una aplicación acceder a recursos seleccionados de otro servicio. Permite, por ejemplo, que una herramienta de programación lea un calendario sin recibir la contraseña de Google del usuario.

Esta separación aporta beneficios reales de seguridad. Los usuarios no tienen que compartir credenciales con todos los servicios conectados. Los administradores también pueden restringir aplicaciones, revisar los ámbitos solicitados y revocar concesiones.

El mismo modelo crea un objetivo valioso. Un token OAuth representa un permiso que ya ha pasado por un proceso de aprobación. Cualquiera que robe o controle ese token puede actuar a través de la aplicación aprobada, sujeto a los ámbitos que se le hayan concedido.

El informe sobre riesgos de OAuth de Material Security examinó entornos de producción de Google Workspace y encontró una amplia superficie de autorización distribuida. Sus hallazgos públicos citan una mediana de 1.807 conexiones de aplicaciones OAuth por empresa.

El informe también indica que el 47,2 por ciento de las concesiones observadas no se habían utilizado durante más de 90 días. Entre esas concesiones inactivas, 1.526 conservaban acceso completo a Gmail.

Estas cifras proceden del conjunto de datos de clientes de un proveedor de seguridad, no de un censo representativo de todos los tenants de Workspace. El tamaño de la empresa, el sector y la madurez de seguridad existente pueden afectar a los totales. Aun así, los hallazgos exponen un problema estructural: las autorizaciones antiguas suelen seguir siendo válidas después de que desaparece su propósito empresarial.

La adopción de IA acelera esta acumulación. Material clasificó 356 aplicaciones públicas en su categoría de IA y automatización. Afirma que 325 aparecieron por primera vez en los entornos analizados después del 1 de enero de 2024.

Eso significa que el 91 por ciento de la población observada de aplicaciones de IA llegó en un plazo de 16 meses. Según se informa, más de la mitad de esas aplicaciones contaban con ámbitos sensibles o restringidos.

Un ámbito define a qué puede acceder o qué puede modificar una aplicación. Los ámbitos amplios pueden permitir que una aplicación lea correos electrónicos, revise contenido de Drive, envíe mensajes o elimine información.

Por tanto, las organizaciones se enfrentan a un difícil problema de clasificación. Una solicitud de acceso a Drive podría respaldar a un asistente de investigación útil. El mismo permiso puede exponer contratos, documentos de estrategia, credenciales y registros de clientes si la aplicación se ve comprometida.

La amenaza no requiere que una aplicación sea maliciosa desde el principio. Un proveedor legítimo puede convertirse en el punto de entrada después de que se vulneren un dispositivo de empleado, una cuenta de desarrollador, una clave de firma o un entorno en la nube.

Esta posibilidad convierte la aprobación rutinaria de aplicaciones en una decisión de cadena de suministro. El usuario ve una pantalla de consentimiento, pero la organización hereda los futuros fallos de seguridad del proveedor.

Una herramienta de IA comprometida puede cruzar dos límites de seguridad

El incidente de Vercel ilustra cómo un atacante puede desplazarse a través de un proveedor de IA en lugar de atacar directamente al objetivo final.

Vercel divulgó un incidente de seguridad en abril de 2026 que involucraba una herramienta externa de IA comprometida y la cuenta de Google Workspace de un empleado. Los informes públicos identificaron a ese proveedor como Context.ai.

Según las divulgaciones disponibles, un empleado de Vercel había conectado AI Office Suite de Context.ai usando una identidad corporativa. La conexión recibió amplios permisos de Google Workspace.

Posteriormente, un actor de amenazas obtuvo el control de accesos relevantes en poder de Context.ai. Según se informa, esos accesos proporcionaron una ruta hacia la cuenta de Workspace del empleado y luego hacia los sistemas internos de Vercel.

La secuencia creó dos exposiciones vinculadas de cadena de suministro. Context.ai dependía de sus propias identidades de empleados e infraestructura. Vercel, a su vez, dependía de la integridad de la aplicación OAuth de Context.ai.

Investigadores independientes atribuyeron el compromiso inicial de Context.ai a una infección por infostealer. Un infostealer es un malware diseñado para recopilar contraseñas, cookies de navegador, tokens y otros materiales de autenticación.

Los informes vincularon esa infección con software presentado como un exploit de Roblox. Sin embargo, no todos los detalles del compromiso inicial recibieron confirmación independiente por parte de Vercel.

Lo que Vercel confirmó es más importante para la planificación empresarial. La autorización existente de una aplicación de terceros ayudó al atacante a acceder a la cuenta corporativa de Workspace de un empleado.

Según se informa, el atacante accedió a variables de entorno que no estaban designadas como sensibles. Vercel aconsejó a los clientes afectados auditar la actividad y rotar las credenciales expuestas.

Un relato contemporáneo informó que el atacante buscaba un pago por los datos robados. Vercel contrató a Mandiant, notificó a las fuerzas del orden y contactó a un grupo limitado de clientes afectados.

Vercel también indicó que las variables de entorno sensibles estaban cifradas en reposo y no fueron accedidas. Según se informa, sus proyectos de código abierto, incluidos Next.js y Turbopack, no se vieron afectados.

El incidente no debe simplificarse como una afirmación de que OAuth falló por sí mismo. OAuth ejecutó la autorización que usuarios y administradores habían permitido.

El fallo surgió de toda la cadena de confianza. Un proveedor fue comprometido, una aplicación tenía acceso amplio y ese acceso alcanzó una identidad empresarial valiosa.

Las defensas tradicionales de inicio de sesión cubrían solo una parte de esa secuencia. El atacante no necesitó repetir la decisión de consentimiento original una vez que existía una autorización utilizable.

Cambiar una contraseña también puede dejar intactas algunas autorizaciones de aplicaciones. Eso hace que la respuesta sea más complicada que restablecer credenciales y cerrar sesiones activas del navegador.

Los equipos deben identificar qué tokens existen, qué ámbitos tienen y qué aplicaciones conectadas todavía pueden actuar. Después deben revocar el acceso sin interrumpir los flujos de trabajo empresariales necesarios.

Esta es la inversión central de la cadena de ataque moderna. La aplicación diseñada para reducir el intercambio de contraseñas puede convertirse en una ruta duradera para sortear defensas centradas en contraseñas.

Los agentes de IA hacen que los registros OAuth conocidos sean menos informativos

Los agentes de IA pueden parecer ordinarios en los registros de autorización, mientras se comportan de forma mucho menos predecible que las integraciones convencionales.

Una aplicación tradicional suele realizar un conjunto limitado de funciones. Un servicio de firma de documentos podría recuperar un archivo, recopilar firmas y devolver la copia completada.

Su comportamiento puede cambiar, pero los administradores aún pueden comparar los permisos solicitados con un propósito relativamente estable. Un acceso excesivo a Gmail o Calendar debería parecer sospechoso para ese tipo de servicio.

Un agente de IA no sigue el mismo modelo de comportamiento. Su siguiente acción puede depender de una instrucción del usuario, contenido recuperado, herramientas disponibles, salida del modelo e instrucciones entregadas por un sistema externo.

En la capa de autorización, esas diferencias pueden desaparecer. Una concesión de acceso de solo lectura a Drive emitida para un asistente de IA puede parecerse a otra emitida para una utilidad documental fija.

El análisis de agentes de Material sostiene que las señales de seguridad están pasando de las concesiones al comportamiento posterior a la autorización. La identidad del proveedor y el ámbito siguen siendo útiles, pero no pueden describir por completo lo que hará un agente de propósito general.

Model Context Protocol, comúnmente llamado MCP, puede aumentar esa incertidumbre. MCP es un estándar para conectar sistemas de IA con herramientas y fuentes de datos externas.

Un agente conectado mediante MCP podría buscar en Workspace, pasar contenido seleccionado a otra herramienta, resumirlo y activar una acción de seguimiento. El flujo de trabajo puede cruzar varios servicios dentro de una sola solicitud de usuario.

Esto plantea varias cuestiones de seguridad que una pantalla de consentimiento no puede responder. Los administradores necesitan saber a qué información accedió realmente el agente, adónde envió esa información y si su actividad coincidía con la intención del usuario.

La inyección de prompts añade otra capa. La inyección de prompts ocurre cuando contenido no confiable manipula las instrucciones o el uso de herramientas de un sistema de IA.

Un agente podría encontrar instrucciones hostiles dentro de un correo electrónico, documento compartido, entrada de calendario o página web. Si trata ese contenido como una instrucción, sus permisos legítimos pueden convertirse en el mecanismo de una actividad dañina.

Ese riesgo difiere del malware clásico. No es necesario que llegue ningún ejecutable al dispositivo del usuario, y el proveedor de IA podría permanecer sin verse comprometido.

En cambio, el sistema puede hacer un mal uso de herramientas válidas mientras procesa contenido adversarial. Los controles de seguridad deben distinguir la automatización autorizada de la automatización autorizada que se comporta peligrosamente.

Esto no significa que todos los agentes conectados necesiten una supervisión sin restricciones de los prompts o del contenido privado. La vigilancia excesiva crea sus propios riesgos de privacidad, cumplimiento y gobernanza.

Significa que las organizaciones necesitan evidencia a nivel de actividad. Entre las señales útiles se incluyen un volumen inusual de descargas, nuevos comportamientos de reenvío, enumeración rápida de buzones, combinaciones inesperadas de servicios y accesos fuera del patrón normal de un usuario.

La IA también aumenta el número de conexiones que requieren revisión. Los empleados pueden adoptar asistentes directamente, a menudo antes de que los equipos de compras o seguridad los evalúen.

Una marca reconocible no garantiza que la aplicación de la pantalla de consentimiento pertenezca a esa marca. El informe de Material describe una aplicación llamada “gamma.com.ai” que se asemejaba al servicio legítimo de presentaciones Gamma.

Material afirma que el editor no estaba relacionado con Gamma y buscaba acceso en múltiples entornos de clientes. El informe presenta el caso como una suplantación OAuth, en la que la familiaridad visual fomenta la aprobación.

La pantalla de autorización seguía mostrando un dominio y los permisos solicitados. La decisión humana falló porque un nombre conocido redujo el escrutinio.

Esta vía de ataque no necesita una página de contraseña falsificada. Convence al usuario para que otorgue una autorización legítima a la parte equivocada.

La MFA protege el inicio de sesión, no todas las decisiones posteriores

La autenticación multifactor sigue siendo esencial, pero no puede validar cada token, aplicación y acción del navegador que sigue a un inicio de sesión exitoso.

La MFA bloquea muchos ataques basados en contraseñas porque una contraseña robada por sí sola no es suficiente. Los métodos resistentes al phishing, incluidas las passkeys y las llaves de seguridad físicas, brindan una protección más sólida frente a la retransmisión de credenciales en tiempo real.

Google ha ampliado la compatibilidad con passkeys y los controles administrativos en Workspace. Estas medidas reducen la exposición a la toma de control convencional de cuentas.

Sin embargo, el consentimiento de OAuth suele producirse después de la autenticación. Un usuario inicia sesión correctamente, completa la MFA y luego aprueba una aplicación.

El token resultante registra una decisión autorizada. Reutilizar ese token podría no activar de nuevo el mismo desafío de autenticación.

El robo de sesiones del navegador crea una brecha relacionada. Una cookie de sesión es un dato que permite a un servicio reconocer un navegador autenticado previamente.

Un atacante que roba una cookie válida puede heredar ese estado autenticado. Google documenta procedimientos de respuesta ante cookies de sesión para investigar sesiones sospechosas y forzar cierres de sesión.

Los tokens de aplicaciones y las sesiones del navegador no son idénticos. Ambos demuestran por qué el evento de inicio de sesión no puede definir todo el perímetro de seguridad.

Los atacantes también usan phishing de adversario en el medio, conocido como AiTM, para retransmitir credenciales y segundos factores mediante una sesión falsificada activa. Esta técnica puede capturar la sesión autenticada creada tras una MFA exitosa.

La autenticación resistente al phishing eleva la dificultad porque las credenciales están vinculadas criptográficamente al sitio legítimo. Las organizaciones deben seguir asumiendo que el malware, las aplicaciones comprometidas y los tokens robados pueden crear otras vías.

Microsoft ha documentado abusos de redirección de OAuth que involucran URL de proveedores de identidad de confianza. Las campañas manipulan parámetros de protocolo o aplicaciones conectadas para dirigir a las víctimas hacia destinos controlados por atacantes.

El patrón más amplio afecta a más actores que Google. Microsoft 365, Salesforce, las plataformas de desarrollo en la nube y los servicios de datos dependen de tokens e integraciones de terceros.

Varias campañas importantes han apuntado a esas relaciones. Los incidentes relacionados con Salesloft Drift mostraron cómo los tokens de integración robados podían proporcionar acceso posterior a entornos de clientes.

La comparación importa porque descarta una explicación exclusiva de Google. El software empresarial opera cada vez más como un grafo de confianza delegada.

Los defensores deben preservar la MFA mientras amplían su modelo. La autenticación responde si una identidad cumplió un requisito de inicio de sesión. La autorización responde qué puede hacer después esa identidad o su aplicación conectada.

Los equipos de seguridad también deben considerar la persistencia. Revocar una sesión del navegador no revoca necesariamente una concesión de aplicación. Suspender a un usuario puede dejar accesos conectados que requieren una investigación independiente.

Los planes de respuesta a incidentes deben enumerar esas acciones explícitamente. De lo contrario, un equipo puede restablecer contraseñas, cerrar sesiones y concluir erróneamente que el acceso ha terminado.

Esta respuesta ampliada es exigente desde el punto de vista operativo. Las grandes organizaciones pueden tener miles de concesiones, cuentas de servicio, permisos delegados y flujos de trabajo de automatización.

Revocarlo todo no es una política creíble a largo plazo. Interrumpiría la productividad y alentaría a los empleados a buscar alternativas menos visibles.

El objetivo defendible es la confianza selectiva. Los equipos deben identificar aplicaciones, verificar editores, limitar alcances, supervisar el comportamiento y retirar el acceso cuando su propósito expire.

La disyuntiva es IA útil frente a confianza no medida

Bloquear todas las integraciones reduciría un riesgo a costa de destruir los flujos de trabajo conectados que hacen útil a la IA empresarial.

Los asistentes de IA necesitan contexto para ir más allá de las respuestas genéricas. Un asistente que redacta una actualización para un cliente puede necesitar correo electrónico, notas de reuniones, historial de cuenta y documentos de proyecto.

Restringirlo a una ventana de chat vacía reduce la exposición. También elimina gran parte del valor que los empleados esperan de la IA empresarial.

Por tanto, las organizaciones afrontan una disyuntiva, no una decisión de seguridad binaria. Deben permitir accesos útiles sin dejar que la autorización se acumule indefinidamente.

El primer paso es la visibilidad. Los administradores necesitan un inventario de todo el dominio de aplicaciones, concesiones, usuarios, alcances, editores y actividad reciente.

El inventario debe distinguir las aplicaciones públicas de terceros de las herramientas internas. También debe identificar concesiones vinculadas a antiguos empleados, contratistas, cuentas de prueba y proyectos inactivos.

Revisar solo los nombres no es suficiente. Los equipos deben verificar la identidad del editor, los dominios de la aplicación, las ubicaciones de redirección, los alcances solicitados y si la herramienta ha completado la verificación pertinente de la plataforma.

La verificación no es una garantía permanente. Un proveedor legítimo aún puede sufrir una brecha, ser adquirido o ser modificado después de la aprobación.

El control de alcances proporciona otra capa. Las aplicaciones deben recibir los permisos mínimos necesarios para un flujo de trabajo definido.

Un servicio de transcripción no debería recibir acceso completo a Gmail sin un requisito claro. Un asistente que solo busca en carpetas seleccionadas de Drive no debería recibir automáticamente acceso a todos los archivos.

El tiempo también importa. El acceso concedido para una evaluación debe expirar al terminar esa evaluación. Las organizaciones deben evitar convertir experimentos temporales en credenciales permanentes.

Los administradores de Google pueden restringir el acceso de aplicaciones de terceros y clasificar los servicios como confiables, limitados o bloqueados. Esos controles funcionan mejor cuando cuentan con un proceso de aprobación que puede avanzar a la velocidad de los empleados.

Un sistema de revisión que tarda semanas impulsará la adopción clandestina. Un sistema que aprueba nombres reconocibles sin examinar los permisos producirá una proliferación de autorizaciones.

La supervisión del comportamiento aborda lo que la aprobación no puede predecir. Los equipos deben detectar cuándo una aplicación de repente lee muchos más datos, accede a usuarios inusuales o empieza a realizar nuevas acciones.

Esto es especialmente importante para los agentes de IA. Sus capacidades de propósito general hacen que las descripciones estáticas sean indicadores más débiles del comportamiento esperado.

La investigación de Cloud Security Alliance presenta las cadenas OAuth de SaaS con IA como una superficie sistémica de ataque empresarial. Su análisis de cadenas de confianza vincula el incidente de Context.ai con otros compromisos posteriores de tokens.

El informe sostiene que las empresas deben tratar la gestión del ciclo de vida de OAuth como una función de seguridad de primer nivel. Eso incluye emisión, inventario, supervisión, rotación, revocación y respuesta a incidentes.

Los equipos de seguridad deben seguir tratando con cautela las estadísticas de los proveedores. Material vende productos de seguridad para Workspace, y su investigación respalda el problema que aborda su plataforma.

No obstante, su conjunto de datos ofrece preguntas verificables para cualquier organización. Los administradores pueden medir su propio número de concesiones, proporción inactiva, alcances sensibles, crecimiento de aplicaciones de IA y brechas de revocación.

La respuesta más sólida es la evidencia recopilada en el propio tenant de la empresa. Una auditoría local puede confirmar si el patrón comunicado se aplica y dónde se encuentran las conexiones de mayor riesgo.

Qué deben vigilar los equipos de seguridad a continuación

Tres señales mostrarán si la defensa de Workspace se está adaptando a la autorización de la era de la IA o si solo está añadiendo otro panel.

La primera señal es una mejor visibilidad posterior a la concesión por parte de Google y los proveedores de seguridad. Los administradores necesitan más que un registro que indique que una aplicación recibió un alcance determinado.

Necesitan respuestas útiles sobre la actividad posterior de la aplicación. Esto incluye a qué recursos accedió, cómo cambió su patrón y si los datos se movieron entre servicios conectados.

Google ya ofrece capacidades de investigación y control de acceso, pero la cobertura depende de la edición, la configuración y la telemetría disponible. La prueba clave es si los equipos pueden rastrear las acciones de un agente de IA sin reunir evidencias de varias consolas no relacionadas.

Si la investigación a nivel de actividad se vuelve más clara, el modelo de seguridad descrito aquí obtiene respaldo práctico. Si los registros siguen centrados en el consentimiento inicial, los defensores continuarán juzgando a los agentes dinámicos mediante metadatos estáticos.

La segunda señal es cómo los proveedores de IA limitan y gestionan los permisos. Los productos maduros deberían explicar por qué cada alcance es necesario y ofrecer flujos de trabajo útiles con huellas de autorización más pequeñas.

Deberían admitir fuentes de datos selectivas, acceso de corta duración cuando sea viable, revocación rápida y registros transparentes de la actividad de las herramientas. También deberían separar la automatización orientada al usuario de las acciones administrativas de alto riesgo.

Los alcances predeterminados amplios debilitarían las afirmaciones de que el mercado está aprendiendo de los incidentes recientes. Controles más granulares demostrarían que los proveedores reconocen la autorización como un problema de diseño de producto.

La tercera señal es si las organizaciones miden la exposición a OAuth durante el trabajo rutinario de seguridad. Una revisión anual no puede igualar la velocidad con la que los empleados adoptan herramientas de IA.

Los equipos deben hacer seguimiento de concesiones inactivas, nuevos editores, alcances sensibles, usuarios desvinculados y cambios repentinos en el comportamiento de las aplicaciones. Estas medidas deben figurar en las revisiones periódicas de identidad y seguridad en la nube.

Los ejercicios de incidentes también deberían poner a prueba un compromiso de token de terceros. Los equipos de respuesta deben saber cómo identificar a los usuarios afectados, revocar concesiones, cerrar sesiones, rotar secretos posteriores y preservar pruebas.

Las últimas noticias de Google no establecen que Workspace se haya vuelto intrínsecamente inseguro. Muestran que los supuestos de seguridad basados en la protección del inicio de sesión ya no cubren toda la ruta hacia los datos empresariales.

Las contraseñas y la MFA siguen siendo necesarias. Simplemente no son el control final una vez que los empleados autorizan a las aplicaciones a actuar en correo electrónico, archivos, calendarios y sistemas conectados.

La pregunta más difícil es si las organizaciones pueden ver y gobernar esa actividad delegada sin bloquear el trabajo útil. Los líderes de seguridad deberían comenzar con una medición directa: ¿cuántas aplicaciones conectadas pueden acceder a los datos de la empresa ahora mismo y quién sigue siendo responsable de cada decisión?