Servidores MCP para IAM: cuáles pueden crear usuarios y cuáles solo pueden leer

Una petición habitual a un administrador: «Crea un usuario, añádelo al grupo Engineering y revócale el acceso dentro de una semana». Para un agente de IA, es una sola frase. Para IAM, son varias operaciones administrativas, y cada una puede acabar en un incidente. El autor de un artículo en Habr comparó lo que los proveedores ya ofrecen a través de Model Context Protocol, y el resultado dejó un panorama desigual.

Qué puede hacer cada uno a 9 de noviembre de 2026

El autor revisó la documentación oficial y las listas de herramientas. No sometió los tenants a pruebas de carga, por lo que se trata de una comparación de las capacidades anunciadas, no de una auditoría independiente.

Okta: servidor autohospedado y de código abierto, en disponibilidad general desde febrero de 2026, capaz de crear y modificar usuarios y grupos. Incluye scopes de OAuth, filtrado de herramientas y aprobación de acciones destructivas mediante MCP Elicitation. La versión alojada sigue en Early Access.

Microsoft MCP Server for Enterprise: en versión preliminar pública y de solo lectura, con tres herramientas para solicitudes GET de Graph y acceso al esquema.

PingOne Remote MCP Server: en Early Access, permite crear, modificar y eliminar usuarios, aunque el propio proveedor desaconseja habilitar estas funciones en producción. Activarlo para un entorno expone todas las herramientas permitidas por el rol.

JumpCloud: creación, suspensión y eliminación de usuarios, modificación de grupos, revocación de sesiones OAuth y eventos en Directory Insights.

Auth0: el servidor automatiza aplicaciones, API, Actions y registros, pero la documentación de referencia no incluye gestión de usuarios ni de grupos. Para la tarea de dar de alta a un empleado, es una diferencia fundamental.

En los materiales oficiales, Keycloak aparece como servidor de autorización para otros servidores MCP, no como el sistema que se administra. Para administrar el directorio hay que recurrir a un servidor de la comunidad y evaluar por separado su modelo de acceso.

Cinco comprobaciones en lugar de contar herramientas

1. Qué está habilitado por defecto. Lo ideal es que el servidor esté desactivado o funcione en modo de solo lectura hasta que un administrador autorice más capacidades. También importa la granularidad de los controles una vez activado.
2. En nombre de quién actúa el agente. La identidad OAuth de un administrador, con sus roles asignados, facilita más la auditoría que una clave API compartida en variables de entorno.
3. Comprobación de permisos en cada llamada. Ocultar herramientas innecesarias en tools/list resulta útil, pero no equivale a autorizar. También hacen falta comprobaciones en tools/call: la lista puede haber quedado desactualizada y una llamada puede construirse manualmente.
4. Qué aprueba exactamente la persona. En Okta, si el cliente no puede mostrar un diálogo de Elicitation, el servidor devuelve un JSON que interpreta el modelo. El límite de confianza es distinto del que ofrece una página de aprobación generada por el propio sistema IAM a partir de una operación almacenada.
5. Cómo identificar al agente en los registros. Es necesario saber qué cliente inició el cambio y quién lo aprobó. Ping registra en la auditoría tanto el user_id del administrador como el client_id del servidor MCP.

La inyección de prompts plantea otro riesgo: el nombre de un grupo o un atributo de usuario pueden contener instrucciones para el modelo. Los resultados de las herramientas no deben tratarse como órdenes fiables; el servidor debe imponer los límites de permisos.

Una aprobación, una operación

El autor desarrolla issuerd y lo declara expresamente. En su proyecto, el servidor almacena los valores canónicos de tool y arguments; la persona vuelve a autenticarse y ve una página construida con datos del servidor. Tras la aprobación mediante CIBA, el cliente recibe un token DPoP de corta duración, sin refresh token. Se rechazan las modificaciones del id, los argumentos o el realm, y repetir la misma llamada devuelve el resultado almacenado sin ejecutar una segunda eliminación.

Esto no es un estándar de MCP. Requiere un cliente compatible con DPoP y CIBA, e issuerd no ofrece administración entre realms ni M2M desatendido.

Qué hacer en la práctica

La especificación MCP Authorization 2026-07-28, con OAuth 2.1 y Resource Indicators, aborda cómo obtiene un cliente acceso a un servidor MCP. No define cómo aprueba una persona la eliminación de un usuario concreto.

La lista de comprobación del autor: empezar con un tenant de pruebas y en modo de solo lectura; contrastar el tools/list real con la tarea; asignar un rol con los permisos mínimos; preferir una identidad delegada a un secreto compartido; exigir una nueva aprobación para las eliminaciones y los roles privilegiados; filtrar las acciones MCP en los registros de auditoría; y ensayar de antemano la revocación del acceso del agente. Los estados Early Access y «no apto para producción» forman parte de la decisión arquitectónica, no de la letra pequeña.

Las comprobaciones deben situarse donde el modelo no pueda reescribirlas: en los roles, los scopes, la audiencia del token, la página de aprobación generada por el servidor y los registros de auditoría. El viejo problema del confused deputy sigue ahí; ahora el intermediario simplemente explica sus acciones con elocuencia.