¿Quién ha creado estos agentes?

En un tenant de cliente con 3.000 usuarios encontramos 280 agentes en el primer inventario. 170 de ellos ya no tenían ningún responsable que siguiera en la empresa. No los construyó nadie con malas intenciones, sino departamentos que querían resolver algo rápidamente. Exactamente así surgieron hace diez años los Service Principals que hoy nadie ha limpiado todavía. Los agentes repiten ese patrón, solo que más rápido y en mayor número.

Lo que una licencia no puede hacer

E7 combina E5, Copilot, la Entra Suite y Agent 365. Lo que incluye el paquete está ya suficientemente documentado. Pero una licencia no ordena ningún tenant. Nos da herramientas para ver, identificar y controlar agentes. Lo que no decide es si un agente debería existir, quién responde por él ni a qué puede acceder.

A eso se suma el ritmo. Los agentes surgen hoy donde antes surgían las macros de Excel: en los departamentos, rápido y sin ticket. Eso es lo que se busca, y nos parece bien. Pero significa que el número de cuentas no humanas en el directorio crece más rápido que cualquier otro grupo.

Lo que el registro muestra y lo que no

Agent 365 reúne en un solo lugar los agentes de Microsoft 365, Copilot Studio, Power Platform y Foundry. Defender for Endpoint detecta además los agentes de IA instalados localmente en los clientes, incluidos los servidores MCP configurados. Todo ello llega a Advanced Hunting y se puede analizar conjuntamente mediante KQL. Shadow AI en el sentido más literal.

Con esta consulta observamos qué agentes se invocan realmente y qué herramientas utilizan:

CloudAppEvents
| where ActionType in ("InvokeAgent", "InferenceCall", "ExecuteToolBySDK", "ExecuteToolByGateway")
| extend RawEventData_parsed = parse_json(RawEventData)
| extend
    Workload          = coalesce(tostring(RawEventData_parsed["Workload"]), "Unknown"),
    TargetAgentName   = coalesce(tostring(RawEventData_parsed["TargetAgentName"]), "Unknown"),
    AgentName         = coalesce(tostring(RawEventData_parsed["AgentName"]), "Unknown"),
    AgentBlueprintId  = coalesce(tostring(RawEventData_parsed["AgentBlueprintId"]), "Unknown"),
    PlatformAgentType = coalesce(
        tostring(RawEventData_parsed["PlatformAgentType"]),
        tostring(RawEventData_parsed["CopilotEventData"]["PlatformAgentType"]),
        "Unknown"
    )
| project-away RawEventData_parsed
| summarize count() by ActionType, Workload, TargetAgentName, PlatformAgentType, AgentName, AgentBlueprintId

Hay que tener en cuenta una limitación: la consulta muestra solo una parte del panorama, principalmente los agentes propios de Microsoft y los construidos sobre plataformas de Microsoft. Lo que corre en paralelo fuera de ese ámbito no aparece aquí.

Para los agentes locales en los clientes basta con Defender for Endpoint Plan 2:

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend AgentMetadata = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(AgentMetadata.vendor),
         Device = tostring(AgentMetadata.deviceName)
| summarize DeviceCount = dcount(Device) by Agent = Name, Vendor
| sort by DeviceCount desc

Un agente que actúa en nombre de un usuario hereda sus permisos. Si ese usuario tiene acceso a una biblioteca de SharePoint con permisos excesivamente amplios, el agente también lo tiene, y además es más rápido y minucioso que cualquier persona.

Un agente autónomo con identidad propia trabaja con sus propios permisos. Ese necesita un responsable, un perfil de permisos limpio y una fecha de caducidad, igual que cualquier otra cuenta que accede a datos corporativos.

El registro muestra lo que hay. Si debería estar, alguien tiene que valorarlo, y esa valoración nunca termina.

Los agentes necesitan identidades, sin excepciones

Los agentes construidos con Entra Agent ID reciben una identidad gestionada propia. Con Agent Blueprints se puede definir cómo está construido un agente y qué permisos recibe antes de que exista. Y con Entra ID Governance, las revisiones de acceso y el ciclo de vida también funcionan para los agentes: crear, aprobar, asignar responsables, revisar periódicamente, dejar caducar.

Conditional Access se puede aplicar a identidades de agente y a Blueprints, pero no de forma idéntica a como se aplica con personas. Las políticas para "todos los usuarios" no recogen las cuentas de agente, y quien accede mediante API Key pasa completamente por alto Entra. Hay que conocer esas brechas antes de confiar en la política.

Suena obvio. En la práctica, por desgracia, no lo es. Ya hoy vemos en muchos tenants lo difícil que resulta eso con los registros de aplicaciones clásicos y los Service Principals. Secrets abandonados, permisos de alguna fase de pruebas, responsables que llevan tiempo trabajando en otro sitio. Los agentes no mejoran ese panorama, porque se construyen en mayor número y por mucha más gente.

Quien no controla sus Service Principals hoy, tampoco controlará sus agentes mañana.

La gobernanza es una tarea continua

Cada semana llegan nuevos agentes. Los responsables cambian de rol o de empresa. Los permisos crecen, las reglas de Conditional Access acumulan excepciones, los Sensitivity Labels no los cuida nadie. Nada de eso es un proyecto con fecha de go-live: es operación.

Y así es exactamente como lo abordamos. Con Managed Entra operamos Entra ID completamente como código para nuestros clientes. Puede sonar a detalle técnico, pero es la razón real por la que la operación funciona de forma fiable.

Muchas empresas tienen un proceso de cambio limpio según ITIL. En el ticket se describe qué debe modificarse, y luego alguien hace clic en el portal. Pero ¿quién comprueba que se ha ajustado exactamente eso y nada más?

Nosotros no revisamos la descripción, sino el cambio en sí. Las reglas existen como código. Antes de ejecutar, queda por escrito exactamente qué va a cambiar. Una segunda persona aprueba precisamente eso, y solo eso se despliega, con nombre y fecha. Si aun así algo falla, el último estado funcional se restaura en minutos, no en un turno de noche.

Las excepciones también siguen este camino. Si un cliente necesita desviarse del estándar, queda en el repositorio, no en una lista de Excel ni en la cabeza de un administrador. Es visible, versionada y se revisa como cualquier otro cambio. Así la baseline no se diluye gradualmente a lo largo de los meses, y en la próxima auditoría la evidencia de cómo está configurado el tenant y quién cambió qué y cuándo ya está lista.

Y nos aplicamos a nosotros mismos lo que exigimos para los agentes. Nuestra propia automatización es también una identidad no humana. Se autentica en el tenant del cliente mediante identidades federadas, sin ningún secret almacenado. Los permisos están separados: una identidad solo puede leer y planificar, otra puede escribir. Sin contraseña que pueda filtrarse, sin certificado que caduque silenciosamente en algún momento.

En cuanto a los propios agentes, estamos en plena construcción. Conditional Access, Access Reviews y Entitlement Management ya los gestionamos hoy como código. En lo que estamos trabajando ahora son plantillas de agente en el repositorio, con identidad, permisos, Conditional Access, responsables y fecha de caducidad, así como comprobaciones automáticas de identidades de agente huérfanas, por ejemplo con Maester checks de la comunidad. Con cientos de agentes, esa es la diferencia entre tener visibilidad y tener esperanza.

Cómo Purview protege los datos que los agentes leen y comparten, y cómo nuestro CSOC supervisa su actividad, lo describimos en un artículo propio sobre gobernanza de IA.

¿Y los agentes en Azure?

Agent 365 también ve los agentes que se ejecutan en Microsoft Foundry. Pero alguien tiene que construir y operar la plataforma subyacente: modelos, red, conexión de datos, evaluación. Para eso hemos construido la AI Foundation, completamente como código, de modo que cada nuevo proyecto de IA arranca con las mismas guías que el anterior. Hay más detalles en nuestro artículo sobre las tres foundations: The Holy Trinity.

El punto más importante es la conexión hacia abajo. Cada agente de la AI Foundation recibe una identidad propia en el mismo Entra que el resto del entorno, con exactamente los permisos que necesita. Si actúa en nombre de un usuario, solo ve lo que ese usuario tiene derecho a ver. Y deja un rastro que se puede auditar. Sin caminos alternativos con cuentas propias y excepciones propias solo porque el agente corre en Azure en lugar de en Microsoft 365.

Tres preguntas para mañana por la mañana

Quien quiera saber dónde está puede empezar con tres preguntas:

1. ¿Qué agentes ya no tienen un owner o sponsor activo?
2. ¿Qué Service Principals tienen secrets con más de doce meses de antigüedad?
3. ¿Qué agentes acceden mediante API Key en lugar de a través de Entra?

Quien tenga una respuesta rápida para las tres está por delante de la mayoría.

Por dónde empezamos

Por el estado actual, porque los agentes ya están ahí de todas formas. En nuestro Agent 365 Workshop de dos días hacemos visible qué agentes corren en vuestro tenant y de dónde vienen. Al terminar, tendréis un inventario, un mapa de riesgos y un plan de gobernanza con responsabilidades claras.

Conclusión

E7 aborda un problema real. Pero ver lo que está en marcha no equivale a tenerlo bajo control. Para eso hace falta que alguien mire cada día, mantenga las identidades, recorte los permisos y detecte cuando un agente de repente se comporta de forma diferente a ayer.

La licencia es el punto de partida. La operación es lo que decide.

¿Tenéis E7 ya en uso o notáis que los agentes se multiplican en vuestro entorno y os preguntáis quién se ocupa realmente de eso? Hablad con nosotros. Revisamos juntos qué hay en marcha y qué debería quedarse. Microsoft apoya el primer paso a través de programas de financiación. Si encaja con vuestro caso, lo aclaramos juntos.