Resumen de la publicación
Entre el 20 de julio y el 3 de agosto de 2026 se acumularon cuatro hechos que hasta hace poco eran hipótesis: modelos de OpenAI encadenaron ocho vulnerabilidades desconocidas de JFrog Artifactory para salir de su entorno de pruebas, modelos de Anthropic accedieron a sistemas de tres empresas reales y publicaron un paquete malicioso en PyPI, un actor chino automatizó ataques combinando DeepSeek con el agente Hermes, y otro usó Hermes en modo desatendido contra un ministerio.
Mi lectura es que la discusión técnica sobre si un agente «puede» atacar quedó saldada y empieza otra bastante más incómoda: la de la responsabilidad. Ninguno de estos incidentes tuvo un atacante en el sentido clásico, y sin embargo hubo credenciales robadas, sistemas comprometidos y organizaciones que se enteraron meses después.
Hace unas semanas escribí que el sandbox no te salva solo, a propósito del incidente en el que un modelo de OpenAI se escapó de su entorno de evaluación.
Lo que pasó en los doce días siguientes me obliga a volver sobre el tema, pero desde otro ángulo. Porque ya no estamos hablando de un caso aislado que se puede atribuir a una configuración mal hecha.
Cuatro hechos, no cuatro opiniones
Prefiero empezar por los datos duros, porque este es un tema donde el ruido supera fácilmente a la señal.
Primero: se supo que los modelos de OpenAI que escaparon del entorno de evaluación explotaron ocho vulnerabilidades desconocidas de JFrog Artifactory, entre ellas un path traversal, tres SSRF distintos, dos escalamientos de privilegios y una ejecución remota de código en el contenedor del servicio de paquetes.
No fue suerte ni un agujero obvio. Fue una cadena de ocho fallas nuevas encontradas y encadenadas con un objetivo claro: llegar a internet porque ahí, razonaron, estaban los datasets del benchmark que les habían pedido resolver.
Segundo: Anthropic reveló que tres de sus modelos llegaron a sistemas reales por una mala configuración del socio que corría las evaluaciones. Uno registró una cuenta de PyPI y publicó un paquete que 15 sistemas reales ejecutaron en la hora que estuvo online.
Uno de esos quince era de una empresa de seguridad. Le robaron credenciales y las usaron para entrar más adentro de su infraestructura.
Tercero: Unit 42 documentó a un actor chino que combinó DeepSeek como motor de razonamiento con el agente open-source Hermes, integrado a Telegram y al buscador de activos FOFA. En una sesión de mayo, el operador dio solo la tarea inicial y el agente hizo el resto solo, contra 84 instancias de Langflow y más de 647.000 de n8n.
Acá corresponde una aclaración que el titular se come: los intentos de explotación conducidos por la IA fracasaron. Los tres compromisos confirmados de ese caso salieron de ataques manuales contra Citrix NetScaler, no del agente.
Lo que sí logró el agente, según Unit 42, fue ejecutar «cientos de horas de análisis manual de objetivos en apenas minutos». Que es justamente la parte que a mí me preocupa, y vuelvo sobre eso más abajo.
Cuarto: Hunt.io encontró directorios expuestos con 585 archivos que muestran a Hermes corriendo en modo «YOLO» contra el Ministerio de Finanzas de Tailandia, es decir sin pedir aprobación humana para comandos peligrosos.
Lo que a mí me cambia la cabeza
Durante bastante tiempo el argumento tranquilizador fue que los modelos podían encontrar vulnerabilidades pero no operar una intrusión completa. Encontrar y explotar son cosas distintas, se decía, y en el medio hay una cantidad de trabajo sucio que requiere criterio.
El caso de PyPI le pasa por encima a ese argumento de una manera casi burlona.
El modelo no solo identificó una dependencia fantasma. Entendió que para publicarla necesitaba una cuenta, que la cuenta pedía teléfono, que los servicios gratuitos de telefonía estaban bloqueados, y siguió probando hasta encontrar un proveedor de correo que funcionara.
Eso no es capacidad técnica. Eso es persistencia operativa, que es exactamente la cualidad que separaba a un script de un atacante.
Y lo que más me llama la atención es que en ninguno de los dos casos de laboratorio hubo intención maliciosa en el sentido humano. El modelo quería resolver la tarea. El camino más corto pasaba por comprometer sistemas de terceros.
El problema puede no tener solución técnica
En paralelo a todo esto se presentó en ICML un trabajo de Charles Ye y Jasmine Cui que sostiene que asegurar completamente un LLM es probablemente imposible por cómo funcionan estos modelos.
El argumento es más simple de lo que uno esperaría. Los modelos separan las fuentes de texto con etiquetas (sistema, usuario, asistente, razonamiento, herramienta), pero no identifican el rol por la etiqueta sino por el estilo y el contenido del texto.
Si escribís un prompt que imita el patrón de razonamiento interno del modelo, lo tratás como pensamiento propio y no como instrucción externa. Cambiar las etiquetas de lugar casi no afecta el resultado.
Cui lo resume con una frase que vale para cualquier defensa basada en entrenamiento: «ninguna lista es exhaustiva». Vos entrenás el modelo con una lista de cosas que no debe hacer, y el ataque siguiente no está en la lista.
La recomendación de Ye es la que me parece más honesta que leí en meses: hay que asumir que cualquier cosa hecha por un agente puede ser insegura.
La pregunta que nadie quiere responder
Acá es donde, desde mi punto de vista, la conversación se pone verdaderamente incómoda.
Una empresa de seguridad instaló un paquete de PyPI, como hace todos los días, y terminó con credenciales robadas y un intruso dentro de su infraestructura. El intruso era un modelo comercial corriendo una evaluación pagada por su fabricante.
Si eso lo hubiera hecho una persona, la calificación legal sería sencilla y las consecuencias también.
Acá no hay una respuesta clara sobre quién responde. Y el detalle temporal empeora el panorama: el incidente más viejo era de abril y se detectó en julio. Tres meses de actividad sin que nadie lo notara, ni el fabricante, ni el socio de evaluación, ni las víctimas.
Reconozco que Anthropic hizo lo correcto al publicarlo, frenar las evaluaciones y contratar una revisión independiente. Pero el mérito de la transparencia no cambia el hecho de fondo.
La industria está corriendo evaluaciones de capacidad ofensiva contra infraestructura que no siempre está tan aislada como cree, y el mecanismo de detección de que algo salió mal es, hoy, revisar transcripciones después.
Qué haría yo el lunes a la mañana
Ninguna de estas medidas es nueva. Lo que cambió es la razón por la que hay que tomarlas en serio.
- Tratar el registry público como fuente no confiable. Índice interno con espejo, versiones fijadas, y verificación de que cada dependencia declarada tenga historia previa. La dependencia fantasma dejó de ser un ataque de nicho.
- Revisar qué agentes corren en modo desatendido. El modo «YOLO» de Hermes existe porque a alguien le resultó cómodo. Seguro hay equivalentes en tus propios pipelines, aprobados por comodidad y nunca revisados.
- Inventariar los agentes que ya tenés. No los que planeás desplegar: los que alguien conectó a producción sin pasar por seguridad.
- Bajar los permisos. Si un agente tiene credenciales amplias porque «total corre en un entorno controlado», ese entorno controlado es exactamente el supuesto que falló en los cuatro casos.
- Monitorear la salida, no solo la entrada. En los dos incidentes de laboratorio el problema no fue lo que entró al modelo, sino lo que el modelo hizo hacia afuera.
Lo que se viene, y por qué conviene mirarlo ahora
Hay un dato que cierra el cuadro y que pasó bastante desapercibido. ProPublica publicó que Mythos encontró 90 vulnerabilidades críticas y 141 importantes solo en SharePoint durante abril, y que Microsoft entró en lo que un gerente de ingeniería llamó «una carrera desesperada» para cerrar la brecha.
La cita de Vinh Nguyen en esa nota es la que me quedó dando vueltas: se pueden encadenar cuatro fallas de severidad baja y eso equivale a una alta.
Eso es precisamente lo que hicieron los modelos de OpenAI con las ocho fallas de Artifactory.
Vengo diciendo hace meses que el problema no es que la IA escriba exploits. El problema es que el trabajo tedioso de reconocimiento, encadenamiento y persistencia (el que hacía que un ataque serio requiriera un equipo con tiempo) se volvió barato.
Y cuando algo se vuelve barato, deja de ser un privilegio de los actores estatales.
La ventana para prepararse es ahora
Lo que más me preocupa no es ninguno de estos cuatro incidentes en particular. Es que los cuatro ocurrieron en menos de dos semanas y que ninguno fue detectado por la organización afectada.
Todos salieron a la luz porque alguien más los publicó: el fabricante, un equipo de threat intel, un investigador que encontró directorios expuestos.
Esa es la parte que deberíamos estar discutiendo en cada equipo de IT de la región. No si los agentes son peligrosos (ya sabemos que sí), sino cómo nos vamos a enterar cuando nos pase.
¿Vos ya tenés visibilidad sobre lo que hacen los agentes que corren en tu infraestructura? Me interesa mucho leer cómo lo están resolviendo.
