Vercel durcit ses sandboxes avec un pare-feu réseau au cœur du modèle

Vercel pose un constat utile pour tous ceux qui exécutent du code généré, téléchargé ou simplement non revu : une sandbox n’est pas vraiment une sandbox si elle ne contrôle que la machine hôte et pas ce que le processus peut atteindre sur le réseau. Dans son billet publié le 11 août 2026, l’éditeur explique qu’une microVM (machine virtuelle très légère) peut empêcher l’accès à l’hôte ou à d’autres charges, mais ne bloque pas à elle seule l’exfiltration (sortie non autorisée de données), le sondage de services internes, ni l’usage de secrets déjà présents dans l’environnement. L’idée centrale tient en une formule : l’isolation du calcul contient le processus, pas forcément ses conséquences. (vercel.com)

Ce que Vercel ajoute concrètement

Le point le plus concret pour un développeur est le modèle de politique réseau. Vercel dit qu’une sandbox utile doit pouvoir aller de l’accès totalement ouvert à l’isolement complet, avec entre les deux des règles granulaires qui refusent par défaut tout trafic non explicitement autorisé. Les politiques peuvent combiner :

• des règles par domaine (nom d’hôte, pratique quand les adresses IP changent),
• des règles par CIDR (plage d’adresses IP écrite en notation réseau, utile pour des réseaux privés ou fixes),
• des permissions temporaires selon la phase du workflow.

Le billet donne des exemples parlants : autoriser seulement un fournisseur de modèles, un seul bucket de stockage objet, un service privé précis, ou encore laisser l’installation de dépendances pendant la phase de préparation puis couper l’accès au registre avant l’exécution du code non fiable. Vercel insiste aussi sur un besoin très opérationnel : changer la politique pendant l’exécution, sans redémarrer la sandbox. (vercel.com)

Comment la frontière réseau est appliquée

Techniquement, Vercel place son pare-feu (firewall) sur l’hôte, donc hors de la microVM, pour que le code exécuté dans la sandbox ne puisse ni le modifier ni le désactiver. Les connexions TCP sortantes et les requêtes DNS sont redirigées de façon transparente vers ce pare-feu. Pour les connexions TLS (le protocole de chiffrement utilisé par HTTPS), le système lit le SNI (Server Name Indication, le nom d’hôte annoncé au début de la poignée de main TLS) afin de vérifier le domaine demandé avant d’ouvrir la connexion vers la destination. Vercel précise que les connexions TLS autorisées passent normalement sans déchiffrement, sauf dans les cas où une politique doit inspecter ou modifier la requête HTTP elle-même. (vercel.com)

Le point le plus intéressant : garder les secrets hors du code exécuté

Le passage le plus utile côté architecture concerne les identifiants. Vercel explique qu’un jeton placé en variable d’environnement ou dans un fichier devient un bearer credential (un secret réutilisable par quiconque le possède). Dans Sandbox, l’authentification peut être injectée à la frontière réseau : le pare-feu crée une autorité de certification dédiée à la sandbox, termine sélectivement TLS pour certaines destinations configurées, ajoute ou remplace l’en-tête d’authentification, puis réouvre une connexion TLS vers le service en face. Résultat annoncé : le secret n’entre jamais dans la microVM, ne sort pas de l’hôte en clair, et ne peut être utilisé que vers la destination prévue, avec des restrictions supplémentaires possibles par chemin d’URL, méthode HTTP, paramètres ou en-têtes. Pour des équipes qui font tourner du code tiers, des jobs éphémères ou des agents internes, c’est une approche plus défendable que le simple API_KEY injecté partout. (vercel.com)

import { Sandbox } from '@vercel/sandbox';

const sandbox = await Sandbox.create({
  networkPolicy: {
    allow: {
      'ai-gateway.vercel.sh': [{
        transform: [{
          headers: {
            Authorization: `Bearer ${process.env.AI_GATEWAY_TOKEN}`
          }
        }]
      }]
    }
  }
});

await sandbox.update({ networkPolicy: 'deny-all' });

Pourquoi ça compte pour ton outillage quotidien

Même si le billet est publié sous l’angle des agents, son intérêt dépasse largement ce cas. On retrouve ici des problèmes classiques de plateformes d’exécution : jobs CI/CD, prévisualisations, exécution de plugins, génération de code, tests d’intégration ou tâches d’analyse de dépôts. Le message de Vercel est net : la frontière de sécurité ne s’arrête pas au noyau Linux, au conteneur ou à la VM ; elle inclut aussi DNS, proxy (intermédiaire réseau), services d’identité, plages privées et destinations explicitement autorisées. L’éditeur ajoute enfin que les capacités complètes de pare-feu de sortie (egress firewall, contrôle du trafic sortant) sont disponibles pour toutes les sandboxes. Pour un lecteur habitué à Node, Next.js, Java ou aux microservices, la leçon est transposable immédiatement : si vous exécutez du code non fiable, la question n’est pas seulement « où tourne-t-il ? », mais aussi « que peut-il joindre, avec quels droits, et à quel moment ? ». (vercel.com)