Politique du bac à sable, bac à sable invité et sentinelle du noyau

Chaque machine tourne déjà derrière la frontière du fil : l'agent ne détient jamais que des identifiants de substitution, et tout ce qu'il envoie traverse le proxy et le commutateur virtuel de Bromure sur le Mac (voir Identifiants et la frontière du fil). La politique du bac à sable décide ce qu'une machine peut faire d'autre — où sa VM peut se connecter et, si vous le voulez, ce que ses agents peuvent toucher dans la VM. Une machine (un espace de travail, dans l'éditeur de réglages) choisit l'un des deux moteurs de bac à sable dans Réglages › Politique du bac à sable :

	Bromure Firewall	OpenShell + Sentry
Ce que vous écrivez	Une table ordonnée de règles d'autorisation et de refus (style pf), avec un refus par défaut facultatif	Une politique de bac à sable NVIDIA OpenShell (YAML, schéma v1)
Défaut pour le trafic non apparié	Autoriser (ou Refuser)	Refuser
Inspection des requêtes	Méthodes HTTP par hôte (règles `web`)	REST, WebSocket, GraphQL, MCP et JSON-RPC, requête par requête, en `enforce` ou `audit`
Dans la VM	Rien	Le bac à sable invité (système de fichiers, processus, binaires), la sentinelle du noyau, les paquets sans root
Se faire débloquer	Règles temporaires, actions rapides de la Chronologie de sécurité, le tiroir Sandbox	Le tiroir Sandbox, le conseiller de politique à `http://policy.local`
Idéal pour	Restreindre le réseau d'une machine sans changer sa façon de travailler	Une machine que vous voulez confinée, observée et auditable de bout en bout

Les nouvelles machines démarrent sur le pare-feu Bromure. Les deux moteurs sont appliqués sur le Mac, hors de portée de l'agent, et chaque décision est une ligne de la Chronologie de sécurité.

Cinq protections fonctionnent sous l'un ou l'autre moteur et se trouvent dans Garde-fous › Protections :

prévenir l'agent quand la politique le bloque ;
le chien de garde des agents ;
le mode strict des identifiants ;
l'interception transparente ;
le contournement non sécurisé par requête.

Le pare-feu Bromure

Le pare-feu est une liste de règles sur chaque connexion que la VM ouvre : hôte, IP/CIDR, protocole, port et, pour le trafic web, la méthode HTTP. Les règles sont appariées de haut en bas, la première correspondance gagne, et elles peuvent être désactivées ou activées pour une durée limitée. Il est vérifié au commutateur virtuel (par adresse de destination et par le nom que la VM a résolu) puis à nouveau dans le proxy (par nom de serveur TLS et, pour les règles web, par méthode). Les ports 80 et 443 de la VM sont détournés vers le proxy, si bien que rien à l'intérieur ne peut s'y soustraire. La syntaxe des règles et l'éditeur sont documentés dans Politique du bac à sable › Pare-feu Bromure.

Les politiques OpenShell

NVIDIA OpenShell est un format ouvert pour mettre des agents d'IA en bac à sable : une seule politique YAML qui dit quels points de terminaison un agent peut atteindre, comment ses requêtes sont inspectées, quels fichiers il peut toucher et quels programmes peuvent le faire. Bromure exécute nativement les politiques OpenShell. Vous pouvez apporter une politique écrite pour OpenShell, ou partir de la politique de départ de Bromure, et obtenir les mêmes décisions. L'évaluateur de Bromure a été comparé à celui d'OpenShell sur plus de 125 000 cas différentiels, sans aucun écart.

Choisir OpenShell + Sentry dans les réglages d'une machine charge la politique par défaut de votre organisation, ou la politique de départ (GitHub, npm et PyPI en lecture seule, les miroirs de paquets d'Ubuntu), et active la sentinelle du noyau. Dès lors, tout est refusé sauf si une règle network_policies l'autorise.

Où la politique s'applique

Où	Ce qu'elle décide
Le commutateur virtuel	Chaque connexion par adresse et port (tous protocoles) et — avec Enforce binaries — par le programme qui l'a ouverte.
Nom de serveur TLS / `Host` HTTP	À quel point de terminaison une connexion appartient, y compris les connexions qui ignorent les réglages de proxy.
Le proxy	Les connexions faites via `HTTPS_PROXY`.
Chaque requête	Un point de terminaison doté d'un `protocol` (`rest`, `websocket`, `graphql`, `mcp`, `json-rpc`) est inspecté requête par requête : méthodes et chemins (`access: read-only`, `read-write`, `full`, ou des règles explicites et des `deny_rules`), paramètres de requête, opérations GraphQL, outils MCP et méthodes JSON-RPC. `enforcement: enforce` bloque ; `audit` enregistre et laisse passer.

Certaines destinations sont refusées quoi que dise la politique :

les adresses de bouclage, de lien local et de métadonnées cloud ;
les ports du plan de contrôle Kubernetes (2379, 2380, 6443, 10250, 10255).

Les plages privées (10/8, 172.16/12, 192.168/16, 100.64/10) ne sont joignables que par un nom d'hôte exact ou des allowed_ips. Les règles réseau s'appliquent aussitôt à une machine en marche. Les réglages du système de fichiers, des processus et de la sentinelle prennent effet au prochain démarrage de la VM.

Une requête refusée reçoit un HTTP 403 avec le corps policy_denied propre à OpenShell, si bien que les outils et agents qui comprennent OpenShell réagissent de la même façon.

Les règles que Bromure ajoute automatiquement

Une machine doit toujours atteindre les fournisseurs de modèles de ses agents, les hôtes auxquels ses identifiants sont destinés, ses clusters Kubernetes, AWS et ses modèles locaux. Comme les règles de fournisseur d'OpenShell, Bromure ajoute pour cela des règles _provider_…. Elles sont listées sous Rules Bromure adds automatically dans la carte Governance, et laissées hors d'une politique exportée.

Les identifiants sous OpenShell

La protection des identifiants de Bromure ne change pas : la VM détient des substituts, et la vraie valeur est échangée sur le fil, uniquement pour les hôtes propres à l'identifiant. Deux ajouts, dans le volet Identifiants d'une machine OpenShell :

Profils de fournisseur OpenShell — importez un profil (openshell profile export), saisissez ses valeurs, et chacune devient un identifiant de la machine lié aux hôtes et chemins du profil, les points de terminaison du profil étant ajoutés comme règle.
Use OpenShell credential placeholders — l'agent voit openshell:resolve:env:NAME au lieu des jetons d'apparence réelle de Bromure, comme il le ferait sous OpenShell.

Les champs d'identifiants propres à la politique (credential_binding, credential_signing et similaires) sont ignorés avec un avertissement : Bromure lie chaque identifiant à ses hôtes et signe lui-même les requêtes AWS.

Différences avec OpenShell

Bromure suit la sémantique d'OpenShell, avec quelques différences délibérées :

Pas de filesystem_policy, pas de bac à sable du système de fichiers. Une politique sans cette section laisse les fichiers de la VM non confinés ; OpenShell confinerait l'agent à son dossier de travail.
binaries exige Enforce binaries. Sans lui, binaries n'est qu'indicatif, et l'éditeur le signale : l'agent détient root dans la VM, donc l'identité d'un processus n'est pas fiable.
Middlewares. Seul le middleware intégré openshell/regex en mode redact s'exécute. Un middleware externe est laissé passer ou bloqué selon son fail_open / fail_closed.
Profils de fournisseur. Les identifiants qui se rafraîchissent (refresh) ou utilisent un token_grant sont utilisés comme valeurs statiques.
Seccomp. Le filtre est ajusté pour que le contrôle des tâches fonctionne dans les terminaux de la VM.

Le bac à sable invité

La politique réseau limite où la VM peut se connecter. Le bac à sable invité limite ce que les agents peuvent faire à l'intérieur. Il provient de trois parties de la politique :

Section de la politique	Ce que Bromure applique
`filesystem_policy` (+ `landlock`)	L'agent ne peut lire et écrire que les chemins que la politique liste, appliqué avec Linux Landlock — même root dans la VM ne peut pas le lever. `landlock.compatibility: best_effort` se dégrade si un chemin est inutilisable ; `hard_requirement` échoue fermé.
`process` (`run_as_user`, `run_as_group`)	L'agent tourne sous ce compte, sans sudo ni Docker. Il voit toujours `/home/ubuntu` comme son dossier personnel, donc sa configuration s'applique.
Enforce binaries (le bac à sable strict)	Chaque connexion est attribuée au programme qui l'a faite par un attesteur appartenant à root dans la VM, et les `binaries` d'une règle doivent le nommer. L'empreinte de chaque programme est épinglée à la première utilisation, et un binaire modifié est refusé. Pour que ce rapport soit fiable, l'agent perd tout chemin vers root : pas de sudo, pas de Docker, et tout le trafic passe par l'interception transparente.

Chaque partie ne s'applique que si elle est présente. Une politique sans section filesystem_policy ni process ne confine rien dans la VM. Une section process active à elle seule Enforce binaries.

Configuration	Ce que vous obtenez
Politique réseau seule	Le réseau est confiné ; la VM ne l'est pas.
`filesystem_policy`, binaires non imposés	Les fichiers sont confinés, même contre root. sudo marche toujours, donc l'agent pourrait arrêter les auxiliaires de Bromure dans la VM — la carte Sandbox le signale.
Enforce binaries, ou une section `process`	Les fichiers, les appels système et les privilèges sont confinés. L'agent ne peut pas devenir root ni interférer avec les processus de Bromure.

Bromure ajoute les quelques chemins dont sa propre plomberie a besoin, en lecture seule sauf s'ils doivent être écrits, et les liste sur la carte Sandbox (Added for Bromure: …) :

les sockets des terminaux ;
le partage meta ;
/proc;
la configuration DNS ;
les dossiers d'installation des agents qui vivent hors de /usr (Grok dans /opt/grok, l'environnement d'exécution d'Oh My Pi dans /opt/bun).

Ils ne sont jamais fusionnés dans vos propres listes.

Échouer fermé

Le bac à sable ne retombe jamais en silence sur une exécution non confinée :

Si le bac à sable strict ne s'applique pas entièrement, aucune session ne démarre, les règles de binaires refusent tout, et la carte Sandbox le dit en rouge. Redémarrer la VM réessaie.
Les commandes que Bromure lance dans la machine pour vous — terminaux, vm exec, opérations sur les fichiers, git, le planificateur — attendent que le bac à sable soit en place (90 secondes pour une commande simple). S'il ne se met pas en place, la commande échoue avec sandbox unavailable: ….
Les appels git que Bromure fait lui-même dans la machine tournent toujours confinés, puisqu'un dépôt peut faire pointer git vers le programme de son choix.

Des paquets sans root

Un agent confiné n'a pas root, donc les installations à l'échelle du système ne peuvent pas marcher. Deux interrupteurs de la carte Sandbox, tous deux activés par défaut, permettent aux installations de fonctionner :

Packages in the home folder — pip install va dans ~/.local (npm installe déjà globalement dans ~/.npm-global). Les propres processus de Bromure dans la VM ignorent les paquets du dossier personnel, si bien que l'agent ne peut pas y planter de code.
System packages on request — quand l'agent lance apt-get install (avec ou sans sudo), la demande vous attend au lieu d'échouer. L'agent voit :
```
bromure: this sandbox has no root. Asked the user to approve installing: libpq-dev
bromure: waiting for their decision (Sandbox drawer › Proposals)…
```
Ouvrez l'onglet Proposals du tiroir Sandbox et choisissez Install ou Reject. Les paquets approuvés sont installés par le superviseur root de la VM depuis les miroirs d'Ubuntu, par leur nom exact uniquement : ni options, ni chemins de fichiers, ni fichiers .deb, ni noms qu'apt lirait comme un motif ou une suppression. Une demande rejetée dit à l'agent de ne pas réessayer. Chaque demande et son issue est une ligne Guest sandbox dans la Chronologie de sécurité.

La sentinelle du noyau

La sentinelle du noyau est un petit module du noyau Linux qui rapporte, depuis l'intérieur du noyau de la VM, ce qui s'y passe. Elle rapporte au Mac par un canal privé que l'agent ne peut pas faire taire en tuant un processus :

les lancements de programmes ;
les connexions, avec la chaîne de processus derrière chacune ;
les changements de privilèges ;
les chargements de modules et de BPF ;
tout ce que le bac à sable invité a refusé.

Une fois démarrée, le noyau est verrouillé pour que même root dans la VM ne puisse pas charger de code pour interférer.

C'est la sentinelle qui rend possible :

La lignée réseau — quel prompt, quel appel d'outil et quel processus ont fait chaque connexion.
Les refus du bac à sable dans la Chronologie et dans l'onglet Files du tiroir Sandbox.
La détection d'altération — un trou dans le flux numéroté de la sentinelle, une sonde désarmée, une reconnexion forgée, le chargement d'un module non signé ou un verrouillage abaissé est signalé en rouge comme tampering suspected, et alimente le chien de garde des agents.
L'identité des binaires pour Enforce binaries.

Elle a deux modes, dans la carte Kernel sentry :

Mode	Au démarrage	Si la sentinelle ne peut pas se charger
Best effort	La sentinelle se charge en arrière-plan ; les sessions ne l'attendent pas.	La machine tourne sans elle, et la carte dit pourquoi.
Required	Rien ne tourne dans la VM tant que la sentinelle n'est pas fixée. Le noyau est verrouillé davantage, ce qui exclut aussi les outils de traçage du noyau comme `bpftrace` et `perf`.	Si la VM explique pourquoi (par exemple, aucun module n'existe pour son noyau), la machine démarre sans elle, avec un avertissement. Une sentinelle qui ne se connecte jamais sans explication est traitée comme une altération.

Votre organisation peut imposer un mode minimal. La machine tourne alors avec le plus strict des deux.

Des modules à la demande

Un module du noyau ne se charge que dans le noyau exact pour lequel il a été compilé, et une machine peut passer à un nouveau noyau Ubuntu par apt upgrade à tout moment. Les modules ne sont donc pas livrés dans l'app. Bromure les compile chaque jour pour chaque noyau Ubuntu et les publie sur dl.bromure.io. Le catalogue et chaque module sont signés, et Bromure vérifie la signature, la somme de contrôle, et que le catalogue n'est pas plus ancien qu'un qu'il possède déjà.

Au lancement, Bromure récupère les modules pour les noyaux que vos machines sont connues pour utiliser, et les prépare avant chaque démarrage.
Quand une VM démarre un noyau que Bromure n'a pas encore vu, la VM le demande, et Bromure récupère le module et le lui remet en quelques secondes.
Quand aucun module n'existe encore pour ce noyau, la VM en est avertie aussitôt, et la carte affiche Couldn't start: no module published for noyau yet. Réessayez un jour plus tard, ou démarrez sur le noyau précédent.

Les modules téléchargés sont conservés dans ~/Library/Application Support/BromureAC/sentry-modules/.

Le tiroir Sandbox

La fenêtre de chaque machine a un bouton bouclier dans sa barre d'outils (« Sandbox: what it blocked, ready to allow »). Il ouvre le tiroir Sandbox par-dessus la scène. Vous pouvez aussi appuyer sur ⌃⌘N, ou choisir Présentation › Toggle Sandbox Drawer. Une pastille rouge sur le bouton compte les destinations bloquées depuis votre dernier coup d'œil. Le tiroir montre ce que le bac à sable de la machine a refusé dans les deux dernières heures, prêt à être autorisé :

Onglet	Moteur	Ce qu'il contient
Network (Blocked sous le pare-feu)	Les deux	Chaque destination bloquée, avec le programme qui a essayé (quand il est connu), combien de fois et quand. Allow ajoute une règle pour cet hôte et ce port. Sous le pare-feu, il propose Toujours, Pendant 15 minutes, Pendant 1 heure ou Jusqu'à l'arrêt de l'espace de travail. Sous OpenShell avec Enforce binaries, la règle nomme le programme qui a essayé.
Files	OpenShell, avec un `filesystem_policy`	Ce que le bac à sable du système de fichiers a refusé, regroupé par dossier, avec l'opération et le fichier. Allow ajoute le dossier en lecture seule, ou en Read and write, ou juste ce fichier-là. L'accès aux fichiers change au prochain démarrage : une carte Redémarrer apparaît.
Proposals	OpenShell	Les demandes de paquets (Install / Reject) et les règles pour lesquelles le conseiller de politique attend votre décision (Approve / Reject).
Temporary	Pare-feu	Les règles activées pour une durée limitée, avec leur échéance, et End.

Les règles ajoutées depuis le tiroir sont enregistrées dans la machine et s'appliquent aussitôt. Elles sont vérifiées par rapport à votre limite d'organisation comme toute autre modification. Sandbox Policy… en bas ouvre les réglages de la machine.

Le conseiller de politique

Un agent qui se heurte à un mur sait généralement exactement ce dont il avait besoin. Sous OpenShell, il peut le demander : quand une requête est bloquée, l'agent peut proposer à http://policy.local, l'API du conseiller d'OpenShell, la règle la plus étroite qui l'autoriserait, et attendre votre décision. Le 403 qu'il a reçu lui explique comment. Vous choisissez ce qu'il peut faire dans Politique du bac à sable › Policy advisor › Agent proposals :

Mode	Ce qui se passe
Off (par défaut)	L'agent ne peut pas proposer de règles. Les connexions bloquées sont toujours rédigées pour vous sous forme de propositions.
Ask me	Chaque proposition attend dans le tiroir Sandbox et la carte Policy advisor jusqu'à ce que vous l'approuviez (Approve) ou la rejetiez (Reject). La raison d'un rejet est renvoyée à l'agent.
Approve if risk-free	Une proposition sans constat de risque est approuvée aussitôt. Une proposition qui atteint un hôte pour lequel la machine a un identifiant, y ajoute une méthode, ou utilise un joker, une adresse privée, un port de base de données ou un port élevé vous attend toujours. De même pour une proposition qui dépasserait la limite de votre organisation.

Les agents ne peuvent proposer que des règles rest ou websocket, et jamais tls: skip. Une règle approuvée est ajoutée à la politique, s'applique à chaud et est conservée dans l'historique des révisions de la politique. Chaque proposition et chaque décision est une ligne Firewall dans la Chronologie de sécurité.

Prévenir l'agent : le guidage par la politique

Un agent qui ne voit que « connection refused » ou « permission denied » a tendance à réessayer, puis à chercher un autre chemin. Vu de l'extérieur, cela ressemble à un agent qui dérape. Avec Tell the agent when policy blocks it (dans Garde-fous › Protections, activé par défaut pour les machines OpenShell), l'agent apprend dans sa conversation ce qui a été bloqué et pourquoi, par exemple :

[Bromure policy] This workspace's network policy blocked connecting to api.stripe.com:443 — no network policy allows api.stripe.com:443. … This is a deliberate restriction, not a fault: don't retry it or reach the same thing another way … If your task needs it, stop and tell the user what you need and why so they can decide.

Claude Code reçoit la note juste après la commande qui a heurté le blocage, en plein tour.
Codex, Grok, Kimi et Oh My Pi la reçoivent tapée une fois leur tour terminé.
La note va à l'agent dont le processus a fait la connexion ou l'accès au fichier bloqué, grâce aux chaînes de processus de la sentinelle du noyau.
Quand Bromure ne peut pas savoir de quel agent il s'agit, un blocage réseau va à tous les agents de la machine, et un blocage de fichier seulement à un agent unique.
Un même blocage n'est signalé qu'une fois toutes les cinq minutes, et un agent reçoit au plus cinq notes par minute. Le trafic d'arrière-plan propre à un agent, et les hôtes de télémétrie courants, ne sont jamais signalés.

Les valeurs de la note qui viennent de la VM (un hôte, un chemin) sont citées comme des données, si bien qu'un programme ne peut pas se servir d'un blocage pour mettre des mots dans la bouche de l'agent.

Le chien de garde des agents

Le chien de garde regarde une session dans son ensemble, depuis l'extérieur de la VM :

des rafales de blocages ;
des identifiants qui n'ont rien à faire là ;
des signes d'altération de la sentinelle ;
un bac à sable qui a échoué ;
l'injection de prompt ;
de nouvelles destinations après la stabilisation de la session ;
un volume sortant bien au-dessus de sa base de référence.

Au-delà d'un seuil en une minute, il enregistre un constat (Alert), ou coupe le réseau de la VM, la met en pause et vous demande quoi faire (Quarantine). Voir Garde-fous › Chien de garde des agents. Il est désactivé par défaut ; sans lui, les alarmes d'altération restent enregistrées dans la Chronologie de sécurité et dans les journaux OCSF.

La limite de l'organisation

Une organisation peut fixer une limite : le maximum que la politique OpenShell d'une machine peut autoriser. Elle vient de bromure.io sur un Mac inscrit (rafraîchie toutes les dix minutes, et mise en cache pour un usage hors ligne), ou d'un fichier sur ce Mac (Politique du bac à sable › Governance › Organization boundary). Chaque enregistrement qui modifie une politique est vérifié par rapport à elle, depuis les réglages, le tiroir Sandbox, le conseiller de politique ou l'API. Bromure utilise le openshell-prover de NVIDIA quand il est installé, sinon sa propre vérification.

Dans l'éditeur, un verdict vert ou rouge s'affiche pendant la saisie (« within boundary », ou « exceeds boundary: … » avec un exemple de ce qu'elle autoriserait), et Enregistrer attend que la politique rentre dans la limite.
Ailleurs, un enregistrement hors de la limite est refusé avec « outside the organization boundary — … ».
Une politique enregistrée plus tôt qui ne rentre plus échoue fermée : seules les règles que Bromure ajoute lui-même restent joignables.

Par le même canal, une organisation peut aussi :

fixer la politique par défaut des nouvelles machines OpenShell ;
imposer Enforce binaries ou les identifiants stricts ;
fixer un mode minimal pour la sentinelle du noyau ;
plafonner le mode du conseiller de politique ;
demander que le raisonnement des agents soit téléversé avec la lignée réseau.

Voir Entreprise.

Chaque enregistrement qui modifie une politique est aussi conservé dans son Revision history, avec l'origine du changement ; Restaurer ramène n'importe quelle version.

Chapitres liés

Réglages › Politique du bac à sable — chaque champ du volet.
Réglages › Garde-fous — les protections communes aux deux moteurs.
Vue d'ensemble et chronologie de sécurité — ce que les moteurs ont décidé, et la lignée réseau.
Identifiants et la frontière du fil — pourquoi l'agent ne détient jamais de vrai secret.