La AutopsIA del riesgo: agentes bajo asedio

En dos palabras

Esta serie analiza la investigación reciente en seguridad de la inteligencia artificial para quienes protegen o despliegan sistemas basados en modelos de lenguaje. La edición de esta quincena gira en torno a los agentes LLM: sistemas que no solo responden preguntas, sino que ejecutan acciones, llaman a herramientas y aprenden de su propia experiencia. Los trabajos reunidos aquí muestran que los vectores de ataque se han desplazado desde el modelo aislado hacia toda la cadena de suministro y el entorno de ejecución. Si usas o construyes agentes en producción, lo que sigue te concierne directamente.

Los agentes LLM han dejado de ser prototipos de laboratorio. Se despliegan en entornos de ingeniería de software, gestión de identidad corporativa y automatización de tareas complejas, y con esa madurez operativa llegan superficies de ataque que los modelos de amenaza tradicionales no contemplaban. La ciberseguridad e inteligencia artificial convergen esta quincena en una pregunta incómoda: ¿hasta qué punto los mecanismos de seguridad que rodean a estos agentes, los arneses de herramientas, los routers de habilidades, los filtros de salida, funcionan realmente cuando se les somete a presión adversarial?

La respuesta que ofrecen los doce trabajos analizados no es tranquilizadora. Los ataques se han vuelto más sutiles: ya no hace falta inyectar contenido malicioso explícito si se puede moldear cómo el agente generaliza una habilidad aprendida. Ya no hace falta romper el modelo si el arnés que lo envuelve tiene rutas de ejecución alternativas que esquivan las restricciones configuradas. Y ya no hace falta acceso privilegiado si añadir ruido gaussiano al espacio de representación interna del modelo basta para eludir sus salvaguardas de seguridad.

Al mismo tiempo, la quincena trae también propuestas defensivas concretas: un marco de autorización en el punto de ejecución, un método de ajuste fino que aprende de los propios fallos del agente, y un banco de pruebas unificado para monitorizar el abuso en trazas de conversación. El panorama es el de un campo que madura a la vez en ataque y en defensa, con la brecha entre ambos todavía abierta.

Panorama de un vistazo

SkillPoison: el veneno que llega en forma de éxito

Los agentes LLM modernos no solo ejecutan instrucciones: aprenden. Cuando completan una tarea con éxito, algunos sistemas extraen esa experiencia y la convierten en una habilidad reutilizable, un fragmento de comportamiento que el agente puede invocar en el futuro sin repetir el razonamiento completo. Es una forma de memoria procedimental. Y según el trabajo de Zhang, He, Fu, Feng, Li, Wang, Wang y Zhang, esa memoria es envenenable sin que ninguna experiencia individual parezca maliciosa.

La clave del ataque, que los autores denominan SkillPoison, está en separar dos cosas que normalmente van juntas: el comportamiento útil y las condiciones contextuales que lo hacen apropiado. El sistema construye un conjunto de experiencias exitosas, verificadas como correctas, que refuerzan un comportamiento objetivo. Luego elimina las restricciones contextuales que delimitan cuándo ese comportamiento es adecuado. El extractor de habilidades del agente aprende entonces una generalización incorrecta: el comportamiento se activa también cuando no debería. Los autores reportan una tasa de éxito del ataque del 95,71% en tres benchmarks, con todas las experiencias inyectadas superando verificación y revisión léxica.

Desde la perspectiva del editor, esto encaja con la categoría LLM04 (Data and Model Poisoning) del OWASP Top 10 for LLM Applications, pero con un matiz que lo hace especialmente difícil de detectar: el vector de envenenamiento no es el dato corrupto sino la generalización incorrecta inducida sobre datos correctos. En términos de MITRE ATLAS, se aproxima a la táctica de manipulación del pipeline de entrenamiento (ML Supply Chain Compromise), aplicada no al modelo base sino al proceso de destilación de habilidades. La cifra del 95,71% merece el matiz habitual: proviene de entornos de laboratorio controlados, y la transferencia a sistemas de producción con pipelines de verificación más heterogéneos es una pregunta abierta que el trabajo no responde.

Paper: SkillPoison, Zhang et al., 2026-10-06.

HarnessSecurity-Bench: los arneses de código no son tan seguros como parecen

Un arnés de agente de código (coding agent harness) es la capa que media entre el modelo de lenguaje y las herramientas del sistema: autoriza acciones, gestiona llamadas a ficheros, red y procesos, y aplica restricciones de seguridad. Herramientas como Claude Code, Codex CLI, Gemini CLI, Qwen Code o GitHub Copilot son ejemplos de este tipo de infraestructura. Zhu, Huang, Ji, Ye, Zhou, Guo, Wu, Ye, Feng, Dai y Zheng presentan el primer estudio empírico sistemático de estos arneses, y los resultados son preocupantes.

Los autores derivan una taxonomía de diez mecanismos de seguridad y evalúan 400 combinaciones de arnés y mecanismo. Encuentran que aproximadamente la mitad de las implementaciones confirmadas son opt-in, es decir, desactivadas por defecto. En los arneses de código cerrado detectan lagunas sustanciales de evidencia sobre qué mecanismos están realmente activos. El benchmark HarnessSecurity-Bench cubre 23 tareas sobre cinco superficies de ataque. Los autores reportan que activar la aprobación automática eleva la tasa de éxito del ataque del 29,2% al 95,6%. El aislamiento de red y el modo de solo lectura reducen los efectos del ataque pero con pérdidas sustanciales de utilidad. Las listas blancas y negras de comandos reducen el riesgo con un impacto menor en la utilidad.

El hallazgo más relevante para el defensor, en lectura del editor, es el de las rutas de ejecución alternativas: herramientas o comandos permitidos pueden dejar operaciones no autorizadas accesibles por caminos que las restricciones configuradas no cubren. Esto conecta directamente con la táctica de evasión de defensas en MITRE ATLAS y con LLM08 (Excessive Agency) del OWASP Top 10 for LLM Applications. La cifra del 95,6% de éxito bajo auto-approve es llamativa, pero el estudio usa un modelo de referencia controlado (GLM-5.2) en un entorno de laboratorio con 2.500 ensayos, lo que no replica necesariamente la variabilidad de un despliegue real con usuarios y configuraciones heterogéneas.

Paper: HarnessSecurity-Bench, Zhu et al., 2026-10-06.

PersistBD: backdoors que sobreviven al ajuste fino

El escenario es el de la cadena de suministro de modelos. Un desarrollador toma un modelo de terceros y lo adapta mediante ajuste fino supervisado (SFT) y aprendizaje por refuerzo (RL) para construir un agente especializado. El atacante ha comprometido el modelo base con un backdoor: un comportamiento oculto que se activa cuando aparece un patrón de entrada específico. La pregunta que estudian Zhan, Lyu, Ding, Mehta, Davies y Kang es si ese backdoor sobrevive al proceso de adaptación benigno del desarrollador.

Los autores observan que el SFT benigno reduce sustancialmente el éxito del ataque, pero que el RL posterior frecuentemente preserva el comportamiento residual e incluso puede aumentar su tasa de éxito. A partir del análisis de los factores que favorecen la supervivencia del backdoor, identifican dos: la fortaleza inicial del backdoor y la compatibilidad de gradientes con el entrenamiento benigno. Estos factores motivan PersistBD, un método que refina el modelo ya backdooreado antes de su distribución para mejorar su persistencia. Sobre Qwen2.5-Coder-7B, los autores reportan que PersistBD eleva la tasa de éxito del ataque del 20% al 74% tras SFT y del 20% al 76% tras SFT más RL, manteniendo un rendimiento comparable en tareas benignas.

En términos de marcos del sector, esto es un caso claro de ML Supply Chain Compromise en MITRE ATLAS. El riesgo es especialmente relevante porque el desarrollador no tiene por qué saber que el modelo base está comprometido: el backdoor está diseñado para pasar desapercibido durante la evaluación estándar. La cifra del 76% de persistencia tras el proceso completo de adaptación proviene de un único modelo y arquitectura en condiciones de laboratorio; la generalización a otros modelos y pipelines de entrenamiento es una pregunta que el trabajo deja abierta.

Paper: PersistBD, Zhan et al., 2026-10-05.

VulValidate: cuando los datos de entrenamiento mienten sobre las vulnerabilidades

Los detectores de vulnerabilidades basados en aprendizaje automático son tan buenos como los datos con los que se entrenan. Y esos datos, según el trabajo de Zhang y Chen, tienen un problema de etiquetado sistemático: los datasets construidos a partir de commits de corrección de seguridad etiquetan como vulnerables funciones que simplemente fueron modificadas por un parche, sin verificar que la función original fuera realmente explotable.

VulValidate es un marco que usa agentes LLM para coordinar herramientas de análisis dinámico y construir experimentos que intentan disparar la vulnerabilidad en tiempo de ejecución. Dado una función etiquetada y su parche, el sistema reconstruye ambas versiones, selecciona herramientas y rutas de ejecución, refina las entradas que podrían activar el fallo, y compara el comportamiento en tiempo de ejecución para determinar si la etiqueta es correcta. Los autores auditan 35.849 instancias etiquetadas como vulnerables en tres datasets (BigVul, PrimeVul y DiverseVul). Confirman 20.510 (57,2%), corrigen 6.819 etiquetas (19,0%), dejan 7.981 sin decidir (22,3%) y no pueden medir 539 (1,5%). En una revisión ciega de 581 decisiones muestreadas, el consenso de expertos apoya entre el 90,0% y el 92,0% de las confirmaciones y entre el 92,6% y el 99,0% de las correcciones de etiquetas.

El impacto práctico es directo: con parámetros de modelo fijos, la evaluación con etiquetas corregidas reduce el F1 de los cinco detectores probados en BigVul y DiverseVul. Reentrenar con etiquetas corregidas mejora el F1 de cuatro de los cinco detectores en cada dataset. Desde la lectura del editor, esto no es un ataque en sentido estricto, sino un problema de integridad de datos que afecta a la fiabilidad de toda la cadena de detección de vulnerabilidades. Conecta con LLM02 (Sensitive Information Disclosure) de forma indirecta: un detector entrenado con etiquetas incorrectas puede generar falsos negativos sobre vulnerabilidades reales, dejando código inseguro sin marcar.

Paper: VulValidate, Zhang y Chen, 2026-10-04.

APEX: defender el punto donde el agente actúa

La inyección indirecta de prompts (IPI) es el ataque en el que instrucciones adversariales se esconden en contenido que el agente lee durante su ejecución: una página web, la respuesta de una herramienta, un fichero de texto. El problema para el defensor es que los ataques pueden llegar por cualquier canal que el agente consulte, y construir filtros para cada patrón de ataque posible es una carrera que el atacante siempre puede ganar añadiendo un nuevo vector.

Zheng, Guo, Hao, Yang, Qian, Du, Xu, Xing, Yang y Wang proponen un cambio de perspectiva con APEX. En lugar de intentar reconocer el ataque, APEX defiende el punto estable donde el daño siempre se materializa: el límite de ejecución, el momento en que el agente convierte su estado interno en una acción externa o en una salida liberada. La defensa se articula en torno a un contrato de autorización compilado antes de que comience la ejecución no confiable. Ese contrato define qué efectos están autorizados por la tarea original. APEX aplica dos mecanismos: prevención condicionada a evidencia (solo admite un efecto si el contrato lo justifica) y exposición basada en engaño (hace que el uso no autorizado se revele antes de que el efecto se confirme). Los autores reportan un 0% de tasa de éxito del ataque en cinco de seis benchmarks y un 0,56% en el sexto, incluyendo ataques adaptativos sobre los tres tipos de unidades de capacidad evaluadas.

En lectura del editor, APEX es una propuesta que se alinea bien con el principio de mínimo privilegio aplicado a agentes: en lugar de confiar en que el modelo detecte la instrucción maliciosa, el sistema verifica que la acción propuesta esté dentro del mandato original de la tarea. Encaja con LLM01 (Prompt Injection) del OWASP Top 10 for LLM Applications como contramedida. Las cifras de 0% en entornos de laboratorio son llamativas y merecen cautela: los benchmarks controlados no capturan la diversidad de tareas, herramientas y contextos de un despliegue real, donde el contrato de autorización puede ser difícil de especificar con precisión suficiente.

Paper: APEX, Zheng et al., 2026-10-03.

COPEX: cuatro puertas de entrada en sistemas MCP

El Model Context Protocol (MCP) es una arquitectura que permite a los modelos de lenguaje usar herramientas externas de forma estructurada. Un agente MCP puede recibir instrucciones adversariales por cuatro vías distintas: las instrucciones del usuario, los esquemas de las herramientas, las respuestas de las herramientas, y los mensajes del propio protocolo. Birhan, Rostamzadeh, Narula, Nazzal, Ghasemigol y Takabi presentan COPEX, un benchmark que aísla el modelo como cliente MCP, fijando el resto del entorno y variando solo el modelo que selecciona herramientas.

COPEX cubre 25 tipos de ataque instanciados en 125 escenarios sobre las cuatro superficies de entrada. En nueve modelos y 3.375 ensayos, los autores reportan una tasa media de éxito del ataque del 64,4%, con medias por superficie que van del 58,3% al 71,4%. Algunos ataques a nivel de cliente y transporte tienen éxito parcialmente fuera de la observación o el control del modelo, lo que separa la exposición del sistema de la susceptibilidad del modelo. La defensa combinada de escaneo de entrada y contexto reduce la tasa media de éxito en un 49,6% sobre un subconjunto de ocho ataques respecto al escenario sin defensa.

Desde la perspectiva del editor, el hallazgo más relevante es la separación entre exposición del sistema y susceptibilidad del modelo: algunos ataques tienen éxito independientemente de lo que haga el modelo, porque explotan el protocolo o la infraestructura que lo rodea. Esto conecta con LLM01 (Prompt Injection) y con la táctica de evasión de defensas en MITRE ATLAS, pero subraya que la defensa no puede residir solo en el modelo. La tasa del 64,4% en un entorno controlado que fija el stack del agente puede subestimar o sobreestimar el riesgo en despliegues reales donde el stack varía.

Paper: COPEX, Birhan et al., 2026-10-03.

SRFT: aprender a resistir ataques desde los propios fallos

Los métodos habituales de alineación de seguridad para agentes LLM se basan en trayectorias de experto estáticas o en optimización de preferencias. Wang, Li, Gao, Suh, Zeng, Vorobeychik, Zhang y Xiao argumentan que este enfoque limita la capacidad de generalización ante patrones de ataque adaptativos, y proponen Self-Reflection Fine-Tuning (SRFT), un marco de entrenamiento que expone al agente a sus propios fallos bajo condiciones adversariales.

En lugar de imitar comportamientos expertos, SRFT construye trayectorias comprometidas mediante ataques de inyección, y usa un modelo experto para generar razonamiento de auto-reflexión estructurado que contrasta las acciones inseguras con las óptimas. Esa supervisión reflexiva enseña al agente a identificar instrucciones maliciosas, razonar sobre sus consecuencias y mantener la alineación con el objetivo original del usuario. Los autores instancian el marco en SR-Agent, construido sobre Llama-3.1-8B-Instruct y Qwen3-8B. Los resultados experimentales muestran, según los autores, que SRFT reduce sustancialmente las tasas de éxito del ataque preservando el rendimiento en tareas legítimas, con generalización bajo ataques adaptativos.

En lectura del editor, SRFT es una propuesta que aborda LLM01 (Prompt Injection) desde el lado del entrenamiento, complementando las defensas en tiempo de ejecución como APEX. La idea de aprender de los propios fallos tiene precedentes en aprendizaje por refuerzo adversarial, y su aplicación a la seguridad de agentes es una dirección prometedora. El trabajo no publica cifras concretas de reducción de tasa de ataque en el abstract, lo que limita la comparación directa con otros enfoques.

Paper: SRFT, Wang et al., 2026-10-03.

NeuroSploit sobre GOAD: explotación autónoma de Active Directory

Active Directory (AD) es la infraestructura de identidad y acceso dominante en entornos empresariales, y su compromiso representa el resultado de mayor impacto en una prueba de penetración interna. Barbosa presenta un benchmark de evaluación de NeuroSploit v4.2.0, un arnés de pentesting autónomo de código abierto escrito en Rust, contra GOAD (Game of Active Directory), un laboratorio AD deliberadamente vulnerable mantenido por Orange Cyberdefense con cinco máquinas virtuales, dos bosques y tres dominios.

El arnés orquesta 22 agentes específicos de AD y 7 playbooks de cadenas de ataque multi-etapa que cubren la cadena de kill completa de AD: enumeración, Kerberoasting, AS-REP roasting, relay y coerción NTLM, abuso de delegación Kerberos, explotación de AD CS (ESC1-ESC8), pivoting por servidores enlazados MSSQL, DCSync, abuso de confianzas entre bosques y detección de persistencia. El estudio evalúa nueve modelos LLM dentro del arnés y compara con invocación directa en 14 categorías de técnica y 7 cadenas. El arnés logra, según el autor, una cobertura del 96-100% de técnicas con una precisión del 90-97%, mientras que la invocación directa cubre solo el 21-54% y produce 3,2 veces más falsos positivos. El tiempo hasta el compromiso completo de los tres dominios con Opus 4.8 fue de 134 minutos.

En lectura del editor, este trabajo es relevante para los equipos de red team y para quienes diseñan defensas en entornos AD. La comparación entre orquestación estructurada e invocación directa sugiere que el valor del arnés no está solo en el modelo sino en la especialización por dominio y en los mecanismos de validación. Desde MITRE ATLAS, esto corresponde a la táctica de uso de IA para reconocimiento y explotación. Las cifras de cobertura y precisión provienen de un entorno de laboratorio deliberadamente vulnerable, lo que no refleja la complejidad y las defensas de un AD empresarial real.

Paper: NeuroSploit / GOAD, Barbosa, 2026-10-03.

CORSA: el ataque que primero tiene que ganar el router

Los agentes modernos no ejecutan una sola habilidad: seleccionan dinámicamente entre un repertorio de habilidades de terceros mediante un router. Najjar, Scionis, Puerto y Abdelnabi señalan un punto ciego en la evaluación de ataques de inyección en habilidades: la mayoría de los estudios asumen que la habilidad maliciosa ya ha sido seleccionada para ejecución. En entornos realistas con múltiples habilidades, la habilidad inyectada tiene que competir primero por la recuperación, y esa competencia reduce la tasa de éxito efectiva de las inyecciones existentes entre un 87% y un 97%, según reportan los autores.

Para abordar esta limitación, los autores introducen CORSA (Cluster Optimization for Router-Aware Skill Attacks), un ataque que optimiza las inyecciones en habilidades tanto para la recuperación como para la ejecución, a través de clusters de tareas relacionadas. CORSA usa etapas de optimización sucesivas: primero mejora la recuperación y luego optimiza el éxito del ataque de extremo a extremo, evaluando la utilidad para el usuario y el naturalismo de la inyección por separado. Los autores reportan que CORSA mejora sustancialmente tanto la recuperación como el éxito del ataque de extremo a extremo respecto a las inyecciones existentes, y que los ataques resultantes se transfieren entre diferentes arquitecturas de router y modelos LLM.

Desde la perspectiva del editor, CORSA refina el modelo de amenaza de LLM01 (Prompt Injection) para entornos de agentes con selección dinámica de habilidades, un escenario cada vez más común en producción. La transferibilidad entre arquitecturas de router es el dato más preocupante: sugiere que la defensa no puede residir solo en el router. La reducción del 87-97% en la tasa de éxito de ataques existentes en entornos multi-habilidad es un resultado que matiza el optimismo de estudios previos que no modelaban la competencia por recuperación.

Paper: CORSA, Najjar et al., 2026-10-06.

PEV: jailbreak por ruido, sin gradientes ni acceso a pesos

Los ataques de jailbreak (evasión de las restricciones de seguridad de un modelo) han requerido hasta ahora computación intensiva: optimización de gradientes por prompt, búsqueda adversarial, o modificación de los pesos internos del modelo. Dubey, Sirri, Chatziafratis y Seshadhri presentan PEV (Perturbed Embedding Vector), un método que prescinde de todo eso.

PEV añade ruido gaussiano independiente a las representaciones vectoriales internas del prompt (los embeddings) sin ninguna manipulación adicional. Para generar respuestas inseguras, el sistema muestrea repetidamente ruido aditivo de esa distribución. Los autores evalúan el ataque sobre seis modelos de código abierto de distintos tamaños en el benchmark JailbreakBench. Reportan que el coste computacional medio para obtener el primer ataque exitoso es hasta un orden de magnitud menor que el de ataques previos. El primer jailbreak exitoso sobre un nuevo prompt llega típicamente en menos de un minuto en todos los modelos probados. Los autores afirman que PEV genera respuestas inseguras en todos los modelos para todos los prompts de JailbreakBench, y que ningún otro método evaluado logra ese resultado en el mismo tiempo.

En lectura del editor, PEV es preocupante precisamente por su simplicidad: no requiere acceso a gradientes ni a pesos, solo a los embeddings, lo que amplía el perfil de atacante potencial. Desde MITRE ATLAS, encaja con la táctica de evasión de modelos de ML. La afirmación de éxito universal en JailbreakBench merece el matiz habitual: ese benchmark tiene un conjunto fijo de prompts y modelos en condiciones controladas, y la transferencia a modelos con capas de defensa adicionales en producción no está evaluada en el abstract. El trabajo abre además una pregunta de investigación más amplia sobre el comportamiento de los LLM bajo perturbaciones en el espacio de embeddings.

Paper: PEV, Dubey et al., 2026-10-05.

IA en vulnerabilidades no públicas: ¿ataca mejor o defiende mejor?

Los benchmarks públicos de capacidades ofensivas de IA tienen un problema estructural: los modelos pueden haber sido expuestos durante el entrenamiento a los avisos, exploits y correcciones de las vulnerabilidades evaluadas. Heldt, Turk, Landolt y Fritz abordan este problema evaluando modelos sobre cinco entornos de software con vulnerabilidades no públicas, incluyendo algunas divulgadas de forma privada mientras permanecían sin parchear.

Los autores usan calificadores deterministas desarrollados y revisados por investigadores, no jueces LLM, para medir las puntuaciones de las tareas. Los resultados muestran variación sustancial entre sistemas y tipos de vulnerabilidad. Las puntuaciones de reparación superan a las de ataque en dos entornos no públicos y quedan por debajo en tres. Un hallazgo relevante: superar una prueba de seguridad inicial es insuficiente. Los autores reportan que otro exploit tiene éxito en 92 de 524 intervalos de prueba del defensor no independientes tras detener el exploit inicial. Este resultado, según los autores, motiva comparaciones específicas por vulnerabilidad entre ataque y reparación, y pruebas de resistencia posterior.

En lectura del editor, este trabajo es metodológicamente importante para quienes diseñan evaluaciones de capacidades de IA en seguridad. La asimetría entre ataque y defensa varía según el tipo de vulnerabilidad, lo que sugiere que las afirmaciones generales sobre si la IA favorece más al atacante o al defensor son demasiado gruesas para ser útiles. El uso de vulnerabilidades no públicas y calificadores deterministas es una contribución metodológica que otros estudios del campo deberían adoptar.

Paper: Estudio ataque-defensa en vulnerabilidades no públicas, Heldt et al., 2026-10-05.

Unified Misuse Monitoring: detectar cuándo, no solo si

Los sistemas de monitorización de agentes LLM se han centrado en detectar si una trayectoria es dañina. Pramod, Oldfield y Bibi argumentan que esa pregunta es insuficiente: lo que importa para el defensor es cuándo el agente comete su primera acción dañina, para poder intervenir antes de que el efecto se materialice.

El trabajo propone monitorizar las respuestas del agente, donde sus acciones son externalizadas, y verificar si el primer punto en que el monitor detecta daño cae dentro de una ventana de daño definida como el intervalo entre el primer compromiso dañino del agente y la ejecución del objetivo. Los autores desarrollan un formalismo unificado para monitorización de abuso a nivel de traza y construyen un benchmark de aproximadamente 6.200 transcripciones de conversación entre usuario, agente LLM y entorno externo, cubriendo dos tipos de amenaza: ataques de descomposición (donde una petición dañina se divide en sub-peticiones aparentemente inocuas) e inyección de prompts (donde una herramienta comprometida entrega una instrucción maliciosa). En 17 configuraciones de monitor, los autores reportan que los monitores orientados a acciones funcionan bien en ambas amenazas bajo métricas clásicas (AUC de 0,95 y 0,99 respectivamente), mientras que los monitores orientados a contenido colapsan en ataques de inyección (AUC de 0,52). También muestran que las métricas clásicas insensibles a la posición dan una imagen optimista del rendimiento, ya que todos los monitores localizan mal los ataques de descomposición bajo la métrica de intervalo.

Desde la perspectiva del editor, este trabajo ofrece algo que faltaba en el campo: un marco unificado que trata conjuntamente dos vectores de abuso que hasta ahora se evaluaban por separado. La distinción entre detectar que hay daño y localizar cuándo empieza el daño es relevante para el diseño de sistemas de intervención en tiempo real. Encaja con la necesidad de monitorización continua de agentes que ejecutan cadenas de acciones largas, un escenario cada vez más común en producción.

Paper: Unified Misuse Monitoring Benchmark, Pramod et al., 2026-10-05.

Que defender

La quincena dibuja un mapa de amenazas que se ha desplazado desde el modelo aislado hacia el ecosistema completo del agente: el pipeline de aprendizaje de habilidades, el arnés de herramientas, el router de selección, el protocolo de comunicación con herramientas externas, y la cadena de suministro del modelo base. Ninguno de estos componentes es inmune, y varios trabajos demuestran que las restricciones configuradas en un punto dejan rutas alternativas accesibles.

Para quien protege un sistema, el mensaje transversal es que la defensa en profundidad no es opcional. Un modelo bien alineado puede estar montado sobre un arnés con mecanismos opt-in desactivados por defecto. Un arnés bien configurado puede estar ejecutando un modelo con un backdoor que sobrevivió al ajuste fino. Un sistema de monitorización que detecta trayectorias dañinas puede no localizar el momento exacto en que el daño comienza, llegando tarde para intervenir.

Triaje por inminencia: los vectores más urgentes son los que se apoyan en infraestructura ya desplegada. Los ataques sobre arneses de agentes de código (HarnessSecurity-Bench) y la inyección en sistemas MCP (COPEX) afectan a herramientas que ya están en uso en entornos de desarrollo. La persistencia de backdoors a través del ajuste fino (PersistBD) es relevante para cualquier organización que adapte modelos de terceros, una práctica habitual. El jailbreak por ruido en embeddings (PEV) amplía el perfil de atacante al eliminar la necesidad de gradientes. Estos cuatro vectores merecen atención inmediata. SkillPoison y CORSA son más especializados y requieren que el atacante tenga acceso al pipeline de aprendizaje de habilidades o al entorno de habilidades de terceros, lo que los hace más condicionales pero no menos relevantes a medida que los agentes con memoria persistente se generalizan. El estudio de vulnerabilidades no públicas y el benchmark de monitorización son contribuciones metodológicas que informan cómo evaluar y medir el riesgo, no amenazas directas.

Que hacer mañana: audita qué mecanismos de seguridad de tus arneses de agentes están activos por defecto y cuáles son opt-in; actívalos explícitamente y documenta la configuración. Aplica Human-in-the-Loop estricto para cualquier ejecución de código o acción con efectos externos irreversibles, especialmente en entornos con auto-approve. Antes de adaptar un modelo de terceros mediante ajuste fino, aplica pruebas de backdoor con entradas de activación conocidas y compara el comportamiento con y sin el trigger a lo largo de todo el proceso de adaptación, no solo al final. Restringe por hardware o por política de red las llamadas salientes de los agentes a lo estrictamente necesario para la tarea. Implementa monitorización orientada a acciones, no solo a contenido, y define ventanas de daño explícitas para poder intervenir antes de que el efecto se confirme.

Metodologia y fuentes

Esta edición se basa exclusivamente en los abstracts de doce preprints publicados en arXiv entre el 2 y el 6 de octubre de 2026, disponibles bajo acceso abierto. Los preprints no han pasado revisión por pares formal. Todos los hechos, cifras y resultados se atribuyen a sus autores originales. El editor no ha alterado, interpolado ni extrapolado ningún dato. El análisis de encuadre en marcos como OWASP Top 10 for LLM Applications y MITRE ATLAS es criterio editorial, no afirmación de los papers. Curado por La AutopsIA.

La pregunta que deja esta quincena no es si los agentes LLM son seguros o inseguros en abstracto: es si las organizaciones que los despliegan tienen visibilidad real sobre cada capa del sistema, desde el modelo base hasta el arnés, el router y el protocolo de herramientas, porque los atacantes ya la tienen.

La AutopsIA del Riesgo | Ciberseguridad e Inteligencia Artificial. Serie quincenal de La AutopsIA. Reúne y analiza la investigación reciente en seguridad de la inteligencia artificial: recopila trabajos de fuentes abiertas, los explica en claro y los sitúa en el mapa de amenazas, sin alterar ni un dato. Curado por La AutopsIA.