Vercel Agent accède à la production via un plan à scopes et une seule approbation

Vercel a publié une analyse de la manière dont son Vercel Agent accède aux systèmes de production. Le problème de départ est familier à quiconque a déjà confié la production à des agents : une requête comme « répare le déploiement » ne dit pas à l'avance quelles actions seront nécessaires ni quels droits il faudra. Un accès large signifie qu'une erreur peut toucher des ressources sans rapport. Exiger une confirmation à chaque étape transforme la relecture en clic automatique sur « Approuver ». Vercel a choisi une troisième voie : l'agent enquête d'abord, puis propose un plan, et l'approbation du plan accorde exactement les droits supplémentaires nécessaires à son exécution.

Le plan comme unité d'autorisation

Prenons l'exemple d'un déploiement en échec. L'agent examine les derniers déploiements et les logs de build, puis compare le déploiement tombé avec le dernier qui fonctionnait. Un accès en lecture seule suffit pour cela, et l'enquête se déroule automatiquement. Si elle débouche sur la proposition d'un redéploiement, l'agent formule un plan et demande le scope read-write:deployment. L'utilisateur voit ainsi, dans une seule décision, l'action et l'accès qu'elle exige.

Le plan relie quatre couches : l'intention (ce que veut l'utilisateur), le travail (les tâches de l'agent), l'accès (les scopes de ces tâches) et l'application des règles, ou enforcement (tokens et contrôles côté API). Chaque plan enregistré conserve les tâches, la progression et les scopes demandés, cumulés sur l'ensemble des étapes. L'agent peut effectuer une brève vérification d'information sans aucun plan. Pour les enquêtes longues, il crée un plan en lecture seule afin que l'utilisateur puisse suivre l'avancement du travail.

Le niveau de base inclut aujourd'hui tous les scopes enregistrés portant le préfixe read:. Une confirmation est requise si le plan dépasse ce niveau ou comprend des actions externes prises en charge, par exemple l'ouverture d'une pull request sur GitHub. Vercel le précise explicitement : la lecture peut elle aussi exposer des données sensibles, et l'approbation automatique n'équivaut donc pas à l'innocuité.

Des tokens que le modèle ne peut pas contourner

Vercel Agent fonctionne comme une Vercel App que l'utilisateur autorise au niveau de l'équipe. Cette autorisation est bornée par les droits de l'utilisateur lui-même : l'approbation d'un plan ne donnera donc pas à l'agent ce que l'humain n'a pas. Le service OAuth échange l'autorisation contre des tokens à courte durée de vie, assortis de scopes précis, et les API vérifient le token à chaque requête.

Un détail important : deployment write est plus large qu'un simple redéploiement. Si le plan nomme le déploiement X, cela ne restreint pas, en soi, le token à ce seul déploiement. La protection repose donc sur plusieurs couches, et les instructions données au modèle sur le moment où demander une approbation ne sont pas considérées comme une frontière de sécurité. Si l'agent tente une opération hors du périmètre du token, l'API la rejette, même si le modèle juge l'action nécessaire.

Le credential utilisé dépend du travail à effectuer :

• enquête : token de base avec des scopes en lecture seule ;
• modifications approuvées dans Vercel : scopes de base plus scopes supplémentaires validés ;
• actions externes : credentials et droits propres au fournisseur concerné.

Un même plan peut inclure à la fois des modifications dans Vercel et une pull request. L'utilisateur vérifie le tout en une fois, mais les fournisseurs appliquent des droits distincts. L'accès GitHub est lié à un propriétaire et à un dépôt : l'approbation pour acme/storefront ne s'étend pas à acme/payments, qui en exige une autre.

Registre unique des scopes et reprise du travail

Vercel Agent disposait au départ de sa propre liste d'autorisations, qui divergeait de celle du service OAuth émetteur des tokens. Désormais, au démarrage d'une session, l'agent charge les définitions depuis un registre commun des scopes dans un catalogue en mémoire (in-memory). Ce catalogue sert à valider le plan (les noms inconnus ou incorrects sont rejetés avant d'être montrés à l'utilisateur), à décider si une approbation est nécessaire et à préparer le token.

Si, d'après les règles du pare-feu, une tâche demande un scope obsolète, le système rejette le plan et renvoie la liste des scopes valides, pour que l'agent se corrige plutôt que d'obtenir par défaut un accès plus large. Le catalogue est mis en cache : les vérifications reflètent donc son état jusqu'à la prochaine actualisation.

Les défaillances ont fait l'objet d'un travail distinct. Une approbation peut arriver après la fin du chat d'origine, ou la connexion peut se couper au milieu d'un redéploiement. Le plan conserve son état, l'auteur de l'approbation et l'horodatage. Avant de poursuivre, le runtime recharge le plan et vérifie qu'il est actif. Un plan arrêté ne passe pas cette vérification, même si le token n'a pas encore expiré. Si une approbation et un arrêt arrivent en même temps, le plan ne passe de l'état d'attente à l'état actif que si l'arrêt n'a pas encore modifié le statut. Le remplacement d'un plan par un autre aux droits plus élevés exige à nouveau une approbation.

Ce qui reste ouvert

Vercel énumère sans détour les points faibles. L'agent choisit les scopes avec des informations incomplètes et peut en demander trop peu ou trop. Un scope valide peut aussi être plus large que nécessaire. Un refus de l'API peut signaler un manque de droits, une ressource erronée ou une opération qui doit rester interdite, et l'agent doit savoir distinguer ces cas. Par ailleurs, des instructions malveillantes peuvent se cacher dans le contenu lu, par exemple dans les logs de build. C'est pourquoi les plans fonctionnent de pair avec l'isolation en sandbox, les politiques réseau, la gestion des secrets, les limites, les logs d'audit et l'autorisation des services.

Ce qu'il faut retenir pour vos systèmes d'agents

Pour les équipes qui conçoivent des agents d'infrastructure, ce schéma offre plusieurs repères. Séparez l'enquête de la modification. Présentez à l'humain l'action en langage simple, à côté des scopes. Puisez les définitions de droits à la même source que celle qui émet les tokens. Vérifiez que le plan est actif avant chaque utilisation d'un credential, et pas seulement à l'émission. Et ne comptez pas sur les instructions données au modèle pour le limiter : les restrictions doivent résider dans l'API.