Garde-fous

Les garde-fous contrôlent comment les identifiants d'une machine peuvent être utilisés (une machine est un espace de travail, dans l'éditeur de réglages), comment la machine réagit quand un agent se heurte à un mur ou se comporte bizarrement, et avec quelle rigueur son trafic est intercepté. Les connexions que sa VM peut ouvrir se règlent dans Politique du bac à sable. Dans les mots du volet : « Les garde-fous régissent la façon dont les identifiants configurés de cet espace de travail sont utilisés. Demander avant usage fait surgir une confirmation côté hôte la première fois qu'un identifiant est utilisé dans une session. Une politique d'écriture dépouille ou bloque les opérations destructrices sur le fil — appliquée dans le proxy, si bien qu'un agent compromis ne peut pas la contourner. Seuls les identifiants que vous avez configurés apparaissent ici. »

Le volet a deux parties : une ligne par identifiant, puis Protections — les réglages communs aux deux moteurs de bac à sable. (Les règles de connexions sortantes qui se trouvaient ici sont passées dans Politique du bac à sable avec la 5.4.) Tout ce qu'il contient s'applique à une machine en cours d'exécution dès que vous cliquez Enregistrer — sans redémarrage. Les mécanismes en profondeur sont dans Détection d'injection de prompt et garde-fous.

Lignes d'identifiants

Le volet liste chaque identifiant configuré dans Identifiants, dans le même ordre. Chaque ligne montre le nom de l'identifiant et ses hôtes, une case Exiger une approbation pour utiliser, et — là où le service en accepte une — un sélecteur de politique d'écriture. Sans identifiants, le volet affiche Aucun identifiant à garder et vous renvoie au volet Identifiants.

Exiger une approbation pour utiliser (demander avant usage)

Désactivé par défaut. Activé, la première fois que l'identifiant est utilisé dans une session, le proxy met la requête en pause et demande, en proposant Autoriser pour 5 minutes, Autoriser pour 1 heure, Autoriser pour le reste de la session ou Ne pas autoriser. Les octrois vivent en mémoire et finissent avec la session ; Fenêtre › Approbations d'identifiants… liste ceux en cours. Voir Identifiants et la frontière du fil.

Tant qu'un identifiant a un octroi actif, sa ligne affiche le temps restant à côté de la case à cocher — un compte à rebours orange (4m, puis 45s) pour un octroi limité dans le temps, autorisé pour cette session pour un octroi valable jusqu'à la fin de la session, et un compte à rebours rouge refusé (ou refusé pour cette session) tant qu'un refus est en vigueur. Faites un clic droit sur la ligne pour Autoriser pour 5 minutes, Autoriser pour 1 heure ou Autoriser pour le reste de la session, pour Refuser pour 5 minutes, Refuser pour 1 heure ou Refuser pour le reste de la session (refusé sans demander), ou Révoquer — demander la prochaine fois pour effacer l'un ou l'autre afin que la prochaine utilisation redemande. Une autorisation ou un refus limité dans le temps part de maintenant, si bien qu'un octroi qui s'épuise repart pour 5 minutes neuves. Ces actions s'appliquent immédiatement à la session en cours ; il n'y a rien à enregistrer. (Le compte à rebours apparaît dans les réglages propres à l'espace de travail sur le Mac qui l'exécute, pas dans les Préférences ni sur un client distant.)

Note : une automatisation qui utilise un identifiant avec approbation activée ne peut pas tourner complètement sans surveillance : elle s'arrête au dialogue jusqu'à ce que vous répondiez sur le Mac. L'éditeur d'automatisations avertit de cela.

Politique d'écriture

Un sélecteur de politique d'écriture apparaît pour :

• les jetons de forge git (GitHub, GitLab, Bitbucket)
• les identifiants AWS
• les jetons DigitalOcean
• les registres de conteneurs
• les contextes Kubernetes
• les points d'accès de bases de données (MongoDB, ClickHouse, Elasticsearch)

Les nouvelles machines utilisent Demander avant écriture pour chaque service (repris du modèle Valeurs par défaut). Les machines créées avant l'existence des garde-fous se chargent en Désactivé.

Note : une politique d'écriture est par service, pas par identifiant, comme le note le volet : « deux identifiants pour le même service (p. ex. deux jetons GitHub) partagent une seule politique. » Changer l'une des lignes change les deux.

Comment chaque service est classé

Les points d'accès de bases de données sont classés par moteur :

Un avertissement orange apparaît quand une politique n'a rien à quoi s'appliquer — un contexte Kubernetes sans kubeconfig, un point d'accès de base de données sans hôte.

Note : pour ClickHouse, si aucun texte SQL n'est visible dans la requête, Lecture seule la bloque (impossible de prouver qu'il s'agit d'une lecture) tandis que Bloquer les destructions la laisse passer.

Le dialogue d'écriture

En Demander avant écriture, une écriture s'arrête pour Autoriser l'écriture sur « portée » depuis l'espace de travail « nom » ?, en montrant l'opération mot pour mot — l'instruction SQL, ou MÉTHODE /chemin. Les choix :

• Autoriser pour 15 minutes (défaut)
• Autoriser une fois — ne crée aucun octroi, si bien que l'écriture suivante redemande.
• Autoriser pour le reste de la session
• Ne pas autoriser — l'agent reçoit la même erreur que renvoient les modes bloquants. Le refus est retenu pendant 60 secondes, pour qu'une boucle de reprise ne redemande pas chaque seconde.

Les octrois sont par machine et par portée : un serveur d'API Kubernetes, AWS dans son ensemble, un registre, chaque forge, ou un hôte de base de données. Des écritures identiques et simultanées partagent un seul dialogue. Quand la machine est pilotée sans surveillance par SSH ou par la CLI, les mêmes choix sont posés dans le tmux de la machine ; pas de réponse signifie refus.

Ne pas alerter sur l'exfiltration d'identifiants

Quand un identifiant est vu partir vers un hôte auquel il n'appartient pas, Bromure bloque la requête, met la VM en pause, et affiche une alerte de compromission avec Éteindre, Bloquer, Autoriser et Enregistrer pour enquête. Autoriser fait confiance à cette destination pour le reste de la session. Voir Identifiants et la frontière du fil.

Ne pas alerter sur l'exfiltration d'identifiants désactive cette alerte pour cette machine. La fuite est toujours bloquée et toujours enregistrée dans la Chronologie de sécurité, comme « bloqué — tentative d'exfiltration (alertes désactivées, VM non mise en pause) » — seule l'interruption disparaît. S'applique à chaud, sans redémarrage. Défaut : désactivé.

Protections

La section Protections regroupe les réglages qui s'appliquent à une machine quel que soit le moteur de bac à sable qu'elle utilise. Chacun s'applique aussitôt à une machine en cours d'exécution.

Prévenir l'agent quand la politique le bloque

Tell the agent when policy blocks it — « l'agent vous demande au lieu de réessayer ou de chercher un détour ». Quand le pare-feu, la politique OpenShell, le bac à sable invité ou un garde-fou refuse quelque chose qu'un agent a tenté, l'agent apprend ce qui a été bloqué et pourquoi, et qu'il doit vous demander plutôt que réessayer ou trouver un autre chemin. Sans cela, un agent ne voit qu'une connexion échouée ou « permission denied » et peut continuer d'essayer. Claude Code lit la note juste après la commande qui a heurté le blocage. Codex, Grok, Kimi et Oh My Pi la reçoivent tapée à la fin de leur tour. Tant que vous n'avez pas choisi, le réglage est activé dès que la machine utilise une politique OpenShell. Voir Prévenir l'agent.

Chien de garde des agents

Agent watchdog — « signale une session au comportement suspect ; Quarantine coupe aussi son réseau et la met en pause ». Le chien de garde observe la session dans son ensemble, depuis l'extérieur de la VM :

• des rafales de requêtes bloquées ;
• des identifiants qui n'ont rien à faire là ;
• des signes d'altération ;
• de nouvelles destinations une fois la session stabilisée ;
• un volume sortant bien au-dessus de la base de référence de la session (compté au commutateur réseau, indépendamment du proxy).

Quand l'alerte ne peut pas s'afficher sur ce Mac (un Mac sans écran, ou une machine reflétée par un client distant), la question part vers le client distant, et une absence de réponse en trois minutes vaut Keep quarantined.

N'autoriser que les identifiants injectés par Bromure (mode strict)

Only allow credentials Bromure injects (strict mode) — « bloque tout identifiant que Bromure n'a pas mis là lui-même ». Avec le mode strict, une requête portant un identifiant que Bromure n'a pas injecté est bloquée et déclenche l'alerte de compromission ; cela couvre une clé que l'agent a trouvée dans un fichier, copiée d'un journal ou apportée. Autoriser dans l'alerte approuve cet identifiant pour la session. Les jetons qu'un site émet dans la VM (un cookie de session après une connexion, par exemple) peuvent toujours retourner vers ce site.

Le mode strict force l'interception transparente et ignore la liste de non-interception. Le trafic TCP brut ne peut pas être inspecté. Chaque identifiant que la machine configure a d'abord besoin d'un filtre d'hôte ; le volet nomme ceux qui n'en ont pas. Désactivé par défaut ; votre organisation peut l'imposer.

Désactiver l'interception transparente

Par défaut, le commutateur virtuel détourne les connexions HTTP et HTTPS de la VM (ports 80 et 443) vers le proxy de Bromure au niveau réseau, de sorte que le proxy les voit même quand un programme ignore les réglages de proxy.

Activer Désactiver l'interception transparente arrête seulement ce détournement forcé. Les programmes qui ouvrent des connexions brutes, et les apps qui épinglent des certificats, atteignent alors le réseau — et le vrai certificat du serveur — directement. Le proxy lui-même reste actif : HTTP_PROXY / HTTPS_PROXY restent définis, si bien que les outils qui savent utiliser un proxy (apt, git, pip, curl, node…) et les appels d'API des agents passent toujours par Bromure et gardent l'échange d'identifiants, le traçage et les garde-fous. S'applique à chaud, sans redémarrage. Indisponible tant que le mode strict est activé.

Servez-vous-en pour une machine dont un client se casse sous l'interception. Pendant qu'il est activé, le trafic des programmes qui contournent les réglages de proxy n'est pas vu par les règles web du pare-feu ni par les politiques d'écriture.

Autoriser le contournement non sécurisé par requête (X-bromure-insecure)

Une échappatoire plus étroite pour les serveurs à certificat auto-signé ou à autorité privée. Quand une requête vers un tel hôte échoue à la validation du certificat, l'agent peut la retenter avec l'en-tête X-bromure-insecure: yes, et Bromure renonce à valider le certificat de ce serveur pour cette requête. L'interception, le traçage et la garde anti-fuite restent actifs, et Bromure ne met aucun véritable identifiant dans une telle requête — seuls les remplaçants de la VM sortent. Chaque usage est enregistré dans la Chronologie de sécurité.

Activé par défaut : il n'agit que quand la VM envoie explicitement l'en-tête. Désactivez-le pour refuser l'en-tête d'emblée.

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

Un appel bloqué renvoie une erreur ordinaire dans le format propre au service — un Status Kubernetes, une AccessDeniedException AWS, un DENIED de registre — dont le message finit par « blocked by Bromure Guardrails ». L'agent voit un échec net qu'il peut rapporter, pas une connexion suspendue. (Les blocages de chaîne d'approvisionnement utilisent plutôt HTTP 451, de sorte que les deux se distinguent aisément — voir Chaîne d'approvisionnement.)

Limites

• Un force-push ressemble à un push normal sur le fil : Bloquer les destructions ne l'arrête donc pas ; Lecture seule et Demander avant écriture filtrent bien les pushes. Les suppressions via l'API REST de la forge sont attrapées.
• Les politiques Kubernetes et registres ne couvrent que les hôtes issus des kubeconfigs et des registres de cette machine ; une politique de base de données a besoin de l'hôte du point d'accès.
• Les autres hôtes relèvent des règles d'hôte, de port et de méthode de la Politique du bac à sable, pas d'une classification au niveau du service.

Référence des réglages

Chapitres liés

• Identifiants — les identifiants que ces lignes régissent.
• Politique du bac à sable — les règles sortantes de la machine ou sa politique OpenShell.
• Détection d'injection de prompt et garde-fous — l'application en profondeur.
• Vue d'ensemble et chronologie de sécurité — chaque blocage et chaque autorisation, par machine.
• Référence des réglages — tous les volets d'un coup d'œil.