Detección del envenenamiento de vectores: cómo detectar la corrupción de la recuperación antes de que actúen los agentes
Un almacén de vectores envenenado no solo implica una mala calidad de búsqueda. Es una corrupción persistente de la memoria. Una vez que los fragmentos maliciosos dominan la recuperación, un agente puede empezar a tomar malas decisiones mucho después de que se haya olvidado el evento de ingesta original.
Por qué esto importa
La mayoría de los equipos siguen hablando de la inyección de prompts como si cada ataque comenzara y terminara dentro de una única interacción con el modelo. Esa visión es demasiado limitada. Si embeddings maliciosos llegan a la capa de recuperación, el sistema puede seguir proporcionando contexto controlado por el atacante una y otra vez. El radio de impacto es mayor porque el estado malicioso se vuelve persistente.
Por eso, el envenenamiento del almacén de vectores pertenece a la misma familia de amenazas que el envenenamiento de memoria. La capa de recuperación es memoria, solo que en formato denso en lugar de markdown o JSON.
El detector más rápido que sigue siendo fiable
La versión económica también es el punto de partida correcto. Supervisa dos señales explicables antes de promover un lote a la memoria de producción: deriva del centroide y anomalías de centralidad.
- Deriva del centroide: ¿el nuevo lote de embeddings se alejó del corpus de confianza más de lo normal?
- Centralidad: ¿un conjunto reducido de fragmentos se convirtió repentinamente en vecinos más cercanos universales y empezó a dominar la recuperación?
Estas dos comprobaciones detectan los casos problemáticos más comunes sin fingir que necesitas reentrenar el modelo o desplegar una enorme plataforma de detección de anomalías desde el primer día.
Qué detecta la deriva del centroide
Si se supone que un espacio de nombres contiene material específico y de confianza, un lote malicioso o irrelevante no debería desplazar demasiado el centro de esa nube de embeddings. Los desplazamientos grandes suelen indicar una de estas tres situaciones: se insertaron en masa fragmentos controlados por un atacante, se generaron embeddings de contenido basura aleatorio o el espacio de nombres incorporó discretamente una fuente que no corresponde.
Esta señal se vuelve más sólida cuando se compara la magnitud del desplazamiento con el radio normal del corpus de confianza, en lugar de usar un umbral de distancia sin procesar. La cuestión no es la elegancia matemática, sino preguntarse si este lote parece pertenecer al conjunto.
Qué detecta la centralidad
La centralidad es el equivalente, en la recuperación, a un secuestro de la atención. Si un pequeño número de fragmentos empieza a aparecer repentinamente como vecino de todo lo demás, algo va mal. A veces se trata de duplicación. Otras veces, de contenido envenenado y parafraseado, diseñado para parecer ampliamente relevante. En cualquier caso, significa que el almacén se está sesgando para que el mismo material controlado por el atacante siga imponiéndose en la recuperación.
Ese es exactamente el tipo de fallo que debería preocupar a los defensores, porque el modelo puede parecer normal mientras la capa de selección de contexto ya está comprometida.
La regla operativa más importante
No permitas que los lotes sospechosos definan su propia línea base. Mantén líneas base móviles de confianza para cada espacio de nombres, restablécelas cuando cambie el modelo de embeddings y actualízalas únicamente con lotes aprobados o de riesgo sistemáticamente bajo. De lo contrario, el almacén aprende poco a poco que el envenenamiento es normal.
- Registra el identificador del lote, el espacio de nombres, la combinación de fuentes, el modelo de embeddings, las métricas de deriva, las métricas de centralidad y la decisión final.
- Admite solo tres resultados:
permitir,poner en cuarentenaobloquear. - Genera una alerta cuando un espacio de nombres reciba repetidamente lotes con advertencias o un único lote claramente malicioso.
Cómo es una implementación adecuada
Una ruta de ingesta sensata mide las señales de anomalía antes de confirmar los cambios, mantiene un registro de auditoría al que solo se pueden añadir entradas y ofrece a los operadores una vía clara para anular la decisión cuando ejecutan intencionadamente cargas históricas o migraciones de modelos. Las comprobaciones estáticas pueden verificar que esas defensas existen, pero la medición en tiempo de ejecución debe realizarse cerca de la ruta de escritura de vectores.
Lo importante es mantener la explicabilidad. Los equipos de seguridad necesitan saber por qué se bloqueó un lote, no solo que una caja negra lo rechazó.
Conclusión de KENSAI
La verdadera lección es sencilla, en el buen sentido. Si tu capa de recuperación puede modificarse silenciosamente, la memoria de tu agente también puede modificarse silenciosamente. Empieza con cálculos sencillos, registros sólidos y controles de cuarentena. Los modelos sofisticados pueden esperar.
Prueba los controles de memoria antes de que el contexto envenenado se vuelva normal
KENSAI ayuda a los equipos a revisar las superficies de memoria de los agentes, las defensas de recuperación y los controles de aprobación antes de que la corrupción persistente del contexto se convierta en un incidente de producción.
KENSAIKENSAI — Inteligencia de seguridad impulsada por IA