Vercel Agent accede a producción mediante un plan con scopes y una sola aprobación

Vercel ha publicado un análisis de cómo su Vercel Agent accede a sistemas en producción. El problema de partida le resultará familiar a cualquiera que haya intentado entregar producción a un agente: una petición como «arregla el despliegue» no indica de antemano qué acciones harán falta ni qué permisos se necesitarán. Un acceso amplio implica que un error puede afectar a recursos ajenos. Confirmar cada paso convierte la revisión en un clic automático sobre «Aprobar». Vercel eligió un tercer camino: el agente primero investiga, luego propone un plan, y la aprobación del plan concede exactamente los permisos adicionales necesarios para ejecutarlo.

El plan como unidad de autorización

El esquema funciona así en el caso de un despliegue roto. El agente revisa los últimos despliegues y los logs de build, y compara el despliegue fallido con el último que funcionó. Para eso basta el acceso de solo lectura, y la investigación se ejecuta de forma automática. Si de ella surge la propuesta de hacer un redespliegue, el agente genera un plan y solicita el scope read-write:deployment. El usuario ve la acción y el acceso que requiere en una sola decisión.

El plan une cuatro capas: intención (lo que quiere el usuario), trabajo (las tareas del agente), acceso (los scopes de esas tareas) y cumplimiento (tokens y comprobaciones en el lado de la API). Cada plan guardado almacena las tareas, el progreso y los scopes solicitados, que se suman a lo largo de todos los pasos. El agente puede resolver una consulta rápida sin ningún plan. Para las investigaciones largas se crea un plan de solo lectura, de modo que el usuario pueda seguir el avance del trabajo.

El nivel base incluye ahora todos los scopes registrados con el prefijo read:. Se exige confirmación si el plan supera ese nivel o contiene acciones externas admitidas, por ejemplo abrir un pull request en GitHub. Vercel advierte de forma expresa que la lectura también puede exponer datos sensibles, así que la aprobación automática no equivale a inocuidad.

Tokens que el modelo no puede eludir

Vercel Agent funciona como una Vercel App que el usuario autoriza en el ámbito de un equipo. Esa autorización está limitada por los permisos del propio usuario, así que aprobar un plan no da al agente nada que la persona no tenga. El servicio OAuth canjea la autorización por tokens de vida corta con scopes concretos, y las API comprueban el token en cada solicitud.

Hay un detalle importante: deployment write abarca más que un solo redespliegue. Que el plan mencione el despliegue X no limita por sí mismo el token a ese despliegue. Por eso la protección se apoya en varias capas, y las instrucciones al modelo sobre cuándo pedir aprobación no se consideran un límite de seguridad. Si el agente intenta ejecutar una operación fuera del token, la API la rechaza, incluso cuando el modelo concluya que la acción es necesaria.

La credencial que se usa depende del trabajo:

• investigación: token base con scopes de solo lectura;
• cambios aprobados en Vercel: scopes base más los adicionales aprobados;
• acciones externas: credenciales y permisos del proveedor correspondiente.

Un mismo plan puede incluir cambios en Vercel y un pull request. El usuario revisa todo a la vez, pero los proveedores utilizan permisos independientes. El acceso a GitHub está vinculado al propietario y al repositorio: la aprobación para acme/storefront no se extiende a acme/payments, que requiere la suya propia.

Registro único de scopes y reanudación del trabajo

Al principio, Vercel Agent tenía su propia lista de permisos, que divergía de la del servicio OAuth que emite los tokens. Ahora, al iniciar una sesión, el agente carga las definiciones desde un registro común de scopes en un catálogo en memoria. El catálogo sirve para validar el plan (los nombres desconocidos o incorrectos se rechazan antes de mostrárselo al usuario), para decidir si hace falta aprobación y para preparar el token.

Si una tarea solicita un scope obsoleto según las reglas del firewall, el sistema rechaza el plan y devuelve la lista de scopes válidos, para que el agente se corrija en lugar de recibir por defecto un acceso más amplio. El catálogo se almacena en caché, así que las comprobaciones reflejan su estado hasta la siguiente actualización.

Los fallos se han tratado por separado. La aprobación puede llegar cuando el chat original ya ha terminado, o la conexión puede cortarse en mitad de un redespliegue. El plan guarda su estado, quién lo aprobó y cuándo. Antes de continuar, el runtime recarga el plan y comprueba que sigue activo. Un plan detenido no supera la comprobación, aunque al token le quede tiempo de vida. Si la aprobación y la detención llegan al mismo tiempo, el plan pasa de «en espera» a «activo» solo si la detención aún no ha cambiado su estado. Sustituir un plan por otro con más permisos vuelve a exigir aprobación.

Lo que queda abierto

Vercel enumera con franqueza los puntos débiles. El agente elige los scopes con información incompleta y puede pedir demasiado poco o demasiado. Un scope válido también puede ser más amplio de lo necesario. El rechazo de la API puede significar falta de permisos, un recurso equivocado o una operación que debe seguir prohibida, y el agente tiene que distinguir entre ellos. Además, pueden esconderse instrucciones maliciosas en el contenido que el agente lee, por ejemplo en los logs de build. Por eso los planes funcionan junto con el aislamiento en sandbox, las políticas de red, la gestión de secretos, los límites, los audit logs y la autorización entre servicios.

Qué llevarse a los sistemas de agentes propios

Para los equipos que construyen agentes para infraestructura, el esquema deja varias pautas. Separe la investigación del cambio. Muestre a la persona la acción en lenguaje sencillo junto a los scopes. Tome las definiciones de permisos de la misma fuente que emite los tokens. Compruebe que el plan está activo antes de cada uso de una credencial, y no solo en la emisión. Y no confíe en que las instrucciones al modelo bastarán para limitarlo: las restricciones deben vivir en la API.