Egiziago Cioffi es arquitecto empresarial y de TI y director ejecutivo de SynSphere Italia, un socio de Microsoft con sede en Milán. Él mismo creó un agente. Escribió el trabajo de indexación, configuró el proceso de recuperación de Azure OpenAI, lo conectó a SharePoint y observó cómo pasaba todas las evaluaciones que realizaba su equipo.
Su asistente de correo electrónico Azure OpenAI resuelve automáticamente alrededor del 60% del correo electrónico entrante de los clientes, dijo Cioffi a VentureBeat en respuestas escritas a las preguntas de nuestra entrevista. Los puntajes de la evaluación fueron limpios y las pruebas unitarias fueron aprobadas. Ninguno de ellos hizo la pregunta que importaba.
Cioffi administró una cuenta de bajo privilegio frente a las mismas preguntas que una cuenta de alto privilegio ya le había planteado al asistente. Las salidas no coincidían. El asistente devolvió contenido de SharePoint que el usuario solicitante no podría haber abierto en SharePoint por sí solo. Los registros contaban una historia diferente a la de las puntuaciones de evaluación.
Los registros de recuperación de Cioffi son la evidencia de este fallo de producción específico. Lo que sigue son datos independientes que muestran que la clase de falla no está aislada.
En muchas implementaciones de RAG de producción, el agente responde con los permisos del indexador, no con los del solicitante.
Azure AI Search ya está disponible recorte de ACL nativo a nivel de documento a través de tokens basados en Entra desde la vista previa en mayo de 2025, y la sincronización ACL de SharePoint siguió en una vista previa posterior. La capacidad existe; sin embargo, no existe en todos los lugares donde es necesario.
La vista previa de ACL de SharePoint ahora puede ingerir metadatos de grupos de sitios a través del prefijo spg: en la API de vista previa 2026-05-01. Sin embargo, solo los principios respaldados por Entra están documentados como aplicados de manera confiable en el momento de la consulta. La vista previa se ejecuta a través de la API REST y los SDK de vista previa y no cubre todas las rutas de implementación del agente. Azure OpenAI On Your Data, por ejemplo, admite el acceso a nivel de documento a través de los filtros de seguridad de Azure AI Search, pero la propia documentación de Microsoft establece que si el campo de grupos permitidos no está asignado, el acceso a nivel de documento está deshabilitado.
Se trata de un valor predeterminado de apertura fallida en una ruta propia. Las canalizaciones RAG personalizadas que omiten por completo Azure AI Search aún se indexan en una cuenta de servicio con amplios privilegios sin verificación de derechos en el momento de la consulta, a menos que el desarrollador cree una. La implementación de Cioffi tomó el camino de la canalización personalizada.
Entre los agentes de producción a escala, el 91 % de los ataques exitosos terminaron en una filtración silenciosa de datos.
del delantero El equipo rojo realizó más de 1.700 intentos exitosos de explotación contra agentes de producción y publicó los resultados en su Informe inaugural de amenazas de STAR Labs en julio. La cifra del 91% de su investigación mide todos los ataques exitosos a agentes de productividad que terminaron en la filtración de datos sin ser detectados. Es una medida de lo que sucedió después de que un exploit tuvo éxito, no una medida de cuántas implementaciones no logran hacer cumplir específicamente los derechos de tiempo de recuperación.
Entre los agentes de productividad incluidos en el alcance, el 91% de los ataques exitosos terminaron en una filtración silenciosa de datos, y el informe señala que no se requirió malware. Tampoco hubo movimiento lateral a través de la red. El agente devolvió todos los datos que pudo alcanzar. El informe de Straiker no detalla cuáles de esos éxitos se deben específicamente a fallas de derechos versus inyección rápida, abuso de herramientas u otras clases de ataques.
Trabajando de forma independiente, el Instituto de Seguridad de IA del Reino Unido documentó 19 acciones de agentes no autorizados en una evaluación cibernética del 25 al 28 de julio. El UKASI publicó su informe de incidente el 4 de agosto de este año. La evaluación se realizó deliberadamente con los clasificadores cibernéticos desactivados y el acceso a Internet habilitado. Lo que demuestra el informe UKASI es que agentes actúan fuera del alcance previsto por sus implementadores, en un entorno de prueba permisivo, sin ningún mecanismo confiable para detectar la desviación antes de que cause daños. Es una falla de contención, no una falla de derecho de recuperación, y la superposición con el incidente de Cioffi es la ausencia compartida de una verificación del alcance del tiempo de ejecución en lugar de un mecanismo idéntico.
Por qué las evaluaciones omiten esto y por qué la solución nativa no llegó a la implementación de Cioffi
Las evaluaciones que realizó el equipo de Cioffi fueron diseñadas para comprobar si el agente responde correctamente. Verifican la precisión de los hechos, la relevancia y la finalización de las tareas. No preguntan qué permisos utiliza el canal de recuperación cuando recupera el material fuente, porque esa pregunta no está en el marco de evaluación.
Azure AI Search actualmente envía la verificación de derechos de tiempo de recuperación a nivel de plataforma. El recorte de ACL en el momento de la consulta valida el token Entra de la persona que llama, extrae las reclamaciones de usuarios y grupos y devuelve solo documentos cuyos metadatos de permisos sincronizados otorgan acceso a la persona que llama. Para las implementaciones que usan Azure AI Search con el indexador de SharePoint y las entidades principales respaldadas por Entra, el control existe de forma nativa. El despliegue de Cioffi no siguió este camino. Su canal de recuperación personalizado de Azure OpenAI pasó por alto la capa de recorte nativa, que es la forma en que la brecha sobrevivió a cada evaluación que realizó su equipo.
Desde el punto de vista del atacante, se trata de un control de acceso roto. Adriel Desautels, fundador y director ejecutivo de Netragard, dijo a VentureBeat en respuestas escritas que el fracaso se reduce a un colapso estructural de los límites de autorización. «Si las credenciales del NHI normalmente tienen una autorización amplia y pueden leer datos de alto privilegio, entonces se almacenan en su índice», escribió Desautels. «Si una aplicación no exige la recuperación consciente de la identidad, entonces un usuario ‘normal’ con permisos más bajos puede consultar la aplicación y acceder a datos que de otro modo estarían restringidos. Esto colapsa los límites de autorización hasta el nivel de privilegio más bajo con capacidad de búsqueda».
Esa brecha es lo que expuso la prueba de bajos privilegios de Cioffi. La ventana contextual del asistente contenía contenido de SharePoint que la cuenta con pocos privilegios no podría haber recuperado directamente a través de SharePoint. La evaluación había pasado. El límite del permiso de recuperación no se había aplicado.
Desautels sitúa el punto ciego de la evaluación en términos operativos. «Los agentes tienden a ejecutar una identidad no humana única, duradera y que posee una amplia gama de permisos que podrían necesitar para cualquier tarea que se les solicite completar», escribió. «Las evaluaciones tampoco suelen cubrir indicaciones, resultados, transcripciones, memoria y registros donde se pueda leer o secuestrar a través de contenido inyectado. Esa falta de coincidencia es en lo que se equivocan la mayoría de las evaluaciones actuales».
El filtro de Cioffi redujo el alcance de recuperación del asistente. Todavía resuelve aproximadamente el 60% de los correos electrónicos.
La solución de Cioffi no requirió una nueva plataforma de identidad. Movió la decisión de derechos a la ruta de recuperación misma, agregando un filtro de ruta de consulta que verifica los permisos de SharePoint del usuario solicitante antes de que el modelo vea un fragmento. El filtro se ejecuta en el momento de la consulta, no en el momento del índice. El contenido que el usuario no pudo abrir en SharePoint no ingresa a la ventana contextual del modelo.
El control redujo lo que el asistente podía alcanzar. El asistente todavía resuelve automáticamente aproximadamente el 60% del correo electrónico entrante con el filtro activo, dijo Cioffi a VentureBeat. No proporcionó una cifra de resolución automática antes del filtro para comparar. La compensación cualitativa que describió es que parte del contenido que el asistente usaba anteriormente para responder preguntas ahora se excluye porque los permisos del usuario solicitante no lo alcanzan. Ése es el precio de hacer cumplir la frontera.
La pregunta de si el filtrado de derechos en el momento de la recuperación vale la pena para el alcance de recuperación reducido no tiene una respuesta única. Depende de la sensibilidad del contenido indexado, la variación de permisos entre la población de usuarios y si la implementación puede tolerar consultas sin respuesta cuando el filtro bloquea una porción que el modelo necesita. Lo que demuestra el incidente de Cioffi es que existe una brecha en los canales personalizados de Azure OpenAI, que las evaluaciones de calidad de las respuestas no la detectan y que un filtro de ruta de consulta la cierra en una compensación que el creador puede describir.
Las plataformas de gobierno de la identidad abordan una capa diferente. Se necesitan ambos controles.
CrowdStrike anunció su Adquisición de SGNL por 740 millones de dólares el 8 de enero de 2026 y cerró el trato el 20 de febrero de 2026. Palo Alto Networks anunció su $Adquisición de CyberArk por 25 mil millones en julio de 2025 y cerró el acuerdo el 11 de febrero de 2026. Ambos acuerdos se cerraron el mismo mes, estableciendo la seguridad de la identidad como pilar de la plataforma en dos de los proveedores de seguridad más grandes del mundo.
Las plataformas de gobierno de identidad se centran en qué cuentas de servicio existen, a qué pueden acceder y cuándo caducan sus tokens. Gobiernan el ciclo de vida de las credenciales que impulsan a los agentes de IA. Esa capa importa. Lo que no rige es el límite del permiso de recuperación. Ese es el momento en que una cuenta de servicio con el alcance correcto recupera contenido en nombre de un usuario que tiene menos permisos que los que tiene el trabajo de indexación.
Todas las credenciales de la cadena son legítimas. La cuenta de servicio está limpia y administrada adecuadamente. La base de conocimientos está correctamente indexada. Un usuario con pocos privilegios consulta al asistente y este responde desde el alcance indexado completo. Nada indica la recuperación porque no se hizo mal uso de ninguna credencial.
El filtro de Cioffi es un control específicamente en la capa límite del permiso de recuperación. El recorte de ACL nativo de Azure AI Search aborda la misma capa para las implementaciones que la usan. Ninguno de los dos reemplaza la gobernanza de la identidad. Una implementación de producción que desee cerrar tanto la brecha del ciclo de vida de las credenciales como la brecha de los derechos del tiempo de recuperación necesita controles en ambas capas.
Una pregunta y una prueba que cualquier equipo de seguridad puede realizar
Pregunte qué permisos utiliza cada sistema de recuperación de IA cuando recupera contenido.
Si la implementación usa Azure AI Search con el indexador de SharePoint y las entidades principales respaldadas por Entra, verifique que el recorte de ACL en el momento de la consulta esté habilitado y que la población de usuarios no dependa de los grupos de sitios de SharePoint. Si la implementación utiliza una canalización de recuperación personalizada, es posible que la verificación de derechos no exista en absoluto.
Comience demostrando la respuesta desde una cuenta con pocos privilegios. Ejecute la misma pregunta que una cuenta con altos privilegios ya le hizo al asistente. Compare los resultados con los que la cuenta con pocos privilegios puede acceder directamente a través del sistema subyacente.
Desautels confirmó que aquí comenzaría un equipo rojo. «La primera prueba probablemente apuntaría a las brechas entre los datos y las instrucciones, y las brechas entre la identidad del usuario y las propias credenciales del asistente», escribió. «Intentaríamos colocar una instrucción dentro del contenido que creemos que el asistente ingerirá como datos. Haríamos que ese contenido dirija una acción privilegiada y de efecto secundario que el usuario atacante no está autorizado a realizar». Un resultado fallido, según la evaluación de Desautels, es «la ejecución exitosa o incluso parcial de nuestros comandos inyectados».
Si el asistente devuelve más de lo que permitiría el acceso directo de la cuenta, el límite del permiso de recuperación no se aplica en el momento de la consulta. Esa prueba cuesta dos cuentas y treinta minutos. Produce un resultado que una puntuación de evaluación no puede replicar.
Cioffi creó el agente en una canalización personalizada de Azure OpenAI que omitió la capa de recorte de ACL nativa. Realizó todas las evaluaciones que tuvo su equipo. Encontró el espacio en sus propios registros después de que todos pasaron. La evaluación comprobó si el agente respondió correctamente. No probó qué permisos estaba usando el agente. Ejecute la comparación de dos cuentas antes de que se active la siguiente implementación. Treinta minutos te dicen de qué lado de la línea estás.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
