OAuth en la capa MCP: Cómo resolvimos la gestión de tokens empresariales para agentes de IA

Un recorrido por la arquitectura de autenticación dentro de la pasarela MCP de TrueFoundry — tres planos, dos flujos de OAuth, una bóveda de credenciales — contado a través de la experiencia de un cliente que lo implementa en producción.

Una mañana de lunes en Northwind. A las 8:47 a.m. de un lunes, el ingeniero de guardia de Northwind Logistics — una plataforma de cadena de suministro ficticia pero, por desgracia, plausible, con 50 ingenieros — recibe un aviso de Slack. Su asistente de IA interno, Cargo Copilot, está devolviendo errores 401 para cada llamada a las herramientas de Jira y GitHub. La causa raíz es el portátil de un desarrollador, perdido en el aeropuerto durante el fin de semana. TI ha revocado la sesión SSO del portátil. Pero el portátil también contenía tokens de OAuth para GitHub, Slack, Jira y un servicio de análisis interno, cada uno copiado en la configuración del editor y los dotfiles del desarrollador. Seguridad no puede decir con certeza qué alcances se expusieron, en qué otras máquinas se replicaron esos tokens (porque los desarrolladores se ayudan entre sí), o cómo revocarlos todos sin arruinar la mañana de nadie.

El incidente de Northwind no es algo exótico. Es lo que parece la gestión de credenciales en la mayoría de las empresas seis meses después de una adopción entusiasta de MCP. El resto de esta publicación es la historia arquitectónica de cómo Northwind — y otros clientes de TrueFoundry — dejan de reproducir este incidente.

1. El problema de la proliferación de credenciales: Cómo se ve realmente 50 desarrolladores × 8 servidores MCP

Northwind cuenta con aproximadamente cincuenta ingenieros que utilizan activamente IDEs compatibles con MCP para ocho servidores — GitHub, Slack, Google Workspace, Jira, un servicio de análisis interno, una API de logística interna, Zendesk y un servicio propietario de planificación de rutas. Eso son cuatrocientas conexiones activas según la aritmética obvia, y en la práctica, un número sustancialmente mayor de ubicaciones de credenciales una vez que se cuentan las entradas del llavero, la configuración del editor, los archivos de entorno de shell, las variables de CI y las copias que la gente hace al incorporar a un compañero de equipo.

El radio de impacto de una estación de trabajo comprometida no es un solo token. Es un token multiplicado por los alcances asociados a ese proveedor, la vida útil del token (a menudo 90 días o más para los tokens de acceso personal), el número de máquinas que lo replicaron y la ausencia de revocación centralizada. Si un token de OAuth de Slack permite la lectura del historial del canal y un token de GitHub colocalizado permite la lectura del repositorio, una única exfiltración se convierte en un incidente entre sistemas antes de que el equipo de seguridad tenga la oportunidad de responder. Las credenciales MCP locales también son operacionalmente invisibles: no hay una pista de auditoría unificada, no hay rotación forzada, no hay verificación de políticas antes de ejecutar una herramienta, no hay una forma rápida de responder quién puede llamar a qué.

El patrón de pasarela cierra la brecha. Los desarrolladores se autentican una vez en la pasarela, y esta gestiona la autenticación posterior según el modelo configurado de cada servidor — que es exactamente el diseño descrito en Descripción general de la pasarela MCP de TrueFoundry y los documentos de autenticación y seguridad. El beneficio no es solo la consolidación. Es que la autenticación se convierte en una propiedad de la infraestructura en lugar de una propiedad de cada portátil de la empresa.

2. La arquitectura de autenticación de tres planos: Entrada, control de acceso y salida

La primera decisión de diseño es separar tres planos que las configuraciones locales de los desarrolladores suelen confundir. Los documentos de autenticación y seguridad de TrueFoundry describen esto como un sistema de tres partes: autenticación de entrada, control de acceso, y autenticación saliente. La documentación es explícita en que las capas de entrada y salida son independientes, lo cual es la ventaja arquitectónica.

• Autenticación entrante. ¿Quién llama a la pasarela? TrueFoundry admite cuatro métodos: clave API de TrueFoundry (PAT), token de cuenta virtual, token de proveedor de identidad (un JWT de Okta/Auth0/Azure AD validado a través de un proveedor de identidadconfigurado), y OAuth de TrueFoundry (utilizado por IDEs como Cursor y VS Code).
• Control de acceso. ¿Qué puede hacer la identidad resuelta? Cada servidor MCP tiene Colaboradores —usuarios, equipos o cuentas virtuales— con permisos basados en roles. El alcance a nivel de herramienta se logra combinando herramientas de múltiples servidores MCP en un Servidor MCP Virtual, que expone solo un subconjunto seleccionado.
• Autenticación saliente. ¿Cómo llega la pasarela a cada servidor descendente? Se admiten siete métodos: OAuth2 (Código de autorización), OAuth2 (Credenciales de cliente), Clave API (Compartida), Clave API (Individual), Sin autenticación, Paso de token y Reenvío de token a través de x-tfy-mcp-headers.

‍

El principio de diseño es simple: la credencial utilizada para llegar a la pasarela nunca es la credencial que llega a la herramienta descendente. La rotación de entrada no afecta ningún estado OAuth del proveedor. Un servidor MCP de GitHub puede usar OAuth por usuario mientras que el servicio de análisis interno usa Credenciales de Cliente — en el mismo agente, en el mismo flujo de solicitud. La pasarela es tanto el punto de aplicación de políticas como el intermediario de credenciales.

3. 2LO vs 3LO: Elegir el tipo de concesión OAuth adecuado para cada servidor MCP

En la jerga empresarial, 2LO y 3LO se refieren a dos tipos de concesión de RFC 6749 (OAuth 2.0), mapeado a cómo participan los usuarios finales.

OAuth de dos patas (2LO) usa el Client Credentials grant. La pasarela tiene un client_id y client_secret, envía grant_type=client_credentials al endpoint de token del proveedor, recibe un access_tokende corta duración, y utiliza ese token en cada solicitud al servidor MCP. Sin navegador, sin consentimiento del usuario. Es la opción correcta para integraciones de servidor a servidor: APIs de análisis internas, microservicios de backend, servicios de datos internos.

OAuth de tres patas (3LO) usa el Authorization Code grant. Cada usuario final es redirigido al proveedor (GitHub, Slack, Google) para autorizar el acceso a sus recursos específicos. La pasarela almacena un refresh_tokenpor usuario, mantiene un mapeo cifrado de user_id → {access_token, expires_at, refresh_token, scopes, provider_metadata}, y rota el token de acceso automáticamente.

Cómo eligió Northwind

Los ocho servidores MCP de Northwind se dividen aproximadamente por la mitad. GitHub, Slack, Jira, Google Workspace y Zendesk son todas herramientas por usuario; el valor de "ejecutar esto como Alice" supera la sobrecarga operativa de un token por usuario. Esos usan 3LO. El servicio de análisis interno, la API de logística y el servicio de planificación de rutas exponen datos de toda la empresa; un OAuth por usuario no tiene sentido, y una única concesión de credenciales de cliente compartida es más sencilla y fácil de auditar. Esos usan 2LO.

Aspecto del modelo de configuración

Nota sobre esta vista de configuración

TrueFoundry registra los servidores MCP a través de la interfaz de usuario (Configuración → Servidores MCP → Añadir servidor MCP) en lugar de mediante un archivo YAML gestionado por el cliente, aunque la configuración también se puede aplicar de forma declarativa a través de tfy apply. El YAML a continuación muestra el modelo de configuración por servidor —los mismos campos que se rellenan en la interfaz de usuario— utilizando el esquema verificado de TrueFoundry (provider-account/mcp-server-group con integrationsanidadas).

# Northwind's backend-group MCP Server Group: two MCP servers, one per OAuth flow.
# Schema matches TrueFoundry's provider-account / integrations pattern (tfy apply).

name: backend-group
type: provider-account/mcp-server-group
collaborators:
  - subject: team:platform-engineering
    role_id: mcp-server-manager
  - subject: team:site-reliability
    role_id: mcp-server-manager
  - subject: virtualaccount:cargo-copilot-runtime
    role_id: mcp-server-manager

integrations:

  # ---- 3LO (Authorization Code): per-user OAuth on GitHub ----
  - name: github
    type: integration/mcp-server/remote
    description: GitHub MCP server using per-user OAuth Authorization Code flow.
    url: https://github-mcp.example.com/mcp
    transport: streamable-http
    authorized_subjects:
      - team:platform-engineering
      - team:site-reliability
      - virtualaccount:cargo-copilot-runtime
    auth_data:
      type: oauth2
      grant_type: authorization_code
      authorization_url: https://github.com/login/oauth/authorize
      token_url: https://github.com/login/oauth/access_token
      client_id: tfy-secret://northwind:github-oauth:client_id
      client_secret: tfy-secret://northwind:github-oauth:client_secret
      scopes:
        - repo
        - read:org
      jwt_source: access_token
      code_challenge_methods_supported:
        - S256

  # ---- 2LO (Client Credentials): shared service identity ----
  - name: internal-analytics
    type: integration/mcp-server/remote
    description: Internal analytics MCP server using OAuth2 Client Credentials.
    url: https://analytics-mcp.internal.example.com/mcp
    transport: streamable-http
    authorized_subjects:
      - team:platform-engineering
      - team:site-reliability
    auth_data:
      type: oauth2
      grant_type: client_credentials
      token_url: https://northwind.okta.com/oauth2/default/v1/token
      client_id: tfy-secret://northwind:analytics-oauth:client_id
      client_secret: tfy-secret://northwind:analytics-oauth:client_secret
      scopes:
        - analytics:read
      jwt_source: access_token

El comando para aplicar el YAML anterior es:

tfy apply -f backend-group.yaml --dry-run --show-diff

Tres cosas a destacar. Primero, tfy-secret:// es el esquema de referencia FQN canónico que TrueFoundry utiliza para los secretos almacenados en un grupo de secretos de TrueFoundry, con el formato separado por dos puntos tfy-secret://<tenant>:<secret-group>:<secret-key> documentado en la Guía de variables de entorno y secretos. El valor reside en su gestor de secretos (AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Key Vault); TrueFoundry resuelve el FQN en tiempo de ejecución, por lo que el archivo anterior es seguro en un repositorio Git. Segundo, authorized_subjects es la lista RBAC por servidor —una mezcla de equipos y cuentas virtuales— lo que permite que el mismo servidor MCP atienda a desarrolladores humanos (cuyos PAT se resuelven en membresías de equipo) y a trabajos programados de cuentas de servicio (cuyos tokens de cuenta virtual se asignan a virtualaccount: sujetos) sin desviación de configuración. En tercer lugar, la entrada 3LO establece code_challenge_methods_supported: [S256] — PKCE se recomienda para cada cliente de Código de Autorización hoy en día y es obligatorio en la especificación MCP más reciente del 25-11-2025.

En el lado del cliente, el agente nunca enumera los modos de autenticación. Se conecta a una URL de pasarela, presenta una credencial de entrada y la pasarela inyecta la credencial de salida correcta por servidor:

from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport

# Real URL pattern from the TrueFoundry docs.
transport = StreamableHttpTransport(
    url="https://llm-gateway.truefoundry.com/mcp-server/backend-group/github/server",
    headers={"Authorization": f"Bearer {user_token}"},
)

async with Client(transport) as client:
    result = await client.call_tool(
        "search_issues",
        {"query": "repo:northwind/logistics-core is:open label:critical"},
    )

4. Gestión del ciclo de vida del token: Actualización proactiva y acceso concurrente

La corrección de OAuth no se trata solo de obtener tokens. Se trata de operarlos de forma segura bajo carga concurrente. El diseño ingenuo se actualiza cuando el proveedor devuelve 401, o cuando ahora ≥ expires_at. Ese diseño funciona en demostraciones y falla el primer lunes que se enfrenta a la realidad.

Reproduzcamos el incidente de Northwind con una actualización ingenua: el lunes a las 8:47 a.m., cincuenta ingenieros se conectan, cada trabajador descubre de forma independiente el mismo token de GitHub caducado, cincuenta llamadas paralelas POST /token llegan a GitHub desde la misma pasarela, y GitHub limita la tasa de todas ellas. Cargo Copilot devuelve 401 a todos hasta que la cola se vacía.

El patrón que funciona en producción tiene dos ingredientes: actualizar proactivamente al 80% del TTL y serializar la actualización por (usuario, servidor) con un bloqueo distribuido.

def get_token(user_id, server_id):
    token = cache.get(user_id, server_id)
    if now() < token.issued_at + 0.8 * token.expires_in:
        return token

    # Crossed the 80% threshold. Serialize refresh so 50 workers
    # do not all hit the provider token endpoint at once.
    with distributed_lock(user_id, server_id):
        token = cache.get(user_id, server_id)   # re-read under lock
        if now() < token.issued_at + 0.8 * token.expires_in:
            return token   # someone else already refreshed

        new = provider.refresh(token.refresh_token)
        vault.put_atomic(user_id, server_id, new)   # access + refresh together
        cache.set(user_id, server_id, new)
        return new

Actualizar al 80% del TTL deja margen para la desviación del reloj, reintentos, puntos finales de token de proveedor lentos y solicitudes ya en curso. El bloqueo por (usuario, servidor) evita una avalancha de solicitudes contra el proveedor. La lectura doblemente verificada dentro del bloqueo no es cosmética: permite que la primera solicitud realice la actualización mientras el resto reutiliza el token recién escrito.

Dos sutilezas importan a escala. Primero, para las integraciones de Credenciales de Cliente, la clave de caché es (server_id, provider_account); para las integraciones de Código de Autorización, la clave debe incluir user_id. Segundo, los proveedores que rotan los tokens de actualización en cada actualización —Google y Microsoft lo hacen, dependiendo de la configuración— requieren que la escritura sea atómica. Si el nuevo access_token se compromete antes del nuevo refresh_token, un fallo deja al usuario varado con un token de actualización antiguo invalidado y una reautenticación forzada.

5. El Flujo de Doble Autenticación: Un Diagrama de Secuencia Completo

Con las capas separadas y la ruta de actualización definida, una solicitud MCP de extremo a extremo a través de la pasarela tiene una estructura precisa. Rastree una llamada de Cargo Copilot — "summarize the open critical-severity issues in repo northwind/logistics-core" — desde el agente hasta GitHub y de vuelta:

‍

Cabe destacar tres propiedades de este flujo. El agente nunca recibe el token de acceso de GitHub; solo la pasarela lo posee. El servidor MCP nunca ve la credencial de TrueFoundry de entrada de Northwind a menos que la transferencia de tokens (Token Passthrough) esté configurada explícitamente (más información en el §7). Y el equipo de seguridad de Northwind obtiene una única ruta de solicitud gobernada con identidad, autorización y auditoría registradas en un solo lugar — la misma propiedad que les habría permitido responder a la pregunta del lunes por la mañana, "¿qué alcances había en ese portátil?", en menos de un minuto.

La especificación de autorización MCP refuerza una parte de este panorama: los tokens de acceso de portador deben enviarse en el encabezado de solicitud Authorization y nunca en una cadena de consulta URI. Esa norma es importante precisamente porque mantiene los tokens fuera de los registros de acceso, el historial del navegador y los rastreos de proxy.

6. Integración de la Bóveda de Credenciales: Por qué los Secretos sin Procesar Nunca Tocan la Memoria de la Aplicación

Una pasarela de producción no debería tratar los tokens de actualización de OAuth como filas de aplicación ordinarias. Los secretos de cliente y los tokens de actualización son llaves de larga duración para el reino — filtrar un token de actualización de Slack es, para la mayoría de los propósitos, equivalente a filtrar el espacio de trabajo de Slack.

El patrón estándar es el cifrado de sobre. La pasarela genera una clave de cifrado de datos (DEK) aleatoria para cada registro de token, cifra el secreto de OAuth con esa DEK, cifra la DEK con una clave maestra en KMS o un gestor de secretos, y almacena la DEK cifrada junto con el texto cifrado. Al leer, la pasarela pide a la bóveda que descifre solo la DEK, luego descifra el token en una ruta de código de alcance limitado que evita el registro o la serialización de texto sin cifrar.

En implementaciones más estrictas, el intercambio de tokens en sí puede ser trasladado a un sidecar o a una operación de tránsito de bóveda, de modo que el código de la aplicación nunca recibe material client_secret en bruto. Incluso con el cifrado de sobre estándar, el radio de explosión cambia sustancialmente: un volcado de base de datos por sí solo es insuficiente (las DEK no se almacenan descifradas), y un volcado de memoria de un trabajador de solicitudes general es mucho menos probable que contenga material de credenciales amplio (solo las claves solicitadas recientemente se descifran, y solo durante la duración de la solicitud).

La implementación de Northwind utiliza AWS KMS como almacén de claves maestras y el almacén de secretos de TrueFoundry para el material cifrado. La pasarela nunca lee un client_secret de proveedor directamente; lee un FQN de secreto de TrueFoundry, obtiene el texto cifrado y pide a KMS que lo desencripte. El trabajo específico de la implementación que queda —política de rotación de claves de KMS, retención de auditorías, manuales operativos— es responsabilidad de cada empresa que ejecuta la pasarela, y merece una revisión dedicada.

7. Transferencia de Tokens (Token Passthrough) vs. Reenvío de Tokens (Token Forwarding): Casos Límite y Cuándo Usar Cada Uno

Dos patrones suenan similares y tienen implicaciones de seguridad muy diferentes. Vale la pena distinguirlos cuidadosamente porque el uso indebido de cualquiera de ellos anula la mayor parte del valor de la pasarela.

La transferencia de tokens (Token Passthrough) es apropiada para servidores MCP internos que validan el mismo token de identidad empresarial que la pasarela ya validó en la entrada. La API de Logística de Northwind es un ejemplo: tanto la pasarela como la API confían en el inquilino de Okta de la empresa, por lo que pasar el JWT de Okta mantiene la identidad del llamante intacta de extremo a extremo. El riesgo es la confusión de audiencia del token: un token emitido para la pasarela no debería ser automáticamente válido para cada servidor MCP. RFC 8707 (Resource Indicators) existe precisamente para vincular tokens a un recurso previsto, y la especificación de autorización de MCP ahora requiere que los clientes incluyan un resource parámetro y que los servidores validen que los tokens presentados fueron emitidos para ellos.

El reenvío de tokens funciona de manera diferente. El encabezado x-tfy-mcp-headers de TrueFoundry contiene un JSON serializado, indexado por el identificador del servidor MCP remoto en formato <group>/<server> . Aquí está el formato textual de la documentación del servidor MCP virtual:

import json
from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport

extra_headers = json.dumps({
    # Custom auth for the backend-group/sentry MCP server backing this
    # virtual server. Overrides whatever outbound auth was configured.
    "backend-group/sentry": {"Authorization": "Bearer your-sentry-token"},
})

transport = StreamableHttpTransport(
    url="https://llm-gateway.truefoundry.com/mcp-server/backend-group/restricted-sentry/server",
    headers={
        "Authorization": f"Bearer {tfy_token}",   # inbound auth (gateway)
        "x-tfy-mcp-headers": extra_headers,        # outbound override
    },
)

Considere el reenvío de tokens como una salida de emergencia, no como una opción predeterminada. El valor de la pasarela reside precisamente en la gestión de tokens que omite.

8. Puntos de referencia de latencia: lo que la gestión de tokens añade a cada llamada de herramienta

Una pasarela añade trabajo antes de la llamada MCP descendente: validación de autenticación entrante, búsqueda de políticas, búsqueda de tokens y, ocasionalmente, una actualización. En una implementación saludable, la ruta común es un acierto de caché — los metadatos del token son válidos, la referencia del token cifrado está disponible en memoria.

Envolventes de escenarios

Combinando los costos de los componentes anteriores, la pasarela añade aproximadamente:

Dos conclusiones. Primero, la ruta común es un acierto de caché, y con latencias de un solo dígito de milisegundos, es imperceptible frente a la llamada LLM circundante (típicamente cientos de milisegundos a segundos) y el servidor MCP descendente (típicamente decenas a cientos de milisegundos). Segundo, la ruta de fallo de caché más actualización es rara pero lo suficientemente costosa como para importar cuando se acumula bajo carga — razón por la cual el §4 especifica una actualización proactiva al 80% del TTL con un bloqueo por (usuario, servidor). Con la actualización proactiva, los usuarios reales casi nunca ven la latencia de actualización en la ruta de la solicitud; la pasarela ya ha precargado un nuevo token.

Cada equipo debería seguir instrumentando por separado los encabezados de tiempo del servidor, la duración del endpoint del token, el tiempo de espera del bloqueo, el tiempo de descifrado del almacén y la latencia del MCP descendente. El objetivo es demostrar que la gestión de tokens no es el costo dominante en la llamada de herramienta de extremo a extremo del agente — los envolventes anteriores sugieren que casi nunca lo es, pero debe verificarlo con su propia combinación de proveedores.

La solución operativa para el caso de fallo de caché es la actualización en segundo plano. Cuando la pasarela detecta que un token supera el umbral del 80%, lo actualiza una vez en la ruta de la solicitud y luego programa actualizaciones posteriores antes de que los usuarios lo noten. Para integraciones de credenciales de cliente compartidas de alto volumen, esto casi elimina la latencia de actualización visible para el usuario. Para integraciones de código de autorización por usuario, el sistema puede priorizar a los usuarios activos y los servidores MCP utilizados con frecuencia.

Antes vs. después: postura de seguridad en Northwind

9. Preguntas frecuentes

¿Es OAuth obligatorio en la capa MCP?

No. La especificación de autorización de MCP hace que la autorización sea opcional, pero las implementaciones basadas en HTTP que la soporten deben ajustarse a la especificación. En la práctica, las empresas con un conjunto de herramientas considerable deberían centralizar la autenticación mucho antes de considerarla estrictamente obligatoria.

¿Debería cada servidor MCP usar 3LO?

No. Utilice el Código de Autorización (3LO) cuando el agente actúe sobre los recursos de un usuario humano (Slack, GitHub, Gmail, herramientas CRM). Utilice las Credenciales de Cliente (2LO) cuando el servidor descendente autentique la aplicación o la pasarela como tal. Mezclar ambos dentro de un mismo Servidor MCP Virtual es normal y esperado.

¿Una pasarela elimina los permisos del proveedor?

No. Los complementa. Slack, GitHub, Google y las API internas siguen aplicando sus propios ámbitos y permisos de recursos. La pasarela añade una capa de política más gruesa y rápida por encima —a nivel de servidor, a nivel de herramienta, a nivel de equipo— y una pista de auditoría uniforme en todos ellos.

¿OAuth 2.0 u OAuth 2.1?

La pasarela de TrueFoundry soporta las concesiones de OAuth 2.0 que los proveedores del mundo real admiten hoy en día: Código de Autorización (con PKCE), Credenciales de Cliente y tokens de actualización. La especificación de autorización de MCP en sí misma apunta a OAuth 2.1, que es en gran medida OAuth 2.0 más las mejores prácticas de seguridad que ya se consideran obligatorias en las implementaciones modernas (PKCE en todas partes, sin concesión implícita, sin concesión de contraseña). A efectos prácticos, ambos son convergentes; seguimos la guía de OAuth 2.1 donde endurece el comportamiento.

¿Qué hay de la nueva especificación MCP del 25-11-2025?

La revisión de noviembre de 2025 añade PKCE obligatorio para todos los clientes, formaliza los Documentos de Metadatos de ID de Cliente (CIMD) como el método preferido de registro de clientes e introduce la autorización por pasos para el consentimiento de ámbito incremental. Esto refuerza la seguridad sin invalidar la arquitectura de esta publicación. Estamos haciendo un seguimiento y añadiendo soporte a medida que madura en todo el ecosistema.

¿Dónde encaja TrueFoundry?

La pasarela MCP de TrueFoundry es una implementación en producción de esta arquitectura: un registro de servidores centralizado, autenticación de entrada configurable, control de acceso, múltiples modos de autenticación de salida y gestión del ciclo de vida de los tokens. Esta publicación describe el diseño; las documentos de autenticación y seguridad son la referencia operativa. Para los patrones de implementación cubiertos aquí, consulte también la documentación sobre Anulaciones de autenticación y Servidor MCP Virtual.

Da el siguiente paso

Si usted es un líder de infraestructura de plataforma, seguridad o IA que ejecuta MCP a una escala considerable, la acción de mayor impacto es inventariar cada servidor MCP en uso activo, mapear cada uno al modelo de autenticación de entrada, política y salida correcto, y decidir dónde la centralización realmente aporta beneficios. El mapeo de Northwind llevó dos tardes; la migración en sí tomó un solo sprint. Estaremos encantados de repasar ese ejercicio con su equipo.

Lee la arquitectura: Autenticación y seguridad del Gateway MCP de TrueFoundry. O reserve una revisión de la arquitectura de seguridad empresarial con nuestro equipo.

Lectura adicional

Todas las citas de esta publicación están enlazadas directamente. Las referencias a continuación recopilan las mismas URL para facilitar la impresión y como seguro contra enlaces rotos.

• Descripción general del Gateway MCP de TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-overview
• Autenticación y seguridad del Gateway MCP de TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-gateway-auth-security
• Anulaciones de autenticación de TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-server-auth-overrides
• Servidor MCP virtual de TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/virtual-mcp-server
• TrueFoundry usando el Gateway MCP en su agente. https://www.truefoundry.com/docs/ai-gateway/mcp/use-mcp-gateway-in-agent
• Proveedores de identidad de TrueFoundry. https://www.truefoundry.com/docs/platform/identity-providers
• Gestor de Secretos de TrueFoundry en AI Gateway. https://www.truefoundry.com/docs/ai-gateway/secret-manager-in-ai-gateway
• Variables de Entorno y Secretos de TrueFoundry (formato FQN tfy-secret://). https://www.truefoundry.com/docs/environment-variables-and-secrets
• Uso de tfy apply de TrueFoundry (patrón YAML de cuenta de proveedor / integraciones). https://docs.truefoundry.com/docs/using-tfy-apply
• Límites de Concurrencia de Okta (orientación sobre el tiempo de respuesta de la API). https://developer.okta.com/docs/reference/rl2-concurrency/
• WorkOS: RS256 vs HS256 (puntos de referencia de verificación JWT). https://workos.com/blog/rs256-vs-hs256-jwt-signing-algorithms
• Documentación de AWS KMS (orientación sobre la latencia de descifrado). https://aws.amazon.com/kms/faqs/
• Especificación de autorización del Protocolo de Contexto del Modelo, 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• RFC 6749: El Marco de Autorización OAuth 2.0. https://datatracker.ietf.org/doc/html/rfc6749
• RFC 8707: Indicadores de Recursos para OAuth 2.0. https://datatracker.ietf.org/doc/rfc8707/
• RFC 9728: Metadatos de Recursos Protegidos de OAuth 2.0. https://datatracker.ietf.org/doc/html/rfc9728/

Nota: Northwind Logistics es una empresa ficticia utilizada para basar el diseño en una implementación concreta. El modelo de configuración que se muestra en el §3 es ilustrativo; los servidores MCP de producción se registran a través de la interfaz de usuario de TrueFoundry o se aplican mediante tfy apply.

‍