URLs MCP efímeras: el patrón TTL para agentes de IA en 2026

Una URL de un servidor MCP es una credencial. Parece un endpoint HTTPS cualquiera, pero quien la tiene puede llamar a las herramientas que hay detrás. Si un agente tiene la URL, el agente puede leer la base de datos, publicar en el canal, lanzar el deploy. Si la URL acaba en otras manos, esas manos pueden hacer lo mismo.

Por eso las URLs MCP de larga duración son el default equivocado. La salida son URLs efímeras con TTL de minutos, tokens con scope estrecho y rotación en cada uso. El patrón no es nuevo. AWS lo llama presigned URL y lo lleva enviando desde 2011 para S3. Lo que cambia en 2026 es que ahora los agentes de IA están al otro lado de esas URLs, y la tasa de exposición ya es lo bastante grande como para medirla.

El problema en cifras

Trend Micro escaneó internet en busca de endpoints MCP a finales de 2025 y encontró 492 servidores sin autenticación de cliente y sin cifrado de tráfico. Su actualización de abril de 2026 sube la cuenta a 1.467 servidores, casi el triple en seis meses. El 74% corre en AWS, Azure, GCP y Oracle. El 90% ofrece acceso directo de lectura a una fuente de datos. Un prompt en lenguaje natural basta para exfiltrar.

El otro modo de fallo es el bypass de autenticación. La CVE-2026-33032 (MCPwn) es un CVSS 9.8 contra la integración MCP de Nginx UI que toma el control del servidor en dos peticiones HTTP. La explotación activa se confirmó en mayo de 2026. El patrón es el mismo que vimos en cada generación anterior de endpoints remotos: la URL existe, las credenciales son estáticas, la rotación nunca ocurre.

Por qué fallan las URLs de larga duración

La URL de un servidor MCP acaba en cuatro sitios donde no debería: logs de chat, archivos de configuración del IDE, capturas de pantalla en tickets de soporte, historial de git. Ninguno es un accidente. Son los artefactos naturales de cómo trabajan los desarrolladores y los agentes. Una URL pegada en una conversación con Claude vive en ese hilo hasta que se borra el hilo. Una URL comiteada en un repo privado vive ahí hasta que el repo se filtra o la cuenta de GitHub de un colaborador queda comprometida.

Si la URL vale un año, cada una de esas copias es una backdoor funcionando durante un año. Si la URL vale 15 minutos, la backdoor se cierra antes de que la fuga llegue a un atacante capaz de explotarla.

La forma del patrón TTL

La forma que usamos, tomada del patrón presigned URL que AWS documenta para el acceso a objetos, tiene cuatro partes:

1. TTL de acceso corto. La URL o el token de acceso valen entre 5 y 60 minutos. La mayoría de las llamadas de los agentes en producción terminan en segundos, así que el límite superior solo cuenta para jobs largos.
2. Refresh largo, rotado en cada uso. Un refresh token válido 30-90 días, rotado cada vez que se intercambia. Si el mismo refresh token se presenta dos veces, ambos quedan revocados.
3. Scope estrecho por token. Si el agente solo necesita acceso de lectura a una cuenta de storage, el token lo dice. Ningún bearer token en 2026 debería poder hacer cualquier cosa en cualquier recurso.
4. Auditoría en cada cambio de estado. Token adquirido, refrescado, aviso de expiración, expirado, revocado. El punto no es la línea de log; el punto es que un refresh token filtrado aparezca como evento de rotación duplicada en horas, no en meses.

La columna vertebral del estándar es OAuth 2.1 con PKCE, que la revisión de junio de 2025 de la especificación de autorización MCP adoptó. La misma revisión empujó a los servidores MCP al rol exclusivo de resource server OAuth: validan tokens emitidos por un authorization server externo, no los emiten. Esa separación es lo que hace aplicable el patrón TTL. El resource server no puede seguir aceptando un token pasado su vencimiento, ni queriendo.

Cómo de corto es corto

El número correcto depende del perfil de la llamada. Para agentes que responden en tiempo real a un prompt de usuario, 5-15 minutos bastan. Para jobs batch que se abren en abanico sobre cientos de herramientas, 60 minutos dan aire al orquestador sin alargar mucho la ventana de fuga. Aún no hemos encontrado un caso en producción donde un access token de 24 horas sea la respuesta correcta. Si el job necesita tanto tiempo, lo que necesita es un loop de refresh.

Para comparar, AWS permite codificar el TTL en la propia URL para S3 (máximo 12 horas vía consola, 7 días vía CLI) y ofrece la condición s3:signatureAge en las bucket policies que rechaza peticiones donde la firma tiene más de N minutos, independientemente de lo que diga la URL (AWS presigned URL best practices, PDF). Es ese segundo control el que hay que copiar. El TTL lo aplica el servidor, no el cliente.

El hueco en los refresh tokens

El patrón depende de que el cliente MCP implemente la rotación del refresh token. Esa implementación falta en la mayoría de los clientes del mercado en abril de 2026. SecureCoders rastrea la matriz de soporte y reporta que ningún cliente MCP CLI relevante envía hoy la rotación del refresh token. La consecuencia práctica: un access token expira, el cliente no puede rotarlo en silencio, y al usuario humano se le pide volver a autenticarse. El patrón sigue funcionando, pero el coste de UX cae sobre quien opera el agente, no sobre la plataforma.

Hasta que los clientes cierren el hueco, dos parches ayudan. Levantar un gateway MCP delante del servidor que sea dueño del loop de refresh y presente tokens frescos a los clientes upstream. O aceptar el re-auth interactivo como feature: forzar a un humano en el loop cada hora no es el peor modo en el que puede fallar un agente con acceso de escritura a la base de datos.

Qué loggear

Cinco eventos cubren el ciclo de vida y deberían acabar en el mismo stream de auditoría que los logs de aplicación:

• token.acquired con subject, scope y TTL.
• token.refreshed con id del token antiguo, id del nuevo, IP de origen.
• token.expiry_warning al 80% del TTL, para que el cliente lo rote antes.
• token.expired cuando el resource server lo rechaza.
• token.revocation_detected cuando un refresh token ya rotado se reproduce.

El último es la alarma. Un refresh token reproducido significa una de dos cosas: o el cliente reintentó tras un fallo parcial, y todo está bien en silencio; o dos partes tienen el mismo refresh token, y eso ya no está bien y debe mandar un page.

Dónde el patrón no encaja

Tres casos resisten. Primero, servidores MCP locales que no salen de la máquina del desarrollador: un TTL añade fricción sin comprar seguridad. Segundo, agentes que corren en redes aisladas sin egress: el vector de fuga ya no existe, la rotación es overhead. Tercero, el mismo servidor MCP consumido por decenas de miles de usuarios low-trust: el cuello de botella es la autenticación, y la respuesta es un gateway con scopes por usuario, no TTLs más cortos a nivel de URL.

Para todo lo demás (servidores MCP en cloud, acceso de colaboradores externos, agentes que llaman herramientas a través de fronteras organizativas, cualquier cosa que Trend Micro pueda encontrar con un port scan) el default debería ser TTL de minutos y un loop de refresh que nadie tenga que pensar hasta que algo salga mal.