Garde-fous

Les garde-fous constituent le contrôle côté hôte de Bromure Agentic Coding sur la manière dont les identifiants d'un espace de travail peuvent être utilisés. Comme le volet lui-même l'indique : les garde-fous régissent la façon dont les identifiants configurés de cet espace de travail sont utilisés. Demander avant utilisation affiche une confirmation côté hôte la première fois qu'un identifiant est utilisé dans une session. Une politique d'écriture supprime ou bloque les opérations destructrices sur le fil — appliquée dans le proxy, de sorte qu'un agent compromis dans la VM ne puisse pas la contourner. Seuls les identifiants que vous avez configurés apparaissent ici.

Le volet affiche une ligne par identifiant configuré, dans le même ordre que celui du volet Identifiants. Chaque ligne indique le titre de l'identifiant et son ou ses hôtes, et comporte deux contrôles :

• Une case à cocher Demander avant utilisation (intitulée Exiger une approbation pour l'utilisation sur le contrôle lui-même) — le verrou de consentement par identifiant, déplacé ici depuis le volet Identifiants.
• Un sélecteur de politique d'écriture en ligne, affiché uniquement lorsque le service de l'identifiant en prend un en charge.

Si l'espace de travail n'a aucun identifiant, le volet affiche un état vide — Aucun identifiant à protéger — qui vous renvoie au volet Identifiants. Les détails d'application, les formats d'erreur et les journaux d'audit sont traités dans l'analyse approfondie de l'injection de prompt et des garde-fous.

Demander avant utilisation

Chaque ligne comporte une case à cocher Demander avant utilisation, désactivée par défaut. Lorsqu'elle est activée, la première fois que cet identifiant est utilisé dans une session, le proxy se met en pause et affiche une boîte de dialogue de consentement proposant des autorisations à durée limitée — 5 minutes, 1 heure, ou le reste de la session — ou Ne pas autoriser. Les autorisations sont conservées uniquement en mémoire et effacées à la fermeture de la fenêtre de session, et chaque décision active est répertoriée dans Fenêtre → Approbations d'identifiants…. Le modèle de consentement, la fusion des invites concurrentes et la fenêtre d'approbations sont traités dans Identifiants et la frontière du fil.

Cette case à cocher s'applique à n'importe quel identifiant, y compris les clés API simples, les clés SSH et les jetons manuels — les lignes sans politique d'écriture n'affichent que ce contrôle.

Politique d'écriture

Lorsque le service d'un identifiant peut classer son propre trafic, la ligne affiche également un sélecteur de politique d'écriture. Il apparaît pour :

• Les forges Git — jetons GitHub, GitLab, Bitbucket.
• Les identifiants AWS.
• Les jetons DigitalOcean.
• Les registres de conteneurs (Docker Hub, ghcr.io, et autres).
• Les contextes Kubernetes.
• Les points de terminaison de bases de données (MongoDB, ClickHouse, Elasticsearch).

Chaque politique d'écriture propose les quatre mêmes modes :

Les nouveaux espaces de travail utilisent par défaut Demander avant écriture sur chaque service prenant en charge une politique (via le modèle de préférences). Les espaces de travail créés avant l'existence des garde-fous — ou les profils dont le JSON omet le champ — sont décodés comme Désactivé.

Remarque : La politique d'écriture est par service, non par identifiant. Deux identifiants pour le même service — par exemple deux jetons GitHub — partagent une seule politique, de sorte que modifier le sélecteur sur l'une des lignes le modifie pour les deux.

Remarque : Les garde-fous classent les opérations ; ils ne masquent pas les identifiants. L'identifiant lui-même est toujours injecté et échangé par le proxy tel que configuré sous Identifiants. Combinez une politique d'écriture Lecture seule avec la case à cocher Demander avant utilisation de la même ligne pour une défense en profondeur.

Comment chaque service classe les appels

Les points de terminaison de bases de données se classent selon le moteur :

Un avertissement orange en ligne apparaît lorsqu'une politique est définie mais qu'elle n'a rien sur quoi s'appliquer — pas de kubeconfigs pour un contexte Kubernetes, pas d'hôte défini pour un point de terminaison de base de données — puisque le garde-fou n'a alors aucun hôte auquel s'appliquer.

Remarque : Pour ClickHouse, si aucun texte SQL n'est visible dans la requête, Lecture seule bloque la requête (Bromure ne peut pas prouver qu'il s'agit d'une lecture) tandis que Bloquer les opérations destructrices la laisse passer (elle échoue en mode ouvert).

La boîte de dialogue de consentement (Demander avant écriture)

En mode Demander avant écriture, les lectures passent silencieusement et chaque écriture s'interrompt pour une boîte de dialogue hôte intitulée Allow write on "<scope>" from workspace "<name>"?. Le corps de la boîte de dialogue affiche l'opération exacte telle quelle — l'instruction SQL littérale pour une base de données, ou METHOD /path pour un appel REST — afin que vous approuviez ce qui va réellement s'exécuter, et non un résumé. Les boutons sont :

• Autoriser pendant 15 minutes (le bouton par défaut)
• Autoriser une fois — ne crée délibérément aucune autorisation, de sorte que l'écriture suivante redemande. Utile pour auditer un agent bavard écriture par écriture.
• Autoriser pour le reste de la session
• Ne pas autoriser — l'agent reçoit la même erreur bloquante que celle produite par les modes de blocage. Le refus est mémorisé pendant 60 secondes afin qu'un agent réessayant la même écriture en boucle ne redemande pas chaque seconde.

Les autorisations sont limitées par espace de travail et par portée de protocole : un hôte d'API Kubernetes, AWS dans son ensemble, un registre de conteneurs, chaque forge git dans son ensemble, ou un hôte de base de données. Autoriser les écritures ClickHouse sur un hôte n'accorde rien ailleurs. Les écritures identiques concurrentes fusionnent en une seule boîte de dialogue, et toutes les décisions sont conservées uniquement en mémoire — les autorisations limitées à la session sont effacées au démontage de la session.

Lorsque l'espace de travail est piloté sans interface via SSH ou la CLI, les quatre mêmes choix sont proposés sous forme d'invite textuelle à l'intérieur du tmux de l'espace de travail ; l'absence de réponse équivaut à un refus.

Remarque : Les autorisations d'écriture des garde-fous ne sont répertoriées dans aucune fenêtre. La fenêtre Approbations d'identifiants (menu Fenêtre → Approbations d'identifiants…) affiche uniquement les décisions de consentement d'identifiants — les autorisations Demander avant utilisation ; une autorisation de politique d'écriture expire selon son propre chronomètre ou au démontage de la session.

Le pare-feu de sortie

Sous les lignes d'identifiants, le volet héberge le pare-feu Connexions sortantes de l'espace de travail : une table de règles ordonnée qui régit quelles connexions la VM est autorisée à ouvrir tout court — n'importe quel protocole, n'importe quelle destination, et pas seulement les services que les garde-fous classent. Les règles sont évaluées de haut en bas, la première correspondance l'emporte, et un contrôle segmenté Trafic non apparié choisit la valeur par défaut pour tout ce qu'aucune règle ne fait correspondre : Autoriser (la valeur par défaut des nouveaux espaces de travail) ou Refuser pour une posture verrouillée, en liste d'autorisation.

Chaque règle comporte cinq parties :

Une zone dépliable en bas affiche le même jeu de règles dans son format pf canonique — une règle par ligne, se terminant par default allow ou default deny — qui est la manière dont les règles sont stockées et ce que transportent la CLI et les profils gérés :

allow tcp api.github.com:443
allow web api.example.com GET,POST     # seuls ces verbes atteignent le site
deny  web api.internal PUT,DELETE      # bloquer ces verbes, autoriser le reste
deny  udp any:53
deny  any 10.0.0.0/8
default deny

L'application est côté hôte et se fait en couches, de sorte qu'un agent compromis ne peut pas la contourner : le commutateur du réseau virtuel applique les règles à chaque flux d'après l'IP de destination et le nom d'hôte capté par écoute DNS (tous protocoles confondus, y compris TCP et UDP en clair), et le proxy MITM les applique de nouveau d'après le nom de serveur TLS et — pour les règles web — d'après la méthode HTTP individuelle. C'est cette dimension « méthode » qui permet à un espace de travail de lire une API dans laquelle il n'est pas autorisé à écrire : allow web api.example.com GET,POST donne à l'agent des requêtes sans mutations, sur le fil, quel que soit l'outil qui émet la requête à l'intérieur de la VM.

Les modifications de règles s'appliquent immédiatement aux sessions en cours — enregistrer l'espace de travail rafraîchit la politique active sans redémarrage, y compris pour les sessions sans interface. Chaque verdict est consigné sous forme de ligne Pare-feu dans la fenêtre Chronologie de sécurité, et, sur les installations inscrites, comme événement egress.firewall dans le flux de l'organisation.

Remarque : L'inférence locale est exemptée par construction : une règle allow pour le point de terminaison d'inférence sur l'hôte (bromure.llm) est ajoutée en tête, avant vos règles, de sorte que même default deny ne peut pas couper les agents des Modèles locaux. Ce trafic ne quitte jamais votre Mac.

Interception transparente

Le pare-feu ne serait qu'indicatif si la VM pouvait simplement ignorer le proxy ; elle ne le peut plus : le commutateur virtuel détourne de façon transparente les flux des ports 80 et 443 de la VM vers le proxy de l'hôte — aucune variable d'environnement nécessaire, rien que l'invité puisse désactiver. Le HTTP en clair sur le port 80 est intercepté et inspecté de la même manière que le HTTPS. C'est activé par défaut pour chaque espace de travail.

La porte de sortie est le commutateur Désactiver l'interception transparente situé sous la table de règles. L'activer empêche le commutateur de détourner les ports 80 et 443, de sorte que les garde-fous et les règles web du pare-feu ne voient plus que le trafic qui utilise volontairement les variables d'environnement de proxy — ne l'utilisez que pour un espace de travail qui se casse véritablement sous interception (par exemple un épinglage de certificat marqué que la liste de contournement intégrée ne couvre pas), et considérez le pare-feu comme purement indicatif tant qu'il est activé.

Ce que voit l'agent lorsqu'un appel est bloqué

Les appels bloqués renvoient un corps d'erreur de style 403 adapté au protocole — un JSON Kubernetes Status, un AccessDeniedException AWS, une charge utile DENIED de registre — dont le message se termine par « blocked by Bromure Guardrails ». L'agent voit un échec d'API ordinaire et propre qu'il peut signaler, plutôt qu'une connexion suspendue. (Les blocages de chaîne d'approvisionnement utilisent plutôt un HTTP 451, précisément pour que les deux se distinguent d'un coup d'œil — voir Chaîne d'approvisionnement.)

Limitations

• Le push forcé Git ne peut pas être distingué d'un push normal sur le fil, de sorte que Bloquer les opérations destructrices ne le bloque pas — seuls Lecture seule et Demander avant écriture contrôlent les pushs. Les suppressions explicites via les API REST de la forge sont tout de même détectées.
• Les politiques Kubernetes et de registre de conteneurs ne s'appliquent qu'aux hôtes dérivés des kubeconfigs de l'espace de travail et des registres configurés ; les politiques de base de données ont besoin que l'hôte du point de terminaison soit défini sous Identifiants. Un garde-fou n'ayant rien sur quoi s'appliquer ne filtre rien (le volet vous avertit en ligne).
• Les politiques d'écriture couvrent les services répertoriés ci-dessus ; le trafic vers d'autres hôtes est régi par les règles d'hôte, de port et de méthode du pare-feu de sortie plutôt que par une classification sémantique. Pour les téléchargements de paquets, voir Chaîne d'approvisionnement, et pour le trafic IA de l'agent, voir Injection de prompt.