Cómo evitar que un RAG muestre documentos de otro tenant
Revisa permisos antes de recuperar contenido y prueba filtraciones en fragmentos, cachés, citas y enlaces de un RAG con varios tenants.
Dos clientes hacen la misma pregunta a un asistente documental. La respuesta del segundo incluye una condición del contrato del primero. Puede que la búsqueda haya aplicado bien sus filtros y que la filtración provenga de una caché compartida por texto de consulta.
Es un ejemplo hipotético, pero plantea una prueba concreta. La separación entre tenants, los grupos de datos y usuarios de cada cliente, debe mantenerse en todos los pasos que puedan devolver información. Una comprobación al entrar en el chat deja fuera la recuperación, las respuestas guardadas y la apertura de las fuentes.
Sigue el documento hasta cada salida
Dibuja el recorrido de un archivo desde la ingesta. Identifica dónde se guarda el original y qué copias aparecen después: fragmentos, índice, respuestas y trazas. Incluye los servicios externos que reciben texto, como un reranker o el proveedor del modelo.
En cada paso, anota qué identidad ejecuta la operación y dónde se comprueba su acceso. Si un documento prohibido llega a un modelo externo y se oculta después en la interfaz, el control llegó tarde. Los nombres de archivos y sus títulos también pueden revelar información aunque el cuerpo se omita.
OWASP incluye la filtración entre contextos y los permisos insuficientes entre los riesgos de los sistemas vectoriales. Conviene convertir ese riesgo en casos de prueba del producto que estás construyendo.
Obtén la identidad de una sesión validada
El servidor debe establecer quién pregunta, a qué tenant pertenece y qué documentos puede consultar. La pregunta del usuario, los argumentos de una herramienta o un campo enviado por el navegador no deben decidir esa identidad por sí solos.
Un usuario puede tener acceso a una parte de los documentos de su empresa. Por tanto, filtrar únicamente por tenant resulta insuficiente cuando hay grupos privados o permisos por archivo. Conserva esa información durante la ingesta y comprueba cómo se actualiza al cambiar la pertenencia a un grupo.
Separa las credenciales de ingesta de las usadas para consultar. Una tarea administrativa puede necesitar acceso amplio para indexar archivos; reutilizar esa misma identidad para responder a usuarios puede eliminar la separación que esperabas obtener de la base de datos.
Restringe antes de enviar contenido al modelo
Aplica los permisos en el sistema que selecciona los candidatos de búsqueda. Si la herramienta devuelve identificadores que después se resuelven a texto, valida también esa lectura antes de entregar contenido a otro componente.
En PostgreSQL, revisa la política y el rol efectivo con el que se ejecuta la consulta. La documentación de seguridad por filas indica que los superusuarios y los roles con BYPASSRLS omiten las políticas; los propietarios de tablas también suelen hacerlo. Tener RLS configurado no demuestra que la conexión de la aplicación esté sometida a él.
Comprueba el comportamiento con el rol de producción y con usuarios de prueba restringidos. Cuando el servicio que resuelve permisos no está disponible, define una salida que no entregue contenido privado basándose en una suposición de acceso.
Incluye cachés y citas en la política
Una caché indexada solo por pregunta puede devolver una respuesta creada con más permisos. Decide si la reutilización se hará por usuario o por un ámbito de acceso equivalente y verificable. Incluye la versión de los documentos y una forma de invalidar resultados cuando cambien los permisos.
Las citas necesitan la misma atención. Al abrir una fuente, el servidor debe comprobar de nuevo el acceso. Si utilizas enlaces firmados, documenta cuánto tiempo pueden seguir funcionando y qué ocurre tras una revocación. Una URL larga o difícil de adivinar no reemplaza ese control.
Limita las copias de contenido en logs y paneles de soporte. Una herramienta interna para depurar respuestas también necesita permisos; de lo contrario, puede convertirse en otra forma de consultar documentos de otros clientes.
Prueba la retirada de acceso
Construye dos tenants sintéticos con documentos que contengan frases distintas. Ejecuta la misma pregunta desde ambos y examina fragmentos, respuesta y enlaces. Intenta abrir una cita con la otra identidad.
Después, permite una consulta y revoca el permiso antes de repetirla. Reutiliza una sesión existente y una consulta previamente cacheada. El resultado debe ajustarse a la revocación, aunque todavía queden copias en otros componentes.
La guía de recuperación de OpenAI advierte que eliminar un archivo del vector store puede tardar en reflejarse en las búsquedas. Si el producto exige retirada inmediata de acceso, necesita un control de autorización que no dependa únicamente de esa eliminación.
Añade casos con permisos incompletos y con una ingesta interrumpida. Guarda el resultado esperado y el observado en cada prueba. Una búsqueda que casualmente no encontró el documento privado no acredita que se haya denegado su acceso.
Qué revisar antes de ampliar usuarios
La entrega técnica debería incluir un mapa de copias, reglas de acceso por operación y pruebas de revocación repetibles. Haz visible qué casos quedan fuera, especialmente si el sistema conserva respuestas exportadas o enlaces que ya se entregaron.
La consultoría RAG puede revisar estos permisos junto con la recuperación. La auditoría técnica de IA explica cómo convertir un fallo en un entregable comprobable.
Describe cómo se separan tus clientes y quién puede leer cada documento. Con una matriz de acceso y datos de prueba se puede delimitar una revisión de filtraciones antes de ampliar el uso del asistente.
Servicio relacionado
RAG y búsqueda
Conectar respuestas con documentos y fuentes verificables.