Análisis en profundidad · Unos 6 min de lectura
Vercel propone sustituir claves persistentes de agentes por identidades limitadas
Herramientas OIDC, intercambio de tokens en ejecución y requisitos previstos del Marketplace: la seguridad depende de las políticas de confianza y los permisos del usuario.
- Publicado aquí
- Fecha de la fuente
- Fuente revisada
En un artículo técnico del 22 de octubre de 2026, Malte Ubl, CTO de Vercel, explica el paso de secretos reutilizables a identidades de servicio de corta duración. Trata cómo acceden los agentes de IA, cómo valida ese acceso el proveedor y qué lo incentivaría a cambiar sus integraciones.
Escucha las noticias
Escucha este artículo o continúa con las noticias.
Preparando la lectura…
Voz del dispositivo
El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.
Al continuar puede repetirse una frase breve.
Resumen
- Vercel informa de un 8,4% de compatibilidad con autenticación segura en su encuesta a más de 1000 proveedores SaaS; no es una puntuación de seguridad del sector.
- La empresa prevé advertencias en el Marketplace para el 30 de noviembre de 2026 y la retirada de proveedores que incumplan sus requisitos para enero de 2027.
1. La duración limita una forma concreta de exposición
Un agente que utiliza varios servicios puede heredar claves con más permisos de los necesarios. Una copia robada puede seguir funcionando después de terminar la conversación. Ubl menciona repositorios, chats, dependencias comprometidas e inyección de instrucciones como vías de exposición. Cifrar secretos almacenados no impide que código malicioso lea las credenciales disponibles para la aplicación en ejecución. Importan tanto el alcance de la autoridad como su duración.
La encuesta de Vercel abarca más de 1000 proveedores SaaS, de los cuales el 8,4% admitía los métodos que denomina seguros. El artículo no detalla suficientemente el muestreo ni la clasificación para obtener una estimación representativa del sector. Es compatibilidad declarada, no probabilidad de intrusión ni calidad de despliegue. Las miles de horas de ingeniería que Vercel dice haber dedicado a rotaciones preventivas tampoco equivalen a un ahorro medido para cada cliente.
2. La identidad debe corresponder al destinatario
Con OpenID Connect, u OIDC, un emisor de confianza firma un token temporal que identifica la aplicación. El servicio receptor lo verifica antes de decidir qué operaciones permite. Las reglas de proyecto y entorno delimitan el despliegue aceptado; la audiencia identifica el servicio destinatario. Una firma válida, por sí sola, no demuestra que el token deba aceptarse en esta API ni que autorice cualquier acción.
Un token temporal expuesto sigue siendo utilizable hasta caducar, dentro de sus permisos. La corta vigencia limita esa copia, pero no impide la filtración ni que una carga comprometida solicite reemplazos. Vercel afirma que su federación está disponible de forma general desde 2024 para obtener credenciales temporales de AWS, Google Cloud y Azure. Blob, AI Gateway y Sandbox son ejemplos existentes, no lanzamientos realizados con este artículo.
3. Connect y OIDC UI cubren lados distintos
Vercel Connect utiliza la identidad del despliegue para solicitar tokens del proveedor durante la ejecución. El ejemplo de Linear especifica un usuario y un permiso de lectura. Requiere un conector configurado y vinculado al proyecto, la cuenta del usuario conectada y ámbitos admitidos por el proveedor. Una llamada de función no concede acceso a cualquier cuenta ni elimina la conexión del usuario o unifica los permisos entre servicios.
OIDC UI está dirigido a proveedores de API: su registro shadcn/ui ofrece formularios de políticas de confianza y código de verificación del servidor. El constructor mostrado separa emisor, equipo, proyecto, entorno y audiencia. Reduce trabajo repetido. Nuestro análisis es que no decide la frontera de confianza correcta: aceptar proyectos demasiado amplios o una audiencia incorrecta sigue siendo un error de política aunque el formulario y el verificador se generen correctamente.
4. El intercambio sigue dependiendo de la red
El artículo distingue leer un token disponible de intercambiarlo. Vercel Functions recibe un token de identidad de la plataforma en la cabecera de la solicitud; el SDK puede leerlo sin obtener otro. La plataforma reutiliza tokens vigentes; Connect almacena tokens del proveedor en el proceso y los renueva cerca de la caducidad. Las audiencias personalizadas y los intercambios del proveedor siguen requiriendo llamadas de red: no se promete latencia adicional nula para toda autenticación.
El ejemplo de Cosmos DB concreta las etapas: Azure debe confiar en el proyecto Vercel y la audiencia predeterminada; ClientAssertionCredential presenta el token Vercel para obtener un token de acceso de Azure; CosmosClient utiliza esa credencial. Hay que considerar renovación y disponibilidad del proveedor, además del primer acceso correcto. No se aporta un benchmark independiente de latencia ni una garantía de que la caché elimine las interrupciones de autenticación.
5. Los plazos son un incentivo comercial previsto
Ubl señala tres obstáculos: configuración difícil, latencia en la ruta de las solicitudes y pocos incentivos para el proveedor. Vercel aborda el último mediante su Marketplace. Planea marcar como “Not secure” para el 30 de noviembre de 2026 los listados de proveedores sin autenticación OIDC desde Vercel que sigan utilizando secretos de larga duración. Dice que retirará para enero de 2027 a quienes no ofrezcan autenticación segura.
Son requisitos futuros anunciados para su ecosistema, no medidas ya aplicadas ni una norma legal universal. El artículo no fija día ni hora concretos de enero. Vercel dice exigir lo mismo a su API e integraciones nativas; la configuración automática al conectar servicios sigue siendo trabajo en curso. Conviene comprobar la compatibilidad real de cada integración, sin suponer que toda conexión del Marketplace ya configura la federación.
6. La migración debe probar la autorización
Imaginemos un agente que solo lee las tareas de Linear de un usuario. Proponemos inventariar las claves persistentes y relacionar cada servicio con despliegue, usuario y permiso necesario. Tras configurar confianza y conexión del usuario, hay que comprobar que funciona la lectura prevista y se rechazan otros proyectos, entornos, audiencias u operaciones no autorizadas. Es un método de revisión sugerido, no una prueba de AISubHub ni una promesa adicional de Vercel.
Antes de retirar la clave anterior, compruebe caducidad, renovación, caché y fallos de intercambio, con un plan explícito de recuperación. Obtener un token puede ocultar permisos excesivos o una renovación frágil. El cambio útil consiste en autoridad limitada, renovable y con fronteras observables. No elimina las credenciales del agente, no resuelve la inyección de instrucciones ni garantiza que todos los proveedores posteriores hayan adoptado el protocolo.
Por qué importa
Nuestro análisis: la identidad del despliegue puede reducir la distribución de claves persistentes, pero el receptor debe admitirla y limitarla. Los incentivos del Marketplace podrían ampliar la compatibilidad; configuración y autorización del usuario siguen siendo necesarias.
Límites y disponibilidad
Análisis del artículo oficial y su ilustración de configuración, sin auditoría independiente ni prueba de rendimiento. La metodología de encuesta es incompleta y los plazos previstos no son ejecución consumada. No se modificaron cuentas, integraciones ni producción.
Fuentes y pruebas
Fecha de la fuente: · Fuente revisada:
Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.