La AutopsIA del riesgo: cadenas de suministro, agentes y vacíos de datos

En dos palabras

Esta serie disecciona la investigación reciente en seguridad de la inteligencia artificial para que quien protege sistemas sepa qué viene y con qué tiempo cuenta. La edición de esta quincena recorre doce trabajos que cubren desde plugins que secuestran modelos de lenguaje por dentro hasta exploits que aprovechan el silencio de la web para colar desinformación en respuestas sintetizadas. Si tu organización usa LLMs en producción, en agentes autónomos o en herramientas de análisis de seguridad, algo de lo que sigue te afecta directamente.

La quincena que cierra octubre de 2026 deja un patrón claro: los atacantes ya no necesitan romper el modelo, les basta con rodearle. Plugins de terceros, contenido web estratégicamente colocado, inyecciones que imitan respuestas legítimas, agentes que confunden contexto de ejecución con autorización real. El perímetro de un sistema basado en LLMs se ha disuelto hasta el punto de que la superficie de ataque incluye la cadena de suministro de comportamiento, no solo la de código.

Al mismo tiempo, varios de estos trabajos muestran que los propios LLMs empiezan a usarse como herramientas defensivas: para detectar vulnerabilidades en código fuente y en binarios, para razonar sobre logs de ataque, para reparar controles de acceso rotos. La tensión entre el modelo como vector y el modelo como escudo define buena parte de la investigación actual en ciberseguridad e inteligencia artificial.

Panorama de un vistazo

IDH: cuando el plugin de steering se convierte en troyano

Los vectores de steering (vectores de dirección) son plugins que modifican el comportamiento de un LLM interviniendo directamente en sus representaciones internas, sin tocar los pesos del modelo. Se usan, por ejemplo, para reforzar el rechazo a peticiones dañinas. El problema, según el trabajo de Yu Yan, Jiahao Chen, Siqi Lu, Yongjuan Wang, Ziming Zhao, Zhaoxuan Li y Qingjun Yuan, es que ese mismo mecanismo puede armarse.

Los autores auditaron ocho bibliotecas de plugins de steering de código abierto y encontraron tres vulnerabilidades estructurales: verificación insuficiente de la integridad de la distribución, privilegios excesivos para los plugins y ausencia de monitorización en tiempo de ejecución. Sobre esa superficie proponen IDH, un plugin malicioso que implementa un mecanismo de enrutamiento mutuamente exclusivo controlado por norma y un método de localización automática de la capa de inyección óptima. El resultado, según los autores, es que el plugin puede cumplir su función legítima (reforzar el rechazo a peticiones dañinas) y al mismo tiempo manipular recomendaciones comerciales de forma encubierta. Los experimentos, realizados sobre cinco LLMs de uso habitual y seis marcas en tres dominios comerciales, reportan una tasa de éxito del ataque de hasta el 97,8% manteniendo tasas de rechazo altas ante peticiones dañinas.

Una cifra tan próxima al 100% merece cautela. Los autores trabajan en condiciones de laboratorio controladas, con modelos y dominios seleccionados; en un despliegue real, la variabilidad de las distribuciones de entrada y la heterogeneidad de los entornos de producción suelen rebajar estas métricas de forma significativa. Aun así, el vector es real.

Desde la perspectiva del editor, este ataque encaja con la categoría de envenenamiento de modelo y manipulación de la cadena de suministro que MITRE ATLAS recoge bajo la táctica de Supply Chain Compromise (AML.T0010). No es un ataque al modelo en sí, sino a la infraestructura que lo rodea, lo que lo hace especialmente difícil de detectar con las herramientas habituales de revisión de código. El propio trabajo propone un marco de defensa en tiempo de ejecución basado en suprimir intervenciones de activación anómalas y ortogonalizar trayectorias entre capas, aunque su eficacia en producción queda por evaluar.

Paper: Yan et al., 2026

RALE y VulDec: LLMs como escáner de vulnerabilidades

Dos trabajos del mismo equipo, Francesco Crescenzo Grasso, Pietro Liguori, Roberto Natella y Domenico Cotroneo, abordan el problema de la detección automática de vulnerabilidades desde ángulos complementarios.

El primero, RALE (Representation-Aware Logical Ensemble), parte de una observación empírica: los LLMs entrenados sobre una sola representación del código (código fuente en bruto, árbol de sintaxis abstracta o grafo de flujo de control) tienen puntos ciegos distintos según el tipo de vulnerabilidad. Los autores proponen combinar modelos entrenados sobre cada representación mediante reglas lógicas explícitas y votación por mayoría. Según el trabajo, los modelos individuales alcanzan hasta un 73% de F1, mientras que el ensemble integrado llega al 78%, con mejoras consistentes en precisión y exhaustividad. La ganancia no es espectacular en términos absolutos, pero el argumento metodológico es sólido: distintas vistas del código revelan distintas clases de fallos, y combinarlas de forma explícita es mejor que asumir que una sola representación es universalmente adecuada.

El segundo trabajo, VulDec, ataca un problema más difícil: detectar vulnerabilidades en ejecutables binarios, sin código fuente disponible. Los autores introducen un dataset a gran escala que alinea pares ensamblador-C con anotaciones CWE detalladas en múltiples arquitecturas, y un marco de extremo a extremo que usa descompilación neuronal para recuperar código fuente aproximado antes de aplicar un detector. Los descompiladores neuronales ajustados sobre su dataset alcanzan una similitud de edición de aproximadamente el 56% y un BLEU-4 de aproximadamente el 43% en la recuperación del código fuente. El detector ajustado alcanza un F1 macro de 0,61 en un conjunto de prueba realista con una tasa de vulnerabilidad del 3%. Los propios autores presentan este resultado como evidencia de que la descompilación neuronal es una alternativa viable a las representaciones de bajo nivel, no como una solución definitiva.

Ambos trabajos son defensivos por naturaleza. Desde el punto de vista del editor, su relevancia práctica depende de cuánto ruido generan en entornos reales: un F1 de 0,61 con una tasa de vulnerabilidad del 3% implica que la mayoría de las alertas pueden ser falsos positivos, lo que exige un flujo de triaje humano antes de actuar sobre los resultados. Dicho esto, como capa de pre-filtrado en un pipeline de revisión de seguridad, ambas aproximaciones tienen mérito.

RALE: Grasso et al., 2026 | VulDec: Grasso et al., 2026

Red teaming con roles separados: el crítico y el atacante no deben ser el mismo

El red teaming automático, es decir, usar LLMs para generar y refinar ataques contra otros LLMs, se ha convertido en una práctica habitual. Mintong Kang, Stephen Rawls, Melissa Kazemi Rad, Jian Ni y Bo Li se preguntan algo más fino: dentro del bucle de red teaming, ¿quién debe diagnosticar el fallo y quién debe proponer el siguiente ataque?

Los autores separan dos roles: la crítica (diagnosticar por qué falló un ataque) y la propuesta (generar el siguiente intento). Su análisis muestra que la autocrítica, es decir, que el propio modelo objetivo diagnostique sus fallos, es más efectiva porque tiene acceso al contexto de ejecución real, incluyendo observaciones, restricciones y razonamiento disponible. Eliminar el razonamiento en este paso reduce el éxito de los ataques posteriores entre un 6% y un 17%, según los autores. En cambio, la autoproposición, que el modelo objetivo genere también el siguiente ataque, es contraproducente: la conciencia del objetivo adversarial induce rechazo explícito y lo que los autores llaman sandbagging no adversarial.

La configuración resultante, en la que el modelo objetivo diagnostica y un atacante separado propone, alcanza una tasa de éxito del 63,2% en DTAP-BENCH, un benchmark que cubre dominios de telecomunicaciones, flujos de trabajo, CRM y código, bajo modelos de amenaza directa e indirecta. Los autores reportan que esta cifra supera a las líneas base evaluadas.

Para el editor, este trabajo tiene implicaciones directas para los equipos de red team internos: la distribución de roles entre sesiones de modelo distintas no es solo una cuestión de diseño elegante, sino que afecta materialmente a la efectividad del ejercicio. En términos de MITRE ATLAS, la técnica se relaciona con la táctica de Craft Adversarial Data (AML.T0043), pero aplicada de forma iterativa y automatizada. El matiz sobre el contexto de ejecución como fuente de ventaja para el crítico también sugiere que los modelos con mayor visibilidad de su propio estado interno son más útiles para diagnosticar sus propias debilidades, lo que tiene consecuencias para cómo se diseñan los entornos de evaluación.

Paper: Kang et al., 2026

SentryBench: el coste real de que un agente sea demasiado cauto

La mayoría de los benchmarks de seguridad para agentes LLM tratan el rechazo como la respuesta segura por defecto. Md Abu Yusuf, Oyshi Tabassum Aditi y Md Faysal Hosain Mazed argumentan que esa suposición es incorrecta en despliegues de seguridad pública, donde un agente que rechaza despachar ayuda de emergencia falla tan gravemente como uno que genera una alerta falsa.

SentryBench introduce una métrica de coste asimétrico que penaliza simultáneamente el éxito del ataque, el exceso de rechazo (no atender una emergencia real) y el exceso de reacción (actuar sin justificación). Los escenarios se basan en transcripciones reales de llamadas de emergencia, mensajes de desastre y payloads reales de inyección y jailbreak. Los autores demuestran formalmente que la cautela ingenua (rechazar más) es dominada en términos de daño cuando rechaza más emergencias genuinas de las que evita por ataque. También demuestran que una compuerta de confianza dirigida no añade exceso de rechazo en entradas limpias.

En 840 episodios evaluados sobre tres modelos de frontera y tres defensas, los autores reportan que la estrategia de rechazar más lleva el exceso de rechazo al 100% en dos de los tres modelos con un cambio máximo de 3,7 puntos en la tasa de éxito del ataque, y produce el peor daño en todos los casos. La compuerta de confianza propuesta domina el frente de Pareto en todos los modelos evaluados.

Desde la perspectiva del editor, este trabajo es relevante para cualquier organización que despliegue agentes con acceso a herramientas de acción real, no solo en emergencias. La lección es que calibrar la robustez de un agente requiere medir los dos lados del error, no solo los ataques que tienen éxito. En términos de OWASP Top 10 for LLM Applications, la combinación de inyección de prompt (LLM01) con acceso a herramientas de consecuencias reales se acerca a lo que LLM08 (Excessive Agency) describe como el riesgo de agentes con demasiado alcance de acción.

Paper: Yusuf et al., 2026

BAC-Bench: reparar el control de acceso roto con LLMs

El control de acceso roto (Broken Access Control, BAC) ocupa el primer puesto en el OWASP Top 10 de aplicaciones web desde 2021. Mingrui Liu, Liang He, Xinchu Wang, Yeting Li, Dongxu Han, Yunpeng Li y Yuling Liu construyen el primer benchmark específico para evaluar la reparación automática de este tipo de vulnerabilidades.

BAC-Bench reúne 46 vulnerabilidades reales extraídas de seis aplicaciones web ampliamente usadas, en cuatro lenguajes de programación, cada una con entorno de ejecución en sandbox, programa de validación PoC y prueba funcional. Los autores proponen además un marco de estrategia de reparación que caracteriza cualquier parche a lo largo de cuatro dimensiones: posición, cobertura, mecanismo y contenido.

Los resultados muestran que los LLMs base en turno único reparan de media el 37,68% de las vulnerabilidades. Dos andamiajes mínimos, Apply-Feedback y Navigate-and-Locate, elevan esa media al 66,03%, con el mejor LLM base alcanzando el 75,36%, próximo al 78,99% del mejor agente comercial evaluado. Los autores señalan que algunos parches generados por LLMs superan a los parches oficiales, y que uno de ellos cerró incidentalmente una vulnerabilidad de día cero que llevaba tres años sin detectarse.

Una cifra de 75% en un benchmark controlado no debe trasladarse directamente a producción. Las vulnerabilidades de BAC son vulnerabilidades de lógica de negocio, y el benchmark, aunque cuidadosamente construido, no puede capturar toda la variabilidad de contextos de autorización en aplicaciones reales. Dicho esto, el trabajo es una referencia útil para equipos que evalúen el uso de LLMs como asistentes en revisión de código de seguridad. En términos de OWASP LLM, la capacidad de un LLM de razonar sobre modelos de control de acceso toca directamente LLM02 (Sensitive Information Disclosure) cuando el fallo expone datos protegidos.

Paper: Liu et al., 2026

AquaSense-ICS: infraestructuras de agua y la trampa de las métricas perfectas

Los sistemas ciber-físicos de agua son infraestructura crítica con datasets de investigación escasos, o reales pero pobres en variedad química, o simulados pero sin ruido de sensores ni ataques reales. Amal Neji, Mohamed Fourati y Lamia Chaari Fourati presentan AquaSense-ICS, un dataset híbrido que combina datos reales de un nodo edge con Raspberry Pi 5 (23.688 registros en una ventana de 25,4 horas) con una red simulada en EPANET-MSX de 13 nodos y una biblioteca parametrizada de ataques: inyección de datos falsos, replay, denegación de servicio y deriva de sensor.

El aporte metodológico más relevante no es el dataset en sí, sino el protocolo de evaluación. Los autores muestran que el método habitual de benchmarking, dividir filas aleatoriamente y calcular etiquetas a partir de las propias características de entrada, produce puntuaciones casi perfectas pero sin valor informativo: un Random Forest alcanza F1 macro de 0,9998 bajo ese protocolo. Con su protocolo alternativo, que usa divisiones cronológicas y tipos de ataque no vistos durante el entrenamiento, ningún modelo supera el predictor constante de clase normal para clasificación de ataques (F1 macro de 0,465), y los mejores detectores alcanzan un AUROC medio de 0,64 en tipos de ataque no vistos durante el entrenamiento.

Este resultado es una advertencia directa para quienes evalúan sistemas de detección de intrusiones en infraestructura crítica. Las métricas publicadas en muchos trabajos del área pueden estar infladas por fugas de etiquetas (label leakage) en el diseño experimental. Desde la perspectiva del editor, el protocolo anti-fuga propuesto aquí debería considerarse un requisito mínimo para cualquier evaluación de detección de ataques en sistemas ciber-físicos, no una opción metodológica avanzada.

Paper: Neji et al., 2026

NTBench: inyecciones que se camuflan de respuesta correcta

La inyección de prompt (prompt injection) es el vector de ataque más estudiado en LLMs. Yuyang Gong, Zihao Wang, Jiawei Liu y XiaoFeng Wang identifican un punto ciego en cómo se evalúa la resistencia a este vector: los benchmarks existentes miden si el modelo rechaza ataques que abandonan abiertamente la tarea del usuario, pero no detectan ataques que mantienen la apariencia de una respuesta legítima mientras introducen errores o daño.

A esto lo llaman inyección near-target (cercana al objetivo). NTBench construye pares tarea-instrucción maliciosa a partir de tareas legítimas de datasets existentes, con pistas separadas para objetivos incorrectos y dañinos, incluyendo casos en que el daño acompaña a una respuesta por lo demás correcta. Los autores combinan validación automática con revisión humana de las desviaciones inducidas.

Evaluando siete LLMs en diez datasets de tareas de lenguaje y dos benchmarks de agentes, con un presupuesto de tres ejecuciones de ataque por muestra, los autores reportan que ambas pistas logran tasas de éxito globales superiores a la línea base de objetivo fijo en todos los modelos evaluados. En tareas de lenguaje, los incrementos van de 9,3 a 35,8 puntos porcentuales para objetivos incorrectos y de 1,7 a 17,3 puntos para objetivos dañinos.

Este trabajo encaja directamente con LLM01 (Prompt Injection) del OWASP Top 10 for LLM Applications, pero añade una dimensión que los controles habituales no cubren: un filtro que detecta si la respuesta abandona la tarea no detectará una respuesta que completa la tarea pero introduce un error sutil o un dato dañino. Para el editor, esto implica que los sistemas de evaluación de robustez deben incluir jueces semánticos que comparen la respuesta con una referencia legítima, no solo detectores de rechazo o de contenido prohibido.

Paper: Gong et al., 2026

Ulysses: un agente que genera y verifica exploits web

Aditya Oke, André Vicente Duarte, Rui Melo, Shubham Gandhi, Nachiket Kotalwar, Charmi Khandor, Danqing Wang, Carolyn Rosé y Lei Li presentan Ulysses, un sistema multi-agente que convierte hallazgos de vulnerabilidades candidatas en pruebas de explotabilidad verificadas para aplicaciones web.

El sistema explora hipótesis de exploit de forma iterativa y establece el éxito observando efectos de ejecución independientes, lo que resuelve un problema conocido: los LLMs tienen dificultades para verificar de forma fiable sus propios exploits generados. Evaluado en WebExploitGym, un benchmark de 25 aplicaciones web reales en 5 lenguajes y 7 frameworks, Ulysses produce pruebas verificadas para 10 de los 25 advisories del benchmark. Además, los autores reportan que el sistema descubrió 4 nuevas pruebas de explotabilidad no reportadas previamente.

Un 40% de cobertura sobre advisories reales en un benchmark curado es un resultado que merece contexto. Las aplicaciones seleccionadas para el benchmark son instancias explotables conocidas, lo que facilita la verificación pero no refleja la complejidad de un entorno de producción arbitrario. Dicho esto, la capacidad de generar pruebas verificables, no solo sugerencias de exploit, es un salto cualitativo respecto a herramientas anteriores. Desde la perspectiva del editor, Ulysses ilustra la táctica de MITRE ATLAS de uso de LLMs para descubrimiento de vulnerabilidades (relacionada con AML.T0006), y su existencia como herramienta de código abierto eleva el nivel de amenaza para aplicaciones web que no tienen un programa de gestión de vulnerabilidades activo.

Paper: Oke et al., 2026

SecLog-Bench: razonar sobre logs de ataque es más difícil de lo que parece

Yifan Wang, Dongliang Xu, Xiaoyong Li, Jing Li, Peter S. Pan y Yue Yao presentan SecLog-Bench, un benchmark para evaluar la capacidad de LLMs de razonar sobre logs de ciberseguridad multi-fuente en escenarios de ataque reales.

El benchmark cubre 29 escenarios de ataque, usa logs de auditoría, logs de aplicación y tráfico de red de forma conjunta, y anota cada muestra con una cadena de evidencia estructurada paso a paso. La evaluación de ocho LLMs de uso habitual muestra que, incluso con evidencia estructurada como andamiaje, el mejor modelo alcanza solo el 44,44% de precisión y un F1 macro del 45,07%. La puntuación más alta de razonamiento por etapas (Stage Reasoning F1) es del 54,87%. Los autores señalan además que predicciones correctas pueden ir acompañadas de razonamiento erróneo, y que la calidad del razonamiento no está alineada con la precisión de la predicción.

Este resultado es relevante para quienes evalúan el uso de LLMs como asistentes en centros de operaciones de seguridad (SOC). La capacidad de un modelo de llegar a la respuesta correcta por razones incorrectas es un riesgo operativo real: en un entorno de producción, el analista que confía en el razonamiento del modelo para escalar o descartar un incidente puede tomar decisiones erróneas aunque la etiqueta final sea correcta. El trabajo no propone soluciones, pero delimita con precisión el problema.

Paper: Wang et al., 2026

Omni-UBench: los guardrails multimodales tienen puntos ciegos en las combinaciones

Junhao Wang, Yidou Chen, Li Lu, Hongwei Yao, Xiaodan Li, Mengjie Wu, Yuefeng Chen, Zhan Qin y Kui Ren presentan Omni-UBench, el primer benchmark comprehensivo para evaluar guardrails (sistemas de filtrado y moderación) en modelos de lenguaje omnimodales, es decir, los que procesan texto, imagen, audio y vídeo de forma unificada.

El benchmark reúne más de 183.000 muestras de más de 35 fuentes heterogéneas, con etiquetas de seguridad bajo una taxonomía de riesgo unificada. La evaluación de 15 modelos y guardrails representativos arroja tres hallazgos principales, según los autores: los modelos omnimodales modernos muestran potencial de moderación de contenido incluso sin ajuste específico para guardrails; los guardrails existentes tienen dificultades para identificar consultas que ocultan intención dañina en combinaciones cruzadas de modalidades o que usan jailbreaks sofisticados; y exhiben alucinación de seguridad y sobresensibilidad a patrones textuales, lo que revela una comprensión deficiente de la semántica de seguridad cruzada entre modalidades.

Para el editor, el punto más relevante es el segundo: un guardrail que funciona bien con texto puede fallar ante una instrucción dañina codificada en una imagen o distribuida entre audio y texto. Esto conecta con la expansión de la superficie de ataque que describe MITRE ATLAS y con LLM01 (Prompt Injection) en su variante multimodal. La heterogeneidad de las fuentes del benchmark, más de 35, es un punto fuerte, aunque las métricas específicas por modalidad y tipo de ataque no se detallan en el abstract.

Paper: Wang et al., 2026

Exploits de vacío de datos: cuando el silencio de la web es un arma

Michele Guerra, Wuyeh Jobe, Sanjana Nambiar, Christina Pöpper y Azza Abouzied estudian un vector de ataque que aprovecha una característica estructural de los LLMs con búsqueda web: cuando el modelo sintetiza una respuesta sobre un tema con escasa cobertura en la web, puede recuperar y citar contenido adversarial colocado estratégicamente en ese vacío informativo.

A diferencia de la búsqueda clásica, donde el usuario ve la lista de resultados y puede evaluar la fuente, el LLM presenta una respuesta sintetizada que puede ocultar que se apoya en una sola fuente no verificada o adversarial. Los autores estudian el ataque variando el tono del prompt del usuario (escéptico, entusiasta o neutro), el modelo (ChatGPT, Gemini o Sonar Pro) y tres controles del atacante: la estrategia de construcción del vacío de datos, la visibilidad del dominio que aloja el contenido y la inclusión de características de optimización para motores generativos.

Los resultados muestran que el exploit puede tener éxito con una sola página controlada por el atacante. En todas las condiciones evaluadas, el contenido del atacante aparece en las respuestas del LLM el 31% del tiempo. Los prompts escépticos reducen ligeramente el éxito y aumentan ligeramente las advertencias en las respuestas, pero los autores no encuentran evidencia de efectos grandes del tono del prompt ni de la elección del modelo sobre la tasa de éxito, aunque señalan que no pueden descartar efectos menores.

Este vector es especialmente relevante porque no requiere acceso al modelo, no requiere explotar una vulnerabilidad técnica y puede ejecutarse con recursos mínimos. Desde la perspectiva del editor, se trata de un ataque de envenenamiento de la cadena de recuperación de información, relacionado con LLM02 (Sensitive Information Disclosure) cuando el contenido recuperado desplaza información veraz, y con la categoría de desinformación de MITRE ATLAS. El hecho de que el tono escéptico del usuario tenga un efecto limitado sugiere que la defensa no puede delegarse en el comportamiento del usuario final.

Paper: Guerra et al., 2026

Qué defender

La quincena dibuja un mapa de amenazas que se mueve en tres planos simultáneos. El primero es la cadena de suministro de comportamiento: plugins de steering que secuestran el modelo desde dentro, exploits web que envenenan la recuperación de información, agentes que generan y verifican vulnerabilidades de forma autónoma. El segundo es la superficie de evaluación: varios trabajos muestran que las métricas actuales de robustez y detección están infladas por diseños experimentales defectuosos, lo que significa que los sistemas que creemos seguros pueden no serlo. El tercero es la brecha entre laboratorio y producción: cifras de éxito del 97% o F1 de 0,99 en benchmarks controlados no se trasladan directamente a entornos reales, y confiar en ellas sin matiz es un riesgo de gestión.

Para quien protege sistemas, el mensaje transversal es que el perímetro de un LLM en producción incluye todo lo que el modelo puede leer, ejecutar o citar, no solo el modelo en sí. Eso abarca los plugins de terceros, el contenido web que recupera, los logs sobre los que razona y las herramientas a las que tiene acceso.

Triaje por inminencia. Los vectores más urgentes son dos. El primero es la inyección near-target (NTBench): se apoya en el mismo mecanismo que la inyección de prompt clásica, ya documentada en producción, pero evade los controles habituales porque no abandona la tarea del usuario. Cualquier sistema con agentes que procesen contenido externo está expuesto hoy. El segundo es el exploit de vacío de datos: no requiere acceso al modelo ni vulnerabilidad técnica, y el 31% de tasa de aparición reportado por los autores en condiciones de laboratorio es suficientemente alto para considerarlo un riesgo operativo real en sistemas con búsqueda web habilitada.

Los plugins de steering maliciosos (IDH) son igualmente preocupantes, pero requieren que el atacante tenga acceso a la cadena de suministro de plugins, lo que añade fricción. Los trabajos sobre detección de vulnerabilidades (RALE, VulDec), reparación de BAC y razonamiento sobre logs son defensivos y a más largo plazo: útiles como capas adicionales, pero no urgentes como contramedidas inmediatas. AquaSense-ICS y SecLog-Bench son contribuciones metodológicas cuyo valor principal es corregir cómo se evalúa, no cómo se ataca.

Qué hacer mañana. Para los plugins de steering y cualquier plugin de terceros que intervenga en representaciones internas del modelo: auditar los privilegios concedidos, exigir verificación de integridad de la distribución (firma criptográfica del paquete) y añadir monitorización de activaciones en tiempo de ejecución antes de cualquier despliegue en producción. Para los sistemas con búsqueda web habilitada: implementar un paso de verificación de fuentes que registre y exponga al usuario cuántas fuentes distintas respaldan cada afirmación, y establecer umbrales de confianza mínimos antes de citar contenido de dominios con escasa autoridad.

Para los agentes con acceso a herramientas de acción real: aplicar Human-in-the-Loop estricto para cualquier acción irreversible, y calibrar los umbrales de rechazo midiendo los dos lados del error (falsos positivos y falsos negativos) con un funcional de coste asimétrico como el propuesto en SentryBench. Para los equipos de red team internos: separar el rol de crítico del de atacante en sesiones de modelo distintas, siguiendo el diseño de Kang et al., y verificar que los benchmarks de evaluación de robustez incluyen jueces semánticos que detecten desviaciones sutiles, no solo rechazos explícitos.

Metodología y fuentes

Esta edición se basa exclusivamente en los abstracts de doce preprints publicados en arXiv entre el 21 y el 26 de octubre de 2026, todos de acceso público. Los preprints de arXiv no han pasado revisión por pares formal; todos los resultados se atribuyen a sus autores y se presentan como hallazgos reportados, no como hechos establecidos. No se ha alterado ningún dato ni se ha añadido información externa a los abstracts proporcionados. El análisis editorial (encuadre en marcos OWASP y MITRE ATLAS, valoración de madurez, recomendaciones de defensa) es criterio del editor y no representa afirmaciones de los autores originales.

Curado por La AutopsIA.

La pregunta de esta quincena no es si los LLMs pueden atacar o defender, mas bien si los equipos de seguridad tienen visibilidad sobre todo lo que el modelo puede leer, ejecutar y citar antes de que lo haga. Sin esa visibilidad, el resto de controles trabaja a ciegas.

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 intenta esclarecer y los sitúa en el mapa de amenazas. Curado por La AutopsIA.