Quand un agent IA écrit du code, exécute des commandes et touche à vos repos, « c'est l'IA qui l'a fait » n'est pas une réponse que votre auditeur acceptera. Bromure fait de chaque session un enregistrement structuré et attribuable : qui a exécuté quel agent, contre quoi, et exactement ce qu'il a touché.
Le problème
Du code écrit par l'IA sans chaîne de traçabilité
Une part croissante de votre code est désormais ébauchée par des agents — et la trace est mince. Quel ingénieur a lancé la session ? Quel modèle ? Quels fichiers l'agent a-t-il lus, modifiés ou supprimés ? Quelles commandes a-t-il exécutées, et contre quels systèmes ? Pour la plupart des équipes, la réponse honnête est un haussement d'épaules, et un haussement d'épaules ne survit pas à un audit SOC 2, à un incident de sécurité ou à la question d'un régulateur.
L'agent opère sur le portable de l'ingénieur, sous le compte de l'ingénieur, avec l'accès de l'ingénieur. De l'extérieur, le commit d'un agent est indiscernable de celui d'un humain — jusqu'à ce que quelque chose tourne mal et que vous deviez reconstituer exactement ce qui s'est passé, et qu'il n'y ait rien pour le reconstituer.
La réponse de Bromure
Chaque session est un enregistrement inviolable
Parce que l'agent s'exécute dans une VM Bromure, chaque action est capturée à la frontière : les fichiers qu'il a créés, modifiés et supprimés avec les diffs ; chaque commande shell qu'il a exécutée ; chaque outil qu'il a appelé ; chaque endpoint qu'il a atteint — le tout rattaché à l'identité de l'ingénieur et au modèle utilisé, conservé de manière centralisée.
Le dialogue complet est archivé aussi — prompts, réponses du modèle, appels d'outils, la transcription intégrale — conservé dans le cloud et examinable par la sécurité, échantillonnable par la direction de l'ingénierie, et exportable vers la même archive que vous alimentez déjà pour la rétention des e-mails et des chats. Le travail assisté par IA devient aussi auditable que tout ce que fait votre organisation.
Comment ça marche
Chaque fichier touché par l'agent
Par session, par repo, par ingénieur — l'ensemble exact des fichiers créés, modifiés ou supprimés, avec les diffs, rattachés à qui a lancé la session et au modèle utilisé.
Chaque commande et chaque appel
Chaque commande shell exécutée par l'agent dans la VM, chaque fichier qu'il a lu, chaque outil qu'il a invoqué, chaque API qu'il a interrogée — capturé en direct pendant la session.
La transcription complète, archivée
Prompts, réponses et appels d'outils conservés de manière centralisée, requêtables par équipe, repo ou modèle, et exportables vers votre archive de rétention existante.
Lié à l'identité et inviolable
Chaque enregistrement porte l'identité SSO et l'appareil de l'ingénieur, écrit dans un flux en append-only que votre SIEM peut ingérer comme il ingère l'activité humaine.
Tentatives d'injection, signalées
Quand le contenu qu'un agent a lu — un fichier, une page récupérée, la sortie d'un outil — ou un CLAUDE.md auquel il faisait confiance contenait des instructions injectées, la détection en local de Bromure l'enregistre : la source, l'extrait, et si la requête a été journalisée, signalée ou bloquée.
En pratique
Reconstituer une session, des mois plus tard
Une revue de sécurité pose une question simple : un agent a-t-il jamais touché au module de paiements, et si oui, qu'a-t-il fait ? Sans Bromure, c'est une question sans réponse répartie sur des dizaines de portables. Avec lui, c'est une requête.
Chaque session d'agent s'est exécutée dans une VM Bromure qui a diffusé son activité vers le serveur d'entreprise : l'identité de l'ingénieur, le modèle, chaque lecture et écriture de fichier avec les diffs, chaque commande, chaque destination réseau, et la transcription complète prompt/réponse. Le relecteur filtre sur le repo de paiements et obtient chaque session qui y a touché — trois d'entre elles, deux ingénieurs, avec les changements exacts et les conversations qui les ont produits.
Ils échantillonnent les transcriptions, confirment que les changements ont été relus et fusionnés via le processus normal, et joignent l'export au dossier d'audit. Ce qui aurait été une course forensique de plusieurs jours est une requête de dix minutes — et parce que l'enregistrement est inviolable, il tient comme preuve plutôt que comme souvenir.
Streamez-la vers votre SIEM
La piste n'a pas à vivre dans Bromure
Pointez Bromure vers votre propre SIEM ou collecteur OpenTelemetry et tout l'enregistrement vous y suit. L'activité des agents, les sessions de navigation et la piste d'audit admin sont transmises sous forme de logs OTLP/HTTP — chaque événement un LogRecord avec des attributs sémantiques OTel et une sévérité que vos alertes comprennent déjà. Bromure émet depuis ses propres événements stockés via un curseur continu, de sorte qu'une brève coupure de votre endpoint ne perd rien.
Pointez-le vers votre collecteur
Donnez à Bromure l'endpoint logs OTLP/HTTP et, si votre collecteur en a besoin, un en-tête d'authentification — un token bearer, une clé Datadog, ce qu'il attend. La valeur est stockée chiffrée par enveloppe et n'est jamais réaffichée. Choisissez lesquels des trois flux transmettre.
Chaque action d'agent est mappée vers un LogRecord portant l'identité SSO de l'ingénieur, le modèle, le dépôt et l'action — avec une sévérité sur laquelle votre SIEM peut alerter. Une tentative d'injection de prompt bloquée arrive en WARN que votre pipeline de détection achemine déjà.
Bromure transmet depuis ses propres événements stockés avec un curseur par flux, pas depuis le chemin d'ingestion en direct. Si votre collecteur tombe, rien n'est perdu dans la période de rétention — la livraison reprend à la dernière position confirmée à son retour.
stream cursor last forward status
agentic_coding seq:184201 2s ago ok
web_sessions ts:17:42:08 2s ago ok
audit id:90412 2s ago ok
# endpoint outage → backoff + retry, cursor holds
# at-least-once · no loss within retention
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
En quoi est-ce différent de l'historique Git ?
+
Git montre le diff final commité. Bromure montre toute la session qui l'a produit — les fichiers que l'agent a lus mais pas modifiés, les commandes qu'il a exécutées, les impasses, les appels réseau et la conversation qui l'a piloté. Git vous dit ce qui a atterri ; Bromure vous dit comment, et quoi d'autre s'est passé en chemin.
L'enregistrement est-il inviolable ?
+
Oui. Les sessions sont diffusées vers un journal en append-only sur votre serveur d'entreprise au fil de leur exécution, portant l'identité SSO et le certificat d'appareil de l'ingénieur. Un ingénieur ne peut pas modifier discrètement ce que son agent a fait après coup.
Pouvons-nous alimenter cela dans nos outils SIEM et de rétention existants ?
+
Oui — nativement, via OpenTelemetry. Pointez Bromure vers l'endpoint logs OTLP/HTTP de votre SIEM ou collecteur OpenTelemetry, et l'activité des agents, les sessions de navigation et la piste d'audit y affluent sous forme de LogRecords OTLP avec des attributs sémantiques OTel. Les transcriptions s'exportent séparément vers la même archive que vous utilisez déjà pour la rétention des e-mails et des chats.
Capturer tout cela ralentit-il les ingénieurs ?
+
Non. La capture se fait à la frontière de la VM, hors du chemin de l'ingénieur. Ils exécutent Claude Code ou Codex exactement comme avant ; l'enregistrement s'accumule automatiquement.
« C'est l'IA qui l'a fait » n'est pas une piste d'audit.
Faites de chaque session d'agent un enregistrement attribuable et inviolable que vos auditeurs accepteront.