Microsoft Foundry Agent Service: cómo desplegar agentes con identidad, tools y trazas
Microsoft Foundry Agent Service elimina parte de la infraestructura de un agente, no la responsabilidad de diseñar sus permisos, tools, aprobaciones y pruebas. Esta guía explica dónde encaja de verdad.
`Microsoft Foundry Agent Service` es el runtime gestionado de Microsoft para ejecutar agentes basados en prompts o código. La keyword principal es `Microsoft Foundry Agent Service`; la intención es de implementación: un equipo Azure quiere saber cuándo usarlo, cómo dar tools a un agente y qué controles necesita antes de producción.
Checklist
Qué es y qué no es Agent Service
Un agente combina modelo, instrucciones y tools. En Foundry, la Responses API es el punto de entrada común: permite usar modelos del catálogo y herramientas de plataforma desde un prompt agent, un contenedor propio o un proceso que ya existe. Esa capa no convierte cualquier respuesta en una decisión correcta; organiza el runtime alrededor de ella.
El servicio actual distingue dos rutas. Un `prompt agent` se define por configuración y Foundry ejecuta el runtime; un `hosted agent` es tu código —Agent Framework, LangGraph, OpenAI Agents SDK o un runtime propio— empaquetado y ejecutado con endpoint e identidad administrados. No confundas esta generación con los 'Agents (classic)': Microsoft marca el portal y SDK clásicos como deprecados, con retirada anunciada para marzo de 2027.
La frontera citable es sencilla: Foundry administra cómo se ejecuta y observa un agente; tu producto determina qué puede hacer, contra qué datos y quién responde cuando se equivoca.
Toolbox: centraliza capacidades, no confianza
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratisUn Toolbox es un paquete versionado de tools que se expone por un endpoint MCP. Sirve para evitar que cada agente tenga su propia copia de URLs, credenciales, allowlists y políticas. Un consumidor puede seguir el `default_version` para recibir una versión promovida, mientras un entorno de prueba se conecta a una URL versionada e inmutable antes de aprobarla.
La ventaja real no es que MCP sea moderno; es que puedes gobernar una colección. Empieza con dos tools de lectura, por ejemplo búsqueda web y documentación interna. Después añade una integración remota, separada por dominio y con una conexión de proyecto. Un Toolbox que mezcla GitHub de escritura, facturación, producción y búsqueda pública es una forma elegante de esconder una política pésima.
La documentación es explícita con un detalle que muchos omiten: cuando una tool devuelve `require_approval: always`, el endpoint MCP no bloquea `tools/call`; el runtime debe presentar la acción y esperar confirmación. No declares aprobación en metadata y des por resuelto el control. Prueba que tu interfaz y tu executor lo imponen realmente.
Un piloto reproducible con Azure Developer CLI
El quickstart oficial permite crear un hosted agent de ejemplo, usar una Toolbox y ejecutarlo localmente antes de desplegar. Este flujo es deliberadamente pequeño: valida el endpoint, el descubrimiento de `tools/list` y el comportamiento de una tool de lectura antes de conectar recursos sensibles.
Puntos a revisar
Lo que conviene comprobar
Fija versiones de `azd`, la extensión `microsoft.foundry`, Python y las dependencias del sample en tu CI. El comando scaffold es una base, no una arquitectura aprobada. Revisa el `azure.yaml`, el `toolbox.yaml`, las conexiones y cualquier endpoint antes de asociarlo a recursos de empresa.
Checklist
Identidad, secretos y aislamiento
Al desplegar un hosted agent, Foundry crea una identidad Entra dedicada para ese agente. Esa identidad puede usar el endpoint del proyecto y el almacenamiento de sesión por defecto; para Storage, Search u otros recursos debes conceder roles específicos. Ese diseño es preferible a copiar una clave de administrador en el contenedor, pero mínimo privilegio sigue significando una asignación por recurso y entorno.
No guardes API keys ni OAuth tokens dentro de la imagen ni en el repositorio. Foundry permite resolver valores desde project connections al iniciar el sandbox. Para tools MCP, la conexión decide la identidad downstream; separa conexiones de desarrollo y producción y rota las credenciales con el mismo rigor que las de cualquier servicio.
Las tools externas pueden sacar datos fuera del perímetro de cumplimiento de Foundry. Documenta ese flujo antes de activar un conector: datos enviados, proveedor, región, retención, scopes y respuesta ante un fallo. La red privada y RBAC ayudan, pero no corrigen una tool que devuelve demasiado contexto al modelo.
Checklist
Despliegue, trazas y evaluación
La secuencia sana es build local, prueba de tools y casos negativos, despliegue de una versión, espera a estado activo, canary con identidad de prueba y solo después promoción. Los hosted agents pueden desplegarse como contenedor o desde código fuente empaquetado; elige el primero si ya controlas la imagen y el segundo para un inner loop sencillo, no por comodidad ciega.
Foundry puede inyectar la conexión de Application Insights y habilitar OpenTelemetry. Eso permite ver latencia, excepciones, llamadas de modelo y dependencias, pero puede incluir contenido personal o de cliente en trazas. Define redacción, muestreo, retención y quién puede leer Application Insights antes de celebrar que ya tienes observabilidad.
Evalúa tres capas por separado: resultado final (¿la respuesta sirve?), trayectoria (¿eligió la tool permitida?) y ejecución (¿respetó identidad, timeout y coste?). Cada fallo de producción debe convertirse en un caso de dataset antes de cambiar instrucciones o modelo. Sin ese bucle, el versionado solo te deja volver atrás sin saber por qué.
Checklist antes de producción
- Elegir una tarea que justifique autonomía y escribir el contrato de entrada, salida, tools permitidas y acciones prohibidas.
- Crear una Toolbox versionada de bajo riesgo; probar su endpoint versionado y promover a `default_version` solo tras revisión.
- Conceder RBAC mínimo a la identidad de agente y usar una conexión distinta por entorno; no meter secretos en código o imagen.
- Forzar confirmación en runtime para tools mutantes y probar una denegación, no solo el camino feliz.
- Trazar sin registrar secretos: decidir qué prompts, outputs y argumentos se redactan, durante cuánto tiempo y quién los consulta.
- Medir éxito, tool calls, errores, latencia, coste y tasa de escalado a humano con un dataset de casos normales, ambiguos y hostiles.
Preguntas frecuentes
¿Qué es Microsoft Foundry Agent Service?
Es una plataforma gestionada para construir, ejecutar, escalar y observar prompt agents y hosted agents, con modelos, tools, identidad y endpoints de Foundry.
¿Cuándo conviene un hosted agent?
Cuando necesitas ejecutar código propio, una orquestación o protocolo personalizado, estado de aplicación o una integración que no cabe en la configuración de un prompt agent.
¿Toolbox sustituye a una política de permisos?
No. Centraliza configuración, versiones y credenciales de tools; tu runtime y backend deben imponer scopes, aprobación y reglas de negocio.
¿Foundry gestiona por sí solo la aprobación humana?
No. La metadata de una tool puede pedir aprobación, pero el runtime que llama la tool debe detener la acción y esperar confirmación.
¿Puedo usar LangGraph u OpenAI Agents SDK?
Sí. Los hosted agents pueden ejecutar código con esos frameworks; no necesitas reescribir toda la orquestación para usar el runtime gestionado.
¿Las trazas son privadas por defecto?
Trátalas como datos sensibles. Revisa contenido capturado, permisos de Application Insights, retención y redacción antes de usarlas con tráfico real.
Cómo lanzar un piloto seguro con Microsoft Foundry Agent Service
- Escoger una tarea de lectura. Empieza con una consulta de documentación o búsqueda interna que no cambie sistemas externos.
- Crear un proyecto y modelo. Configura un Foundry project y un deployment de modelo compatible en una región soportada.
- Scaffold del agente. Inicializa el sample oficial con Azure Developer CLI y revisa azure.yaml antes de ejecutar.
- Crear Toolbox mínima. Añade una o dos tools de solo lectura y guarda la URL de la versión concreta para pruebas.
- Ejecutar localmente. Comprueba tools/list, una respuesta útil, timeout y comportamiento ante una tool no permitida.
- Asignar identidad mínima. Da a la identidad del agente solo los roles necesarios para los recursos que realmente consume.
- Configurar trazas seguras. Conecta Application Insights, redacta campos sensibles y limita quién puede consultar los spans.
- Desplegar canary. Publica una versión, invócala con una identidad de prueba y compara resultado, trayectoria, latencia y coste con el dataset.
- Promover con evidencia. Cambia el Toolbox o el agente por versiones revisadas y conserva un rollback probado antes de ampliar permisos.
Fuentes y referencias
- Microsoft Foundry: Agent Service overview
- Microsoft Foundry: hosted agents
- Microsoft Foundry: desplegar un hosted agent
- Microsoft Foundry: qué es Toolbox
- Microsoft Foundry: crear y gobernar un Toolbox
- Microsoft Foundry: usar Toolbox con hosted agent
- Microsoft Foundry: trazas de agentes
- Microsoft Foundry: quickstart Toolbox + hosted agent
También te puede interesar
OpenAI Responses API y function callingLangGraph: agentes Python con estadoOpenTelemetry GenAI para observabilidadMCP en producción: seguridad y permisosEvaluación RAG en producciónRecibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratis
