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 :
| Mode | Comportement |
|---|---|
| Désactivé | Aucun filtrage. |
| Demander avant écriture | Les lectures passent. Chaque écriture s'interrompt pour une boîte de dialogue de consentement côté hôte affichant l'opération exacte, avec des autorisations à durée limitée (voir ci-dessous). |
| Bloquer les opérations destructrices | Les suppressions, abandons et arrêts sont bloqués ; les créations et mises à jour passent. |
| Lecture seule | Toute mutation est bloquée ; seules les lectures passent. |
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
| Service | Portée | Classification |
|---|---|---|
| Kubernetes | Les serveurs d'API Kubernetes issus des kubeconfigs de cet espace de travail | GET/HEAD/OPTIONS = lecture ; DELETE = destructif (inclut deletecollection) ; les autres verbes = écriture. Les appels bloqués renvoient un JSON Kubernetes Status 403 que kubectl affiche proprement. |
| AWS | Tous les hôtes *.amazonaws.com | Le nom de l'action issu de l'en-tête X-Amz-Target (services au protocole JSON tels que DynamoDB et Lambda) ou du paramètre de formulaire Action= (services au protocole de requête tels que EC2, IAM, SQS) est classé par préfixe : Delete*/Terminate*/Remove*/Purge*/Destroy*/Deregister*/Revoke* = destructif ; Get*/List*/Describe* et similaires = lecture. Se rabat sur la méthode HTTP pour S3 et les requêtes de style REST. Les appels bloqués renvoient un corps AccessDeniedException. |
| DigitalOcean | api.digitalocean.com et *.digitalocean.com | Méthode HTTP : DELETE = destructif ; GET/HEAD = lecture. |
| Registres de conteneurs | Les registres configurés sous Identifiants, plus les points de terminaison Docker Hub | Pull (GET) = lecture ; push (PUT/POST) = écriture ; DELETE = destructif. Les appels bloqués renvoient un corps d'erreur DENIED de style registre. |
| GitHub | API REST github.com et git sur HTTPS | Basé sur la méthode pour REST. git push (git-receive-pack) compte comme une écriture — bloqué en Lecture seule, soumis à invite en Demander avant écriture ; git fetch (git-upload-pack) est toujours une lecture. |
| GitLab | API REST gitlab.com et git sur HTTPS | Même logique de classification que GitHub. |
| Bitbucket | API REST bitbucket.org et git sur HTTPS | Même logique de classification que GitHub. |
Les points de terminaison de bases de données se classent selon le moteur :
| Moteur | Lecture | Écriture | Destructif |
|---|---|---|---|
| MongoDB (Atlas Data API) | find, findOne, aggregate | insert, update, replace | deleteOne, deleteMany |
| ClickHouse | SQL dont le mot-clé initial est SELECT, SHOW, DESCRIBE, EXPLAIN, WITH … | INSERT, CREATE, ALTER, … | DROP, TRUNCATE, DELETE, et ALTER … DELETE / DROP COLUMN / DROP PARTITION / CLEAR |
| Elasticsearch | _search, _msearch, _count, _mget, _sql, et autres points de terminaison de requête (même en POST) | _bulk, _update, indexation de documents | DELETE et _delete_by_query |
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.
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 garde-fous couvrent les services répertoriés ci-dessus. Le trafic HTTPS arbitraire vers d'autres hôtes n'est pas classé — pour les téléchargements de paquets, voir Chaîne d'approvisionnement, et pour le trafic IA de l'agent, voir Injection de prompt.