Un agente empresarial puede atender a muchas personas desde un mismo endpoint. Para que eso sea seguro, hay que distinguir la identidad del usuario, su conversación y el espacio donde se conservan sus archivos. Separar el historial no garantiza separar los documentos cuando varias personas comparten el mismo entorno de ejecución.
Roger Barreto y Tao Chen explican estos controles en una guía de Microsoft publicada el 22 de septiembre de 2026. Incluye ejemplos para Microsoft Agent Framework en .NET y Python. El servicio Foundry Hosted Agents está disponible generalmente, mientras que sus paquetes de integración continúan en prerrelease.
Tres conceptos que conviene separar
| Concepto | Función |
|---|---|
| Identidad | Representa al usuario que realiza la solicitud. |
| Conversación | Conserva mensajes, llamadas a herramientas y respuestas. |
| Sesión alojada | Identifica el entorno de ejecución y los archivos persistentes mediante agent_session_id. |
El framework permite utilizar sesiones creadas por Foundry o asociar una sesión previamente creada por la aplicación. Fuente: guía de aislamiento de Microsoft Agent Framework.
Autenticación y delegación
En el acceso directo, Foundry identifica al llamador mediante su token de Microsoft Entra. Cuando una aplicación autentica a sus propios usuarios, un servicio intermediario de confianza puede enviar una identidad delegada mediante x-ms-user-identity.
La identidad de ese servicio necesita un rol personalizado con el permiso Microsoft.CognitiveServices/accounts/AIServices/agents/endpoints/UserIdentityImpersonation/action. La documentación indica que no está incluido en los roles integrados. El valor del encabezado debe derivarse de la identidad autenticada en el servidor; aceptarlo directamente del navegador permitiría suplantaciones.
La aplicación también debe controlar la asignación de sesiones: la delegación no impide por sí sola que dos usuarios sean dirigidos al mismo espacio de archivos. Fuente: aislamiento por usuario y permisos.
Qué sucede cuando se comparte una sesión
Foundry protege las cadenas de respuestas por usuario. Sin embargo, los archivos, filas y cachés que mantiene el contenedor requieren una partición explícita. Microsoft propone identificar esos datos por la combinación de sesión y usuario, en lugar de emplear solamente el identificador de sesión.
Una prueba documentada consiste en crear dos respuestas como usuario A e intentar continuar esa cadena como usuario B. La continuación debe fallar. Esta prueba valida el historial; debe complementarse con verificaciones de los archivos y datos propios. Se requieren identidades realmente distintas y un agente desplegado: el modo local no aplica el aislamiento de la plataforma.
Fuente: sesiones compartidas, partición de datos y prueba A-A-B.
Preparación del piloto
La integración documenta una suscripción Azure, un proyecto Foundry con un modelo desplegado, Azure Developer CLI y paquetes de alojamiento prerrelease. Según el lenguaje, se requiere .NET 10 o Python 3.10 o posterior. Conviene fijar las versiones y comprobar las dependencias del ejemplo elegido antes de desplegar.
Los servicios Azure, los modelos y los sistemas conectados mantienen sus costos y condiciones de uso. Antes de reutilizar código en un producto, deben revisarse sus licencias. Fuente: requisitos e integración con Agent Framework.
Pruebas de aceptación propuestas
El siguiente plan es una propuesta editorial; no representa un piloto ejecutado ni resultados medidos por Enoiax.
- Desplegar un agente mínimo en un proyecto de prueba y registrar las versiones utilizadas.
- Asignar inicialmente una sesión diferente a cada usuario y utilizar documentos sintéticos reconocibles.
- Comprobar lectura, listado y descarga de archivos con ambas identidades.
- Intentar intercambiar identificadores de usuario, sesión y respuesta; verificar los rechazos esperados en cada capa.
- Ejecutar llamadas sin permiso de delegación y confirmar que no se acepten como solicitudes autorizadas.
- Repetir la prueba después de inactividad y reanudación, y verificar eliminación y contenido de las trazas.
El ciclo de vida merece una comprobación independiente: reutilizar agent_session_id recupera el espacio de trabajo, pero no reproduce por sí solo los mensajes anteriores. Fuente: gestión de sesiones y conversaciones.
Aplicación a asistentes empresariales
Este patrón puede orientar pruebas de asistentes que consultan documentación, incidencias o información de D365FO y Azure DevOps. Es una posibilidad de adaptación: las guías citadas no entregan esas integraciones. La autorización debe comprobarse también en cada sistema de destino.
Para una primera evaluación, recomendamos sesiones separadas y datos sintéticos. Compartir sesiones exige justificar la necesidad y demostrar la separación de archivos, cachés y registros. Un piloto mínimo podría requerir entre dos y tres jornadas; es una estimación orientativa, sujeta al despliegue y a los permisos disponibles.
La replicabilidad es media: existen procedimientos concretos, pero falta comprobar su comportamiento en el entorno elegido. Los principales riesgos son la asignación incorrecta de sesiones, permisos excesivos, información sensible en trazas y cambios de compatibilidad en dependencias prerrelease.
Recomendación: probar. Utilizar las verificaciones como criterio de aceptación antes de incorporar datos reales. Una demostración funcional no reemplaza las pruebas de acceso cruzado.