Vercel Sandbox rejoint Secure Compute : relier les agents aux ressources privées

Vercel permet d’associer une sandbox à un réseau Secure Compute existant, depuis le code ou l’outil en ligne de commande. Le fournisseur indique qu’une sandbox existante peut changer de réseau, mais qu’une session en cours conserve sa connexion jusqu’à son arrêt.

Cette distinction importe pour une procédure de changement : une modification de configuration n’a pas nécessairement l’effet immédiat attendu sur une tâche déjà lancée. L’annonce ne précise pas tous les coûts ou les conditions contractuelles. Ceux-ci doivent être examinés pour le plan et l’architecture concernés.

Un agent d’analyse peut devoir consulter une base de test, un dépôt interne ou un service de calcul. Une sandbox reliée au bon réseau peut rendre ce travail possible sans exposer publiquement la ressource. Le besoin doit être décrit en termes de données et d’opérations, plutôt qu’en termes d’accès général.

Commencez par une copie des données adaptée aux essais ou une interface de lecture limitée. Pour une tâche de diagnostic, l’accès en écriture n’est pas toujours nécessaire. Une connectivité nouvelle doit s’accompagner d’une revue des destinations accessibles et des opérations permises.

Une sandbox isolée peut encore transmettre une donnée à une destination autorisée. Un réseau privé peut encore desservir un compte trop puissant. Une identité correctement limitée peut réduire le risque même lorsque l’agent commet une erreur. Ces contrôles doivent être évalués ensemble.

Le sujet des MicroVM et des agents traite de l’isolation d’exécution. La nouvelle capacité Vercel ajoute ici une question de connectivité et de cycle de session, plutôt que de remplacer ce modèle de menace.

Inventoriez les services que la sandbox peut atteindre, les identifiants qu’elle utilise et les données qui lui sont montées. Testez les refus d’accès : une destination interdite, une opération non permise et un identifiant expiré. Un essai réussi avec tous les droits ne valide pas les limites attendues.

Conservez des journaux qui permettent de rattacher l’accès à une tâche, sans enregistrer les secrets. Prévoyez qui peut interrompre une session et comment révoquer un identifiant. OWASP rappelle les risques d’autorisation et de confiance envers les services intégrés; ils demeurent pertinents dans un réseau privé.

Pour une PME dont le besoin est une synthèse de documents publics, cette configuration peut être disproportionnée. Pour un environnement soumis à des règles de réseau ou à une dépendance privée, elle peut répondre à une contrainte précise. La décision doit inclure le plan Enterprise requis, les compétences d’exploitation et les limites de l’usage.

L’architecture cloud doit prévoir l’exploitation après l’essai : changements de réseau, rotation des accès, erreurs, supervision et responsabilités. Daillac n’a pas testé cette nouvelle capacité pour cet article; l’analyse décrit les vérifications à réaliser avant un déploiement.

Dessinez le chemin entre la sandbox, le service interne et la sortie réseau. Pour chaque connexion, indiquez le port, l’identité utilisée et la règle d’accès attendue. Une adresse de sortie fixe peut répondre à une liste d’adresses autorisées; elle ne donne pas à elle seule les bons droits applicatifs. Le scénario de réception doit montrer une connexion autorisée et une destination refusée, sans supposer que la configuration d’une session active a déjà été modifiée.

Vercel — Sandbox now supports Secure Compute · OWASP — API Security Top 10, édition 2023. Sources consultées le 1er octobre 2026; les grilles et exemples de décision sont une analyse éditoriale de Daillac.