Por Canuto  

Una nueva postura académica sostiene que el gran obstáculo para desplegar aplicaciones y agentes basados en modelos de lenguaje no es que “piensen mejor”, sino que las organizaciones carecen de monitoreo sistemático en producción para detectar anomalías, reconstruir incidentes y responder como en los esquemas de Endpoint Detection and Response (EDR). El trabajo propone una taxonomía de 14 categorías de amenazas y detalla qué artefactos deben registrarse a lo largo del flujo completo, desde prompts y RAG hasta tool-calls, cachés y planos de actualización del modelo.
***

  • Plantea que los riesgos de seguridad en apps con LLM deben asumirse como condición operativa esperada y gestionarse con monitoreo e incident-response.
  • Describe 14 categorías de amenazas, desde prompt injection y fuga de datos hasta robo de modelos, deriva y desinformación, con vectores y señales de auditoría.
  • Propone telemetría por etapas del flujo agente-herramientas-RAG, para detección, forensia y contención tras el despliegue.

Las aplicaciones impulsadas por modelos de lenguaje grandes (LLM) se han convertido en piezas centrales de software en dominios como medicina, legal, finanzas e ingeniería de software. Pero esa adopción no viene gratis. Un nuevo trabajo titulado LLM-enabled Applications Require System-Level Threat Monitoring, de Yedi Zhang, Haoyu Wang, Xianglin Yang, Jin Song Dong y Jun Sun, argumenta que la principal barrera para un despliegue confiable no es seguir aumentando la capacidad del modelo, sino instalar mecanismos de monitoreo de amenazas a nivel de sistema una vez que el producto está en producción.

El punto de partida es incómodo para la industria: por su naturaleza no determinista, guiada por aprendizaje y difícil de verificar, el comportamiento de un LLM no ofrece garantías comparables a las de componentes tradicionales sometidos a métodos formales. En ese contexto, los autores proponen tratar fallos y compromisos como eventos previsibles. La consecuencia práctica es adoptar una perspectiva de “respuesta a incidentes” desde el diseño, en lugar de confiar solo en pruebas previas al despliegue o en guardrails.

En software convencional, los equipos de Endpoint Detection and Response (EDR) vigilan sistemas desplegados y ejecutan procedimientos cuando detectan fallas. En cambio, en aplicaciones con LLM las amenazas suelen manifestarse de forma implícita y dependiente del contexto, lo que dificulta usar métricas simbólicas estándar para diagnosticar. Por eso, el trabajo insiste en que el monitoreo debe mapear vectores de ataque hacia artefactos observables, con auditoría y logging a lo largo del flujo completo de una aplicación “agéntica”.

De chatbots a agentes: el flujo de ejecución amplía la superficie de ataque

El documento describe un flujo representativo de aplicaciones con LLM dividido en ocho etapas. El usuario envía un prompt inicial; un cliente orquesta, consulta un servicio para conocer herramientas disponibles, y envía un prompt integrado al “cerebro” del LLM. Ese cerebro puede interactuar con recursos externos como bases vectoriales, Graph-RAG o memoria. Luego produce respuestas intermedias y planes de herramientas, el cliente ejecuta tool-calls, integra resultados, solicita la respuesta final y la entrega al usuario.

Esa arquitectura no es un detalle de implementación. Es la razón por la cual la superficie de ataque crece de forma estructural. Un atacante ya no solo apunta a un modelo. Puede apuntar a documentos recuperados por RAG, a salidas de APIs de herramientas, a cachés, a memoria de largo plazo, o incluso al plano de actualización del propio modelo. Además, las ejecuciones reales suelen incluir bucles entre las etapas de razonamiento y tool-calling, lo que abre la puerta a consumo descontrolado de recursos y a ataques persistentes.

El trabajo enmarca también conceptos como “AI agents” como sistemas autónomos con memoria y planificación por pasos, y el Model Context Protocol (MCP) como una “columna vertebral” estandarizada para conectar agentes con herramientas y datos. Aunque asume MCP para analizar el sistema de forma consistente, su postura es agnóstica al protocolo. El argumento es que el problema se mantiene en cualquier tendencia hacia arquitecturas interoperables de agentes con herramientas.

Con ese contexto, los autores restringen el alcance a amenazas que surgen durante el despliegue y que son intrínsecas a aplicaciones con LLM. Dejan fuera ataques de entrenamiento y vulnerabilidades típicas de ingeniería de software no ligadas al LLM. Aun con esa restricción, la lista de riesgos es amplia y abarca seguridad, privacidad, confiabilidad y abuso.

Las 14 categorías de amenazas: del prompt injection al robo de modelos

La propuesta central es una taxonomía de 14 categorías, cada una con vectores de ataque y artefactos de monitoreo. Entre las primeras están prompt injection, adversarial inputs, manipulación de respuestas, ataques DoS o bucles no acotados, y envenenamiento de datos en vivo. Más adelante aparecen envenenamiento del modelo en vivo, fuga de datos sensibles, divulgación entre contextos, filtración por memorización, robo del modelo en etapa de despliegue, remoción de watermarks, deriva del modelo, desinformación y abuso de la aplicación.

La idea no es solo enumerarlas. El trabajo insiste en que cada clase requiere señales observables en logs. Esas señales deben estar ubicadas por etapa del flujo. En prompt injection, por ejemplo, se monitorean prompts crudos, patrones sospechosos, separadores imitadores, integridad de snippets recuperados en RAG y validación estricta de esquemas en salidas de herramientas. También se vigila la posición de inserción de contenido externo, porque poner la carga maliciosa al final puede aprovechar sesgos de recencia.

En adversarial inputs, el enfoque incluye telemetría lexical y semántica. Se registran diferencias por normalización Unicode, métricas anómalas de tokenización e invisibles, y también “outlier scores” en embeddings para detectar consultas fuera de distribuciones benignas. Además, para entradas multimodales o artefactos intermedios, se escanean metadatos y resultados de OCR, se buscan inconsistencias entre modalidades y se rastrea si outputs intermedios se reutilizan como inputs, lo cual puede propagar payloads.

La manipulación de respuestas aparece como un riesgo acumulativo. Prompt chaining puede degradar gradualmente la seguridad hasta lograr un resultado que al inicio habría sido rechazado. Allí se proponen métricas por turno, tendencia de seguridad, estabilidad de contexto con distancias en embeddings del estado y auditoría de composición de ventana de contexto, en especial si el sistema resume o poda historial. El mismo capítulo incluye tampering del entorno y reuse, con logs de mutaciones de memoria y trazabilidad de qué memorias influyeron en una respuesta.

DoS, bucles y tool-call storms: cuando el costo se vuelve el ataque

El trabajo pone foco en ataques de denegación de servicio y consumo no acotado, porque en LLM el recurso crítico no es solo CPU. También lo son tokens, latencia, colas de herramientas y costos monetarios de APIs externas. Se describen ataques por requests sobredimensionados, prompting recursivo que induce bucles, tormentas de tool-calls sobre herramientas caras y evasión de caché mediante variaciones sintácticas con la misma intención semántica.

Para oversized requests, se sugieren logs del API gateway con códigos como 429 y 503, distribución de tamaños de payload y costos de tokenización, además de medir latencia de tokenización antes de inferencia. En bucles no acotados, aparecen contadores de pasos, burn-down de tokens a nivel de sesión y métricas de similitud de estado para detectar repetición de intenciones de tool-call.

En tool-call storms, se monitorea “fan-out ratio” de invocaciones por prompt, latencia y costo por herramienta, y profundidad de cola. Y para cache-bypass, se vigila la caída abrupta del cache hit rate, la variabilidad de hashes de prompts con similitud semántica alta y un indicador de “costo versus baseline” por usuario. El objetivo es detectar al atacante que agrega nonces para impedir reutilización de resultados costosos.

Este bloque resulta especialmente relevante para productos que combinan LLM con ejecución de tareas, trading algorítmico, análisis de mercado o automatización. Un error o abuso puede escalar a costos sostenidos, degradación de servicio y fallas en cascada. El monitoreo propuesto no elimina la causa, pero permite contener el daño cuando el sistema ya está bajo ataque.

Privacidad y aislamiento: fugas por RAG, logs, cachés y multi-tenant

La fuga de datos sensibles ocupa un capítulo completo. El documento separa tres vectores: leakage por outputs finales, fallas de alcance y autorización en RAG, y “secondary leakage” por observabilidad, logging o cachés. Para outputs, se proponen escaneos PII/DLP, trazas de decisiones de redacción o rechazo, y comparación entre respuesta cruda interna y versión sanitizada. Si el escáner detecta entidades sensibles y la marca de redacción queda en falso, se considera un incidente de alta prioridad.

En RAG scope y autorización, el énfasis está en registrar decisiones de control de acceso que mapeen <user_ID, query, document_ID>, detectar patrones anómalos de consulta tipo “shotgunning”, y medir cuánto contenido recuperado se reproduce de forma literal. Si un usuario sin permisos logra que el sistema recupere documentos restringidos por fallas en ACL, la fuga ocurre antes de que un filtro de salida tenga oportunidad de intervenir.

En secondary leakage, el problema se traslada a la infraestructura: logs que guardan payloads en texto plano, dashboards y observabilidad que se vuelven un canal lateral. Por eso se propone medir cobertura de redacción en logs, escaneo periódico de cachés para patrones sensibles y auditoría de accesos a paneles. El mensaje es que la privacidad no se rompe solo en el texto que ve el usuario final.

El trabajo también aborda “cross-context disclosure”, donde datos de un tenant o sesión pueden filtrarse a otra por colisiones de claves en caché, reutilización de contexto obsoleto tras retries, o incluso pools de memoria compartida en GPU y KV caches. Se plantean señales como entropía y colisión de cache keys, cache hits no autorizados, latencia de reset de contexto, afinidad nodo-sesión, canary tokens, y logs del asignador de memoria junto a métricas de VRAM para detectar reutilización prematura o falta de limpieza.

Riesgos de propiedad intelectual y confianza: memorización, robo y evasión de watermarks

Más allá de la operación diaria, el documento incluye amenazas a la propiedad intelectual y a la atribución. En “memorisation leakage”, el riesgo es inferir pertenencia a datos de entrenamiento o reconstruir datos sensibles mediante logprobs, embeddings o sondeo masivo. Las señales incluyen verbosidad del esquema de respuesta, outliers de confianza, deriva hacia decodificación determinista como temperatura 0, patrones de queries de embeddings con alta similitud sucesiva y vacíos de rate-limiting que permiten miles de intentos.

En “deployment-stage model theft”, se describen ataques por extracción vía API y distillation con alto volumen de pares prompt-respuesta, además de side-channels por latencia o metadatos finos expuestos. También se contempla el escenario más directo: accesos internos o configuraciones erróneas que permiten descargar artefactos como pesos del modelo o system prompts desde registries. Como señales aparecen patrones de volumen y probing, métricas de diversidad, jitter de latencia, control de verbosidad de telemetría, y correlación entre accesos privilegiados y picos de transferencia saliente.

Para watermark removal y fingerprint evasion, el trabajo distingue pipelines de parafraseo o traducción aguas abajo, fine-tuning o distillation para “lavar” la distribución del modelo, y stripping de metadata en el egreso. Se proponen logs de cadena de transformación, comparación de puntajes de detección de watermark entre salida cruda y salida entregada, resultados de pruebas de robustez durante entrenamiento y verificación de manifiestos de trabajos de fine-tuning, además de auditorías en headers esperados y discrepancias en almacenamiento.

De la detección a la respuesta: hacia un ciclo de incident-response

Los autores conectan su propuesta con la práctica de EDR: detección es solo el inicio. Luego viene el análisis post-monitoreo con triage, priorización por severidad, generación de reportes de trazabilidad que reconstruyan progresión temporal y causal, y acciones de contención y recuperación. En LLM, la recuperación no solo es parchear código. También puede implicar tuning de instrucciones, reentrenamiento, sanitización de prompts o respuestas y refuerzo de estrategias de alineación.

El trabajo reconoce desafíos operativos. Construir un corpus robusto de patrones sospechosos es difícil por escala y ambigüedad semántica, y existe un trade-off permanente entre falsos positivos y falsos negativos. También advierte sobre el costo en latencia de inspeccionar contexto, y propone un enfoque por niveles: pre-filtros deterministas ligeros y análisis basado en LLM solo cuando el caso sea de alto riesgo o ambiguo, con caching e inspección incremental.

Finalmente, se subraya una limitación estructural: la observabilidad. En despliegues cerrados o black-box, no hay acceso al entorno interactivo del modelo, lo que vuelve inviable una auditoría rigurosa. Esto motiva la idea de interfaces estandarizadas de observabilidad mínima, suficientes para investigación reproducible sin revelar secretos propietarios. En paralelo, el documento no descarta alternativas como red teaming, guardrails o alineación, pero las considera insuficientes sin visibilidad continua a nivel de sistema.

LLM-enabled Applications Require System-Level Threat Monitoring pone el dedo en una herida frecuente en la conversación sobre IA: la obsesión por el rendimiento del modelo puede ocultar el hecho de que el riesgo real se materializa en producción, a través de toolchains, RAG, cachés, memoria y pipelines de actualización. Para el ecosistema que construye productos financieros, agentes de soporte, automatización y analítica, el mensaje es claro: sin telemetría, no hay forensia; y sin forensia, la respuesta a incidentes se vuelve improvisación.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados