Secuestro de identidad en flujos de trabajo: Noma Labs convierte un correo de soporte común en acceso privilegiado a datos

El 9 de septiembre de 2026, el equipo de investigación de Noma Security, bajo el nombre Noma Labs, publicó un relato de lo que denomina secuestro de identidad de flujos de trabajo: un flujo de trabajo de IA empresarial lee un mensaje ordinario que llega a un punto de entrada público —una bandeja de soporte, un issue de GitHub, un formulario web, un documento compartido— y luego realiza el trabajo solicitado usando su propia cuenta de servicio con privilegios elevados en lugar de los permisos del remitente. El recorrido de Noma presenta a un externo que envía un correo a la dirección pública de soporte de una empresa y solicita, entre otras cosas, las cifras de ventas trimestrales del correo más reciente del Director Financiero; minutos después, el contenido llega a la bandeja de entrada del atacante. No se engañó a ningún modelo ni se vulneró ninguna cuenta, que es el punto del informe: «todo lo que el atacante tuvo que hacer fue pedirlo». El archivo no registra ningún daño real —no se nombra a ninguna víctima ni se describe ningún sistema desplegado como comprometido— y clasifica el hallazgo como investigación, gravedad media, confianza A, disputado falso. Este relato se basa en el informe de Noma Labs, en la cobertura de Dark Reading publicada el mismo día y en el seguimiento de CSO Online, y el archivo de incidentes de IA incluye esta entrada junto a sus vecinas, cada una con sus propias fuentes, grado de gravedad y confianza.

Los campos del propio registro merecen leerse antes que la prosa. Está etiquetado como INFRA y EXFIL, abarca la región GLOBAL, contiene una única fecha precisa al día, el 9 de septiembre de 2026, y no está marcado como entrada de referencia. La fecha es la fecha de publicación de la investigación y nada más; no lleva adjunta ninguna cronología de incidentes, porque no hay incidente que situar en el tiempo. Eso es lo primero que hay que retener: lo que publicó Noma es un mecanismo y una categoría, no un informe de brecha.

Lo que Noma demostró, y lo que no

La secuencia de la bandeja de entrada de soporte es una ilustración construida, no un caso de cliente. El informe de Noma no nombra una organización, no indica un número de implementaciones afectadas, no publica telemetría de ningún pipeline real y no vincula una ejecución de prueba de concepto para este escenario, a diferencia de la investigación de julio del grupo, que apuntaba a una ejecución pública de GitHub Actions. Lo que el informe ofrece en cambio es una descripción del mecanismo lo suficientemente precisa como para verificarla contra una arquitectura: llega una entrada no autenticada, el modelo la interpreta correctamente, el pipeline ejecuta la llamada descendente y esa llamada se realiza con la autoridad del creador del flujo de trabajo.

Sasi Levi, responsable de investigación de seguridad de Noma y autor del informe, resume la causa raíz en una frase: «la identidad y los permisos del usuario que desencadena un flujo de trabajo están desacoplados de la identidad y los permisos que se utilizan para ejecutarlo». Donde eso se cumple, el flujo de trabajo se convierte, en palabras del informe, en «proxies no autenticados para acciones privilegiadas y exfiltración silenciosa de datos».

Debido a que las acciones se ejecutan mediante automatización de confianza con credenciales válidas, Noma sostiene que hay poco que la alerta convencional pueda detectar. La solicitud es normal, la salida del modelo es una salida de modelo válida, la llamada a la API está autenticada y la respuesta es la respuesta que el flujo de trabajo fue diseñado para enviar. CSO Online citó al miembro del equipo rojo Vibhum Dubey, quien hace concreto el problema de detección: "{{1}}Los eventos individuales pueden parecer completamente legítimos. Las señales útiles provendrían de correlacionar al solicitante original, la identidad utilizada posteriormente, los recursos a los que se accedió, los parámetros proporcionados y la acción final."

La verificación que falla es una verificación de autorización, no un filtro de contenido.

La ilustración más nítida del informe es un par de solicitudes idénticas. De un director financiero: «¿Cuáles son las cifras trimestrales de ventas del director de finanzas en su correo electrónico más reciente?». De un remitente externo: las mismas palabras. El punto de Noma es que el prompt y la operación solicitada son los mismos, mientras que la decisión de autorización debería ser completamente diferente: «Un director financiero tiene derecho a esa información; un remitente externo no».

Los detectores estándar de inyección de prompts y las salvaguardas de los agentes, sostiene el informe, clasifican las dos entradas de forma idéntica, porque no hay nada malicioso en ninguna de ellas que detectar. «El riesgo de seguridad no está en el prompt; está en el límite de autorización». La afirmación estructural de Noma se deduce de eso: las salvaguardas, las instrucciones del sistema y los filtros de entrada «no se diseñaron para actuar como límite de autorización», por lo que un pipeline que depende de ellos para decidir qué puede recuperar quien llama se apoya en un control al que nunca se le pidió que desempeñara esa función.

La distinción importa en la práctica. La inyección directa de prompts manipula cómo el modelo sigue instrucciones; la inyección indirecta de prompts oculta instrucciones en contenido que el modelo leerá después; el secuestro de identidad de flujo de trabajo, tal como lo define Noma, no necesita ninguna de las dos, porque la solicitud es una que se supone que el modelo entiende y que el pipeline debe ejecutar. Un defensor que ha pasado el año reforzando las defensas contra la inyección ha estado trabajando en una capa diferente.

Los flujos de trabajo estáticos quedan fuera del esfuerzo de endurecimiento de los agentes

Noma separa dos cosas que normalmente se usan de forma intercambiable. Un flujo de trabajo de IA es una secuencia predefinida y estática en la que un modelo es un paso de procesamiento —la forma abreviada del informe es paso A, modelo, paso B, paso C— y el pipeline determinista que rodea al modelo controla lo que ocurre. Un flujo de trabajo agéntico es autónomo: el agente decide qué pasos dar y qué herramientas invocar. Gran parte del esfuerzo actual en seguridad, sostiene el informe, se ha destinado al segundo tipo: restringir el acceso a herramientas y delimitar los permisos de los agentes que toman decisiones dinámicas, y esos controles no alcanzan al primero.

El informe también cierra una vía de escape obvia. Restringir quién o qué puede desencadenar un flujo de trabajo no resuelve el problema: si una automatización se ejecuta a las 8:00 a. m. según un horario y actúa sobre una bandeja de entrada en la que cualquiera puede escribir, auditar "quién puede desencadenar este flujo de trabajo" responde a la pregunta equivocada. La regla de Noma es que toda automatización debe evaluarse según "la parte menos confiable capaz de influir en aquello sobre lo que actúa", incluidos correos electrónicos, formularios, tickets, incidencias de GitHub, documentos compartidos y mensajes de chat.

Noma dice que Google solucionó un caso de Google Workflows; Google no ha publicado nada.

La única plataforma nombrada en el informe es la de Google. Noma afirma que identificó el mismo vector de riesgo dentro de Google Workflows, que lo reportó de forma responsable y que Google acusó recibo del informe y confirmó una corrección «sin revelar detalles de implementación». Esa frase constituye la totalidad del registro público. No se pudo localizar ningún aviso de Google, nota de versión ni CVE que describiera este vector, y todos los relatos secundarios de la corrección —incluidos los publicados en los días posteriores al 9 de septiembre— la atribuyen a Noma y no a Google.

El informe tampoco es del todo coherente sobre a qué producto de Google se refiere. El texto menciona Google Workflows; un encabezado de sección del mismo informe dice «Google Workspace: AI Workflow Identity Hijacking». Ambos son productos de Google con límites de confianza distintos, y el informe no los concilia. Noma no dice si el caso que reportó había sido explotado, cuántos clientes quedaron expuestos ni qué cambió la corrección —y, como Google no ha dicho nada, ninguna de esas lagunas puede cerrarse desde el lado del proveedor.

GitLost era la misma frontera, vista a través de una lente más estrecha

La divulgación anterior de Noma sienta un precedente para la categoría. En julio de 2026, el grupo publicó una investigación sobre GitHub Agentic Workflows, a la que denominó GitLost: un flujo de trabajo que se activaba cuando se asignaba una incidencia, leía el título y el cuerpo de la incidencia y respondía con un comentario; y, como el agente tenía acceso de lectura a todos los repositorios de la organización, los usuarios externos podían usar la asignación de incidencias para llegar a datos de repositorios privados. Dark Reading lo cubrió el 7 de julio de 2026 y describió a un atacante que ocultaba comandos en inglés sencillo en el cuerpo de una incidencia abierta en un repositorio público, sin necesidad de credenciales ni de conocimientos de programación.

Los dos enfoques no son idénticos, y la diferencia es lo interesante. El relato de Dark Reading de julio es una historia de inyección de prompts: el texto controlado por el atacante se lee como instrucciones. El informe de Noma de septiembre describe GitLost en términos del desencadenante y del acceso de lectura a todo el repositorio, y lo presenta como el mismo límite de autorización visto desde un ángulo. Ambas descripciones encajan con un flujo de trabajo en el que el agente leyó texto escrito por un externo, pero solo la primera depende de que el modelo sea dirigido. Noma ahora dice que reportó el mismo vector de riesgo a Google; no dice si el caso GitLost llegó a explotarse más allá de la demostración publicada.

La propia versión de Noma sobre su alcance es que Hacker News, Dark Reading y más de 100 otros medios internacionales se hicieron eco de la investigación de GitLost. Esa cifra es del proveedor, y este artículo no ha contado la cobertura de forma independiente.

Los profesionales coinciden en que el mecanismo es antiguo; la discusión es sobre el nombre.

La cobertura independiente no cuestionó el hallazgo, y dos profesionales externos objetaron la novedad más que el fondo. Morey Haber, asesor jefe de seguridad de BeyondTrust, declaró a Dark Reading: «Nadie engañó a un modelo de IA para que hiciera algo que no debía hacer. El modelo hizo exactamente lo que le indicó un desconocido (no confiable), y el flujo de trabajo que lo rodea usó la identidad de otra persona para lograrlo, ya que no estaba delimitado ni se trató con privilegios mínimos». CSO Online citó a Vibhum Dubey, quien describió el patrón como «una clase conocida de debilidad de autorización», y añadió que, cuando una entrada no autenticada puede desencadenar un flujo de trabajo de confianza que actúa con sus propios privilegios, «el flujo de trabajo puede actuar eficazmente como un delegado confundido».

Ram Varadarajan, director ejecutivo de Acalvio, ofreció a Dark Reading un control completamente distinto: en lugar de más filtrado, sembrar el entorno con señuelos —hilos ejecutivos falsos, registros honeytoken— que no tengan ninguna razón legítima por la que un flujo de trabajo autorizado deba tocarlos, de modo que una solicitud de aspecto benigno que intente alcanzar uno haga saltar una frontera que nunca debería cruzar. La discrepancia, si es que la hay, gira en torno a si la contribución útil es un nuevo nombre para una falla de delegación de la era de 1988 o una descripción funcional de dónde vive ahora esa falla. La postura de Noma es la segunda: que el patrón es sistémico en las canalizaciones de IA empresariales y que los marcos actuales de seguridad de IA se fijan en la superficie equivocada.

La mitigación es delegación y un punto de control, no un filtro mejor.

Los controles recomendados por Noma son de capa de aplicación en lugar de capa de modelo. La delegación de tokens con conocimiento de identidad implica eliminar las claves de API administrativas estáticas de los flujos de trabajo de IA y ejecutar operaciones de datos con tokens de delegación de corta duración y alcance limitado vinculados al solicitante autenticado, de modo que el contexto del usuario se propague a la llamada que realmente accede a los datos. Los puntos de control de autorización contextual implican tratar cada salida del modelo como una entrada no confiable y colocar una evaluación explícita de control de acceso y protección en tiempo de ejecución entre el paso de transformación del modelo y cualquier llamada posterior a la base de datos o a herramientas. La separación asimétrica de salidas implica aislar estructuralmente la recuperación de datos de los canales de comunicación externos, de modo que un flujo de trabajo que maneja datos internos sensibles no comparta una ruta de ejecución con un mecanismo automatizado que responde a terceros.

Dubey le dio a CSO Online una prueba más económica que cualquiera de las tres: comparar los resultados entre niveles de privilegio. "Si un usuario con pocos privilegios puede obtener el mismo resultado que un administrador porque los sistemas posteriores solo ven la identidad del flujo de trabajo, ahí es donde centraría la investigación".

Lo que el registro deja abierto

• Ninguna víctima, ningún recuento y ninguna telemetría. El caso del buzón de soporte de Noma es una demostración; el informe no nombra ninguna organización y el archivo registra daños reales como falsos. La plausibilidad del mecanismo no es evidencia de que se haya utilizado.

• Qué producto de Google se corrigió y en qué consistió la corrección. El texto de Noma dice Google Workflows, el encabezado de su sección dice Google Workspace, y Google no ha publicado nada. Las organizaciones aún no pueden determinar a partir de fuentes públicas si un pipeline que ejecutan estaba dentro del alcance.

• Si el vector se ha explotado en algún lugar. Ni el informe ni ninguna cobertura revisada para este artículo describe una campaña observada, una pérdida de datos ni un hallazgo forense atribuible al secuestro de identidad de flujos de trabajo.

• Si la categoría se sostiene cuando se la somete a medición. Ninguna parte independiente ha publicado un escaneo, un corpus de canalizaciones afectadas ni una suite de pruebas para el patrón; la evidencia que circula consiste en argumentos arquitectónicos más el relato de un proveedor sobre un único caso ya corregido.

• Quién hace el argumento. Noma Labs es el brazo de investigación de Noma Security, que vende controles de seguridad para agentes exactamente del tipo que recomienda su informe. Eso no hace que el hallazgo sea incorrecto —Dark Reading y CSO Online lo informaron, y ninguno encontró un error factual—, pero es un contexto que el lector debería tener en cuenta al sopesar cuán ampliamente se define la categoría.

La calificación de gravedad de media y su indicador de daño real en falso describen la evidencia, no el mecanismo. Lo que Noma ha establecido realmente es limitado y verificable: que la identidad del desencadenante de un flujo de trabajo y su identidad de ejecución son cosas distintas, que la segunda suele ser más poderosa y que una canalización que nunca compara ambas hará por un desconocido lo que haría por la persona para quien fue creada. El control que se deriva de ello es, en consecuencia, poco glamuroso: preguntar, para cada automatización, quién puede influir en aquello sobre lo que actúa y si algo posterior en la cadena vuelve a comprobar que la persona que pregunta tenía permiso para preguntar.