MCP conecta agentes a sus herramientas. No las gobierna. watsonx Orchestrate muestra la capa que falta

Model Context Protocol hizo por las herramientas de los agentes lo que el USB hizo por los periféricos: una forma estándar de conectar cosas. Por eso la adopción ha sido rápida. Y por eso la gobernanza va por detrás. Un conector estándar dice cómo se llama a una herramienta; no dice qué herramientas pueden llamarse, quién puede hacerlo, con qué frecuencia, con qué entradas ni qué pasa cuando una llamada parece incorrecta.

La versión de finales de septiembre de watsonx Orchestrate, de IBM, es una buena muestra de lo que contiene esa capa que falta.

Qué ha lanzado IBM

Las notas de versión del equipo de watsonx Orchestrate, publicadas el 22 de septiembre, incluyen:

• Registro de MCP por tenant. Los servidores MCP remotos pueden registrarse directamente en el espacio de nombres de un tenant desde el catálogo, de modo que un equipo use una herramienta sin publicarla en el catálogo global.
• Controles personalizados sobre las herramientas. Desde una página unificada de Controles, los administradores definen reglas de validación, vigilan el número de ejecuciones de cada herramienta y aplican salvaguardas de runtime. Los controles se aplican a herramientas MCP, especificaciones OpenAPI y paquetes de plugins ZIP, junto con los controles propios de IBM.
• Monitorización por espacio de trabajo. Los dashboards se pueden filtrar por espacio de trabajo privado para ver rendimiento, uso y métricas operativas. IBM indica que este filtro es exclusivo de IBM Cloud.
• Soporte del protocolo Agent-to-Agent (A2A) para conectar agentes externos, además de novedades como la transcripción de llamadas en tiempo real para Genesys Cloud Agent Assist.

Nada de esto es espectacular por separado. En conjunto, describe los controles que necesita un equipo de plataforma cuando MCP deja de ser un experimento de desarrolladores.

La capa de gobernanza de herramientas, pieza a pieza

1. Servidor MCP registrado en un tenant
2. Herramienta habilitada para agentes concretos
3. Reglas de validación de entrada y salida
4. Recuento y límite de ejecuciones
5. Salvaguardas de runtime
6. Uso vigilado por espacio de trabajo

• Quién puede usarla: Servidor MCP registrado en un tenant · Herramienta habilitada para agentes concretos
• Cómo puede usarse: Reglas de validación de entrada y salida · Recuento y límite de ejecuciones · Salvaguardas de runtime
• Evidencia: Uso vigilado por espacio de trabajo

AlcancePolítica en cada llamada

Alcance. Una herramienta registrada en un tenant o espacio de trabajo no queda disponible automáticamente para todos los agentes. Es la diferencia entre una tienda interna de aplicaciones y una carpeta compartida.

Validación. Las reglas sobre entradas y salidas detectan los fallos evidentes: una herramienta de pagos llamada con un importe por encima del umbral, una consulta que devuelve datos personales que el agente no debería ver, un parámetro fuera de su rango permitido.

Límites. El recuento de ejecuciones es un control de fiabilidad y de coste. Un agente atrapado en un bucle llamando mil veces a la misma herramienta debería toparse con un techo, no con una factura.

Salvaguardas de runtime. Una política aplicada en el momento de la llamada, fuera del razonamiento del agente, es el mismo principio que describimos en nuestro análisis sobre la contención de agentes: la frontera debe estar donde el agente no pueda discutir con ella.

Monitorización. El uso por espacio de trabajo es la evidencia que necesita un responsable para responder “¿qué agentes usaron esta herramienta y cuántas veces?”

Lo que no cubren los controles de la plataforma

Una capa de control gobierna cómo usan sus agentes una herramienta. No convierte en fiable al servidor MCP. Un servidor de terceros puede cambiar de comportamiento, devolver contenido envenenado o tener vulnerabilidades propias. Trate cada servidor MCP externo como un proveedor: quién lo mantiene, cómo se actualiza, qué datos recibe y qué dicen sus condiciones. Fijar versiones y revisar cambios importa tanto como en cualquier otra dependencia.

Para una entidad financiera española, esto tiene un encaje concreto. DORA exige mantener un registro de información de todos los acuerdos con proveedores terceros de servicios TIC y gestionar su riesgo. Un servidor MCP externo que lee o modifica datos de clientes es, a todos los efectos, un servicio TIC de un tercero, y debería figurar en ese registro como cualquier otro.

La identidad es la otra mitad. Los controles sobre herramientas funcionan mejor cuando cada llamada ya lleva la identidad de un usuario o de un agente, que es el tema de nuestro análisis de por qué el MCP empresarial empieza por la identidad.

En un stack Microsoft

Los controles de IBM son de IBM; no existen dentro de los productos de Microsoft. Las preguntas, en cambio, son las mismas. En Copilot Studio, los servidores MCP se añaden mediante conectores, así que las directivas de datos de Power Platform y los límites de entorno son el lugar natural para decidir qué agentes usan qué herramientas. En Foundry, ese papel lo cumple el gateway situado delante de las herramientas. Sea cual sea la plataforma, escriba los mismos cinco controles: alcance, validación, límites, política de runtime y monitorización.

Qué hacer ahora

1. Inventaríe los servidores MCP en uso en todas las plataformas, incluidos los que han añadido los desarrolladores.
2. Registre las herramientas por equipo o espacio de trabajo, no de forma global, y mantenga una lista de herramientas permitidas por agente.
3. Escriba primero reglas de validación para las herramientas de alto impacto: pagos, cambios de registros, exportación de datos.
4. Fije límites de ejecución en cada herramienta, con alertas antes de alcanzarlos.
5. Trate los servidores MCP de terceros como proveedores: responsable, versión fijada, revisión de cambios, datos recibidos y, en el sector financiero, alta en el registro de proveedores TIC.
6. Compruebe la disponibilidad de cada función según el modelo de despliegue (IBM indica que parte de la monitorización es solo de IBM Cloud) antes de diseñar sobre ella.

En resumen

MCP resolvió la fontanería. Ahora las plataformas competirán en las válvulas: alcance, validación, límites, política de runtime y evidencia. Con IBM, con Microsoft o con cualquier otro stack, la capa de gobernanza le corresponde definirla a usted, y conviene tenerla lista antes de que el número de herramientas conectadas la haga dolorosa.