Su agente puede leer el documento. ¿Y quien pregunta? El patrón de Microsoft para SharePoint lo resuelve
En la arquitectura de referencia de Microsoft, el agente de Foundry infiere con su propia identidad y busca en SharePoint como el usuario. Su prueba con dos usuarios sirve para todo RAG.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Una analista de finanzas, un responsable de RR. HH. y un jefe de proyecto hacen la misma pregunta a un agente interno. En SharePoint, cada uno puede abrir un conjunto distinto de documentos. El agente, que funciona con su propia identidad, puede abrir lo que se le haya concedido. ¿Los permisos de quién deciden la respuesta?
En demasiados sistemas de RAG empresariales (búsqueda en documentos de la empresa antes de responder), la respuesta honesta es: los del agente. La búsqueda se ejecuta con una identidad de servicio y el empleado recibe una respuesta construida con documentos que él nunca habría podido abrir. Ningún prompt lo arregla, y Microsoft lo dice sin rodeos en una arquitectura de referencia publicada el 12 de octubre: “Cambiar el modelo o el prompt no lo arregla. La arquitectura tiene que llevar la identidad del usuario hasta SharePoint.”
Dos identidades en una misma petición
El patrón divide la petición en dos. Un agente alojado en Foundry Agent Service “sigue usando su propia identidad para la inferencia del modelo, mientras que la búsqueda se ejecuta con la identidad del usuario conectado”. Tres piezas llevan la identidad del usuario de extremo a extremo:
- el Foundry toolbox del agente envía un identificador de llamada por petición en cada llamada a herramientas, para que Foundry sepa a qué usuario pertenece;
- una conexión UserEntraToken transmite el token de Microsoft Entra ID de ese usuario a una base de conocimiento de Foundry IQ en Azure AI Search, un paso On-Behalf-Of;
- una fuente de conocimiento remota de SharePoint consulta SharePoint en vivo mediante la Microsoft 365 Copilot Retrieval API como ese usuario, limitada a los sitios elegidos. “Nada se copia a un índice.”
| Paso | Se ejecuta como | Por qué |
|---|---|---|
| Inferencia del modelo | El agente | Usa el acceso propio del agente al modelo |
| Enrutado de la llamada a herramienta | El agente, con el identificador del usuario | Vincula cada llamada a un solo usuario |
| Consulta a la base de conocimiento | El usuario | Token de Entra transmitido en nombre del usuario |
| Búsqueda en SharePoint | El usuario | SharePoint aplica su propio filtrado de permisos |
El diseño importa tanto por lo que elimina como por lo que añade. No hay un índice aparte que proteger, ni una copia de los permisos de los documentos que mantener sincronizada, ni una cuenta de servicio capaz de leer todos los sitios. SharePoint sigue siendo la autoridad sobre quién puede abrir qué, que es donde debe estar esa decisión.
Los errores son la parte útil
El texto de Microsoft es más valioso donde describe lo que falló en las pruebas:
- Una managed identity en la conexión falla. La búsqueda se ejecuta entonces como el agente, SharePoint no tiene usuario contra el que comprobar y rechaza la petición.
- Un cliente MCP propio puede mezclar usuarios. Un cliente hecho a mano que solo adjuntaba la credencial del agente perdía el identificador de llamada por petición; en las pruebas de Microsoft con otra herramienta OAuth, “todos los usuarios acabaron ejecutándose como quien dio su consentimiento primero”. Es una exposición de datos entre usuarios causada por un detalle de integración, no por el modelo.
- Cada usuario necesita un rol en el servicio de búsqueda, porque ahora el token de cada uno llega a Azure AI Search. Asígnelo a un grupo, o la búsqueda fallará para personas que sí pueden acceder al agente.
- Un proxy On-Behalf-Of propio puede funcionar, pero entonces el equipo asume su alojamiento, sus secretos, la validación de tokens y los parches.
El segundo error merece un lugar en toda revisión de seguridad de un agente que llama a herramientas en nombre de usuarios. La propagación de identidad no es una propiedad del protocolo; es una propiedad del cliente que lo implementa. Es la misma lección de nuestro análisis sobre por qué el MCP empresarial empieza por la identidad y sobre las tres identidades de todo agente.
Límites antes de planificar sobre esto
Es una implementación de referencia, no un producto nuevo. Las fuentes de conocimiento remotas de SharePoint en Foundry IQ estaban en versión preliminar cuando se escribió el texto. Los usuarios finales necesitan una licencia de Microsoft 365 Copilot, un rol de lectura en el servicio de búsqueda y acceso al agente, y el servicio de búsqueda debe estar en una región que admita agentic retrieval, en el mismo tenant de Entra que Microsoft 365. Microsoft sitúa Work IQ, que también busca como el usuario, para agentes que necesitan el contexto más amplio de Microsoft 365 de una persona; este patrón es para agentes que deben quedarse dentro de sitios concretos de SharePoint.
La prueba que conviene conservar
El consejo final de Microsoft es el que hay que copiar en la lista de verificación de cada versión: “Una buena respuesta no demuestra que se hayan usado los permisos correctos.” Elija un documento que solo uno de dos usuarios de prueba pueda abrir. El usuario A debe recibir una respuesta con cita; al usuario B se le debe decir que las fuentes no contienen la respuesta. Haga la prueba en conversaciones separadas y repítala tras cada cambio de permisos. Las instrucciones del agente también ayudan: pídale que diga cuándo las herramientas no devuelven nada relevante en lugar de adivinar, para que un límite de permisos aparezca como “no lo sé” y no como una respuesta inventada.
Un sistema de RAG que pasa esta prueba aplica los permisos de la empresa. Uno que nunca la ha hecho solo lo supone.