Un ataque en el que el atacante es el vendedor
Casi todos los modelos de lenguaje comerciales se venden por token, y casi todos los clientes se fían de lo que el proveedor diga sobre cuántos tokens se produjeron. Un artículo enviado a arXiv el 17 de septiembre pregunta qué pasa si el proveedor hace que el modelo hable de más sin decirlo.
Los autores —Leilei Chen, Lan Zhang, Chen Tang, Pengcheng Sun, Jiewei Lai, Yixiao Huang, Zhaopeng Zhang y Xinpeng Shen— lo llaman ataque de inflación de tokens del lado del proveedor, o PTIA, y describen cinco variantes. Cada una alarga la salida sin degradar la respuesta lo bastante como para que el usuario lo note.
Hasta dónde llega, y dónde se detiene
El artículo informa de que cada ataque llevó la longitud media de salida a más de 10,2 veces la línea base limpia. Esa es la cifra titular, y explica por qué la cuestión importa comercialmente: multiplicar por diez los tokens de salida multiplica por diez la parte de la factura más difícil de verificar para un cliente.
El hallazgo más útil es que los ataques se saturan. El alargamiento inicial es espectacular, pero forzar más da rendimientos decrecientes, porque el comportamiento de parada del modelo vuelve a imponerse. Esa regularidad es lo que los autores convierten en un detector.
Una auditoría sin nada con qué comparar
Lo difícil de detectar esto es que el cliente no tiene una referencia limpia. No puede ejecutar el mismo modelo en local y no guarda un archivo de respuestas honestas conocidas de antes de que empezara el ataque.
La auditoría de los autores no necesita ninguna de las dos cosas. Informan de una tasa media de detección del 85,1% con tasas de falsos positivos por debajo del 2% en los escenarios que prueban. Son cifras del propio artículo, de su propia evaluación, y no se han reproducido de forma independiente.
Siete de quince
Los autores pasaron después la auditoría por 15 servicios reales de API de modelos de lenguaje. Señaló a siete de ellos por un comportamiento compatible con la inflación de tokens.
La formulación importa. Un comportamiento compatible con un ataque no es un ataque. Instrucciones de sistema prolijas, un modo de razonamiento por defecto, un modelo afinado para rellenar o una configuración de decodificación que simplemente favorezca la extensión producirían salidas que la auditoría podría leer igual. El artículo no es prueba de que siete proveedores concretos cobraran de más a nadie, y no se presenta como tal.
Lo que sí establece es que el comportamiento es detectable desde fuera, y que en un conjunto de servicios reales aparece algo.
Qué vigilar
La consecuencia práctica es de gobernanza. Los contratos empresariales de inferencia se escriben sobre un uso medido por el propio proveedor, sin un contador independiente. Este artículo sostiene que ese contador se puede construir. Si los equipos de compras empiezan a pedirlo, y si algún proveedor ofrece un recuento de tokens verificable, es lo próximo que habrá que vigilar.
