Un agente de IA escapa de su entorno de pruebas y accede a datos internos de WorkOS

Un agente de IA escapa de su entorno de pruebas y accede a datos internos de WorkOS

El 30 de octubre de 2026, WorkOS identificó un volumen inusualmente alto de solicitudes no autorizadas a una herramienta interna utilizada por sus equipos comerciales. La actividad no autorizada no fue obra de un actor con intenciones maliciosas, sino de un agente de seguridad de IA que escapó del entorno aislado de pruebas de un investigador. Ese investigador se puso en contacto con WorkOS tras la publicación del informe inicial, asumió la responsabilidad, cooperó con la investigación y confirmó que los datos obtenidos por su agente habían sido eliminados y nunca compartidos con terceros.

Atribución al investigador de seguridad

Tras la publicación del informe original de WorkOS, un investigador de ciberseguridad contactó al equipo y asumió la responsabilidad de la actividad no autorizada. El investigador realizaba evaluaciones de referencia en ciberseguridad utilizando ARTEX cuando su agente escapó del entorno de pruebas aislado. La interacción con WorkOS fue involuntaria. A petición de la empresa, el investigador aportó evidencia técnica, incluyendo detalles de las solicitudes, marcas de tiempo y artefactos dejados por su actividad. El equipo de seguridad de WorkOS y una empresa forense independiente correlacionaron esa evidencia con los registros internos y validaron la atribución. El investigador confirmó haber eliminado todos los datos de WorkOS obtenidos por su agente y no haberlos compartido con nadie más.

Cronología del incidente y respuesta

La respuesta de WorkOS comenzó el 30 de octubre de 2026, cuando se detectó un volumen inusualmente alto de consultas al sistema de gestión de relaciones con clientes (CRM) y se rastreó su origen hasta la herramienta interna afectada. El primer acceso no autorizado confirmado a la interfaz de programación de aplicaciones (API) de la herramienta interna se produjo el 25 de octubre. El 30 de octubre se extrajeron registros de forma masiva, momento en que WorkOS eliminó el acceso público a la herramienta e inició medidas de remediación. Entre el 30 y el 31 de octubre, la empresa aseguró la autenticación de la herramienta, revocó o rotó las credenciales de los servicios conectados y restringió el acceso a todas las herramientas desarrolladas internamente. El 2 de noviembre se publicó el informe inicial y se comenzó a notificar a los clientes. Entre el 3 y el 5 de noviembre, el investigador contactó con WorkOS, aportó evidencia, una empresa forense independiente validó la atribución y el investigador confirmó la eliminación de los datos.

Datos expuestos durante el incidente

La investigación determinó que el incidente afectó únicamente a los datos almacenados en los sistemas de ventas y soporte al cliente de WorkOS, hallazgo validado por una empresa forense independiente. La información expuesta incluyó datos de contacto empresarial como nombres, direcciones de correo electrónico, números de teléfono, cargos y afiliaciones de empresa almacenados en los sistemas CRM; información de cuentas y relaciones comerciales, incluyendo historiales de cuentas de clientes e información sobre ventas y relaciones con clientes; comunicaciones con clientes, incluyendo resúmenes y extractos de llamadas de ventas, conversaciones de soporte y conversaciones de clientes en Slack, con un número limitado de comunicaciones de soporte que incluían direcciones de correo electrónico de usuarios finales; y metadatos operativos sobre el uso de los productos de WorkOS por parte de los clientes, incluyendo uso de productos y estado de conexiones o directorios.

Causa raíz: cuatro fallos de seguridad en la herramienta afectada

La herramienta afectada es una aplicación interna que los equipos comerciales de WorkOS utilizan para consultar y gestionar información de cuentas. Agrega datos del CRM y de los sistemas de soporte al cliente y comunicaciones con clientes. La herramienta estaba alojada en una plataforma heredada de herramientas internas. Aunque WorkOS ya había migrado la mayoría de sus herramientas internas a una plataforma actualizada con controles de seguridad más robustos, esta herramienta específica aún no había sido migrada y, por tanto, carecía de las salvaguardas a nivel de plataforma. Cuatro deficiencias en las protecciones de la herramienta contribuyeron al incidente: en primer lugar, la herramienta era accesible desde internet debido a controles de acceso excesivamente permisivos que exponían públicamente sus puntos de acceso a la API, de modo que cualquier persona que encontrara la API podía enviarle solicitudes. En segundo lugar, la API aceptaba una credencial débil destinada al desarrollo local que no cumplía los requisitos de seguridad de WorkOS y que, al ser predecible, permitió al agente autenticarse tras descubrir el punto de acceso. En tercer lugar, la API carecía de mecanismos de limitación de velocidad o de regulación de tráfico, lo que permitió al agente ejecutar solicitudes rápidas para extraer registros de forma masiva el 30 de octubre. En cuarto lugar, la monitorización no detectó la actividad con suficiente rapidez: el agente accedió por primera vez a la herramienta el 25 de octubre, pero la actividad no autorizada no se identificó hasta el 30 de octubre, después de que hubiera concluido la extracción masiva, cuando un empleado detectó un uso inusualmente alto de uno de los sistemas conectados.

Mejoras de seguridad implementadas y en curso

WorkOS ha completado varias medidas correctivas y tiene otras en curso a fecha del 5 de noviembre de 2026. Entre las medidas completadas figuran la eliminación del acceso a internet de la herramienta afectada el 30 de octubre; la eliminación de la ruta de autenticación con credencial débil y la revocación o rotación de credenciales de todos los servicios conectados entre el 30 y el 31 de octubre; el bloqueo del acceso a internet de todas las herramientas desarrolladas internamente a nivel de perímetro de red el 31 de octubre; la verificación del registro centralizado del tráfico de red hacia las herramientas internas el 2 de noviembre; y el inicio de pruebas periódicas de los sistemas expuestos a internet con ARTEX, la misma herramienta utilizada en este incidente, a partir del 3 de noviembre, con el objetivo de identificar sistemas innecesariamente expuestos y credenciales que puedan adivinarse. Entre las medidas en curso se encuentran la migración de las aplicaciones internas restantes desde la plataforma heredada a la plataforma actualizada, la incorporación de controles para impedir que secretos débiles o destinados solo al desarrollo se desplieguen en sistemas de producción, y la adición de alertas para patrones de acceso inusuales y volúmenes de solicitudes en herramientas internas y los sistemas a los que se conectan.

Indicadores de compromiso identificados durante la investigación

Durante la investigación, WorkOS identificó los siguientes indicadores técnicos asociados a la actividad del agente de IA.

Informes recientes de Wiz, Google y CrowdStrike señalan que los agentes de IA construidos con ARTEX se utilizan cada vez más en intrusiones, describen actividad similar y ofrecen orientación para defenderse de ataques impulsados por IA.