Pointez l'agent sur du code en lequel vous n'avez pas confiance. Ne perdez rien quand il mord.
Les agents clonent des repos tiers, installent des dépendances et exécutent des scripts de build écrits par des inconnus. Un hook postinstall malveillant ou une instruction enfouie dans un README ne devrait atteindre ni vos tokens, ni vos clés, ni votre réseau. Dans une VM Bromure, il ne le peut pas.
Le problème
Chaque npm install est une exécution de code à distance
Dès qu'un agent exécute `npm install`, `pip install` ou un Makefile depuis un repo non fiable, du code arbitraire écrit par des gens que vous n'avez jamais rencontrés s'exécute avec les privilèges de votre ingénieur. Un script postinstall empoisonné, un paquet typosquatté, une étape de build qui téléphone à la maison — chacun s'exécute en tant qu'utilisateur, avec les clés SSH, les identifiants cloud et l'environnement de l'utilisateur à un appel système près.
Le coding agentique rend cela plus fréquent et plus dangereux. L'agent clone avec enthousiasme le repo qu'un ticket lui a indiqué, installe tout ce que le lockfile dit, et exécute la suite de tests — et une injection de prompt dans le README du projet peut l'orienter vers « lance juste ce script de setup » avant qu'un humain n'ait relu une seule ligne.
La réponse de Bromure
Le rayon de souffle est une VM sur le point d'être supprimée
Bromure exécute l'agent — et tout ce qu'il lance — dans une VM Linux jetable avec son propre noyau, son propre système de fichiers et sa propre pile réseau. Le repo non fiable, ses dépendances et ses scripts de build s'exécutent là, pas sur le portable de l'ingénieur. Les vrais identifiants n'entrent jamais dans la VM ; l'agent atteint Git et les registres de paquets à travers un proxy qui détient les secrets.
Si un hook postinstall tente de lire `~/.ssh`, d'exfiltrer une variable d'environnement ou d'ouvrir un reverse shell, il trouve une VM éphémère sans vrais secrets, une sortie réseau verrouillée sur une liste d'autorisation, et rien qui vous appartienne à voler. Quand la tâche se termine, la VM est détruite, et tout ce que le paquet a planté disparaît avec elle. Et si le README ou un script de build tente d'orienter l'agent lui-même, la détection d'injection de prompt en local de Bromure signale la tentative — si bien qu'une instruction hostile est attrapée, pas seulement contenue.
Comment ça marche
Les identifiants n'entrent jamais dans la pièce
L'accès à Git et au registre passe par un proxy d'identifiants. L'agent et le code non fiable qu'il exécute obtiennent un accès cadré et de courte durée — ils ne voient jamais un vrai jeton ni une clé SSH.
Une sortie réseau en laisse
L'accès réseau est sur liste d'autorisation par profil. Une dépendance qui balise vers un domaine fraîchement enregistré ou une IP littérale est bloquée, et la tentative apparaît dans le journal.
Environnement de build éphémère
Clone, install et build se font tous dans une VM détruite en fin de tâche. Un implant persistant n'a rien de persistant où vivre.
L'injection attrapée, pas seulement contenue
Un classifieur en local analyse ce que l'agent lit — READMEs, commentaires de code, pages récupérées, sortie d'outils — et les fichiers de règles de type CLAUDE.md auxquels il fait confiance, à la recherche d'instructions qui tentent de l'orienter. La tentative est signalée ou bloquée avant que le modèle n'agisse, pas simplement mise en bac à sable après coup.
Non fiable par défaut
Les nouveaux repos reçoivent automatiquement le profil verrouillé — téléchargements confinés, secrets proxifiés, sortie réseau restreinte — pour que « lance l'agent sur ce projet externe » soit sûr avant que quiconque ne le vérifie.
En pratique
Ce qui se passe quand le paquet est hostile
Un ingénieur demande à l'agent d'évaluer une bibliothèque open-source qu'un ticket a suggérée. L'agent clone le repo dans une VM Bromure fraîche et exécute `npm install`. À l'insu de tous, une dépendance transitive embarque un script postinstall qui lit les variables d'environnement et les POST vers le endpoint d'un attaquant.
À l'intérieur de la VM, le script s'exécute — et ne trouve rien qui vaille la peine d'être pris. Il n'y a pas de vrais identifiants dans l'environnement ; Git et le registre ont été atteints à travers le proxy, qui n'a jamais exposé de jeton. Le POST vers le domaine de l'attaquant n'est pas sur la liste d'autorisation de sortie du profil, donc il est rejeté et journalisé. Le relevé de session montre la lecture de l'environnement, la connexion bloquée et la destination.
L'ingénieur lit le rapport, signale le paquet, et clôt la session. La VM — et l'implant, les fichiers modifiés, le payload mis en cache — est détruite. Le portable n'a jamais exécuté une ligne du code hostile, et la seule chose que l'attaquant a apprise, c'est que la porte était verrouillée.
Architecture & intégration
Comment c'est réellement construit
Fin du marketing. Ce qui suit, c'est le socle technique sur lequel chaque déploiement de Bromure repose — le même que vous protégiez des effectifs BYOD ou que vous cloisonniez des niveaux de classification dans une agence régulée.
Isolation appliquée par l'hyperviseur
Chaque profil s'exécute dans sa propre VM Linux légère au-dessus du Virtualization.framework d'Apple — un noyau, un système de fichiers et une pile réseau distincts de l'hôte. L'image de base est un build Alpine signé et reproductible, cloné via APFS copy-on-write au lancement de la session (coût disque quasi nul). L'hôte ne peut pas lire la mémoire de la VM ; la VM ne peut pas lire le presse-papiers, le système de fichiers ou les adaptateurs réseau de l'hôte, sauf si la politique du profil l'autorise explicitement.
Identité : SSO pour les utilisateurs, mTLS pour les appareils
L'enrôlement et le lancement de session sont conditionnés à deux facteurs que votre organisation exploite déjà. OIDC / SAML contre Google Workspace, Okta, Microsoft Entra ou Authentik identifie l'utilisateur. Un certificat client mTLS par appareil, émis par votre PKI et lié à l'installation, identifie la machine. Révoquez l'un ou l'autre et la prochaine session refuse de se lancer — aucun agent à trafiquer, aucune politique locale à contourner.
Profile-as-code
Le profil de travail — liste de SaaS autorisés, posture téléchargement / presse-papiers / capture d'écran, configuration VPN, disposition clavier, CA racines, règles de sortie réseau — est un artefact déclaratif signé. Versionnez-le dans Git. Poussez-le via votre MDM ou l'endpoint de configuration Bromure. Les profils altérés échouent à la vérification de signature et la session refuse de démarrer. Ce qui tourne sur la machine de l'utilisateur est bit pour bit ce que vous avez écrit.
Plan réseau par profil
Chaque profil porte son propre NIC virtuel. Choisissez le NAT à travers l'hôte, le pont vers une interface physique, ou le tunnel via WireGuard, IKEv2 / IPsec ou Cloudflare WARP — tous terminés à l'intérieur de la VM, invisibles pour l'hôte. Ajoutez par-dessus des overrides DNS, des listes blanches de ports sortants, de l'isolation LAN et un proxy HTTP. La segmentation est appliquée par l'hyperviseur, pas par un autocollant sur le pare-feu.
Pipeline d'audit
Chaque requête — horodatage, verbe, URL, statut, utilisateur, profil, appareil — est capturée hors de la VM dans un flux JSON Lines résistant à l'altération et livrée au puits de logs que vous alimentez déjà (SIEM, data lake, archive de rétention). En option, enregistrement de session en en-têtes seuls ou corps complet pour le trafic suspect. Schéma stable, champs documentés, pas de vendor lock-in sur le format.
Éphémère par défaut, persistant sur opt-in
Fermez la fenêtre, la VM est détruite. Jetons, cookies, cache, téléchargements et tout malware qui a atterri pendant la session s'en vont avec. Les profils qui ont besoin d'état — un ensemble de favoris, une session sauvée, un SaaS connecté — optent pour un disque persistant chiffré LUKS, scellé sur le Keychain de macOS. La clé ne quitte jamais l'appareil de l'utilisateur.
Questions fréquentes
Un conteneur ou un runner CI frais ne fait-il pas déjà ça ?
+
Les conteneurs partagent le noyau de l'hôte et sont régulièrement compromis ; les runners CI détiennent souvent les identifiants de déploiement mêmes qu'un attaquant convoite. Bromure utilise des VM isolées matériellement avec leur propre noyau et garde les vrais secrets entièrement hors de la VM derrière un proxy — si bien que même une évasion au niveau du noyau ne trouve rien à voler.
Comment l'agent pousse-t-il du code ou installe-t-il des paquets privés sans secrets ?
+
À travers le proxy d'identifiants. Il s'authentifie auprès de votre hôte Git et de vos registres privés au nom de la VM, en injectant un accès cadré et de courte durée au niveau réseau. L'agent obtient un Git et un npm fonctionnels ; il n'obtient jamais un identifiant qu'il pourrait exfiltrer.
Qu'est-ce qui empêche une injection de prompt dans un README d'escalader ?
+
Deux couches. D'abord, la détection en local de Bromure analyse le contenu que l'agent lit — READMEs, commentaires, pages récupérées, sortie d'outils — et les fichiers de règles de type CLAUDE.md auxquels il fait confiance, et signale ou bloque les instructions injectées avant que le modèle n'agisse. Et même si l'une passe entre les mailles, elle s'exécute à l'intérieur de la VM — pas de vrais identifiants, sortie réseau sur liste d'autorisation, aucune portée vers l'hôte — si bien que le pire des cas, c'est du calcul gaspillé dans un bac à sable sur le point d'être supprimé, le tout journalisé.
Pouvons-nous quand même récupérer les artefacts de build que nous voulions ?
+
Oui. Les sorties légitimes sont promues hors de la VM par le même chemin contrôlé que n'importe quel téléchargement — optionnellement sous contrôle VirusTotal — pour que vous gardiez le résultat sans garder le risque.
Exécutez le repo non fiable. Gardez vos clés.
Donnez aux agents un environnement de build où le code hostile ne trouve rien et ne laisse rien derrière lui.