Detectar la extracción de modelos observando la ventana de tráfico, no las consultas aisladas

¿Qué es esto?

La extracción de modelos (model stealing) es el ataque en el que se consulta repetidamente una API de LLM alojada, se conservan los pares entrada-salida y luego se entrena un modelo sustituto, más barato, que aproxima el comportamiento, el conocimiento de dominio e incluso parte de los parámetros del objetivo. Figura como una amenaza importante para los servicios de LLM en el estudio de 2025 sobre ataques y defensas de extracción de modelos, y los resultados clásicos se remontan a Tramèr et al. (2016) sobre el robo de modelos mediante API de predicción.

El 4 de junio de 2026, Shuze Liu, Qianwen Guo y Yushun Dong (Santa Clara University, Florida State, FAMU-FSU) publicaron An Embarrassingly Simple Detector for Model Extraction Attacks in LLM API Traffic (arXiv:2606.05725, cs.CR). La contribución no es un ataque nuevo, sino un replanteamiento defensivo: dejar de intentar marcar consultas «sospechosas» una a una y, en su lugar, comprobar si una ventana de tráfico reciente se ha desviado de su distribución legítima histórica.

Cómo funciona

La observación central es que las consultas de extracción son casi imposibles de detectar de una en una. Los atacantes recurren a texto natural — pasajes tipo Wikipedia, prompts de SQuAD, bancos de preguntas de dominio — de modo que cada solicitud parece la de un usuario normal. Lo que los delata es la estructura en el agregado: un lote de consultas de extracción induce un desplazamiento medible en el espacio de embeddings semánticos, incluso cuando el tráfico atacante es solo una fracción de una ventana multiusuario más grande.

El detector es deliberadamente sencillo:

1. Codificar cada consulta entrante con un codificador de frases estándar.
2. Reunir una ventana deslizante de embeddings de tráfico reciente.
3. Calcular la Maximum Mean Discrepancy (MMD) — un estadístico
   de dos muestras con núcleo — entre la ventana y un conjunto
   de referencia legítimo.
4. Alertar si la MMD supera un umbral.

La decisión de diseño decisiva es la calibración. El umbral se fija usando solo comparaciones legítimo-contra-legítimo — sin datos de ataque etiquetados, sin generador de consultas atacante. Esto importa porque el defensor casi nunca dispone de las herramientas del atacante; solo tiene sus propios registros históricos. El artículo lo formaliza como prueba de distribución sobre ventana de tráfico calibrada con lo legítimo y lo evalúa sobre catorce pares de consultas atacante-normal en cuatro escenarios de extracción, incluido el caso realista de tráfico mixto donde las solicitudes del atacante se diluyen entre muchos usuarios legítimos.

Frente a PRADA, SEAT, CAP, DATE y una distancia de Mahalanobis marginal (todas adaptadas al mismo protocolo de embedding y calibración legítima para una comparación justa), el detector MMD reporta, en tres semillas: 0,3 % de tasa de falsos positivos legítimos, 100,0 % de tasa de verdaderos positivos en tráfico puramente atacante, 90,5 % de TPR medio según las fracciones de atacante y 95,1 % de exactitud equilibrada. El código está publicado en LabRAI/mmd-llm-mea-detection.

Por qué importa

La mayoría de las defensas publicadas contra la extracción se evalúan a nivel de cuenta: un usuario legítimo solo emite consultas limpias, un atacante ejecuta un flujo de extracción completo y el detector separa ambos. La supervisión real de una API no es así. El tráfico es un flujo mezclado de muchos inquilinos, y una campaña de extracción es solo una fina rebanada. Un detector que solo distingue cuentas puramente legítimas de cuentas puramente atacantes falla en silencio en cuanto el atacante es uno de mil llamantes simultáneos.

El enfoque de distribución sobre ventana aborda esto directamente, y la cifra de falsos positivos merece atención. La supervisión de seguridad vive y muere por la fatiga del analista: un detector que se dispara constantemente queda silenciado en una semana. Una tasa de falsos positivos del 0,3 % con calibración sin etiquetas de ataque hace que un control sea desplegable, no solo publicable. La otra cara, por honestidad: esto es detección de la fase de consulta, no prevención. Indica que probablemente hay una campaña en curso; no impide que el sustituto se entrene con datos ya exfiltrados, y un atacante paciente que reparte sus consultas con suficiente finura en el tiempo y entre cuentas puede reducir la señal por ventana.

Defensas

Este artículo es la técnica defensiva, así que las conclusiones prácticas son sobre su adopción:

1. Trate la supervisión de la extracción como un problema de distribución, no de anomalía por consulta. Agregue sobre una ventana de tráfico y compare con su propia referencia legítima. Los clasificadores por solicitud fallarán porque cada consulta es legítima por construcción.

2. Calibre con el tráfico legítimo que ya tiene. No necesita muestras de ataque ni el generador del atacante. Fije el umbral de alerta a partir de la variación legítimo-contra-legítimo de sus registros, lo que mantiene bajos los falsos positivos y evita sobreajustarse a un estilo de extracción.

3. Codificar y luego probar. Un codificador de frases genérico más MMD es una base sólida y barata. Empiece por ahí antes de recurrir a codificadores específicos de la tarea o a modelos de anomalía autosupervisados — aquí, la simple prueba de dos muestras superó a las bases adaptadas.

4. Ajuste el tamaño de ventana y la procedencia, no solo el umbral. El tráfico mixto diluye la señal; ventanas más pequeñas por inquilino o por segmento recuperan sensibilidad. Combínelo con limitación de tasa, cuotas por clave y defensas del lado de la salida (watermarking, perturbación de respuestas) para que la detección sea una capa, no toda la estrategia.

5. Planifique la respuesta, no solo la alerta. Detectar la fase de consulta da tiempo para limitar, desafiar o revocar una clave antes de que se entrene un sustituto utilizable. Decida de antemano qué desencadena una alerta de MMD.

Estado

Elemento	Referencia	Fecha	Notas
Detector MMD de extracción	arXiv:2606.05725	2026-06-04	Prueba MMD sobre ventana calibrada con lo legítimo
Resultados reportados	arXiv:2606.05725	2026-06-04	0,3 % FPR, 100 % TPR atacante puro, 95,1 % exactitud eq.
Código	LabRAI/mmd-llm-mea-detection	2026-06	Publicación pública
Contexto de amenaza	Estudio de extracción de modelos (Zhao et al.)	2025	La extracción como amenaza importante de los servicios LLM

El enfoque que conviene retener es simple: la extracción de modelos es difícil de detectar consulta por consulta y fácil de detectar ventana por ventana. Si su supervisión de API todavía evalúa las solicitudes de forma aislada, una prueba de distribución calibrada con su propio tráfico legítimo es una mejora de bajo coste — y de baja tasa de falsos positivos.