Este tipo de riesgo informático comenzó con el Shadow IT generado por las personas que utilizaban aplicaciones no autorizadas en las empresas. Hoy existe un riesgo más sofisticado, más opaco y potencialmente más peligroso: el Shadow SaaS (Sofware como Servicio Oculto), una nube paralela compuesta no solo por aplicaciones no autorizadas, sino por identidades, permisos, integraciones de aplicaciones y, cada vez más, agentes de inteligencia artificial.
A diferencia del viejo Shadow IT, el Shadow SaaS no se manifiesta como un software “instalado sin permiso”, sino como relaciones de confianza invisibles entre servicios cloud legítimos, autorizadas mediante OAuth (Open Authorization – es un protocolo estándar abierto que permite a una aplicación acceder a recursos protegidos en otra aplicación), API keys o tokens de larga duración, muchas veces creadas con buenas intenciones, pero sin una evaluación real de riesgo. En este nuevo escenario, la nube corporativa deja de ser un conjunto finito de plataformas conocidas y pasa a convertirse en un grafo dinámico de dependencias SaaS-a-SaaS, difícil de observar incluso para organizaciones maduras en seguridad.
De la visibilidad al espejismo de control
La mayoría de las empresas modernas cree tener un control razonable de su ecosistema SaaS porque utiliza herramientas como CASB (Cloud Access Security Broker) o, más recientemente, plataformas de SSPM (SaaS Security Posture Management). Sin embargo, estas soluciones fueron diseñadas bajo supuestos que hoy son obsoletos.
Los CASB convencionales dependen en gran medida de inspección de tráfico, proxies o logs de acceso del usuario final, lo cual resulta insuficiente cuando gran parte de la interacción ocurre directamente entre servicios cloud, sin pasar por el endpoint de las personas. Por su parte, muchas herramientas SSPM se enfocan en configuraciones “estáticas” de cada SaaS (MFA, políticas de retención, settings de compartición), pero tienen dificultades para modelar permisos delegados, scopes OAuth granulares y flujos de datos dinámicos.
El resultado es una ilusión de control: dashboards prolijos que muestran cumplimiento de buenas prácticas mientras, en paralelo, decenas o cientos de integraciones no auditadas acceden a datos sensibles utilizando credenciales válidas, emitidas por los propios proveedores SaaS.
OAuth: el nuevo perímetro invisible
La base del Shadow SaaS es OAuth 2.0. Diseñado como un estándar para delegación segura de acceso, OAuth se ha convertido, paradójicamente, en uno de los principales vectores de pérdida de visibilidad. Cuando un usuario autoriza una aplicación de terceros a acceder a su correo, a sus archivos o a su CRM, no está “instalando” nada. Está creando una relación de confianza persistente, muchas veces sin fecha de expiración clara y con scopes excesivamente amplios.
Desde el punto de vista de seguridad, el problema no es OAuth en sí, sino la combinación de tres factores:
Primero, la proliferación de aplicaciones que solicitan permisos amplios por conveniencia de desarrollo. Segundo, la falta de revisiones periódicas de esos permisos una vez concedidos. Y tercero, la dificultad de correlacionar qué aplicación accede a qué datos, en nombre de qué usuario, y con qué propósito real.
La Cloud Security Alliance describe este fenómeno como uno de los principales riesgos emergentes en entornos SaaS modernos, señalando que muchas organizaciones desconocen más del 60 % de las aplicaciones con acceso OAuth a sus datos corporativos (https://cloudsecurityalliance.org/press-releases/2025/04/22/research-from-csa-highlights-critical-need-purpose-built-approach-to-saas-security).
BYOK, scopes personales y la evasión de controles clásicos
El Shadow SaaS moderno también se apoya en mecanismos que, en teoría, mejoran la seguridad, pero que en la práctica pueden dificultar la detección de riesgos. El uso de BYOK (Bring Your Own Key), por ejemplo, permite a las empresas mantener control criptográfico sobre sus datos, pero al mismo tiempo ciega a los sistemas de control convencionales, que ya no pueden analizar el contenido cifrado.
Algo similar ocurre con los llamados personal scopes: accesos concedidos a nivel de usuario individual que no se reflejan claramente en las configuraciones globales del tenant SaaS. Desde la perspectiva del equipo de seguridad, el sistema “cumple”, pero a nivel micro existen excepciones silenciosas que permiten exfiltración, correlación indebida de datos o entrenamientos de modelos de IA con información sensible.
Agentes de IA y aceleración del sprawl
La irrupción de agentes de IA autónomos añade una capa completamente nueva al problema. Estos agentes no solo consumen datos, sino que crean integraciones, generan tokens, llaman APIs y encadenan servicios de forma automática. En muchos casos, lo hacen utilizando credenciales legítimas proporcionadas por desarrolladores o usuarios avanzados, pero sin pasar por ningún proceso formal de evaluación de riesgo.
Desde una perspectiva sistémica, los agentes de IA actúan como aceleradores del SaaS Sprawl (crecimiento sin control). Donde antes una integración llevaba días o semanas de configuración humana, ahora puede crearse en segundos. Esto produce un entorno altamente dinámico, en el que los mapas de dependencias quedan obsoletos casi en tiempo real.
Investigaciones recientes sobre sistemas multi-agente muestran que estos modelos tienden a optimizar objetivos funcionales sin una comprensión semántica del riesgo organizacional, lo que incrementa la probabilidad de exposiciones no intencionales (https://arxiv.org/abs/2308.08155).
Inspección semántica y nuevos enfoques técnicos
Frente a este escenario, los enfoques puramente basados en firmas, reglas estáticas o listas de aplicaciones permitidas resultan insuficientes. La frontera técnica se está desplazando hacia mecanismos más sofisticados, como la inspección semántica de tráfico TLS y el análisis de comportamiento a nivel de API.
La inspección semántica no busca “ver” el contenido cifrado, sino inferir la naturaleza de los flujos de datos a partir de patrones, metadatos, frecuencia, direccionalidad y contexto de negocio. Esto permite detectar, por ejemplo, cuando un SaaS aparentemente inocuo comienza a comportarse como un extractor sistemático de datos sensibles.
En paralelo, el mapeo de integraciones SaaS-a-SaaS se está convirtiendo en una disciplina en sí misma. No se trata solo de listar aplicaciones conectadas, sino de construir un grafo de confianza, donde cada nodo y cada relación tengan un peso de riesgo asociado, dinámico y auditable.
Estado del mercado: soluciones aún inmaduras
Plataformas como Netskope OneSaaS, BetterCloud o Drata SSPM muestran que el mercado reconoce el problema y está avanzando hacia soluciones más holísticas. Sin embargo, incluso estas herramientas enfrentan límites estructurales: dependen de APIs proporcionadas por los propios vendors SaaS, lo que implica que solo pueden ver lo que el proveedor decide exponer.
Esto lleva a una conclusión incómoda: el Shadow SaaS no es un problema que pueda resolverse únicamente comprando una herramienta. Es un problema de gobernanza, arquitectura y modelo mental. Requiere redefinir qué significa “control” en un entorno donde las identidades, no las redes, son el nuevo perímetro.
Hacia una gobernanza de la nube invisible
La verdadera mitigación del Shadow SaaS pasa por aceptar que la nube corporativa ya no es completamente observable y que la seguridad debe operar bajo supuestos de incertidumbre parcial. Esto implica combinar controles técnicos avanzados con políticas claras de autorización de integraciones, revisiones periódicas de permisos OAuth, y un entendimiento profundo de cómo la IA está transformando los flujos de datos internos.
Como advierte la Cloud Security Alliance, el mayor riesgo no es la existencia de Shadow SaaS, sino la ilusión de que no existe (https://cloudsecurityalliance.org/research).
En los próximos años, las organizaciones que sobrevivirán mejor no serán las que intenten eliminar esta nube paralela, sino las que aprendan a hacerla visible, modelarla y gobernarla, incluso cuando no puedan controlarla por completo.
Caso real: Brecha masiva vía integración OAuth Salesloft–Drift que comprometió Salesforce en más de 700 organizaciones
En agosto de 2025, un ataque a la cadena de confianza entre Salesloft y su integración Drift con Salesforce, basada en tokens OAuth válidos otorgados a aplicaciones de terceros, resultó en una de las brechas más grandes de los últimos años en el ecosistema SaaS empresarial. El grupo atacante, identificado como UNC6395 / ShinyHunters, logró comprometer y reutilizar estos tokens para acceder a las instancias de Salesforce de más de 700 organizaciones en múltiples industrias sin romper contraseñas ni exigir MFA adicional.
Este incidente no fue causado por una vulnerabilidad en Salesforce, sino por el abuso de relaciones de confianza delegadas entre aplicaciones SaaS, una de las bases de lo que hoy llamamos Shadow SaaS: integraciones que operan fuera del perímetro clásico de visibilidad y control, y que pueden conceder permisos amplios sobre datos sensibles.
Cómo ocurrió
- Compromiso inicial del proveedor
Los atacantes obtuvieron acceso a tokens OAuth asociados con la integración Salesloft–Drift, aprovechando exposiciones en los sistemas de desarrollo o almacenamiento de credenciales de la propia aplicación de terceros. - Uso de tokens legítimos para acceso no autorizado
Con estos tokens de federación legítimos, los atacantes accedieron a las APIs de Salesforce como usuarios corporativos reales, sin necesidad de autenticarse de nuevo ni activar mecanismos de autenticación fuerte como MFA. - Exfiltración de datos empresariales críticos
Una vez dentro, los actores ejecutaron consultas que extrajeron datos sensibles de objetos clave, incluyendo credenciales de acceso a otros servicios (como tokens de Snowflake y claves AWS), y eliminaron registros de auditoría para evitar detección inmediata. - Cadena de confianza SaaS a SaaS explotada
Además de Salesforce, se reportaron accesos a Google Workspace mediante tokens provenientes de la misma integración comprometida, lo que demuestra cómo un único vector de Shadow SaaS puede propagarse transversalmente entre servicios.
Por qué este caso es paradigmático de Shadow SaaS
Este ataque ilustra cuatro pilares del riesgo Shadow SaaS en un entorno empresarial moderno:
- Delegación de acceso invisible
Las integraciones OAuth funcionan con permisos que a menudo no son auditados periódicamente, y pueden permanecer válidos indefinidamente si no hay expiración o revisión de scopes. - Evasión de controles clásicos
Debido a que se reutilizaron tokens legítimos, los mecanismos tradicionales de CASB o IAM no detectaron los acceso de los atacantes como un inicio de sesión anómalo y no hubo contraseñas robadas ni fallas en el MFA. - Efecto dominó en cadena de confianza SaaS
La dependencia de relaciones SaaS-a-SaaS creó un efecto multiplicador del compromiso: una sola app de terceros comprometida permitió acceso a muchos otros servicios SaaS críticos. - Visibilidad insuficiente del riesgo
Muchas organizaciones no tenían inventarios actualizados de aplicaciones conectadas ni políticas estrictas para revisar scopes OAuth o revocar permisos de apps poco usadas.
Impacto y lecciones clave
- Alcance transversal: más de 700 organizaciones afectadas en sectores regulados, lo que llevó a auditorías de cumplimiento (p.ej., GDPR, CCPA, SOX y GLBA).
- Persistencia de acceso: el uso de tokens con largos periodos de validez permitió movimientos laterales silenciosos.
- Necesidad de nuevas defensas: este incidente demuestra que los enfoques tradicionales de CASB/SSPM, sin visibilidad continua de integraciones y de uso real de tokens, están insuficientes frente a ataques sofisticados que explotan la dinámica de confianza entre SaaS.
Conclusión
El caso Salesloft–Drift–Salesforce no es un accidente aislado ni un error de configuración puntual: es un síntoma claro de cómo la nube paralela, esa red de relaciones SaaS invisibles a equipos de seguridad, puede transformarse en un vector de compromiso sistémico. Este tipo de brechas ocurre precisamente porque la organización no ve lo que ocurre fuera de sus perímetros tradicionales, y porque la seguridad de las empresas modernas depende cada vez más de relaciones de confianza que no están bajo su control directo.
Este ejemplo real es una advertencia clara: el riesgo de Shadow SaaS ya dejó de ser una hipótesis, y se está materializando como incidentes de gran escala que explotan la misma arquitectura de confianza que la digitalización moderna diseñó.
Leer más
- Check Point Software da un nuevo paso en su alianza estratégica con Wiz para ofrecer una solución integrada de CNAPP y seguridad de red en la nube
- Cómo sacar provecho de los servicios de nube pública de Inteligencia Artificial
- Shadow IA: El riesgo invisible que crece en las empresas
