Un gateway MCP para que los agentes no vean nunca tus credenciales

Trece pasos. Es lo que propone una guía publicada por tech-insider.org este 7 de octubre para montar un gateway MCP que se sitúe entre los agentes de IA y las credenciales que necesitan para trabajar. El planteamiento parte de un problema que reconoce enseguida cualquiera que haya configurado un MCP server en local: la API key acaba escrita en texto plano dentro de un fichero de configuración. Ahí la tienen a mano el propio agente y cualquier proceso que pueda leer ese disco.

No es un detalle menor. Cada MCP server que se añade a `claude_desktop_config.json` o a Claude Code suele llevar su bloque `env` con un token de GitHub, una clave de un proveedor de pagos o las credenciales de una base de datos. Con tres o cuatro servidores configurados, un portátil de desarrollo puede acabar guardando más secretos de producción que muchos servidores.

Qué es un gateway MCP y qué resuelve

La idea es sencilla de explicar y algo más laboriosa de montar. El cliente (Claude Desktop, Claude Code o cualquier otro host compatible) deja de hablar directamente con cada MCP server y de pasarle credenciales. Todas las llamadas pasan por un intermediario. Ese gateway es el único que conoce los secretos: los inyecta en la petición saliente y devuelve al modelo solo el resultado de la herramienta.

El agente nunca ve el token. Si un prompt injection consigue que el modelo intente volcar su configuración o reenviar variables de entorno, desde su lado no hay nada que filtrar.

Más allá de esconder claves, un gateway centralizado permite cosas que en un despliegue disperso cuesta mucho conseguir:

Rotación sin tocar clientes: una clave se cambia en un solo sitio, no en el portátil de cada miembro del equipo.
Permisos por herramienta: se puede decidir que un agente lea issues pero no haga merge, aunque el token subyacente tenga más alcance.
Registro de auditoría: cada llamada queda anotada con quién la hizo, con qué herramienta y cuándo, algo que los MCP servers locales casi nunca ofrecen.
Revocación inmediata: si un agente se comporta de forma extraña, se le corta el acceso en el gateway sin tener que perseguir copias de credenciales.

Por qué llega ahora

El protocolo ya contempla autorización basada en OAuth para servidores remotos, y cada vez más proveedores publican MCP servers alojados con login propio. Pero en muchos equipos la realidad sigue siendo mixta: servidores remotos con OAuth conviven con servidores locales lanzados con `npx` o `uvx` que esperan una variable de entorno. El gateway pone orden en esa mezcla sin esperar a que todos los proveedores migren.

Además, el uso de agentes ha cambiado de escala. Con subagentes que se lanzan en paralelo, hooks que ejecutan comandos en cada evento y plugins que instalan sus propios MCP servers, han aumentado bastante en el último año las vías por las que puede escaparse una credencial. Que una guía necesite trece pasos ya indica que esto no se arregla tocando una línea del fichero de configuración.

Para quién tiene sentido

No todo el mundo necesita un gateway. A un desarrollador que usa un par de MCP servers de solo lectura en su máquina pueden bastarle el gestor de secretos del sistema y algo de disciplina. El patrón empieza a compensar en otros casos:

Equipos en los que varias personas comparten los mismos MCP servers con credenciales de empresa.
Agentes que corren en servidores o en CI, sin nadie delante que apruebe cada acción.
Organizaciones con requisitos de cumplimiento que tienen que demostrar quién accedió a qué sistema y cuándo.
Integraciones con datos de clientes, donde una fuga no se queda en un susto: obliga a notificarla.

Conviene no olvidar el coste. Un gateway es otra pieza de infraestructura que hay que mantener, monitorizar y proteger. Si cae, todos los agentes se quedan sin herramientas; si alguien lo compromete, tiene todos los secretos en un único punto. El aislamiento de red, el almacenamiento cifrado y los tokens de corta duración reducen ese riesgo, pero no lo eliminan.

Lo que hemos visto en proyectos reales

En las integraciones con Claude que montamos para clientes, esta conversación suele aparecer en un momento previsible: cuando el piloto funciona y alguien pregunta cómo pasarlo a producción con veinte usuarios. Es entonces cuando las credenciales repartidas en ficheros de configuración dejan de ser una comodidad y se convierten en un problema. Separar desde el principio quién razona (el modelo) y quién guarda las llaves (el gateway o un vault) evita tener que rehacer la arquitectura más adelante.

Antes de copiar los pasos tal cual, recomendamos leer la guía completa en tech-insider.org. Cada stack tiene sus particularidades, y lo útil es el criterio de diseño más que la receta concreta.

Creemos que el gateway MCP acabará siendo tan habitual en los despliegues de agentes como hoy lo es un API gateway delante de un backend. Cuanto antes se asuma que el modelo no debe tocar secretos, menos sustos habrá después.