OAuth el riesgo silencioso que convierte permisos en puertas de acceso a tus sistemas

La conversación sobre riesgos de la inteligencia artificial en las empresas suele centrarse en lo visible: empleados pegando datos sensibles en chatbots públicos. Sin embargo, hay una amenaza menos ruidosa y más perniciosa que merece prioridad: las integraciones OAuth que los empleados conectan a aplicaciones críticas (Google Workspace, Microsoft 365, Salesforce, etc.). A diferencia de una conversación con un LLM, una conexión OAuth crea un puente persistente entre tu entorno y un tercero; ese puente no desaparece cuando el usuario deja de usar la app y puede convertir una brecha en un proveedor en una puerta de acceso directa a tus sistemas.

El caso reciente que afectó a Vercel es ilustrativo: una prueba de una app de productividad con permisos sobre Google Workspace acabó siendo el eslabón que permitió a atacantes pivotar tras comprometer al proveedor. Es una demostración práctica de por qué no basta con controlar los datos que se escriben en un chat: hay que controlar las relaciones de confianza que se crean entre sistemas. Para leer un análisis técnico del incidente y cómo se explotaron tokens y permisos, puede consultarse el informe de investigación publicado por especialistas en seguridad: Unpacking the Vercel breach.

Esto no es un caso aislado ni exclusivo de aplicaciones “AI”. Durante los últimos años hemos visto campañas de robo de tokens y ataques basados en OAuth que impactaron a miles de organizaciones, y la llegada de herramientas AI que orquestan flujos entre aplicaciones solo ha multiplicado la superficie de ataque. Los atacantes han convertido a OAuth en un vector fiable porque un token válido es, en muchos casos, tanto o más valioso que una credencial.

Las implicaciones para la seguridad corporativa son claras y operativas: necesitas tratar a las autorizaciones de aplicaciones como activos críticos. En primer lugar, conviene adoptar un modelo de consentimiento por defecto restrictivo en tus identidades corporativas y evitar que los usuarios puedan vincular nuevas aplicaciones sin aprobación. Google Workspace y otras plataformas permiten políticas para administrar el acceso de terceros; la guía oficial sobre cómo controlar aplicaciones de terceros en Google Workspace es un buen punto de partida para administradores: Manage third-party app access to Google Workspace data.

La higiene operativa también importa: auditorías periódicas de las integraciones activas, revisiones de los permisos solicitados por cada app, y capacidad de revocar tokens de forma automática frente a indicadores de compromiso son medidas que reducen ventana de exposición. Es igualmente crítico disponer de procedimientos de respuesta que contemplen la revocación masiva de consentimientos y la rotación de claves y tokens cuando un proveedor se ve comprometido.

No bastan sólo controles en el proveedor de identidad. Muchas conexiones ocurren entre SaaS y SaaS y no son visibles desde el panel de administración principal. Por eso hace falta una combinación de métodos: inventorizar aplicaciones usadas por equipos, monitorizar autenticaciones y consentimientos desde el navegador y desde el SSO, y desplegar detección que identifique patrones raros de tráfico API o accesos fuera de horario. Además, controles en el endpoint y políticas de extensiones de navegador ayudan a mitigar vectores de entrega como infostealers o phishing que terminan en robo de tokens.

En el plano táctico, hay herramientas y prácticas que funcionan mejor en conjunto: aplicar SSO obligatorio con políticas de consentimientos centralizadas, exigir MFA fuerte (idealmente con claves hardware) para cuentas con permisos elevados, limitar los scopes de las aplicaciones al mínimo necesario y exigir revisiones de seguridad a proveedores antes de permitir integraciones. También resulta útil implementar alertas que detecten la creación de aplicaciones autorizadas por un usuario y que las sometan a revisión automática.

La evolución del ataque —desde campañas de phishing que inducen a autorizar aplicaciones, hasta brechas en proveedores que almacenan tokens— exige una respuesta que combine gobernanza, tecnología y formación. Los equipos de seguridad deben dejar de pensar en estos consentimientos como “pequeñas elecciones de usuario” y verlos como relaciones de confianza que hay que gestionar activamente. Para ampliar la visión sobre cómo los ataques basados en navegador y OAuth están cambiando el panorama, existen informes recientes que analizan técnicas como device-code phishing y otros vectores relevantes: Device code phishing: informe técnico.

Si tu organización aún no tiene una política clara sobre integraciones OAuth y uso de AI, el momento de actuar es ahora. Pequeñas defensas preventivas —bloqueo de consentimientos no autorizados, auditorías regulares, detección en el navegador y controles en el IDP— reducen significativamente el riesgo de que una prueba o utilidad de IA se convierta en la vía de acceso para una brecha mayor. Tratar a OAuth como una superficie crítica y coordinar controles entre equipos de identidad, seguridad de endpoints y administración de aplicaciones es la decisión estratégica que puede evitar el próximo incidente de proveedor.