Laissez l'agent entrer en production. Approuvez avant qu'il ne mute.
Déboguer un incident en direct ou exécuter une migration suppose de donner à un agent un vrai accès à la production — et un vrai accès à la production est précisément ce que vous ne pouvez pas confier à une boucle autonome. Bromure laisse l'agent lire librement, puis s'arrête à la porte de chaque action mutante et vous demande d'abord.
Le problème
L'accès en lecture, ça va. Ce sont les écritures qui brisent les carrières.
Un agent qui peut interroger la production est un super-pouvoir de débogage. Un agent qui peut `DROP TABLE`, `terraform apply`, supprimer un bucket ou pousser un correctif à chaud est à une hallucination confiante d'une panne. La même boucle qui lit les logs pour trouver le bug va, sans qu'on le lui demande, le « corriger » sur le système en direct.
Alors les équipes font ce qui est prudent et tiennent les agents entièrement hors de la production — et perdent le seul endroit où les agents sont le plus utiles : l'incident en direct, le bug lié aux données, la migration qui ne échoue que sur des données réelles. Le choix proposé : une autonomie en laquelle vous ne pouvez pas avoir confiance, ou un accès que vous n'accorderez pas.
La réponse de Bromure
Les lectures passent. Les mutations s'arrêtent et attendent un humain.
Bromure exécute l'agent dans une VM qui n'atteint la production qu'à travers un proxy d'identifiants — et le proxy connaît la différence entre une lecture et une écriture. Requêtes, gets et describes passent directement. Tout ce qui mute l'état — une écriture, une suppression, une instruction DDL, un déploiement, un appel d'API destructeur — se met en pause et fait apparaître une demande d'autorisation affichant l'opération exacte, pour que l'ingénieur l'approuve ou la refuse avant qu'elle ne s'exécute.
L'agent garde son élan sur tout ce qui est sûr et ne bloque que là où ça compte. Vous voyez précisément ce qu'il s'apprête à faire — le SQL, l'appel d'API, la ressource — et rien ne touche la production tant que vous ne dites pas oui. Refusez, et l'agent reçoit le rejet et s'adapte, comme pour n'importe quelle autre erreur d'outil.
Comment ça marche
Lecture en transparence, écriture sous contrôle
Le proxy classe chaque opération. Les appels en lecture seule passent sans friction ; les appels mutants s'arrêtent pour une approbation humaine explicite. La vitesse de l'agent là où c'est sûr, un arrêt net là où ça ne l'est pas.
Voyez exactement ce qu'il va faire
Chaque demande affiche l'opération littérale — l'instruction SQL, le verbe et la cible de l'API, la ressource modifiée — avant qu'elle ne s'exécute. Pas de « tout autoriser » à l'aveugle.
Les identifiants n'atteignent jamais l'agent
L'accès à la production est injecté par le proxy au niveau réseau. L'agent opère contre la prod sans jamais détenir un identifiant qu'il pourrait laisser fuiter ou détourner.
Chaque décision enregistrée
Approbations, refus et les opérations qui les sous-tendent sont journalisés par session et par ingénieur — un relevé complet de ce que l'agent a fait à la production et de qui l'a autorisé.
En pratique
Un agent sur un incident en direct, sans la sueur froide
Il est 2 h du matin et un service renvoie des erreurs sur un sous-ensemble de lignes. Un ingénieur pointe son agent sur le réplica de production à travers Bromure. L'agent interroge les données en direct, les corrèle avec les déploiements récents et restreint le bug à une colonne malformée écrite par une migration il y a trois heures — le tout en lecture seule, le tout fluide sans interruption.
L'agent propose le correctif : un `UPDATE` sur les lignes affectées. Comme cela mute la production, Bromure se met en pause. Une demande d'autorisation montre à l'ingénieur l'instruction exacte — table, prédicat, nombre de lignes estimé — et attend. L'ingénieur la lit, resserre la clause `WHERE` et approuve. C'est seulement alors que l'écriture atteint la base de données.
L'incident se clôt en vingt minutes au lieu de deux heures. Le relevé de session montre chaque requête exécutée par l'agent, l'unique mutation qu'il a proposée, la modification de l'ingénieur et l'approbation — si bien que le post-mortem s'écrit tout seul, et personne n'a à se demander si l'agent a discrètement fait autre chose.
La politique comme config
Définissez ce qui est sous contrôle dans un seul bloc de politique
La classification lecture/écriture du proxy est déclarative. Passez une politique par profil et l'agent en hérite à chaque session. Voici la forme pour les backends que les équipes mettent le plus sous contrôle.
MongoDB / ClickHouse
Les lectures — finds, agrégations, SELECTs — passent ; insertions, mises à jour, suppressions et DDL sont sous contrôle par défaut. Optionnellement, réservez une base scratch que l'agent peut muter librement.
Les appels describe / list / get passent ; tout ce qui crée, modifie ou supprime une ressource — une ressource cloud ou un objet Kubernetes — demande une approbation avec la requête complète affichée.
GET et HEAD passent ; POST, PUT, PATCH et DELETE vers les hôtes de production sont sous contrôle. Cadrez par hôte pour que la staging reste sans friction.
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
Comment Bromure sait-il qu'un appel est une mutation ?
+
Le proxy d'identifiants comprend les protocoles qu'il arbitre — SQL, API cloud, verbes HTTP, Git. Il classe les opérations par effet : SELECT et GET passent ; INSERT/UPDATE/DELETE/DDL, API d'écriture et appels destructeurs sont sous contrôle. Ajustez la politique par profil — mettez tout sous contrôle, ou autorisez les écritures vers un schéma scratch tout en contrôlant le reste.
La demande d'autorisation ralentit-elle chaque action ?
+
Seules les mutations déclenchent une demande. La grande majorité de ce qu'un agent fait contre la production pendant un débogage est en lecture seule, et cela passe à pleine vitesse. L'humain est dans la boucle précisément et uniquement là où l'état change.
Que voit l'agent quand je refuse ?
+
Un rejet d'outil normal. L'agent le traite comme n'importe quel appel échoué — il peut expliquer, proposer une alternative ou demander conseil — sans que la mutation n'ait jamais eu lieu.
Puis-je approuver un lot d'opérations en une fois ?
+
Oui. Les approbations peuvent être accordées par opération ou cadrées — approuvez une classe d'opération pour le reste de la session, ou pré-autorisez une migration spécifique — chaque autorisation étant enregistrée. Le défaut est strict ; vous le relâchez délibérément.
N'est-ce pas juste un `--dry-run` sophistiqué ?
+
Non. Un dry-run montre ce qui se passerait et exige quand même une vraie ré-exécution à l'aveugle. Bromure met sous contrôle le vrai appel lui-même : l'agent est en cours d'exécution, vous voyez l'opération exacte, et votre approbation est ce qui lui permet de continuer — ou non. Rien ne s'exécute deux fois, et rien ne s'exécute sans approbation.
Donnez la production à l'agent. Gardez la main sur l'interrupteur.
Un accès en lecture transparente et en écriture sous contrôle qui laisse les agents travailler sur des systèmes en direct sans jamais les muter dans votre dos.