La verdadera brecha de seguridad en asistentes de Azure OpenAI: un filtro y un enfoque más preciso cerraron el riesgo de acceso no autorizado

Un arquitecto de TI italiano descubrió que un asistente de Azure OpenAI respondía con permisos más amplios que los del usuario, exponiendo datos restringidos. La solución no requería una plataforma nueva, sino un filtrado en tiempo de consulta que limita el acceso según los privilegios reales del solicitante.

Egiziago Cioffi, arquitecto de TI y CEO de SynSphere Italia, desarrolló un asistente de correo electrónico basado en Azure OpenAI que automatiza la gestión de cerca del 60% de los emails entrantes. Sin embargo, a pesar de superar con éxito todas las evaluaciones internas de su equipo, Cioffi descubrió durante pruebas adicionales que el asistente devolvía información confidencial que usuarios con bajos privilegios no deberían haber podido consultar directamente en SharePoint.

El asistente, configurado con una tubería personalizada para la recuperación de información (retrieval pipeline) dentro de Azure OpenAI, indexaba y consultaba datos almacenados en SharePoint. Sin embargo, el problema radicaba en que la autorización de acceso a los documentos no se aplicaba correctamente en tiempo real durante la consulta: el sistema respondía con datos basándose en los permisos de la cuenta de indexación —de alto privilegio— y no en los derechos específicos del usuario final. Esta brecha originó que mensajes con contenido sensible fueran accesibles para usuarios no autorizados.

Limitaciones en la implementación de control de acceso en los sistemas de recuperación de información

Desde mayo de 2025, Azure AI Search introdujo un sistema nativo de control de acceso a nivel documental que utiliza tokens basados en Entra para filtrar resultados según los permisos del usuario que hace la consulta. SharePoint incorporó esta sincronización de listas de control de acceso (ACL) en una fase preliminar, y aunque esta funcionalidad ya existe, no está desplegada de forma universal y no cubre rutas de implementación personalizadas, como la utilizada por Cioffi.

Patrocinado

En casos donde la arquitectura de recuperación evita Azure AI Search y emplea cuentas de servicio con privilegios amplios sin realizar un control de acceso en tiempo de consulta, los filtros de permisos desaparecen. Esto facilita que un usuario con menos derechos obtenga acceso a datos restringidos mediante el asistente de IA.

Un problema extendido y documentado a gran escala

Este fallo no es un caso aislado. Un equipo de expertos en seguridad de Straiker llevó a cabo más de 1.700 ataques exitosos a agentes de IA en producción, concluyendo que el 91% de esos ataques terminaron con extracciones silenciosas de datos sin ser detectadas. El informe destaca que no fue necesario usar malware ni movimientos laterales en la red, sino que los agentes devolvieron simplemente toda la información que tenían a su alcance.

Por otro lado, el Instituto de Seguridad en IA del Reino Unido detectó múltiples comportamientos no autorizados en agentes durante una evaluación en condiciones de prueba permisivas, evidenciando la falta de mecanismos efectivos para contener y monitorear desviaciones en tiempo real.

Evaluaciones convencionales no detectan el problema

A pesar de que las pruebas de evaluación suelen medir la exactitud, relevancia y completitud de las respuestas del asistente, no examinan de forma sistemática desde qué perfil de usuario se recuperan los datos. Por tanto, un asistente puede pasar todas las pruebas y, sin embargo, seguir dando acceso a información para la que el usuario no está autorizado.

Cioffi explicó que en su implementación personalizada, que evitaba el sistema nativo de Azure AI Search, no se aplicó la lógica de filtrado de permisos en tiempo de consulta (query-time ACL trimming), lo que permitió la filtración. Según expertos en seguridad, esta es una forma grave de fallo de control de acceso que socava las barreras entre usuarios según sus niveles de permisos.

El filtro que cerró la brecha sin sacrificar la eficacia

La solución desarrollada por Cioffi consistió en incorporar un filtro en la ruta de consulta que verifica los permisos del usuario solicitante antes de presentar cualquier fragmento de contenido al modelo de lenguaje. Este filtro actúa en tiempo real y solo incluye en la ventana de contexto datos a los que el usuario tiene acceso legítimo en SharePoint.

Tras implantar esta medida, el asistente sigue resolviendo alrededor del 60% de los correos de forma automática. El coste es una reducción en el alcance de la información disponible para responder, ya que ciertos contenidos quedan fuera del acceso para usuarios con permisos más limitados, pero garantiza una protección adecuada del perímetro de acceso.

La diferencia entre gobernanza de identidades y control en el momento de recuperación

Recientemente, gigantes de la ciberseguridad como CrowdStrike y Palo Alto Networks han reforzado la gestión de identidades mediante adquisiciones de plataformas especializadas, orientadas a controlar la existencia, alcance y expiración de las credenciales que usan los agentes de IA. Sin embargo, estas soluciones de gobernanza no resuelven el problema específico del control de permisos en el momento en que los agentes recuperan datos en nombre de usuarios con distintos niveles de acceso.

Para atender esta necesidad, los controles deben implementarse en la capa de consulta misma, asegurando que el contenido servido se ajuste a los privilegios reales del solicitante. En este sentido, la solución de Cioffi y la funcionalidad nativa de Azure AI Search comparten el objetivo de proteger ese perímetro.

Un test básico que todos los equipos de seguridad pueden realizar

La recomendación principal para evaluar esta brecha es verificar explícitamente bajo qué permisos opera cada sistema de recuperación de información:

  • Si se usa Azure AI Search con indexación SharePoint y autenticación Entra, hay que corroborar que el filtrado ACL en tiempo de consulta esté activado y funcione correctamente.
  • Si se emplea un pipeline personalizado, conviene realizar una comparación entre las respuestas recibidas con cuentas de diferentes privilegios para detectar accesos indebidos.

Este sencillo test, que requiere dos cuentas con distintos niveles de permisos y una media hora de dedicación, permite detectar si el asistente ofrece información fuera del alcance real del usuario. Es un examen clave que no sustituye a las evaluaciones convencionales, pero que revela un fallo crítico que puede pasar desapercibido.

En resumen, aunque las evaluaciones de respuesta de asistente de IA pueden ser exitosas, la comprobación del cumplimiento estricto de permisos en tiempo de recuperación es esencial para evitar la exposición inadvertida de datos sensibles, y se puede mitigar mediante filtros apropiados sin necesidad de implementar plataformas de identidad adicionales.

Add a Comment

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Patrocinado