MCP está construyendo su capa de identidad en silencio

Los números de adopción se llevan los titulares. Uber corre 60.000 tareas de agentes por semana sobre MCP, y el MCP Toolbox for Databases de Google Cloud gestionó 20 millones de tool calls en un solo mes. Model Context Protocol cruzó la línea que separa una spec prometedora de la infraestructura de producción.

Mi punto es otro: la historia más interesante está en el changelog.

Trabajo en la parte de seguridad del ecosistema de agentes: reviso servers MCP y monitoreo qué se publica en los registries públicos. Cuando encuentro vulnerabilidades en herramientas de agentes, las reporto. Con ese día a día, una revisión de la spec no se lee como release notes. Los protocolos codifican supuestos sobre la confianza, y cuando esos supuestos cambian, todo lo construido encima hereda el cambio, casi siempre sin darse cuenta. En las últimas dos revisiones, MCP viene cambiando un supuesto en particular: qué tiene permitido recordar una conexión.

¿Qué cambiaron de verdad las últimas dos revisiones de la spec?

Movieron la confianza, pieza por pieza, de la conexión al request. La revisión 2025-06-18 clasificó a los servers MCP como resource servers de OAuth y exigió que los clientes implementaran Resource Indicators (RFC 8707). Suena burocrático hasta que lo traducís. Un token emitido para un server ya no puede reutilizarse contra otro, y un server malicioso ya no puede juntar tokens que nunca fueron para él. Imaginate un agente conectado a tu server de despliegues y a un server de notas de terceros: antes del binding al recurso, un server de notas comprometido podía agarrar un token que veía pasar y probarlo contra tus despliegues. Ahora un token solo sirve donde fue emitido. Una familia entera de problemas de confused deputy quedó cerrada a nivel de protocolo, antes de que ningún desarrollador individual tuviera que pensarla.

La revisión 2025-11-25, la vigente, siguió tirando del mismo hilo. El descubrimiento del authorization server ahora soporta OpenID Connect. El consentimiento incremental de scopes vía WWW-Authenticate le permite a un server pedir más acceso cuando una tarea lo necesita de verdad, en lugar de exigir todo por adelantado. Los OAuth Client ID Metadata Documents pasaron a ser la forma recomendada de que los clientes se identifiquen. Nada de esto es vistoso. Cada cambio toma algo que era implícito en la conexión y lo vuelve explícito en el request.

Esa distinción importa por el rumbo que tomó el protocolo.

¿Cuánta seguridad dependía de la sesión?

Mucha más de la que se decidió a propósito. La página del proyecto en la AAIF describe el próximo release de la especificación en una línea: MCP se está volviendo stateless en la capa del protocolo.

En el MCP de hoy, un cliente y un server abren una sesión. Negocian una versión del protocolo e intercambian capacidades, y después sostienen una conexión sobre la que pasa todo lo demás. Esa sesión carga mucho peso de seguridad. La autenticación ocurre al principio. Las aprobaciones humanas se amortizan a lo largo de ella: aprobás una vez y las llamadas siguen fluyendo. Y la identidad suele ser posicional, es decir que muchos servers saben quién llama por el momento en que se abrió la conexión, no por nada que venga en el request mismo. Un caso típico: dos agentes llegan al mismo server por una única conexión compartida. El server ve una sola conexión y las aprobaciones corren bajo una sola identidad. Después, nadie puede decir cuál de los dos agentes ejecutó de verdad una herramienta.

La revisión actual ya apunta lejos de ese modelo. Las tasks, experimentales en 2025-11-25, permiten que un request sobreviva a su conexión: mandás el trabajo y te desconectás, y el resultado te espera hasta que volvés a buscarlo. Los servers ahora pueden cerrar streams SSE cuando quieran, y los clientes retoman por polling. Con cada uno de estos cambios, dependen menos cosas de la conexión. Seguí la trayectoria y caés exactamente donde la fundación dice que va el protocolo: cualquier request puede llegar a cualquier instancia, sin memoria compartida detrás.

Para quien opera servers es, sin vueltas, una buena noticia. Podés escalar horizontalmente sin sticky sessions, y los reintentos se simplifican porque queda menos estado de conexión colgado del que ocuparse. Pero si la sesión desaparece como unidad de continuidad, todo lo que la sesión cargaba de forma implícita tiene que mudarse a algún lugar explícito. La identidad tiene que llegar con cada request. El contexto de autorización también. El rastro de auditoría deja de ser "qué pasó en esta conexión" y pasa a ser "qué evidencia trae cada llamada por su cuenta".

Visto desde ahí, el trabajo de autorización de las últimas dos revisiones deja de parecer un conjunto suelto de detalles de OAuth. Tokens atados al recurso, descubrimiento estándar del authorization server, scopes incrementales, identidad de cliente estandarizada: son las piezas que necesitás cuando ya no queda una sesión que responda por quien llama. El protocolo está construyendo su capa de identidad primero, para que lo stateless no aterrice encima de la confianza implícita. Para alguien que revisa infraestructura de agentes todos los días, ese orden es lo más tranquilizador de la hoja de ruta.

¿Cómo te preparás hoy si mantenés un server MCP?

Empezá a actuar como si la sesión ya no existiera. Después de monitorear decenas de miles de skills y servers en los registries públicos, mi observación es que la mayoría de los servers MCP publicados todavía asume el modelo viejo: una conexión de larga vida desde un cliente confiable, con la autenticación resuelta una sola vez al conectar (si es que hay) y los logs indexados por sesión.

Nada de eso falla hoy. Solo construye sobre un supuesto del que el protocolo se está alejando. Para cualquiera que mantenga un server, los ajustes son concretos y vale la pena arrancarlos ahora.

Tratá cada request como si fuera el primero. Validá el token en cada llamada y respetá el binding al recurso, así un token emitido para el server de otro nunca funciona en el tuyo.

Acotá los scopes y volvé a pedir cuando haga falta. El consentimiento incremental existe justamente para que no tengas que cargar los permisos por adelantado. Un server de base de datos puede arrancar en solo lectura y pedir escritura la primera vez que una tarea la necesita de verdad. Un server que pide todo al instalarse está entrenando a los usuarios a aprobar sin leer.

Atá la evidencia a las llamadas, no a las conexiones. Registrá la identidad autenticada, la herramienta y los argumentos por request. Cuando el estado se va del protocolo, los registros por llamada son el único rastro de auditoría que sobrevive. El día que alguien pregunte quién borró esa tabla el martes, "la conexión de las 10:03" no es una respuesta. "Esta identidad llamó a esta herramienta con estos argumentos" sí.

Diseñá las herramientas para reintentos y resultados diferidos. Con las tasks, tu herramienta puede correr desacoplada de quien la pidió y entregar su resultado más tarde. El caso clásico acá es un despliegue que corre dos veces porque llegó un reintento. La idempotencia deja de ser opcional, y también decidir explícitamente de quién es cada resultado.

¿Dónde se decide todo esto?

En público, y ese es justamente el punto. La revisión 2025-11-25 también formalizó cómo se gobierna MCP: working groups con alcance definido y cambios que pasan por el proceso de SEPs. Cada cambio que describí arriba pasó por una propuesta pública que cualquiera podía leer y comentar. Si corrés MCP en producción, tenés datos de campo que los autores de la spec necesitan, y ahora hay una puerta definida para entrar con ellos.

La madurez de la infraestructura rara vez se ve como una keynote. Se ve como resource indicators y documentos de descubrimiento que aterrizan de a un pull request a la vez, bajo revisión abierta. Para eso existe la gestión responsable de un protocolo, y es la señal más fuerte que puedo mostrar de que MCP se está construyendo para durar.