Phase 13 - Lesson 17

Gateways y Registros de MCP — Planos de Control Empresariales

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

Las empresas no pueden permitir que cada desarrollador instale servidores MCP aleatorios. Un gateway centraliza la autenticación, RBAC, auditoría, limitación de tasa, caché y detección de envenenamiento de herramientas, exponiendo luego la superficie de herramientas fusionada como un único endpoint MCP. El Registro Oficial de MCP (Official MCP Registry, mantenido por Anthropic + GitHub + PulseMCP + Microsoft, con verificación de espacio de nombres) es el upstream canónico. Esta lección describe dónde encaja un gateway, recorre una implementación mínima y analiza el panorama de proveedores de 2026.

Tipo: Learn Lenguajes: Python (stdlib, minimal gateway) Prerrequisitos: Fase 13 · 15 (tool poisoning), Fase 13 · 16 (OAuth 2.1) Tiempo: ~45 minutos

Objetivos de Aprendizaje

• Explicar dónde se ubica un gateway MCP (entre los clientes MCP y múltiples servidores MCP de backend).
• Implementar las cinco responsabilidades del gateway: auth, RBAC, audit, rate limit, policy.
• Imponer un manifiesto de hash de herramienta fijado (pinned-tool-hash manifest) en la capa del gateway.
• Diferenciar el Registro Oficial de MCP de los metarregistros (Glama, MCPMarket, MCP.so, Smithery, LobeHub).

El Problema

Una empresa de Fortune 500 tiene 30 servidores MCP aprobados, 5000 desarrolladores, requisitos de cumplimiento y auditoría, y un equipo de seguridad que desea una política centralizada. Permitir que cada desarrollador instale servidores arbitrarios en sus IDE es inviable.

El patrón de gateway:

1. El gateway se ejecuta como un único endpoint HTTP de streaming (Streamable HTTP endpoint) al que se conectan los desarrolladores.
2. El gateway almacena las credenciales de cada servidor MCP de backend.
3. Cada solicitud del desarrollador se autentica y se delimita su alcance a través del propio OAuth del gateway.
4. El gateway enruta la llamada al servidor de backend, aplicando políticas.
5. Todas las llamadas se registran para auditoría.

Cloudflare MCP Portals, Kong AI Gateway, IBM ContextForge, MintMCP, TrueFoundry, Envoy AI Gateway — todos lanzaron gateways o características de gateway en 2025-2026.

Mientras tanto, el Registro Oficial de MCP se lanzó como el upstream canónico: servidores curados, con verificación de espacio de nombres y nombres en formato de DNS inverso de los cuales el gateway puede extraer recursos. Los metarregistros (Glama, MCPMarket, MCP.so, Smithery, LobeHub) agregan servidores de múltiples fuentes.

El Concepto

Cinco responsabilidades del gateway

1. Auth. OAuth 2.1 para identificar al desarrollador; se asigna a los roles de usuario.
2. RBAC. Política por usuario: qué servidores, qué herramientas, qué alcances.
3. Audit. Cada llamada se registra con quién, qué, cuándo y el resultado.
4. Rate limit. Límites por usuario / por herramienta / por servidor para evitar abusos.
5. Policy. Rechazar descripciones envenenadas, imponer la Regla de Dos (Rule of Two), redactar información de identificación personal (PII).

Gateway como un único endpoint

Para los desarrolladores, el gateway parece un único servidor MCP. Internamente, enruta a N backends. Los ID de sesión (Fase 13 · 09) se reescriben en el límite de la frontera.

Almacenamiento seguro de credenciales (Credential vaulting)

Los desarrolladores nunca ven los tokens de backend. El gateway los almacena (o actúa como proxy para un proveedor de identidad que lo hace). Un desarrollador con notes:read en el gateway puede acceder transitivamente al servidor MCP de notas con las propias credenciales de backend del gateway — pero solo bajo una política que vincule este acceso transitivo.

Fijación de hashes de herramientas en el gateway (Tool-hash pinning)

El gateway mantiene un manifiesto de descripciones de herramientas aprobadas (hashes SHA256). Al momento del descubrimiento, obtiene el tools/list de cada backend, compara los hashes con el manifiesto y elimina cualquier herramienta cuya descripción haya cambiado. Esta es la defensa contra tirones de alfombra (rug-pull defense) de la Fase 13 · 15 aplicada centralmente.

Política como código (Policy-as-code)

Los gateways avanzados expresan políticas en OPA/Rego, Kyverno o Styra. Reglas como "el usuario alice puede llamar a github.open_pr solo en repositorios de la organización acme" se codifican declarativamente. Los gateways simples usan Python programado manualmente. Ambos formatos son válidos.

Enrutamiento consciente de la sesión (Session-aware routing)

Cuando la sesión de un usuario incluye una mezcla de servidores, el gateway realiza la multiplexación: la sesión MCP única del desarrollador mantiene N sesiones de backend, una por servidor. Las notificaciones de cualquier backend se enrutan a través del gateway hacia la sesión del desarrollador.

Fusión de espacios de nombres (Namespace merging)

Los gateways fusionan los espacios de nombres de herramientas de todos los backends, normalmente con prefijos en caso de colisión. Ejemplo: github.open_pr, notes.search. Esto hace que el enrutamiento sea inequívoco.

Registros

• Official MCP Registry (registry.modelcontextprotocol.io). Lanzado bajo la gestión de Anthropic, GitHub, PulseMCP y Microsoft. Espacio de nombres verificado (DNS inverso: io.github.user/server). Pre-filtrado para calidad básica.
• Glama. Metarregistro centrado en la búsqueda que agrega muchas fuentes.
• MCPMarket. Directorio de orientación comercial con listados de proveedores.
• MCP.so. Directorio de la comunidad; envíos abiertos.
• Smithery. Flujo de instalación al estilo de administrador de paquetes.
• LobeHub. Registro integrado en la interfaz de usuario en su aplicación LobeChat.

Los gateways empresariales extraen del Registro Oficial por defecto, permiten adiciones seleccionadas por el administrador desde metarregistros y rechazan cualquier elemento que no esté fijado (unpinned).

Nomenclatura basada en DNS inverso (Reverse-DNS naming)

El Registro Oficial exige nombres de DNS inverso para servidores públicos: io.github.alice/notes. Los espacios de nombres evitan la ocupación indebida de nombres (squatting) y aclaran la delegación de confianza.

Encuesta de proveedores, abril de 2026

La Fase 17 (infraestructura de producción) profundiza en las operaciones de gateway.

Use It

El archivo code/main.py entrega un gateway mínimo en unas 150 líneas: autentica a los usuarios mediante un token Bearer falso, mantiene una política RBAC por usuario, enruta las solicitudes a dos servidores MCP de backend, escribe cada llamada en un registro de auditoría, impone un límite de tasa y rechaza cualquier herramienta de backend cuyo hash de descripción no coincida con un manifiesto fijado.

Qué observar:

• El diccionario RBAC con clave de user_id con las entradas permitidas de server_tool.
• AUDIT_LOG es una lista de eventos de tipo append-only.
• El límite de tasa utiliza un token bucket por usuario.
• El manifiesto fijado es un diccionario de tipo server::tool -> hash.

Ship It

Esta lección produce outputs/skill-gateway-bootstrap.md. Dado un plan de MCP empresarial (usuarios, backends, cumplimiento), la skill produce una especificación de configuración del gateway.

Ejercicios

1. Ejecute code/main.py. Realice una llamada como usuario permitido; luego como usuario no permitido; por último, una ráfaga que exceda el límite de tasa. Verifique los tres flujos.

2. Agregue una política que oculte la información de identificación personal (PII) de los resultados antes de devolverlos al cliente. Utilice un paso simple de regex para cadenas con formato de CPF/SSN; note la brecha (correos electrónicos, números de teléfono).

3. Extienda el registro de auditoría para emitir spans GenAI de OpenTelemetry. La Fase 13 · 20 cubre los atributos exactos.

4. Diseñe una política RBAC para un equipo de 50 desarrolladores con cinco backends (notes, github, postgres, jira, slack). ¿Quién obtiene acceso de solo lectura en cada uno? ¿Quién obtiene acceso de escritura?

5. Lea la publicación de MCP empresarial de Cloudflare de principio a fin. Identifique una característica que Cloudflare ofrece y que este gateway stdlib no tiene.

Términos Clave

Lecturas Adicionales

• Official MCP Registry — upstream canónico, espacio de nombres verificado
• Cloudflare — Enterprise MCP — patrón de gateway con OAuth y políticas
• agentic-community — MCP gateway registry — gateway de referencia de código abierto
• TrueFoundry — What is an MCP gateway? — artículo de comparación de características
• IBM — MCP context forge — gateway empresarial de IBM