Gestión de credenciales en Vercel Connect: quién debe tener el control

La gestión de credenciales compartidas ya puede quedar en manos de una persona identificada sin convertirla en Owner del equipo de Vercel. El 11 de septiembre de 2026, Vercel incorporó Connector Permissions para los equipos Pro y Enterprise, de modo que un Owner puede limitar la creación y administración de conectores a las personas con rol Owner o con el permiso Connector Manager.

Hay un matiz importante: el rol Member ya incluye Connector Manager. La configuración solo establece un límite de responsabilidad estricto si la asignación de roles también lo hace.

Qué cambia en la gestión de credenciales con Connector Permissions

Un conector de Vercel Connect es el registro propiedad del equipo que representa un servicio como Slack, GitHub, Microsoft o un proveedor personalizado. Puede guardar o intermediar la credencial que utilizan varios proyectos; por eso, modificarlo es una operación de equipo y no un cambio cualquiera en una aplicación.

Connector Permissions añade a ese registro un control sobre quién puede administrarlo. Un Owner activa la restricción en Team Settings. A partir de ese momento, solo un Owner o una persona con el permiso ampliado Connector Manager puede crear o administrar conectores.

Ese permiso abarca los conectores de todo el equipo, las conexiones de proyectos, las instalaciones y los tokens. No concentra todas las decisiones de acceso en un único interruptor.

Esta separación es importante. Un Connector Manager puede mantener la conexión compartida, mientras que una aplicación desplegada sigue demostrando a qué equipo, proyecto y entorno pertenece mediante Vercel OIDC —la identidad de despliegue que Vercel entrega a la aplicación en ejecución— y un vínculo de proyecto. Después, el proveedor aplica sus propios alcances. Si publicar un mensaje o actualizar el registro de un cliente exige una decisión humana, esa aprobación debe seguir dentro del flujo de trabajo de la aplicación.

El análisis anterior sobre la autenticación de Vercel Connect explica con más detalle ese recorrido de intercambio de tokens. Esta versión cambia quién puede mantener la conexión, no la forma en que la aplicación en ejecución demuestra que puede solicitar un token.

La cuenta que importa es el tamaño del grupo con capacidad de cambio

La cifra relevante aquí no es otro límite de la API, sino cuántas personas pueden modificar un recurso del equipo que contiene credenciales.

Si todo el personal de desarrollo puede editar un conector compartido, cada cambio de plantilla, relevo de un contratista o corrección apresurada en producción amplía la superficie que debe revisarse. Connector Permissions permite definir de forma explícita el grupo de administración y dejar que el resto del equipo siga trabajando con vínculos de proyecto ya aprobados por la persona responsable.

La versión del 11 de septiembre no anuncia un cambio directo de precio. Vercel factura Connect por solicitudes de token y activadores, no por asignaciones de Connector Manager. Una página independiente de precios de Connect indica que los precios beta actualizados entran en vigor el 25 de septiembre de 2026: Pro cuesta $3.00 por cada 1,000 solicitudes de token, mientras que Enterprise tiene precios personalizados. La descripción del permiso no indica que cambie esa medición del uso en tiempo de ejecución.

Lo que sí puede reducirse es el costo operativo. Menos personas necesitan conocer la configuración del proveedor, el secreto de cliente y el contexto de instalación, o tener autoridad para cambiar las conexiones de proyectos. Quienes desarrollan dejan de depender del Owner cuando la persona designada puede encargarse del trabajo, mientras el Owner conserva el control sobre quién recibe esa autoridad.

Un traspaso ordenado para un solo equipo

Tomemos Northstar Agency como ejemplo con responsables identificados. Maya tiene el rol Owner de Vercel. Jon tiene el rol Developer y el permiso Connector Manager, y se encarga de las conexiones compartidas con los servicios. Priya tiene el rol Developer sin Connector Manager y desarrolla la aplicación del cliente. Leah es responsable de la regla de negocio que determina si la aplicación puede enviar o actualizar algo.

Este es el traspaso que mantiene separadas esas funciones.

1. 1

   Auditar el acceso heredado

   Maya revisa la lista del equipo antes de habilitar la restricción. Quien tenga el rol Owner o Member ya dispone de Connector Manager. Una persona con el rol Developer, Security, Billing, Viewer o Contributor puede recibir Connector Manager como permiso ampliado cuando ese rol base encaja con el resto de sus funciones.

2. 2

   Designar a la persona responsable del conector

   Maya abre Settings del equipo, entra en Members y utiliza Manage Role para Jon. Jon conserva el rol Developer y recibe Connector Manager. El registro del traspaso identifica el conector, la cuenta del proveedor, los proyectos y entornos vinculados, la persona responsable del lado del proveedor y el canal para gestionar la rotación o revocación del acceso.

3. 3

   Activar Connector Permissions

   Maya abre Team Settings, busca Connector Permissions y activa la restricción. Jon ya puede crear y administrar conectores sin recibir el rol Owner completo.

1. 1

   Mantener separado el alcance del proveedor

   Jon documenta los alcances, recursos o detalles de autorización solicitados al proveedor. Connector Manager responde quién puede mantener el objeto de Vercel; la autorización del proveedor establece qué puede hacer la credencial resultante. La regla de aprobación de Leah permanece en la aplicación porque ninguna de estas configuraciones decide si una acción de negocio real debe continuar.

2. 2

   Probar el recorrido de la solicitud

   Priya ejecuta una solicitud acotada desde el proyecto de QA vinculado. El recorrido definido es: identidad OIDC del despliegue de QA, vínculo de proyecto de Vercel Connect, token del proveedor con alcance de lectura y respuesta de la API del proveedor. Jon confirma la solicitud del token y la autorización en la pestaña Observability del conector. Maya también verifica que Priya no pueda acceder a la vía de administración del conector.

Ese último paso es la prueba de aceptación. Un documento de políticas no basta. La persona que desarrolla debe poder utilizar el recorrido aprobado en tiempo de ejecución y, a la vez, no debe poder modificar el conector compartido salvo que esa tarea forme parte de su función.

Quién debería usarlo ahora

Una startup Pro con una persona a cargo de la plataforma

La persona fundadora puede conservar el rol Owner y dar Connector Manager a quien se ocupa de la plataforma. El equipo de producto sigue trabajando mediante proyectos vinculados, mientras los cambios de conectores quedan en manos de una sola persona y tienen un único canal para escalar incidencias. El beneficio es reducir la dependencia de la persona fundadora sin ampliar la propiedad completa del equipo.

Un equipo de seguridad Enterprise

La persona a cargo de seguridad puede separar la revisión de la autorización del proveedor del mantenimiento cotidiano del conector. Quien mantiene el conector gestiona instalaciones y conexiones de proyectos, mientras la administración del proveedor aprueba los alcances relevantes. El beneficio es un registro de cambios más claro cuando una credencial compartida para agentes llega a varias aplicaciones.

Una agencia que entrega varias aplicaciones de clientes

La agencia puede designar a una persona responsable del conector en cada entorno de cliente y mantener a los contratistas de entrega centrados en los proyectos que tienen asignados. El beneficio aparece con la siguiente aplicación: el equipo reutiliza un recorrido de conexión aprobado sin conceder a todas las personas que desarrollan autoridad para editar la capa de credenciales compartidas.

Un equipo de operaciones que incorpora acciones de agentes

La persona que dirige operaciones debería usar Connector Permissions para traspasar la responsabilidad sobre las credenciales y conservar las acciones de alto impacto detrás del paso de aprobación propio del producto. El beneficio es una división clara: Jon puede reparar la conexión, Priya puede poner en producción el flujo de trabajo y Leah puede decidir cuándo se permite modificar el registro de un cliente o enviar un mensaje externo.

Lo que esta configuración no hace

Activar Connector Permissions no demuestra que se haya revocado el acceso existente en el proveedor. La revocación es una acción aparte, y Vercel señala que la invalidación inmediata depende de si el proveedor ofrece un endpoint de revocación.

Tampoco reduce los alcances del proveedor, cambia qué entornos de despliegue vinculados pueden solicitar tokens, añade aprobación humana a las acciones de agentes ni disminuye los cargos por uso de Connect. Son controles independientes con responsables distintos.

Los equipos Hobby no se ven afectados porque esta restricción administrativa es para Pro y Enterprise. Un prototipo individual sin conectores compartidos quizá todavía no necesite un traspaso. Un equipo con credenciales de producción compartidas, varias aplicaciones creadas con agentes o colaboradores externos debería establecer el límite antes de añadir el siguiente conector.

Qué conviene hacer el lunes

Hay que actuar esta semana si un conector atiende a más de un proyecto o si más personas están por desarrollar agentes que lo utilicen. Conviene esperar si el conector sigue siendo una prueba individual y nadie más depende de él. Si una aplicación solo consume en tiempo de ejecución un conector ya vinculado, su recorrido de código no necesita cambiar a raíz de esta versión.

El trabajo se cierra con una línea escrita y una solicitud real: Maya es responsable de la política, Jon mantiene el conector y el recorrido de lectura de QA se probó desde la identidad de despliegue, pasando por el vínculo de proyecto, hasta la respuesta del proveedor. Ese es el traspaso. La opción de configuración solo es el mecanismo que lo hace cumplir.

Recibe en el newsletter el próximo cambio de plataforma explicado con claridad.