Resumen Técnico: Protección del Agente en Entornos Empresariales Multitenants

1. Declaración del Problema

El documento aborda una brecha de seguridad fundamental en el despliegue de sistemas de Generación Aumentada por Recuperación (RAG) y sistemas de IA agéntica dentro de entornos empresariales. Mientras que los tratamientos académicos y las APIs orientadas al consumidor a menudo asumen acceso a datos de un solo tenant y homogéneo, los despliegues empresariales del mundo real involucran múltiples tenants compartiendo infraestructura con datos heterogéneos, cumplimiento regulatorio estricto y requisitos de control de acceso granular.

El problema central identificado es la brecha de relevancia-autorización. Los sistemas de recuperación existentes (vectoriales, por palabras clave o híbridos) optimizan la relevancia semántica o la coincidencia de palabras clave, pero carecen de mecanismos nativos para hacer cumplir las políticas de autorización. En consecuencia, una consulta de un tenant puede recuperar y exponer datos confidenciales pertenecientes a otro tenant si esos datos obtienen la puntuación más alta en las métricas de relevancia. Esta brecha se ve exacerbada en sistemas agénticos donde:

• La divulgación mediada por herramientas ocurre cuando los agentes invocan herramientas con credenciales amplias en lugar de la autorización del usuario final.
• La acumulación de contexto permite que las conversaciones de múltiples turnos filtren datos entre tenants sin una revalidación de política por turno.
• La orquestación del lado del cliente distribuye la lógica crítica de seguridad a clientes potencialmente no confiables, permitiendo eludir las verificaciones de autorización.

Los enfoques estándar de aislamiento, como replicar toda la pila agéntica (almacenamientos vectoriales, puntos finales de inferencia) por tenant, se consideran prohibitivos en costos y operativamente fragmentados.

2. Metodología y Arquitectura

Los autores proponen una arquitectura de aislamiento en capas aplicada mediante orquestación del lado del servidor para proteger los flujos de datos y control de la IA agéntica. Este enfoque se implementa en OGX (Open GenAI Stack), un framework de código abierto y neutral para proveedores que proporciona APIs compatibles con OpenAI.

2.1 Aislamiento en Capas (Ruta de Datos)

La arquitectura protege el flujo de datos a través de tres capas distintas dentro del límite de confianza del servidor:

1. Ingesta Consciente de Políticas: Los metadatos del tenant (propiedad, atributos) se adjuntan a los documentos en el momento de la ingesta. Esto asegura que cada fragmento de documento herede atributos de tenant consistentes, evitando el acoplamiento accidental entre tenants.
2. Control de Acceso en la Recuperación: Se aplica un mecanismo de aplicación de dos niveles:
   • Pre-búsqueda: Se evalúa el Control de Acceso Basado en Atributos (ABAC) antes de que comience la búsqueda.
   • Post-recuperación: Se aplica filtrado a nivel de fragmento después de la recuperación.
   • El sistema soporta el empuje de predicados (donde el backend vectorial aplica filtros nativamente durante la búsqueda) para mantener una recuperación perfecta a escala. Si el empuje no está disponible, el filtrado post-recuperación asegura la seguridad (cero filtración) pero puede degradar la recuperación en corpus grandes.
3. Inferencia Compartida: La capa de inferencia del Modelo de Lenguaje Grande (LLM) se comparte entre todos los tenants. Dado que las Capas 1 y 2 aseguran que solo los documentos autorizados entren en el contexto del prompt, el modelo en sí no requiere aislamiento por tenant, reduciendo los costos de infraestructura de $O(N \cdot M)$ a $O(M)$.

2.2 Orquestación del Lado del Servidor (Ruta de Control)

Para abordar los riesgos de elusión del lado del cliente, los autores abogan por la orquestación del lado del servidor del bucle de inferencia $\to$ herramienta $\to$ inferencia.

• Límite de Confianza: Todas las operaciones críticas de seguridad (autorización de ejecución de herramientas, aislamiento de estado, aplicación de políticas) se centralizan dentro del proceso del servidor.
• Compensaciones: Si bien esto introduce latencia para las llamadas a herramientas en comparación con la ejecución local, evita que clientes comprometidos salten filtros o manipulen las invocaciones de herramientas.
• Enfoque Híbrido: La arquitectura permite que los frameworks del lado del cliente mantengan el control sobre la composición del agente y las operaciones sensibles a la latencia, mientras que el servidor hace cumplir las invariantes de seguridad.

3. Contribuciones Clave

El documento hace cuatro contribuciones principales:

1. Formalización de la Brecha de Relevancia-Autorización: Los autores definen matemáticamente por qué la clasificación por relevancia por sí sola es insuficiente para el aislamiento y proporcionan evidencia empírica de que la recuperación sin control filtra datos entre tenants en el 98–100% de las sondas.
2. Arquitectura de Aislamiento en Capas: Un diseño propuesto que combina ingesta consciente de políticas, control de acceso en tiempo de recuperación e inferencia compartida, con la orquestación del lado del servidor como capa de aplicación.
3. Validación Empírica: Una evaluación de seis experimentos que mide la seguridad (filtración, resistencia a la inyección de prompts), el rendimiento del sistema (latencia, rendimiento) y la calidad de la recuperación a través de una matriz $2 \times 2$ de modos de orquestación (cliente vs. servidor) y control de acceso en la recuperación (sin control vs. controlado por ABAC).
4. Implementación de Código Abierto: La arquitectura se implementa en OGX, un framework neutral para proveedores que ofrece APIs compatibles con OpenAI (incluida una API de Respuestas para orquestación de múltiples turnos) y un Operador de Kubernetes para el despliegue.

4. Resultados Experimentales

La evaluación utilizó un banco de pruebas sintético con tres tenants (finanzas, ingeniería, legal) y 300 documentos.

• Seguridad (Filtración entre Tenants):

  • Configuraciones sin Control: Independientemente del modo de orquestación, la recuperación sin control resultó en una filtración del 98–100% de datos entre tenants.
  • Configuraciones con Control: El control de acceso ABAC eliminó por completo la filtración entre tenants (0% de filtración), logrando el objetivo de seguridad (G1).
  • Inyección de Prompts: Bajo configuraciones con control, se bloquearon las 90 sondas de inyección de prompts (0% de filtración). En configuraciones sin control, el 62–80% de las sondas recuperaron con éxito datos no autorizados.
  • Aplicación: El estudio destaca que, aunque el control del lado del cliente (Configuración B) puede lograr 0% de filtración, depende de la integridad del cliente. La orquestación del lado del servidor (Configuración D) proporciona la garantía de aplicación necesaria (G2) al mover la lógica dentro del límite de confianza.

• Rendimiento:

  • Latencia: El control de acceso en la recuperación añadió aproximadamente 19ms a la ruta de búsqueda (ida y vuelta de autenticación + evaluación de políticas + búsqueda), lo cual es despreciable en comparación con los tiempos de inferencia (segundos). La orquestación del lado del servidor añadió ~3s de latencia total debido a las idas y vueltas, pero soporta transmisión para reducir el tiempo hasta el primer token.
  • Rendimiento: El control no degradó el rendimiento. El rendimiento escaló linealmente con la concurrencia. La orquestación del lado del cliente logró ~2 veces las consultas por segundo (QPS) de la orquestación del lado del servidor a alta concurrencia debido a rutas de solicitud más cortas.

• Calidad de Recuperación:

  • El filtrado a nivel de fragmento mejoró la Precisión@5 en 2.2x (de 0.200 a 0.433) al filtrar el ruido entre tenants.
  • Empuje de Predicados: Los backends que soportan empuje de predicados mantuvieron Recuperación@5 = 1.0 a través de todos los tamaños de corpus. Los backends sin empuje (usando filtrado post-recuperación) vieron degradarse significativamente la recuperación (de 1.0 a 0.002) a medida que el tamaño del corpus aumentaba a 50k fragmentos, aunque las garantías de seguridad permanecieron intactas.

5. Significancia y Alcance

El documento afirma que este trabajo es el primero en abordar la intersección del diseño estandarizado de APIs agénticas, la orquestación del lado del servidor y el aislamiento multitenant en infraestructura compartida.

• Significancia: La arquitectura demuestra que se puede lograr simultáneamente multitenancy seguro, APIs compatibles con OpenAI neutrales para proveedores y capacidades de agentes autónomos sin duplicación de infraestructura por tenant. Cambia el paradigma de seguridad de "basado en relevancia" a recuperación "basada en políticas".
• Alcance y Limitaciones:
  • La solución está diseñada para entornos empresariales multitenants; es innecesaria para despliegues de un solo tenant o datos públicos.
  • La arquitectura protege la construcción de contexto pero no la memoria paramétrica; los modelos aún pueden generar información absorbida durante el preentrenamiento.
  • El límite de confianza es el proceso del servidor; la arquitectura no protege contra procesos del servidor comprometidos, operadores internos o ataques de canal lateral.
  • Las herramientas de función del lado del cliente permanecen fuera del límite de confianza del servidor, aunque OGX mitiga esto mediante la clasificación explícita de herramientas.

Los autores concluyen que, si bien la orquestación del lado del cliente ofrece menor latencia para entornos confiables, la orquestación del lado del servidor con control de acceso ABAC es esencial para escenarios empresariales que requieren aislamiento estricto y cumplimiento.