Un filtro, no una plataforma: asi se cierra la brecha de permisos en agentes de Azure OpenAI

Egiziago Cioffi, CEO de SynSphere Italia, construyo un agente de Azure OpenAI que resolvia automaticamente alrededor del 60% de los correos entrantes de clientes. Paso todas las evaluaciones internas y las pruebas unitarias. Pero cuando Cioffi lanzo las mismas preguntas desde una cuenta con menos privilegios, las respuestas no coincidian: el agente devolvia contenido de SharePoint que el usuario no podria haber abierto directamente.

El problema no estaba en la calidad de las respuestas, sino en los permisos con los que el agente recuperaba la informacion. Cioffi habia construido un pipeline de recuperacion personalizado que indexaba los documentos con una cuenta de servicio con amplios privilegios y no comprobaba los permisos del usuario en el momento de la consulta. Las evaluaciones que habian pasado solo median si el agente respondia bien, no si respondia con lo que no debia.

Un fallo que se repite

Esto no es un caso aislado. Straiker, una empresa de seguridad, publico en julio un informe que detecto que el 91% de los ataques exitosos contra agentes de productividad terminaban en exfiltracion silenciosa de datos, sin malware ni movimiento lateral. Y el Instituto de Seguridad de IA del Reino Unido (UKASI) documento en agosto 19 acciones no autorizadas de agentes durante una evaluacion con controles desactivados.

La causa de fondo es lo que Adriel Desautels, CEO de Netragard, llama un colapso de las fronteras de autorizacion: si el asistente usa credenciales amplias y no verifica la identidad del usuario en cada consulta, cualquier usuario con permisos bajos puede acceder a datos restringidos. Las evaluaciones tipicas no cubren este aspecto, porque se centran en la precision y no en los permisos.

La solucion: un filtro de permisos en la ruta de recuperacion

Cioffi no necesito una nueva plataforma de identidad. Anadio un filtro que comprueba los permisos del usuario en SharePoint antes de que el modelo vea cualquier fragmento de contenido. Este filtro actua en tiempo de consulta, no en el momento de indexar. Asi, si el usuario no puede abrir un documento en SharePoint, el agente no lo usa para responder.

Con el filtro activo, el agente sigue resolviendo el 60% de los correos, pero ahora solo con contenido que el usuario puede ver legalmente. El coste es que algunas respuestas que antes se basaban en contenido restringido ya no se pueden dar, pero eso es el precio de hacer cumplir la frontera.

Azure AI Search ya ofrece recorte de permisos a nivel de documento de forma nativa desde 2025, pero no cubre todos los caminos. Los pipelines personalizados, como el de Cioffi, quedan fuera. Las plataformas de gobernanza de identidad, como las que estan comprando CrowdStrike y Palo Alto Networks, gestionan los ciclos de vida de las credenciales, pero no controlan los permisos de recuperacion. Se necesitan ambas capas.

Una prueba de treinta minutos

Cualquier equipo de seguridad puede comprobar si sus agentes tienen esta brecha: basta con ejecutar la misma pregunta desde una cuenta con privilegios bajos y otra con privilegios altos, y comparar las respuestas con lo que la cuenta baja puede acceder directamente. Si el agente devuelve mas de lo que la cuenta podria ver, la frontera no se esta aplicando. La prueba cuesta dos cuentas y media hora, y arroja un resultado que ninguna evaluacion de calidad puede replicar.