Autenticación en MCP explicada: identidad entrante, credenciales salientes y delegación

El token que identifica a quien realiza la llamada a una pasarela y la credencial utilizada para llegar a un servicio posterior resuelven problemas diferentes. Los sistemas MCP seguros mantienen esa distinción.

La autenticación no es cuestión de un solo salto

Una solicitud MCP puede cruzar varios límites de confianza antes de que un sistema de negocio la procese. Una persona o servicio se autentica ante una aplicación. Un agente puede actuar como un principal de software independiente. El cliente se autentica ante MCP Gateway. La pasarela decide si quien llama puede utilizar un servidor o una herramienta. Luego, la pasarela se autentica ante el servidor MCP saliente, el cual puede llamar a otro servicio con autoridad.

Utilizar la palabra «token» para cada credencial hace que estos límites desaparezcan. La credencial entrante responde a quién está llamando a la pasarela. La directiva de acceso responde a qué recursos de la pasarela puede utilizar esa identidad. La autenticación saliente determina qué credenciales y permisos recibe el servidor posterior. Esas respuestas pueden ser intencionadamente diferentes.

La documentación de TrueFoundry divide la arquitectura en autenticación entrante, control de acceso y autenticación saliente. Esa separación es el punto de partida adecuado para razonar sobre delegación, atribución y el riesgo del diputado confundido (confused deputy).

La pasarela se divide intencionadamente en tres comprobaciones. Una autenticación entrante correcta identifica a quien realiza la llamada, pero la directiva de acceso sigue seleccionando las herramientas permitidas y la autenticación saliente sigue determinando el principal que ve el servidor MCP.

La autenticación entrante resuelve el cliente de la pasarela

TrueFoundry documenta varios métodos entrantes: un token de acceso personal para usuarios con cuentas de TrueFoundry, un token de cuenta virtual para llamadas entre servicios, un token de proveedor de identidad para clientes o servicios que utilizan el emisor JWT de una organización, y OAuth de TrueFoundry para clientes IDE compatibles.

Tras validar la credencial, la pasarela resuelve una identidad de TrueFoundry y aplica el control de acceso a los servidores MCP y a las herramientas individuales. La identidad relevante puede ser un usuario, un equipo o una cuenta virtual. La identidad del agente (Agent Identity), documentada como beta, añade un actor agente registrado independiente para las llamadas que se originan en un agente. Esto es diferente de una cuenta virtual, que representa un servicio o aplicación sin un ser humano detrás.

La resolución de identidad debe validar el emisor, la audiencia, la firma, los límites de tiempo y la asignación de notificaciones (claim mapping) utilizada para seleccionar el sujeto. Un token firmado válidamente para una audiencia incorrecta no otorga autoridad ante la pasarela. Las asignaciones deben ser lo suficientemente específicas como para que dos servicios no se resuelvan accidentalmente con la misma identidad de agente.

La autenticación saliente selecciona el principal posterior

La pasarela puede autenticarse ante un servidor MCP utilizando código de autorización OAuth por usuario, credenciales de cliente OAuth a nivel de aplicación, la configuración documentada de intercambio de tokens/OBO de Okta, claves API compartidas o individuales, sin autenticación para servicios públicos, passthrough de tokens, reenvío de tokens o AWS SigV4 para puntos de enlace de AWS admitidos.

Estos modos codifican autoridades distintas. El flujo OAuth por usuario permite que cada persona autorice su propia cuenta de terceros. Las credenciales de cliente representan a la aplicación y suelen exponer permisos de servicio compartidos. El intercambio de tokens u OBO solicita a un sistema de identidad que emita un nuevo token saliente derivado de la identidad del cliente y dirigido a otra audiencia. Una clave API compartida agrupa a todos los clientes en un único principal ascendente, incluso si la pasarela conserva la atribución interna.

Elegir la integración más sencilla puede cambiar silenciosamente el modelo de autorización. Si un servidor MCP de Gmail utiliza una sola credencial de servicio compartida, el servicio ascendente no ve la autoridad de la casilla de correo personal de cada empleado. Si un servidor MCP interno valida directamente el token del IdP de la organización, el passthrough puede conservar el sujeto, pero solo si el emisor, la audiencia y los ámbitos (scopes) se aceptan deliberadamente.

El diagrama agrupa los modos por la semántica de autoridad en lugar de por las etiquetas del protocolo. Los flujos por usuario y OBO pueden preservar el contexto del sujeto, mientras que las credenciales de cliente y las claves compartidas representan la autoridad de la aplicación, a menos que el servicio posterior aplique controles adicionales conscientes del sujeto.

Passthrough y reenvío no son sinónimos

En la terminología documentada de TrueFoundry, el passthrough de tokens reenvía al servidor MCP el mismo token utilizado para la autenticación entrante. El servidor debe poder validar ese token de TrueFoundry o del proveedor de identidad. El reenvío de tokens transporta credenciales específicas del servidor independientes, proporcionadas por el cliente en encabezados dedicados. La credencial saliente no es el portador (bearer) entrante.

Esta distinción es importante para el registro, la redacción, la revocación y el modelado de amenazas. El passthrough conserva una sola credencial a través del límite de la pasarela y, por lo tanto, requiere una confianza de audiencia correcta en el servicio posterior. El reenvío introduce otro secreto que el cliente debe obtener y proteger. Ninguno de los dos demuestra automáticamente que la API de negocio final haya verificado la relación prevista entre el humano y el agente.

El intercambio de tokens OAuth y OBO ofrecen un patrón diferente: la pasarela o la capa de identidad obtienen un nuevo token específico para la audiencia que representa la autoridad delegada. Esto puede reducir la reutilización de tokens portadores y permitir que los sistemas posteriores apliquen ámbitos diseñados para su recurso. Las garantías exactas dependen del proveedor de identidad, las notificaciones, la validación y la aplicación posterior.

Modele los principales, no solo los encabezados

Evite el problema del diputado confundido

Una pasarela se convierte en un diputado confundido (confused deputy) cuando tiene una amplia autoridad posterior y la utiliza para un cliente que carece de un permiso equivalente. La autenticación entrante puede ser perfectamente válida mientras que la acción compuesta sigue estando sobreautorizada. La pasarela debe vincular la identidad del cliente, la identidad del agente, el servidor y la herramienta solicitados, el modo de credencial saliente y el ámbito posterior.

En el caso de las credenciales compartidas, el servidor MCP o la aplicación de respaldo deben recibir suficiente contexto de confianza para volver a aplicar una autorización consciente del sujeto, o la herramienta debe exponer únicamente recursos que sean seguros para todos los clientes permitidos. No confíe en que el modelo filtre los resultados después de una consulta amplia. Para credenciales por usuario, verifique que la autorización esté vinculada al sujeto previsto y que otro usuario no pueda sustituirla mediante anulaciones (overrides).

Cada salto también debe conservar un identificador de correlación para auditorías sin copiar tokens portadores en los registros. Registre el modo de credencial, la identidad resuelta, el emisor, la audiencia, la clase de ámbito, la versión de la directiva y los metadatos de respuesta posteriores. Los valores secretos pertenecen a almacenes protegidos, no a transcripciones o trazas.

La cadena transporta tanto a un sujeto humano como a un actor de software a través de la decisión de la pasarela. El modo saliente puede preservar, intercambiar o agrupar ese contexto de identidad; el sistema posterior sigue realizando la autorización final del recurso y la acción.

Un ejemplo práctico: acceso al CRM de atención al cliente

Un agente de soporte recibe una solicitud de un empleado autenticado. La aplicación envía el token del proveedor de identidad del empleado a MCP Gateway y presenta por separado la identidad del agente registrado. La directiva de la pasarela permite que ese par usuario-agente llame a la herramienta de búsqueda del CRM.

Asuma que la implementación utiliza la configuración Okta OBO documentada de TrueFoundry. La pasarela intercambia el token de usuario entrante por un token orientado a la audiencia del CRM con un ámbito de casos de solo lectura. El CRM valida el nuevo token y aplica su propia autorización a nivel de fila. El agente puede recuperar los casos permitidos del empleado, pero no puede modificarlos. Una herramienta de actualización independiente requiere un ámbito posterior más restringido y una aprobación.

Si la implementación utiliza en su lugar una clave API compartida, la arquitectura debe compensarlo. El servicio orientado al CRM recibe un atributo de sujeto resuelto de confianza desde la pasarela, lo valida y filtra los registros en el lado del servidor. Si el servicio no puede aplicar el contexto del sujeto, la clave compartida no es adecuada para datos con autorización específica de usuario.

Elija la autenticación saliente según la semántica de autoridad

• Utilice la autorización por usuario cuando el recurso ascendente sea propiedad de cada persona o esta tenga permisos sobre él.
• Utilice credenciales de cliente para recursos que sean genuinamente propiedad de la aplicación, no como un atajo para eludir la autorización del usuario.
• Utilice el intercambio de tokens u OBO cuando el sistema posterior necesite un token de usuario delegado y específico para su audiencia.
• Utilice passthrough solo cuando el sistema posterior confíe en el token entrante y lo valide deliberadamente.
• Utilice el reenvío cuando el servidor MCP tenga un esquema de credenciales independiente y acepte la carga resultante de la gestión de secretos en el cliente.
• Trate los servidores sin autenticación como capacidades públicas; no coloque datos confidenciales ni operaciones de mutación detrás de ellos.

Pruebas de fallos para la cadena de autenticación

• Reproduzca un token válido con una audiencia, emisor, inquilino (tenant) o sujeto asignado incorrectos.
• Mantenga el usuario constante y cambie la identidad del agente; verifique que el alcance efectivo de la herramienta cambie según lo diseñado.
• Mantenga el agente constante y cambie el usuario; verifique que los datos posteriores sigan al sujeto humano donde sea necesario.
• Sustituya una credencial individual a través de la anulación de autenticación de otro usuario.
• Revoque una concesión de la pasarela y una concesión de OAuth ascendente de forma independiente; verifique sus diferentes efectos.
• Llame al servidor MCP fuera de la pasarela; verifique que la directiva de red y del servidor impidan una elusión cuando sea necesario.
• Inspeccione registros, trazas, errores y el contexto del modelo para detectar fugas de tokens portadores o secretos reenviados.

El ciclo de vida de las credenciales forma parte de la ruta de datos

El diseño de la autenticación continúa después de que se acepta un token. Las credenciales expiran, se renuevan, se rotan y se revocan en diferentes sistemas. La documentación de TrueFoundry señala, por ejemplo, que su acción «Revocar todos los tokens» elimina las credenciales almacenadas de AI Gateway, pero no revoca las concesiones en el proveedor de OAuth ascendente. Los operadores necesitan procedimientos independientes para la credencial de la pasarela, la sesión del proveedor de identidad, la autorización ascendente y cualquier token posterior almacenado en caché.

Defina qué componente renueva cada credencial, qué sujeto representa el token renovado y qué sucede cuando la renovación falla a mitad de la tarea de un agente. Un flujo de autorización en pausa no debería recurrir silenciosamente a una credencial de aplicación con un acceso más amplio. Cuando el usuario vuelva a conectar una cuenta, la nueva concesión debe correlacionarse con el sujeto y el servidor previstos antes de que el agente continúe.

La rotación crea otro límite de prueba. Las claves API compartidas pueden necesitar un periodo de clave doble; los tokens OAuth por usuario pueden invalidarse de forma independiente; los tokens OBO pueden almacenarse en caché hasta su expiración, mientras que el token entrante debe mantenerse actualizado para un nuevo intercambio. Almacene los identificadores del modo de credencial y de la familia de tokens en metadatos operativos protegidos para que los encargados de responder puedan encontrar las llamadas afectadas sin exponer secretos.

La revocación debe verificarse de afuera hacia adentro. Elimine al colaborador de la pasarela, revoque la concesión ascendente, deshabilite la cuenta posterior y pruebe cada efecto por separado. Un procedimiento de incidentes completo sabe qué acción detiene las nuevas llamadas a la pasarela, cuál invalida el acceso directo y cuál solo elimina una copia local.

El manejo de tokens también debe estar ausente del contexto visible para el modelo. Los agentes pueden razonar sobre etiquetas de identidad estables, resultados de autorización e instrucciones de reconexión sin recibir material portador. Los errores devueltos por los proveedores deben normalizarse para que la salida de depuración no filtre encabezados, tokens de renovación, secretos de cliente o componentes de solicitud firmados en la transcripción.

La regla operativa

Una autenticación MCP segura comienza nombrando a cada principal y a cada salto. La identidad entrante, el acceso a la pasarela, la credencial saliente y la autorización de negocio son controles relacionados pero no intercambiables. El diseño más seguro hace explícito cualquier cambio de principal o de audiencia.

TrueFoundry MCP Gateway proporciona mecanismos documentados para cada capa orientada a la pasarela, e Identidad del agente (documentada como beta en el mapa de disponibilidad de gobernanza) puede distinguir el actor de software del sujeto humano. La aplicación posterior sigue siendo la propietaria de la autorización de su dominio y la organización sigue siendo la responsable de la minimización de credenciales. Ese límite no es una limitación en la explicación; es lo que hace que el modelo de seguridad sea evaluable.

Referencias

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

Aviso editorial. Este artículo refleja la interpretación de ingeniería de TrueFoundry sobre los materiales públicos citados a fecha de 17 de septiembre de 2026. Las capacidades del producto están delimitadas en la documentación enlazada. Los ejemplos y las opciones predeterminadas de funcionamiento son ilustrativos; no constituyen asesoramiento legal, una opinión de auditoría, una comparativa independiente ni una garantía de seguridad, protección o cumplimiento normativo.

‍