Radar IA · Edición 001 · Noticias de inteligencia artificial explicadas en español.

LiteLLM 1.93.0 cambia cómo autentica servidores MCP

Confirmado y disponible. LiteLLM publicó la versión estable 1.93.0 el 19 de julio de 2026. El release reúne una serie amplia de cambios, pero el bloque más importante para quienes conectan agentes con herramientas MCP está en la autenticación: nuevos modos OAuth, soporte de intercambio de tokens On-Behalf-Of y un flujo más explícito para registrar clientes.

También trae una advertencia de migración. Las configuraciones MCP con auth_type: oauth2 ahora deben declarar oauth2_flow. La documentación oficial dice que el proxy se niega a iniciar si ese campo falta o tiene un valor inválido. Actualizar sin revisar el archivo de configuración puede romper un despliegue que antes dependía de la inferencia automática.

Tabla de contenido

1. Qué cambió en LiteLLM 1.93.0
2. OAuth deja de depender de inferencias
3. OBO y autenticación delegada no son lo mismo
4. Qué aporta el puente DCR
5. Dónde entra Zero Trust
6. Funciones nuevas y correcciones
7. El cambio potencialmente rompedor
8. Cómo actualizar con menos riesgo
9. Disponibilidad y límites

Qué cambió en LiteLLM 1.93.0

LiteLLM funciona como una puerta de enlace entre aplicaciones, modelos y herramientas. Su MCP Gateway ofrece un endpoint fijo para listar y llamar herramientas, con controles por clave, equipo u organización. La versión 1.93.0 amplía las formas de resolver la identidad cuando esas herramientas están protegidas.

El release oficial incluye soporte para oauth2_token_exchange desde la API REST y el panel, un perfil entra_obo, modos true_passthrough y oauth_delegate, mejoras al puente de registro dinámico y límites de concurrencia configurables desde la interfaz.

No todo en la lista es una función nueva. El release también corrige cómo se guardan, renuevan y eliminan tokens; cómo se registran los errores MCP; y cómo el filtro semántico falla cuando no puede evaluar una solicitud. Conviene separar ambos grupos antes de decidir si la actualización cambia la arquitectura o simplemente la hace más confiable.

OAuth deja de depender de inferencias

LiteLLM documenta dos flujos para servidores con auth_type: oauth2: authorization_code para autorización interactiva con PKCE y client_credentials para conexiones máquina a máquina. En v1.93.0, el campo oauth2_flow pasa a leerse de forma explícita y es obligatorio en las entradas de config.yaml.

La distinción importa. El flujo interactivo abre un navegador y produce tokens por usuario. El flujo máquina a máquina usa credenciales del servicio, almacena el token temporalmente y lo renueva cuando expira. Elegir por la forma de otros campos podía ocultar una configuración ambigua; declararlo convierte la intención en una parte visible del despliegue.

La interfaz también incorpora un selector de flujo OAuth al editar servidores MCP, según las notas del release. La captura oficial muestra la sección de configuración OAuth de LiteLLM; la apariencia exacta puede variar según la versión del panel.

OBO y autenticación delegada no son lo mismo

Con On-Behalf-Of, u OBO, LiteLLM recibe el token del usuario y lo intercambia mediante RFC 8693 por otro token limitado al servidor MCP. El servidor final recibe el token intercambiado, no la credencial original. La documentación indica que LiteLLM lo almacena temporalmente por combinación de usuario y servidor.

La autenticación delegada sigue otra ruta. El cliente —por ejemplo, un IDE o agente compatible con MCP— completa PKCE directamente con el proveedor OAuth. LiteLLM transmite el desafío y el token sin imponer una segunda autenticación propia cuando todos los destinos involucrados permiten esa modalidad.

Eso puede simplificar conexiones donde el proveedor ya es la fuente de identidad. También reduce una barrera: la propia documentación advierte que, al delegar, el acceso debe protegerse en el proveedor de identidad y en el borde de red. No es un modo que deba activarse como atajo universal.

Qué aporta el puente DCR

DCR significa registro dinámico de clientes. Permite que una aplicación MCP registre un cliente OAuth sin depender de un alta manual previa. LiteLLM 1.93.0 añade varias piezas para actuar como puente: una fachada de descubrimiento, retransmisión de registro y redirecciones, PKCE obligatorio con S256 y un “sobre sellado” para credenciales conservadas por el cliente.

Las notas del release describen estas piezas por separado. No publican una promesa de compatibilidad con todos los proveedores OAuth. El resultado real seguirá dependiendo de que el servidor de autorización implemente los endpoints y estándares esperados.

Dónde entra Zero Trust

Zero Trust no aparece en el release como una capacidad nacida en 1.93.0. Es una capa complementaria que LiteLLM ya documenta para impedir llamadas directas al servidor MCP. Su componente MCPJWTSigner firma cada llamada saliente con un JWT RS256 de corta duración; el servidor MCP verifica esa firma contra la clave pública de LiteLLM.

La diferencia es sencilla: OAuth responde quién puede obtener o presentar un token; el firmante Zero Trust permite comprobar que una llamada pasó por la puerta de enlace autorizada. La guía oficial de Zero Trust recomienda usar una clave de firma propia en producción, porque las claves generadas automáticamente se pierden al reiniciar.

La combinación puede ser útil para herramientas internas: OBO conserva la identidad del usuario con un token limitado, mientras la firma prueba el camino de la solicitud. Son controles distintos y ninguno reemplaza permisos, auditoría o seguridad de red.

Funciones nuevas y correcciones

Tipo	Cambio documentado	Impacto práctico
Función	OBO mediante oauth2_token_exchange en REST y panel	Permite intercambiar el token del usuario por uno limitado al MCP
Función	Modos true_passthrough y oauth_delegate	Amplían cuándo el cliente conserva el control del flujo OAuth
Función	Puente DCR con PKCE S256	Facilita registrar clientes a través del gateway
Corrección	Elimina tokens almacenados cuando cambian credenciales relevantes	Reduce el uso accidental de una autorización anterior
Corrección	Registra como fallo las herramientas que devuelven isError=true	Mejora la lectura operativa de errores MCP
Corrección	El filtro semántico falla cerrado ante errores de ventana de contexto	Evita tratar un fallo de filtrado como permiso implícito

El cambio potencialmente rompedor

El release marca con un signo de exclamación el cambio de oauth2_flow. La documentación es más concreta: cada servidor OAuth definido en archivo debe usar authorization_code o client_credentials, y el proxy no inicia si el valor está ausente o es inválido.

Los registros antiguos guardados en base de datos tienen una ruta de compatibilidad y una tarea de actualización mencionada en el release. Eso no protege a un config.yaml heredado. Antes de desplegar, hay que localizar todas las entradas OAuth y declarar el flujo correcto.

Cómo actualizar con menos riesgo

1. Inventariar los servidores MCP con OAuth y distinguir usuarios interactivos de servicios automáticos.
2. Añadir oauth2_flow a cada entrada de configuración antes de cambiar la imagen o el paquete.
3. Probar descubrimiento, autorización, listado de herramientas y una llamada real en un entorno de ensayo.
4. Verificar que la clave de LiteLLM viaje en x-litellm-api-key cuando Authorization se reserve para el token del usuario.
5. Si se usa autenticación delegada, comprobar controles en el proveedor de identidad y en la red.
6. Si se despliega con Docker, validar la firma de la imagen con el comando cosign publicado en el release.

Disponibilidad y límites

LiteLLM v1.93.0 figura como release estable y público. Las notas no describen restricciones regionales ni un despliegue gradual. La disponibilidad real depende de actualizar la instalación propia y configurar cada modo de autenticación.

Lo confirmado es la incorporación de estas capacidades y correcciones al release. No hay en las fuentes revisadas una medición pública de rendimiento, una auditoría externa de seguridad o una garantía de compatibilidad con todos los proveedores OAuth.

Fuentes primarias: release v1.93.0 en GitHub, documentación MCP OAuth, documentación OBO, documentación Zero Trust y descripción general del MCP Gateway.

Ver todas las noticias de Radar IA.