Agent 365 ya puede bloquear las herramientas MCP que llama un agente. La política se vuelve real en el gateway

Una lista de sus agentes no es un control. Un control es poder impedir que un agente llame a una herramienta un miércoles por la tarde, sin volver a desplegar el agente y sin preguntarle al equipo que lo construyó. La mayoría de los programas de gobernanza de agentes de hoy tienen la lista.

El 9 de octubre, Microsoft unió las dos mitades. Una versión preliminar pública conecta Agent 365, su producto de gobernanza de agentes, con Azure API Management para el tráfico hacia servidores y herramientas MCP. Microsoft describe la división sin rodeos: “Agent 365 define la intención de gobernanza, mantiene el inventario y gestiona las decisiones de acceso”, mientras que “Azure API Management aplica esas decisiones en línea para el tráfico hacia servidores y herramientas MCP”.

Esa frase describe una arquitectura que vale la pena copiar, sea cual sea su proveedor.

Dos planos, dos responsables

El equipo que decide qué pueden hacer los agentes rara vez es el que los opera. Los equipos de identidad y seguridad definen la política de acceso; los equipos de plataforma operan los gateways; los equipos de producto construyen agentes sobre el framework que más les convenga. Hasta ahora, los productos de gobernanza de agentes vivían sobre todo del primer lado: inventarios, puntuaciones de riesgo, políticas escritas. La aplicación dependía de la configuración de cada agente.

Aquí la decisión y la aplicación viven en sistemas distintos, con responsables distintos, unidos por una integración. Los agentes ya configurados para llegar a las herramientas a través del gateway conservan su conexión, los servidores MCP permanecen en las suscripciones de Azure del cliente, y el descubrimiento necesita un consentimiento único a nivel de tenant. Un agente no tiene que reconstruirse sobre el runtime de Microsoft para estar gobernado, siempre que su tráfico de herramientas pase por API Management.

Quién decide, quién aplica

Agent 365

• Inventario MCP
• Intención de gobernanza
• Decisiones de acceso

A cargo de gobernanza y seguridad

Azure API Management

• Aplicación en línea en cada llamada a una herramienta

A cargo del equipo de plataforma

Defender y Purview (nivel AI Gateway)

• Evaluar las solicitudes a herramientas
• Evaluar los resultados de las herramientas

Servidores y herramientas MCP

• En las suscripciones de Azure del cliente

Lea el nivel antes del titular

Lo que puede aplicar depende del nivel de API Management que tenga. Microsoft dice que los niveles v2 admiten “inventario MCP centralizado y bloqueo y desbloqueo a nivel de servidor a través de Agent 365”. El nivel AI Gateway añade “bloqueo de herramientas individuales, observabilidad de la actividad de las herramientas y protección frente a amenazas para las herramientas”, con el bloqueo de herramientas individuales etiquetado como versión preliminar.

La diferencia es mayor de lo que parece. Bloquear un servidor entero es un interruptor de emergencia: útil durante un incidente, tosco en la operación diaria. El mínimo privilegio necesita el control más fino: un agente conserva sus herramientas de lectura en un servidor CRM y pierde la que actualiza registros. Ese control está en el nivel AI Gateway.

La protección frente a amenazas funciona en dos direcciones. Defender y Purview evalúan las solicitudes y los resultados de las herramientas en busca de contenido malicioso, inyección de prompts e información sensible. Con el bloqueo configurado, “la evaluación previa a la invocación puede impedir que se ejecute una llamada no permitida”, y “la evaluación posterior a la invocación puede retener resultados no seguros antes de que lleguen al agente”. La segunda dirección merece atención: la respuesta de una herramienta es por donde entran las instrucciones inyectadas a un agente, y hoy pocos equipos la inspeccionan.

El anuncio no cubre licencias, precios, regiones ni límites numéricos. Consulte la documentación antes de planificar en torno a esto, y recuerde que todo esto está en versión preliminar.

Lo que el gateway no puede ver

La aplicación en línea gobierna el tráfico que pasa en línea. Un agente que usa su propia credencial contra un servidor MCP, que llama a una herramienta local o que navega por la web queda fuera de este control, y el dashboard no se lo dirá. Como argumentamos cuando la conectividad MCP superó a la gobernanza MCP, el protocolo conecta; no gobierna.

El trabajo de diseño consiste, por tanto, en hacer del gateway la única ruta:

• Credenciales que solo funcionan a través del gateway. Si una herramienta acepta un token que el agente podría usar directamente, el gateway es opcional.
• Reglas de salida para las cargas de trabajo de los agentes, de modo que una ruta directa a un servidor de herramientas falle en la red.
• Conciliación del inventario con el tráfico. Los agentes que aparecen en Agent 365 pero nunca envían tráfico a través de API Management o están inactivos o lo están eludiendo. Ambos casos merecen una pregunta.

Este es el patrón que describimos para el gateway de IA como punto de aplicación de políticas, aplicado ahora a las herramientas en lugar de a los modelos. También mantiene separadas a dos de las seis autoridades que gobiernan a un agente: quienes conceden el acceso a las herramientas no son quienes pueden desconectar la aplicación.

Vale la pena hacerse tres preguntas antes de un piloto. ¿Qué herramientas de nuestros agentes se pueden bloquear individualmente hoy, y en qué nivel? ¿Qué tráfico llega a las herramientas sin pasar por el gateway? Y cuando seguridad decide cortarle una herramienta a un agente, ¿cuántos minutos tarda y quién tiene que dar el visto bueno?