Cuando un agente puede invocar herramientas empresariales, actualizar su framework requiere comprobar algo más que la compilación. También importa que conserve las autorizaciones, solicite las aprobaciones correspondientes y mantenga un comportamiento predecible al reanudar una ejecución.
Qué incorpora la versión .NET 1.23.0
El release oficial dotnet-1.23.0 de Microsoft Agent Framework, publicado el 1 de octubre de 2026, incorpora origin pinning para el cliente MCP de Foundry Toolbox y validación de encabezados antes del transporte. También corrige un caso en el que la invocación de una herramienta podía eludir la aprobación y refuerza la vinculación de las respuestas de aprobación.
El registro incluye mejoras en la validación de recursos de skills MCP y en la conservación del estado de aprobación. Identifica cambios incompatibles relacionados con herramientas entre ejecuciones, claves de configuración permitidas, continuación de aprobaciones y dependencias de Azure.AI.Projects, OpenAI y Microsoft.Extensions.AI.
Por qué importa para agentes empresariales
Un asistente que consulta documentación y otro que modifica un registro no necesitan el mismo nivel de intervención humana. La aprobación debe corresponder a una operación concreta, con argumentos conocidos y una identidad autorizada. Si la aplicación se interrumpe, reintenta o recupera una conversación, esos controles deben seguir funcionando.
En soluciones conectadas con Dynamics 365 Finance and Operations o Azure DevOps, esto plantea una validación de extremo a extremo: qué solicita el usuario, qué herramienta propone el agente, quién autoriza y qué permite realmente el sistema de destino. Se trata de una aplicación potencial de estos cambios; la versión no entrega por sí sola una integración completa con esos productos.
Antes de actualizar
La propuesta editorial es comenzar en una rama y un ambiente de prueba. Registrar la versión actual, las dependencias resueltas, la configuración y los casos de regresión facilita comparar resultados y recuperar una versión conocida si aparecen incompatibilidades.
- Inventariar los paquetes utilizados y revisar las notas de los cambios incompatibles que afecten a la aplicación.
- Fijar versiones compatibles de los paquetes necesarios; el nombre del tag del repositorio no sustituye la comprobación de versiones disponibles de cada paquete NuGet.
- Utilizar identidades de prueba con permisos mínimos y documentos sintéticos o anonimizados.
- Separar las herramientas de consulta de las que modifican datos o disparan procesos.
Checklist de pruebas recomendado
Los siguientes escenarios son una propuesta de validación, no resultados medidos ni una garantía del fabricante.
- Aprobación y rechazo: comprobar que una herramienta protegida no actúa antes de la autorización y que un rechazo no produce efectos.
- Correspondencia de la aprobación: verificar que una respuesta corresponde a la llamada y argumentos esperados; probar respuestas repetidas o ajenas a esa solicitud.
- Interrupción y reanudación: detener una ejecución de laboratorio y recuperarla. Comprobar si conserva el estado y si evita repetir operaciones con efectos.
- Cambios de herramientas: retirar o modificar una herramienta entre ejecuciones y observar cómo responde la aplicación.
- Origen MCP: probar en laboratorio el endpoint autorizado y un cambio controlado de origen. Revisar el comportamiento del cliente y sus errores.
- Configuración: comprobar cómo se detectan las claves no admitidas y que el despliegue falla de forma comprensible cuando corresponde.
- Telemetría: revisar que las trazas permiten investigar errores sin exponer tokens, documentos ni argumentos sensibles.
Permisos, soporte y límites
Una aprobación humana no concede automáticamente permisos en el sistema conectado. La autorización debe seguir aplicándose en cada servicio. Del mismo modo, proteger el origen MCP no reemplaza la autenticación, el control de acceso ni la revisión del servidor.
Microsoft Agent Framework utiliza licencia MIT. Los modelos, Foundry y demás servicios conectados conservan sus condiciones y costos. La documentación general muestra instalación .NET mediante --prerelease; conviene revisar el estado y compatibilidad de cada componente utilizado.
La evidencia del release es código y cambios enlazados. No permite afirmar que una aplicación concreta quedará libre de fallos. Además, el registro incluye una omisión temporal de pruebas de integración OpenAI por un problema de credenciales de CI; esa anotación no demuestra por sí sola qué pruebas finales se ejecutaron sobre cada escenario.
Recomendación
Probar antes de adoptar. El objetivo es cerrar la actualización con evidencia de que permisos, aprobaciones, reanudación y herramientas siguen comportándose como se espera. Para un piloto técnico acotado, una estimación orientativa es de dos a tres jornadas; la persistencia, las integraciones y la complejidad de la aplicación pueden ampliar ese esfuerzo.