Vercel Agent : le plan fixe les permissions

Ce qui se passe

Demander à un agent de « réparer ce déploiement » ne dit pas d'avance quelles actions il lui faudra. Lui donner un accès large, c'est prendre le risque qu'une erreur touche des ressources sans rapport. Exiger une validation à chaque pas, c'est habituer l'utilisateur à cliquer sur « approuver » sans lire. Vercel décrit sa réponse pour Vercel Agent : il enquête d'abord, puis propose un plan qui liste le travail et l'accès nécessaire. L'approbation du plan accorde les permissions supplémentaires, et rien d'autre.

Du plan au jeton

Les permissions sont des scopes, des capacités nommées que le système d'autorisation de Vercel reconnaît. La base en lecture seule est constituée de tous les scopes enregistrés dont le nom commence par read: : l'enquête tourne avec, sans validation. Pour une panne de déploiement, l'agent lit les derniers déploiements et les journaux de build, puis les compare au dernier déploiement sain.

Un plan qui dépasse la base, ou qui comprend une action externe prise en charge (ouvrir une pull request GitHub, par exemple), attend l'approbation en entier, tâches en lecture seule comprises.

L'agent est une application Vercel autorisée par l'utilisateur au sein d'une équipe, donc bornée par les droits que celui-ci a déjà : approuver un plan ne peut pas créer un accès que l'utilisateur n'a pas. Le service OAuth échange cette autorisation contre des jetons de courte durée, et les API vérifient le jeton à chaque requête. Les consignes du modèle lui disent quand proposer un plan, mais s'il tente une opération hors des permissions du jeton, l'API la rejette, même s'il la juge nécessaire.

Pour les actions externes, les droits restent propres à chaque fournisseur : l'approbation d'une pull request sur acme/storefront ne couvre pas acme/payments, même si l'utilisateur a accès aux deux.

Un registre unique de scopes

Vercel a d'abord tenu une liste de permissions séparée pour l'agent, qui pouvait diverger du service OAuth émetteur des jetons. Les deux lisent maintenant le même registre, chargé en mémoire au début de chaque session. Un plan qui réclame un nom inconnu, mal formé ou périmé est rejeté avant d'être présenté, avec la liste des scopes valides pour qu'il se corrige explicitement, sans repli vers un accès plus large. Le catalogue est mis en cache : il peut être en retard sur le registre jusqu'à son rafraîchissement.

Les limites que la source assume

• read-write:deployment couvre plus qu'un redéploiement : citer un déploiement dans le plan ne restreint pas le jeton à celui-là.
• Une lecture seule peut exposer des informations sensibles : l'approbation automatique ne veut pas dire que le travail est inoffensif.

Ce qu'on peut en reprendre

Pour un agent ou un serveur MCP que vous écrivez : séparer l'enquête en lecture de l'action en écriture ; faire demander les scopes par le plan et les valider contre un registre unique ; émettre des jetons courts, liés à un plan actif ; faire appliquer les limites par l'API, jamais par le prompt.

Source : Vercel, « How Vercel Agent accesses production safely », 23 octobre 2026. Source en anglais.