Robo de prompts por tiempo: canales laterales de caché de prefijos en LLM multiinquilino

¿Qué es esto?

Los sistemas modernos de servicio de LLM almacenan en caché el trabajo ya realizado. El Automatic Prefix Caching (APC) reutiliza los tensores clave-valor calculados para el comienzo de una solicitud cuando otra posterior empieza con el mismo texto: una aceleración considerable para documentos largos y conversaciones multironda. El problema es que un acierto de caché (hit) es más rápido que un fallo (miss), y esa diferencia de tiempo es observable desde fuera. En un despliegue multiinquilino donde la caché de prefijos se comparte entre usuarios, un atacante puede enviar prompts manipulados, medir cuánto tarda el primer token y deducir si el prefijo que ha adivinado coincide con algo que otro inquilino ya tenía en caché. Repitiendo la sonda, token a token, se reconstruye el prompt de un desconocido.

No es teórico. Un equipo de Stanford —Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang y Tatsunori Hashimoto— auditó API reales en Auditing Prompt Caching in Language Model APIs (arXiv 2502.07776, febrero de 2025, aceptado en ICML 2025) y detectó uso compartido global de la caché entre usuarios en siete proveedores de API, incluido OpenAI. La misma señal temporal incluso filtró un dato de arquitectura: que el modelo de embeddings de OpenAI es un Transformer solo de decodificador. La publicación más reciente de esta línea, CacheSolidarity (arXiv 2603.10726, marzo de 2026), motivó este artículo.

Cómo funciona

Aquí no hay payload que censurar: el ataque es pura medición contra una API de caja negra. El mecanismo:

Etapa                        Qué ocurre
---------------------------  --------------------------------------------------
1. Elegir un prefijo objetivo  Adivinar una cadena por la que podría empezar
                             el prompt de una víctima (cabecera de system
                             prompt, dirección de correo, ID de cuenta)
2. Sondear                   Enviar una solicitud que empiece por ese candidato
                             y registrar el time-to-first-token (TTFT)
3. Clasificar hit / miss     TTFT bajo => el prefijo ya estaba en caché de
                             otro (hit); TTFT alto => miss
4. Extender y repetir        Añadir el siguiente token, volver a sondear y
                             avanzar el prefijo pieza a pieza

El atacante nunca lee directamente los datos de otro usuario; los infiere de la latencia. Trabajos posteriores muestran su alcance: PromptPeek (Wu et al., 2025), según lo informado por el estudio SafeKV, reconstruye prompts con hasta un 99 % de precisión cuando se conoce la plantilla del prompt y ~95 % sin ese conocimiento, atacando la planificación por árbol radix que usan frameworks como SGLang. Tanto CacheSolidarity como SafeKV enumeran el mismo conjunto de sistemas que incorporan caché de prefijos: OpenAI, DeepSeek, Google Gemini, MoonShot Kimi, vLLM y SGLang.

Por qué importa

La exposición crece con la cantidad de texto sensible que acaba en un prefijo compartido. Los autores de SafeKV señalan que corpus de preentrenamiento habituales como C4 y el Pile contienen nombres de usuario, números de teléfono, números de tarjeta y números de seguridad social: justo el tipo de secuencia que se vuelve inferible si se almacena y se comparte entre inquilinos. Todo lo que coloque al principio de un prompt —un system prompt con secretos, una ficha de cliente añadida como contexto, un documento recuperado— es candidato a ser reconstruido por un coinquilino.

Para ser honestos: se trata de una fuga de confidencialidad bajo condiciones concretas, no de una ejecución remota de código. El atacante necesita un servicio multiinquilino que comparta la caché más allá de las fronteras de seguridad, una diferencia de tiempo medible y suficiente presupuesto de sondeo. El propio análisis de CacheSolidarity subraya que la explotabilidad depende del hardware, el tamaño del modelo, la carga del sistema y la longitud de las solicitudes: en algunas configuraciones, la diferencia hit/miss es demasiado ruidosa para armarla. Es un factor atenuante real, pero es una propiedad del despliegue, no una garantía.

Defensas

La investigación ha convergido en tres familias de defensa, con una progresión clara en cuán quirúrgicamente cortan.

1. Aislamiento total por usuario. Desactivar por completo el uso compartido de prefijos entre inquilinos; cada usuario (u organización) tiene una caché privada. Cierra el canal pero descarta el beneficio del APC. SafeKV midió que el aislamiento eleva el time-to-first-token hasta ~38 % en modelos grandes; CacheSolidarity reporta costes similares. Eficaz, tosco, caro.
2. Ofuscación temporal. Rellenar o introducir jitter para que aciertos y fallos parezcan iguales. La trampa, expuesta por ambos artículos: al atacante le basta una separación estadística, así que hay que rellenar las respuestas de hit hacia la cola lenta de la distribución de miss, lo que borra casi toda la ganancia de latencia e infla los P95/P99.
3. Aislamiento selectivo. Compartir por defecto, aislar solo lo arriesgado. SafeKV (arXiv 2508.08438) clasifica los prefijos sensibles de forma asíncrona y los mantiene privados, recuperando un rendimiento de hasta 2,66× frente al aislamiento total. CacheSolidarity va más allá: rastrea la propiedad de los prefijos, marca los que varios usuarios reutilizan de forma sospechosa y aísla solo esos, además de un «Activator» que activa el aislamiento solo cuando la diferencia de tiempo es realmente distinguible para el hardware y la carga del momento. Construido sobre vLLM y evaluado en nueve modelos (de 0,5 a 13 mil millones de parámetros), reporta hasta un 70 % más de reutilización de caché y un 30 % menos de latencia que el aislamiento por usuario, con sobrecarga insignificante, y los autores anuncian que será de código abierto.

Para los equipos que operan o compran inferencia de LLM, la lista práctica:

• No ponga secretos en posición de prefijo compartido. Mantenga claves de API, credenciales y datos personales de cada usuario fuera de los system prompts y de la cabecera cacheable de una solicitud.
• Acote la caché a una frontera de confianza. Una caché delimitada por organización o por inquilino elimina el canal entre inquilinos; confirme que su proveedor lo hace así en lugar de compartir globalmente.
• Trate la política de caché como una cuestión de compra. Pregunte a los proveedores si la caché de prefijos o semántica se comparte entre clientes y cuánto persisten las entradas: los proveedores del audit tenían ventanas de retención de minutos a días.
• Si autoaloja, prefiera el aislamiento selectivo. El aislamiento total funciona pero es caro; los enfoques al estilo de SafeKV y CacheSolidarity conservan la aceleración a la vez que cierran el canal.

Estado

Elemento	Referencia	Fecha	Notas
Auditoría empírica de API	arXiv 2502.07776 (Stanford, ICML 2025)	2025-02	Caché compartida entre usuarios en 7 proveedores, incluido OpenAI
Ataque de robo de prompt	NDSS 2025 (Wu et al.)	2025	Reconstrucción de prompt hasta 99 % / 95 % vía caché KV compartida
SafeKV (aislamiento selectivo)	arXiv 2508.08438	2025-08	Clasificación de sensibilidad asíncrona; rendimiento hasta 2,66× vs aislamiento
CacheSolidarity (aislamiento selectivo)	arXiv 2603.10726	2026-03	Marca la reutilización sospechosa; hasta +70 % de reutilización, -30 % de latencia vs aislamiento

El hilo conductor de dos años de investigación: las optimizaciones de velocidad de las que depende el servicio de LLM —el uso compartido de la caché de prefijos y de KV— son también un canal lateral de confidencialidad en cuanto la caché cruza una frontera de confianza. El trabajo de 2026 no le pide elegir entre velocidad y seguridad; demuestra que el canal puede cerrarse aislando los pocos prefijos que importan en lugar de amurallar a cada usuario.