Foundry Control Plane, Agent 365 y Entra Agent ID no compiten, se reparten el trabajo.
Agent Control Plane: el Kubernetes que tus agentes ya necesitan
Crear un agente es fácil. Llevas dos años viéndolo: cualquiera con acceso a Copilot Studio o cuatro líneas de Python monta uno en una tarde. El problema nunca ha sido crear el primero. Es lo que pasa cuando ya tienes 200.
Según el informe State of AI Agent Security 2026 de Gravitee, ahora mismo hay más de 3 millones de agentes de IA operando dentro de corporaciones. Solo el 47,1% están monitorizados de alguna forma. Eso deja millón y medio actuando por libre: accediendo a sistemas, tomando decisiones, moviendo datos, sin que nadie los esté mirando. Y por si acaso pensabas que tu empresa es la excepción, IBM dice que solo el 18% de las organizaciones tiene un inventario completo y actualizado de qué agentes tiene corriendo. El resto se entera en una auditoría. O, con más frecuencia de la que gustaría, en un incidente.
Bienvenido al Agent Sprawl, el primo hipervitaminado del Shadow IT. Con una diferencia importante: un SaaS no autorizado espera a que alguien lo abra. Un agente actúa solo.
Por qué esto no se arregla con más políticas en un PDF
La respuesta habitual a este tipo de caos es un documento de gobernanza que nadie lee. No va a funcionar aquí, porque el problema no es de intención, es de arquitectura. Un agente no es una aplicación con un despliegue fijo y un dueño conocido de toda la vida. Se crea, actúa y a veces se destruye miles de veces al día como parte de un flujo automatizado. Intentar gobernarlo con las mismas herramientas que usabas para una app monolítica de 2015 es como intentar llevar el tráfico de una ciudad con las señales de un pueblo.
Microsoft ha llegado a la misma conclusión, y lo interesante es que no ha construido una sola pieza para resolverlo. Ha construido tres.
Tres planos, no dos
La mayoría de los artículos que he leído sobre esto los presentan como rivales, como si tocara elegir uno. Es un error de lectura bastante tonto, la verdad, porque es la misma lógica de Kubernetes: el control plane no le hace la competencia al kubelet. Cada uno resuelve una capa distinta del mismo problema.
Entra Agent ID es la identidad primitiva. Cada agente es un service principal especial que no tiene credenciales propias, depende de un «blueprint» (la plantilla de la que nace) para pedir tokens en su nombre. Y siempre hay un sponsor: una persona a la que llamar cuando algo se tuerce, porque algo se va a torcer tarde o temprano.
Foundry Control Plane es la capa de desarrollador: observabilidad, evaluaciones, red teaming automatizado, coste por token, quién hizo qué y cuándo. Ahí vive el agente entre el primer commit y producción.
Y Agent 365 es el plano de gobierno organizativo: el registro unificado de todos los agentes de la empresa, los tuyos y los que compraste a un tercero, los permisos de herramientas, las políticas que aplica IT sin tener que meterse en el código de nadie.
Tres capas para tres audiencias distintas. Lo raro habría sido que Microsoft intentara resolverlo con una sola.

Quién autoriza qué: el problema de los servidores MCP sueltos
La mayoría de las empresas grandes ya se están quemando con esto sin saberlo. Es normal tener decenas de servidores MCP internos corriendo fuera de cualquier frontera de gobernanza, sin que nadie en seguridad sepa qué herramientas exponen ni quién los está llamando.
La solución de Microsoft es un gateway de herramientas dentro de Agent 365. Los servidores MCP propios se registran, un admin los revisa y aprueba, y a partir de ahí quedan bajo telemetría y política central. Lo que de verdad importa: si un administrador bloquea un servidor, queda bloqueado para todos los usuarios y todos los agentes de la organización, sin excepciones ni «es que mi equipo lo necesita». El permiso central gana siempre.
Es el mismo principio que aplicamos en el AESIA Compliance Accelerator, y por el que discuto cada dos por tres con algún cliente: documentar la política en un Excel o un PDF no sirve de nada si el sistema no la impone. Suena obvio hasta que ves cuántas empresas siguen operando así.
Inventario, huérfanos y quién paga la factura
El otro efecto colateral de 200 agentes sueltos es que nadie sabe cuánto cuesta cada uno ni si sigue vivo. Foundry ya soporta chargeback a nivel de proyecto, con etiquetado automático que permite repartir el gasto compartido entre equipos sin que nadie tenga que perseguir facturas a mano. Y a nivel de agente individual, se puede llegar a saber qué consume cada uno hasta el token, no solo la factura del mes.
Del lado de identidad, el reto es distinto: agentes abandonados que siguen teniendo acceso porque la persona que los creó cambió de puesto o se fue de la empresa. Entra Agent ID ataca esto con flujos de vida automatizados: cada agente necesita un sponsor asignado, y si ese sponsor desaparece, hay un flujo que reasigna o revoca antes de que el agente quede huérfano con permisos activos.

El kill switch
Todo lo anterior no sirve de nada si al final no hay un botón real de «apaga esto ya». Y aquí hay que distinguir dos cosas que se suelen mezclar.
Borrar un agente en Entra dispara una limpieza en cascada: revoca tokens, retira permisos heredados, deja rastro auditable. Tiene hasta soft-delete, por si te confundes de agente (pasa más de lo que nadie admite en voz alta). Eso es matar al agente entero.
Pero a veces no quieres matarlo, solo cortarle una mano. Ahí entra el bloqueo de un servidor MCP: corta el acceso a esa herramienta concreta sin tocar el resto del agente, que sigue funcionando con lo que le queda.
Las dos cosas tienen que existir y las dos tienen que activarse en segundos, no después de que alguien encuentre manualmente en qué rincón del tenant vive el agente que está haciendo de las suyas.

Así lo dibuja Microsoft
Todo esto que llevo contándote no es una síntesis mía forzada para que quede bonito el artículo. Microsoft lo tiene dibujado, con nombre y apellidos, en el Cloud Adoption Framework, en la guía de gobierno y seguridad de agentes a escala de organización. Y el diagrama, para mi sorpresa, tiene más sentido del que esperaba.
Son cuatro capas horizontales, no tres. Arriba del todo, gobernanza de datos y cumplimiento: Purview Compliance Manager, las APIs de Purview, la gobernanza propia de Copilot Studio, controles de dónde vive físicamente el dato. Debajo, observabilidad: Agent 365, Defender for Cloud, Log Analytics, Application Insights, Cost Management, el sitio donde vive el chargeback del que hablábamos antes. La tercera capa es seguridad: Defender detectando amenazas específicas de IA, el Content Safety que corre dentro de Foundry Control Plane, el Red Teaming Agent que ataca tus propios sistemas antes de que lo haga otro, RBAC y Sentinel. Y abajo del todo, la capa de desarrollo: Agent Framework, el SDK de Foundry, MCP y A2A para que los agentes hablen entre sí.
Lo que más me gusta de este diagrama es justo lo que no dice: no hay una casilla para «elegir entre Foundry Control Plane o Agent 365». Los dos aparecen conviviendo en capas distintas porque ahí es donde cada uno pinta algo. Si te interesa verlo con tus propios ojos y no fiarte de mi resumen, el original está en la propia documentación de Microsoft: Governance and security for AI agents across the organization.

Autonomía sin gobierno es deuda operacional
Gartner calcula que el 40% de las aplicaciones empresariales tendrá agentes específicos por tarea a finales de este año, frente a menos del 5% en 2025. Eso no es una tendencia para vigilar de reojo, es un reloj corriendo. Las empresas que sigan tratando a sus agentes como si fueran una app más lo van a descubrir tarde: en una auditoría, en una fuga de datos, o mirando una factura de cloud que nadie en el equipo sabe explicar.
La pieza técnica ya existe, no hay que inventarla. Lo que no existe todavía en la mayoría de los sitios es la disciplina de montarla antes de que haga falta, que es justo cuando nadie quiere pararse a hacerlo. Conectar bien Entra Agent ID, Foundry Control Plane y Agent 365 no es un checkbox de viernes por la tarde. Es arquitectura, con lo pesado que eso suena, y hay que diseñarla antes de que la flota llegue sola a 200.
Si ahora mismo estás en el «tenemos tres agentes y van bien», este es el momento de pensar en el control plane. No cuando ya sean trescientos y nadie en la sala sepa de quién es la mitad.




Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.