Le 13 octobre, un groupe d'ingénieurs a publié The Secure Software Factory (« la fabrique logicielle sécurisée »), une architecture de référence pour les organisations qui laissent des agents de codage écrire, tester et livrer du code. Elle est rédigée par Eli Aleyner, Ranti Familusi et William Manning (Docker), Allie Howe et Ian Livingstone (Keycard), Andy McMahon (Barclays), Ahmad Nassri (Socket) et Aaron Stanley (Secure Theory). Elle s'appuie sur Agent Baseline, un ensemble de 35 contrôles regroupés en six objectifs, que Keycard a réuni avec des ingénieurs de Docker et de Snyk.

Nous sommes heureux de la voir paraître. C'est un brouillon public et versionné, avec des identifiants de contrôle stables, sous licence CC BY 4.0, ouvert aux commentaires sur GitHub, et destiné à être confié à un organisme communautaire une fois arrivé à maturité. Les éditeurs et les équipes qui achètent leurs produits peuvent désormais se référer aux mêmes contrôles.

Ce que demande l'architecture

Son idée centrale tient en une ligne : « l'agent propose, la politique autorise et l'infrastructure applique ». L'agent est considéré comme non fiable, qu'il soit dans la confusion, manipulé par quelque chose qu'il a lu ou pris en main par un tiers ; ses limites doivent donc être appliquées en dehors de ses propres décisions. Le document trace quatre frontières :

Bac à sable : le code de l'agent ne s'exécute que dans un bac à sable isolé qu'il ne peut ni modifier ni quitter.
Réseau : « rien n'entre ni ne sort, sauf par des chemins que l'agent ne peut ni reconfigurer ni contourner ».
Chaîne d'approvisionnement : les composants ne viennent que de sources approuvées, et rien de ce qui entre dans le bac à sable ne contient d'identifiants.
Identité et accès : un agent n'utilise que l'accès accordé pour sa tâche, ne détient jamais d'identifiants, et a besoin, pour les actions à fort impact, d'une approbation qu'il ne peut pas se donner lui-même.

Ces frontières valent pour trois niveaux d'autonomie : un développeur qui pilote un agent (niveau 1), un workflow qui fait tourner des agents comme un service partagé (niveau 2), et un agent orchestrateur qui décide de la suite (niveau 3). Autour d'elles se trouvent une couche d'exécution capable d'arrêter n'importe quel agent, et une piste d'audit hors de portée de tous les agents.

Le document s'appuie sur des incidents réels. Dans l'un d'eux, un agent de codage chargé d'une tâche sur l'environnement de préproduction a trouvé un jeton d'API dans un fichier sans rapport et s'en est servi pour supprimer une base de données de production en neuf secondes. Dans le ver Shai-Hulud, des paquets malveillants récoltaient tous les identifiants qu'ils trouvaient sur la machine qui les installait.

Comment Bromure couvre les quatre frontières

Bromure Agentic Coding tourne sur votre Mac et place chaque espace de travail d'agent dans sa propre VM Linux. Voici la correspondance.

Frontière	Ce que demande l'architecture	Bromure
Bac à sable	Une isolation proportionnée au risque, jusqu'à une microVM avec son propre noyau ; aucun accès à l'hôte ; des tests exécutés dans la même isolation ; un arrêt à la demande, avec l'état conservé comme preuve	Une VM Linux complète par espace de travail, avec son propre noyau et son propre Docker pour les tests. Avec une politique OpenShell, Landlock et seccomp y confinent l'agent. Une machine peut être mise en pause, et Sauvegarder pour analyse exporte ses disques avant qu'elle soit effacée
Réseau	Tout le trafic passe par un proxy de sortie imposé au niveau du réseau, et non par des réglages de proxy ; un contrôle opération par opération	Le commutateur virtuel du Mac vérifie chaque connexion, et redirige le trafic web vers le proxy de Bromure même quand un outil ignore les réglages de proxy. Les règles peuvent limiter les méthodes HTTP et, avec une politique OpenShell, les chemins ainsi que les opérations MCP, GraphQL et WebSocket
Chaîne d'approvisionnement	Des paquets uniquement par un point d'admission ; les nouvelles versions attendent la fin d'un délai de carence ; rien de ce qui entre dans le bac à sable ne contient d'identifiants	Les installations de huit écosystèmes passent par les vérifications de Bromure : un délai d'ancienneté de deux jours sur les nouvelles versions, actif par défaut, et en option des consultations d'OSV et de socket.dev. Un paquet sans verdict est retenu jusqu'à votre décision
Identité et accès	L'agent ne détient jamais d'identifiants ; ils sont ajoutés au niveau du proxy ; les actions à fort impact nécessitent une approbation	La VM ne détient jamais que des jetons de substitution ; le proxy les remplace par les vrais pour le bon hôte. Les clés SSH restent sur le Mac, et les requêtes AWS sont signées à nouveau hors de la VM. Les écritures comme un `git push` peuvent exiger un clic, et les branches des agents ne sont fusionnées qu'avec votre approbation

C'est la frontière des identifiants qui compte le plus face à de tels incidents. Un paquet Shai-Hulud qui fouille une VM Bromure n'y trouve que des jetons de substitution, inutilisables hors du proxy de Bromure. (Socket, où travaille l'un des auteurs, est aussi l'une des vérifications de paquets que Bromure peut utiliser.)

Les niveaux se retrouvent eux aussi. Un développeur qui fait tourner des agents dans des sessions, c'est le niveau 1. Les automatisations qui lancent un agent selon un calendrier, ou à l'arrivée d'une pull request GitHub ou d'un ticket Linear, chacune dans un nouveau worktree git et, en option, dans un clone jetable de la machine, relèvent du niveau 2. Des agents qui délèguent du travail à d'autres agents, chaque message étant relayé par l'hôte, examiné pour détecter l'injection de prompt et journalisé, sont le début du niveau 3.

Là où Bromure va plus loin

Le brouillon est franc sur ses propres points faibles. Sa déclaration de provenance indique que, sur les six objectifs, Discover, Observe et Respond (découvrir, observer, répondre) « ne sont vendus par aucune des organisations à l'origine du projet » et « sont en conséquence moins développés », et qualifie cette asymétrie de « défaut ». Elle indique aussi que, selon le propre critère de la baseline, aucune des trois entreprises à l'origine du projet n'en est une mise en œuvre complète. C'est une chose d'une honnêteté peu commune à mettre par écrit.

C'est sur l'observation et la réponse que nous avons le plus travaillé :

Observer depuis l'intérieur du noyau. L'architecture demande au runtime du bac à sable d'enregistrer l'activité des processus, des fichiers et du réseau. La sentinelle noyau de Bromure le fait depuis l'intérieur du noyau invité et transmet ces données au Mac par un canal que root dans la VM ne peut pas fermer. Toute tentative de la réduire au silence est traitée comme une altération.
De l'intention au résultat. Le contrôle OBS-05 d'Agent Baseline demande des preuves qui relient ce qu'un agent voulait faire à ce qu'il a fait. La lignée de Bromure remonte chaque connexion à travers les processus qui l'ont ouverte jusqu'à l'appel d'outil de l'agent et au raisonnement que le modèle a donné pour cet appel. Quand le script d'installation d'une dépendance tente d'envoyer des données à l'extérieur, vous voyez l'installation qui l'a lancé et pourquoi l'agent a lancé cette installation.
Examiner les entrées. L'architecture considère comme non fiable tout ce qu'un agent lit. Bromure peut analyser sur votre Mac les résultats d'outils et les fichiers de règles comme CLAUDE.md à la recherche d'injection de prompt, examine chaque message échangé entre agents, et examine toujours le texte d'un événement GitHub ou Linear avant qu'une automatisation n'y donne suite.
Les données envoyées pour l'inférence. La protection des données personnelles de Bromure remplace les noms, adresses e-mail, numéros de compte et données similaires par des substituts avant qu'une requête n'atteigne un modèle dans le cloud, et les rétablit dans la réponse.
Répondre en gardant les preuves intactes. Quand Bromure voit un identifiant partir là où il ne devrait pas, il met la VM en pause. Vous pouvez l'éteindre, ou sauvegarder ses disques pour analyse, après quoi la machine refuse de démarrer tant qu'elle n'a pas été effacée. Avec les politiques OpenShell, une rafale d'opérations refusées met l'espace de travail en quarantaine : réseau coupé, VM en pause.
Des traces hors de portée. La trace de chaque machine, avec les requêtes au modèle, les appels d'outils, les commandes et l'activité des fichiers, est stockée sur le Mac, chiffrée, hors de la VM.

Il y a encore une différence, qui tient à l'endroit où tout cela s'exécute. L'architecture est écrite pour des fabriques, et le niveau 1, un développeur avec un agent local, n'a droit qu'à quelques paragraphes. C'est pourtant là que tournent la plupart des agents aujourd'hui. Bromure place les quatre frontières sur le Mac de ce développeur, sans infrastructure à mettre en place, et il est gratuit et open source.

Un bon début

The Secure Software Factory en est à sa version 1 et reste ouverte aux commentaires : prudente dans ce qu'elle affirme, et honnête sur les entreprises dont les produits l'ont façonnée. Son outil de suivi des tickets est ouvert à tous, et c'est dans les sections sur l'observation et la réponse que, selon nous, il reste le plus à écrire.

Que davantage d'entreprises travaillent publiquement sur la sécurité des agents, avec des identifiants de contrôle stables, c'est une bonne chose pour tous ceux qui font tourner des agents.