Proxy, Enrutador, Pasarela: Tres Palabras para Tres Cosas Diferentes

Estos términos se usan indistintamente hasta que algo falla. Describen arquitecturas distintas con garantías diferentes, y el costo de confundirlos se paga con brechas de seguridad, fallos en auditorías y reconstrucciones que no deberían haber sido necesarias.

El problema de la terminología es un problema de arquitectura

A medida que el Protocolo de Contexto del Modelo se convierte en el medio predeterminado para conectar agentes de IA a fuentes de datos y herramientas, la terminología de la infraestructura se ha enredado. Proveedores, publicaciones de blog y documentos de diseño internos usan "proxy", "enrutador" y "pasarela" indistintamente. La distinción es difusa cuando todo está en el portátil de un desarrollador y letal cuando se empiezan a desplegar agentes de producción — porque las tres palabras nombran cosas estructuralmente diferentes, y la diferencia solo se manifiesta cuando un auditor hace una pregunta que una de ellas no puede responder.

Tomar prestado de las redes ofrece el modelo mental más claro. Un proxy opera en la capa L4: reenvía bytes y no los interpreta. Un enrutador opera en la capa L7 de despacho de capacidades: conoce la herramienta, pero no conoce al principal que la invoca. Una pasarela opera en la capa L7 de políticas: conoce la herramienta, el principal, el presupuesto y el registro de auditoría. Cada nivel es estrictamente más capaz, estrictamente más costoso de operar y responde a estrictamente más preguntas sobre cada solicitud.

Proxy: bytes, nada más

Un proxy es la pieza más simple del diagrama. Su función es la mediación de protocolos. MCP hace un uso intensivo de stdio para la ejecución local; un proxy puede envolver un servidor MCP basado en stdio y exponerlo a través de HTTP/SSE o WebSockets para que un cliente remoto pueda acceder a él. Esa es toda su función.

Un proxy no interpreta en absoluto la carga útil. No analiza JSON-RPC, no entiende las llamadas a herramientas, no sabe lo que significa "herramienta". Reenvía bytes. Esto lo hace ultrarrápido (en submilisegundos) y casi gratuito de operar. Un único desarrollador que conecta Claude Desktop a un servidor MCP dentro de un contenedor Docker en la misma máquina: ese es un caso de uso de proxy. Sin gobernanza, sin estado, sin razón para ninguno de los dos.

El error es pensar que el proxy escalará. No lo hará. En el momento en que tienes más de un desarrollador o más de un servidor MCP descendente, el proxy deja de soportar la carga y el enrutador toma el control. Un proxy no es un componente fundamental de una pila empresarial; es una herramienta de conveniencia personal que una pasarela podría envolver internamente para la adaptación del transporte. Tratarlo como algo más o menos que eso —sobreconstruirlo, subestimarlo— produce una arquitectura que envejece mal.

Enrutador: despacho de capacidades

A medida que los entornos crecen, codificar las URL de los servidores directamente en los clientes deja de ser mantenible. Un enrutador resuelve el descubrimiento: en lugar de que el cliente sepa dónde reside github-mcp-server, el cliente se conecta al enrutador y pregunta qué herramientas están disponibles. El enrutador mantiene un registro de servidores descendentes y un mapa de capacidades.

Cuando el LLM llama a search_repositories, el enrutador inspecciona la carga útil JSON-RPC, identifica la herramienta de destino y despacha la llamada al backend correcto. Es, mecánicamente, un agregador con una tabla de enrutamiento: rápido, simple y una abstracción limpia. La mayoría de los equipos internos recurren a uno tan pronto como tienen más de dos servidores MCP, y no se equivocan al hacerlo.

Lo que el enrutador no hace es formular la pregunta más importante en producción: ¿la identidad que realiza esta llamada está realmente autorizada para invocar esta herramienta? Enruta por capacidad. No restringe por política. El modelo puede llamar a delete_branch en producción con la misma facilidad con la que puede llamar a list_issues en un repositorio público. El enrutador despachará ambos obedientemente, y el registro de auditoría que produzca o no, estará determinado únicamente por la conexión — no por quién la operó.

El enrutador es el nivel adecuado cuando los agentes son internos, la red es de confianza y la acción en el peor de los casos es reversible. La transición que les causa problemas a los equipos es de enrutador → pasarela, y suele ocurrir el día que alguien pregunta quién llamó a delete_branch en producción el martes pasado. El enrutador no tiene respuesta que dar, porque nunca lo supo.

Pasarela: el plano de control completo

Una pasarela engloba al proxy y al enrutador y añade un plano de control L7 encima. Esta es la capa donde realmente ocurren las operaciones de IA empresariales — y la capa donde comenzará una revisión de seguridad, independientemente de si alguien la llamó así durante el diseño.

Una pasarela inspecciona cada paquete. Se integra con la identidad corporativa (OAuth 2.0, SAML, OIDC) para establecer en nombre de quién actúa el agente. Aplica RBAC a nivel de herramienta. Ejecuta la sanitización de esquemas que detecta el envenenamiento de MCP. Rastrea el uso de tokens para la atribución de presupuesto. Escribe registros a prueba de manipulaciones en SIEM externos. Es, estructuralmente, el lugar donde se codifica la política de IA de la organización — y el único lugar donde el agente de un contratista desvinculado deja de funcionar en el momento adecuado.

Matriz de capacidades

La misma comparación en formato tabular, para los revisores de documentos de diseño que solo echarán un vistazo. Lea las columnas; cada una responde a una pregunta sobre una solicitud.

Tabla 1 — Matriz de capacidades. La columna de la derecha es lo que su auditor preguntará; la columna central es lo que su equipo buscará primero; la columna de la izquierda es lo que se ejecuta en su portátil.

Marco de decisión

Un árbol de decisión corto, escrito en el orden en que los equipos de producción realmente responden a las preguntas:

• Utilice un proxy cuando sea un único desarrollador conectando herramientas locales a través de espacios de nombres de red — WSL a un host de Windows, host a un contenedor Docker. El radio de impacto es su máquina.
• Utilice un enrutador cuando sea un equipo pequeño que ejecuta un puñado de agentes internos que necesitan un punto de descubrimiento unificado, confía implícitamente en todos en la red y la acción de la herramienta en el peor de los casos es reversible.
• Utilice una pasarela (gateway) cuando esté desplegando agentes en producción, implementando Claude Code para más de diez desarrolladores, accediendo a bases de datos de cualquier tipo, o operando bajo cualquier marco de cumplimiento que exija registros de auditoría y acceso con privilegios mínimos.

La transición que más afecta a la mayoría de los equipos es de enrutador a pasarela (router → gateway), y siempre ocurre en el mismo momento: alguien hace una pregunta de auditoría que requiere registros correlacionados con la identidad, y el enrutador no tiene respuesta porque nunca supo quién estaba llamando. La solución barata en ese momento es añadir una pasarela. La solución cara es reconstruir la plataforma de agentes después de un incidente de seguridad — que es lo que una parte de los equipos terminará haciendo en su lugar, porque la solución barata es invisible hasta el incidente.

Cómo TrueFoundry implementa la capa de pasarela

TrueFoundry está construido como una pasarela federada. El plano de control (donde se crean las políticas, se registran los modelos y reside la observabilidad) está separado del plano de pasarela (donde fluye el tráfico). El plano de pasarela es completamente sin estado — cada pod de pasarela se suscribe al plano de control a través de NATS para las actualizaciones de configuración, y cada verificación que realiza se hace en memoria contra ese estado sincronizado. No hay un único punto de fallo entre el agente y el backend. Si el plano de control cae, las pasarelas siguen funcionando con su última configuración conocida; cuando el plano de control regresa, NATS se reconcilia. Como medida de seguridad final, el plano de control vuelve a publicar toda la configuración cada 10 minutos — la consistencia eventual está garantizada incluso si se perdió una actualización intermedia.

‍

El plano de datos está construido sobre Hono — un framework alineado con la API Web Fetch y optimizado para el edge — y realiza todas las comprobaciones de límite de tasa, autenticación y enrutamiento en la memoria del proceso. El plano de control sincroniza la configuración a través de NATS con una cadencia de subsegundos; la propia ruta de solicitud nunca realiza una llamada externa a menos que se invoque la caché o una barrera de seguridad basada en la red. La propiedad estructural que importa es la ausencia de estado (statelessness): un pod de pasarela puede ser eliminado en cualquier momento sin perder decisiones de política en curso, porque no hay decisiones de política en curso — cada decisión se toma desde la memoria local contra la configuración que llegó asincrónicamente.

La característica que une la arquitectura es la composición virtual de servidores MCP. La pasarela fusiona esquemas de docenas de servidores MCP de backend en una única superficie de API, con alcance dinámico por cada llamador. El token IAM de un desarrollador frontend produce una lista unificada de herramientas diferente a la de un ingeniero de plataforma, y ninguno ve herramientas que el otro no tiene permitido usar. Desde la perspectiva del modelo, hay un servidor MCP. Desde la perspectiva del equipo de plataforma, hay un lugar para establecer políticas. Desde la perspectiva del auditor, cada llamada a una herramienta tiene un ID de seguimiento que vincula la decisión del modelo con la identidad del desarrollador que la autorizó.

Mismo cliente, mismos backends, un intermedio muy diferente. El intermedio es la parte que envejece bien.

La cuestión de fondo

La arquitectura es principalmente la práctica de elegir dónde van los límites, y el costo de equivocarse en esa elección no se paga en el momento del diseño, sino en el siguiente incidente, la siguiente auditoría, la siguiente migración. La distinción entre proxy/enrutador/pasarela no es un problema de vocabulario. Es una cuestión de si su plataforma tiene un punto de control en la unión donde la identidad corporativa se encuentra con el bucle del agente, o si tiene una tabla de enrutamiento donde debería haber un punto de control.

La mayoría de los equipos descubren esta distinción por las malas. Algunos lo descubren durante un análisis post-mortem; otros durante una revisión de cumplimiento; otros cuando el agente de un contratista desvinculado sigue funcionando una semana más de lo debido. El momento del descubrimiento es el mismo en los tres casos. Lo que varía es el costo del descubrimiento.

Preguntas frecuentes

¿Puedo implementar un enrutador hoy y añadir una pasarela más tarde?

Sí, y la mayoría de los equipos lo hacen. La ruta de migración es sencilla: la pasarela utiliza el mismo protocolo de comunicación MCP, por lo que los clientes existentes siguen funcionando. Lo que cambia es la URL a la que apuntan y el encabezado de autenticación que incluyen. Planifique la migración en dos fases: primero, configure la pasarela en modo auditoría (registro, sin aplicación de políticas) y valide que los registros coinciden con las expectativas; luego, active la aplicación de políticas por servidor, comenzando con los servidores MCP de menor riesgo y terminando con la base de datos de producción.

¿Cómo se comporta la pasarela si el plano de control está inactivo?

Las pasarelas continúan sirviendo tráfico con la última configuración que obtuvieron, indefinidamente. Se suscriben a NATS para recibir actualizaciones en tiempo real y, como respaldo, reintentan obtener la configuración por HTTP del servicio de backend del plano de control. Si tanto NATS como el backend están inactivos, los pods de pasarela existentes siguen funcionando con la última configuración conocida; los nuevos pods que intenten iniciarse durante la interrupción fallarán su prueba de preparación y no recibirán tráfico. La recomendación es ejecutar múltiples réplicas de pasarela; la probabilidad de que todas se reinicien durante una interrupción del plano de control es el riesgo que hay que mitigar con el diseño, y es pequeña.

¿Por qué Hono específicamente? ¿Qué ventajas les ofreció Hono frente a Express o Fastify?

Hono está construido sobre la API Web Fetch y está diseñado para entornos de ejecución de borde (Cloudflare Workers, Deno, Bun, Node). Es pequeño, rápido y funciona de forma idéntica en todos los entornos de ejecución, lo cual es importante porque la pasarela debe ser portable entre SaaS, Kubernetes on-premise y entornos aislados con proxy Squid. Express tiene demasiada complejidad; Fastify está bien, pero está ligado a las especificidades de Node. La propiedad relevante es una baja sobrecarga consistente a alta concurrencia, algo que Hono ofrece de forma fiable.

¿Es la composición virtual de MCP solo una fusión estática, o realmente define el alcance por cada solicitante?

Define el alcance por cada solicitante. La pasarela evalúa los atributos IAM y ABAC del principal contra el paquete de políticas cada vez que sirve una lista de herramientas (tools/list), y emite una unión filtrada de descriptores de herramientas. Dos desarrolladores que inician sesión con segundos de diferencia pueden recibir listas de herramientas diferentes desde el mismo punto final de la pasarela. El modelo nunca sabe que hay múltiples backends, y nunca sabe que hay herramientas a las que su solicitante actual no puede acceder. Así es también como se consiguen implementaciones multi-inquilino limpias: la misma pasarela sirve mundos diferentes a inquilinos diferentes.

¿Cómo evita la pasarela el desajuste de la configuración entre el plano de control y los pods?

Tres mecanismos. Las cargas útiles de configuración son idempotentes: el plano de control publica todo el estado actual en NATS con cada cambio, por lo que recibir el mismo mensaje dos veces no tiene efecto. NATS proporciona entrega al menos una vez, por lo que la pasarela verá cada actualización al menos una vez. Y como medida de seguridad adicional, el plano de control vuelve a publicar la configuración completa cada 10 minutos; incluso si se perdió una actualización intermedia, la pasarela converge al estado correcto en un máximo de 10 minutos. El desajuste está limitado por diseño.

‍