Qué es un MCP gateway (y en qué se diferencia de un MCP firewall).

¿Qué es un MCP gateway?

Un MCP gateway es un punto de control único que se ubica entre los agentes y los servers MCP que consumen. Decide qué tool calls se permiten, con qué credenciales se ejecutan y deja registro de cada uno, todo antes de que la acción ocurra. En lugar de que cada agente hable directo con cada server MCP, con su propio token y su propio criterio, el tráfico pasa por un lugar donde vive la política.

La idea es sencilla y por eso funciona. Si un agente quiere invocar una herramienta, la solicitud llega primero al gateway. El gateway consulta qué está permitido para ese entorno, adjunta la credencial correcta con el scope justo, deja pasar la llamada o la rechaza, y guarda evidencia de lo que sucedió. El agente nunca sostiene las credenciales crudas ni decide por su cuenta qué herramienta es aceptable.

¿En qué se diferencia de un API gateway?

Un API gateway enruta requests entre servicios; un MCP gateway gobierna qué puede hacer un agente a través de las herramientas. La distinción no es cosmética. Un API gateway clásico se preocupa por el transporte: balanceo, rate limiting, terminación de TLS, autenticación de quien llama. Su modelo mental es una red de servicios que se hablan entre sí de forma predecible.

Un MCP gateway opera sobre otra superficie de confianza, la propia de MCP. Aquí quien decide qué llamar es un modelo, y lo decide a partir de texto que puede venir de cualquier parte, incluidas las descripciones de las herramientas y sus resultados. Lo que se autoriza no es una ruta hacia un backend, es una capacidad: leer un repositorio, correr una consulta con permisos de escritura, alcanzar una URL. El gateway razona sobre acciones y sus efectos, no sobre paquetes y endpoints.

¿MCP gateway o MCP firewall?

La diferencia está en el enfoque: un firewall filtra tráfico que parece malicioso, y eso es detección; un gateway con política determinística decide qué se permite, y eso es autorización. La palabra firewall arrastra una promesa vieja: inspeccionar lo que entra, reconocer lo peligroso y bloquearlo. Aplicado a MCP, un firewall intentaría leer las tool calls y los payloads buscando señales de una inyección o de un abuso.

El problema es que la detección compite en un terreno donde siempre va perdiendo. El atacante escribe la entrada, y hay infinitas formas de decir lo mismo. Un filtro que hoy reconoce un patrón es un filtro que mañana no reconoce su variante. Esa carrera no la ganas.

La autorización determinística vence a la detección. Decidir de antemano qué está permitido no depende de reconocer lo malo; solo deja pasar lo que ya sabías bueno.

Un gateway con política determinística no intenta adivinar la intención. Tiene una lista de lo que se permite y rechaza todo lo demás, sin importar cuán convincente sea el argumento que llega dentro de un resultado de herramienta. Es el mismo razonamiento que desarrollamos en la prompt injection es un problema de autorización: el punto de control no está en detectar la instrucción inyectada, está en que la acción nunca estuvo autorizada.

¿Qué controla un MCP gateway en la práctica?

Cuatro cosas, y las cuatro son deterministas. Un MCP gateway no opina sobre el contenido; aplica reglas que un equipo definió de antemano y que se pueden auditar.

1. Allow-list de tools por entorno. Cada entorno de agente recibe las herramientas que necesita, no todas las que un server MCP exponga. Lo que no está en la lista, no existe para ese agente.
2. Scope de credenciales por tool. Cada herramienta se ejecuta con un token acotado a su función, con vida útil corta, y el agente nunca ve el secreto en crudo.
3. Alcance de red. El gateway declara hacia dónde puede hacer egress cada herramienta y qué hosts internos puede tocar, para que una llamada no se convierta en un punto de pivote.
4. Evidencia por llamada. Queda registro de qué herramienta se invocó, con qué argumentos y bajo qué política, de modo que después se pueda verificar qué ocurrió de verdad.

Estas cuatro superficies son las mismas que hay que mapear al revisar un solo server MCP; el gateway las lleva a un punto central. Si quieres el detalle de qué otorga cada herramienta detrás de escena, lo describimos en qué expone realmente un server MCP.

¿Cuándo necesito uno?

Cuando varios agentes tocan varios servers MCP con credenciales reales. Con un solo agente y una sola integración de juguete, un gateway es sobreingeniería; alcanza con acotar bien el token. La cosa cambia apenas hay flota.

En cuanto tienes varios agentes, cada uno con acceso a varios servers MCP, cada server respaldado por credenciales que llegan a sistemas que importan, la política deja de caber en la cabeza de nadie. Sin un punto de control único terminas con tokens amplios repartidos, herramientas disponibles que nadie recuerda haber habilitado y cero evidencia de qué se llamó. Ese es el momento en que un MCP gateway deja de ser un lujo y pasa a ser la única forma sensata de saber qué pueden hacer tus agentes.

La conclusión

Un MCP gateway y un MCP firewall no son dos nombres para lo mismo. El firewall apuesta a reconocer lo malicioso; el gateway decide de antemano qué está permitido y deja constancia. En una superficie donde la entrada la escribe un atacante, la autorización determinística es la apuesta que se sostiene.

Oktsec publica un MCP gateway open source y lo lleva más lejos con Control: allow-list por entorno, credenciales acotadas y evidencia verificada de cada llamada. Ver entornos soportados →