MCP es fácil en una demo. En producción, cada llamada a una herramienta necesita un nombre detrás

Las demos de Model Context Protocol suelen mostrar lo fácil que es que un agente incorpore una herramienta nueva: se le indica un servidor y la herramienta aparece. Las empresas se enfrentan a la pregunta contraria. ¿Quién llama a esta herramienta, con la autoridad de quién, y cómo se comprueba cada llamada? Dos anuncios de la última semana la responden desde lados distintos.

AWS: la herramienta queda detrás de la identidad corporativa

El 2 de octubre, Jishnu Dasgupta, arquitecto de soluciones de AWS, publicó una arquitectura de referencia para añadir búsqueda web a Claude Desktop a través de Amazon Bedrock AgentCore Gateway. La clave del diseño es lo que el escritorio no guarda: ninguna clave de API de búsqueda en el equipo del usuario.

La cadena funciona así. El usuario inicia sesión con AWS IAM Identity Center, el SSO de la organización. Amazon Cognito federa esa identidad y emite un JWT mediante un flujo OAuth 2.0 de código de autorización. AgentCore Gateway valida el token en cada petición y expone la herramienta gestionada de búsqueda como endpoint compatible con MCP sobre HTTP con streaming. Claude Desktop descubre la herramienta con la llamada estándar tools/list de MCP y la usa cuando necesita información actual. AWS afirma que el tráfico de las consultas permanece dentro de su infraestructura.

Dos límites que conviene anotar. Es una arquitectura de tutorial, no una afirmación de que todo despliegue MCP necesite exactamente este stack. Y la búsqueda gestionada está disponible hoy en US East (Norte de Virginia), Europa (Irlanda) y Asia Pacífico (Tokio); configurar Identity Center exige la cuenta de administración de AWS Organizations.

Ping: el agente toma prestada la autoridad del usuario

El 29 de septiembre, Ping Identity lanzó tres agentes de identidad para Gemini Enterprise, disponibles en Google Cloud Marketplace y construidos con el Agent Development Kit de Google. Los empleados pueden gestionar sus dispositivos de autenticación conversando; el soporte técnico y los administradores de identidad gestionan usuarios, sesiones, accesos y altas de MFA.

El detalle de diseño que importa: Ping afirma que el agente de dispositivos sigue un modelo de mínimo privilegio, no guarda credenciales permanentes y no puede actuar sin la indicación del usuario autenticado. Las acciones pasan por las API de Ping, dentro de la autoridad asignada a la persona, y los cambios administrativos en Advanced Identity Cloud exigen confirmación explícita. Su consejero delegado, Andre Durand, lo resumió como mantener “cada acción vinculada a la autoridad de la persona que está detrás”.

Cinco identidades en cada llamada

Si se juntan ambas piezas, una llamada MCP en producción implica más identidades de las que admite una demo:

• la persona que pidió el trabajo;
• el agente que decidió llamar a la herramienta;
• la credencial que lleva la llamada, idealmente de vida corta y acotada a esa llamada;
• la identidad de la herramienta o del servidor, en la que confía el gateway;
• el responsable del agente y de la herramienta.

1. El usuario entra con el SSO corporativo
2. Token emitido para ese usuario y cliente
3. El agente pide la herramienta vía MCP
4. El gateway valida token y política
5. La herramienta actúa con la autoridad del usuario
6. Llamada registrada con usuario, agente y herramienta

• Quién: El usuario entra con el SSO corporativo · Token emitido para ese usuario y cliente
• Qué: El agente pide la herramienta vía MCP
• Aplicado y registrado: El gateway valida token y política · La herramienta actúa con la autoridad del usuario · Llamada registrada con usuario, agente y herramienta

Identidad humanaIntención del agente

Qué deben llevarse los equipos

Deje de repartir claves de API estáticas a los agentes. Una clave en un portátil o en la configuración de un agente es una credencial sin usuario asociado. Ponga las herramientas detrás de un gateway que acepte tokens ligados a una persona autenticada o a una identidad de agente.

Decida cuándo el agente actúa como el usuario y cuándo como sí mismo. La autoridad delegada (el modelo de Ping) es lo correcto cuando la acción pertenece al usuario. Una identidad propia del agente, con derechos estrechos, es lo correcto para el trabajo en segundo plano. Mezclarlas, por ejemplo un agente con todos los derechos de un usuario ejecutándose sin supervisión, es donde empiezan los incidentes. Lo desarrollamos en nuestro análisis de la identidad de los agentes como disciplina propia de IAM.

Haga del gateway el punto de control. La validación de tokens, la lista de herramientas permitidas y la política por herramienta deben estar en un único lugar que registre cada llamada. Es el papel que describimos para el gateway de IA como punto de aplicación de políticas.

Apóyese en el proveedor de identidad que ya tiene. En un entorno Microsoft, las mismas preguntas se resuelven con Entra ID como proveedor de identidad y un gateway como Azure API Management delante de los servidores MCP. El artículo de AWS no cubre esa configuración, y los detalles cambian, pero las preguntas de auditoría son idénticas.

Mire adónde van las consultas. Para una empresa española, una herramienta que se ejecuta en la región de Irlanda mantiene el tráfico dentro de la UE; una que se ejecuta en Virginia no. Si un empleado pega datos de clientes en una búsqueda, eso es una transferencia internacional sujeta al capítulo V del RGPD. En México, Colombia o Chile, donde la búsqueda gestionada no tiene región propia, las consultas salen siempre del país, y cada legislación nacional de datos personales decide qué condiciones exige. No es motivo para no usarla; es motivo para decidir antes qué puede contener una consulta.

Recuerde por qué es urgente. El nuevo informe de amenazas de Microsoft, que analizamos en nuestro artículo sobre agentes e higiene de identidad, incluye la identidad del agente, la autenticación entre agentes y la revocación entre las preguntas que ahora son del equipo de seguridad.

Qué hacer ahora

1. Inventaríe los servidores y herramientas MCP en uso, incluidos los que los desarrolladores conectaron por su cuenta, y las credenciales de cada uno.
2. Retire las claves estáticas de escritorios y configuraciones de agentes; sustitúyalas por tokens validados en el gateway.
3. Clasifique cada herramienta: actúa como el usuario o como el agente. Déjelo por escrito.
4. Exija SSO en toda llamada a herramientas iniciada por una persona, y registre juntos usuario, agente y herramienta.
5. Añada confirmación en las acciones administrativas o irreversibles, como hace Ping con los cambios de identidad.
6. Compruebe dónde se ejecuta la herramienta y adónde va su tráfico antes de habilitarla para datos regulados.

En resumen

MCP resolvió cómo encuentran los agentes sus herramientas. No resolvió quién puede usarlas. Las empresas que lleven MCP a producción serán las que traten cada llamada a una herramienta como una petición autenticada, autorizada y registrada, con una persona o un agente con nombre detrás.