Traçage et audit

Chaque requête émise par une machine — les appels de l'agent aux fournisseurs de LLM, les téléchargements de paquets, le trafic kubectl et aws, les simples récupérations web — passe par le proxy MITM côté hôte de Bromure Agentic Coding. Comme le proxy se tient déjà sur cette frontière du fil, il peut enregistrer ce qui la traverse : quels hôtes l'agent a contactés, ce qu'il a envoyé, ce qui est revenu, si un identifiant a été échangé ou divulgué, et — pour le trafic IA — l'intégralité de la conversation, les appels d'outils et les commandes shell pilotés par le modèle.

Cet enregistrement constitue la trace de session de la machine. Il existe pour une seule raison : vous permettre de répondre, après coup, à la question « qu'a réellement fait l'agent ? » — jusqu'au prompt individuel, au rm -rf individuel, à la requête sortante individuelle. Tout est enregistré sur votre Mac, chiffré au repos, et (pour les utilisateurs individuels) ne le quitte jamais.

Ce chapitre couvre l'ensemble du système : ce que capture une trace, comment elle est stockée et purgée, la fenêtre de l'Inspecteur de traces, la ligne de commande bromure-cli trace, comment récupérer les données, et la frontière de confidentialité entre l'audit local et la télémétrie que les Mac inscrits diffusent à une organisation. La référence champ par champ des réglages du volet se trouve dans Réglages de traçage.

Le traçage enregistre le trafic. Ce que les moteurs de sécurité de Bromure ont décidé à propos de ce trafic — substitutions, blocages, vérifications de paquets, détections — est enregistré à part, et toujours, dans la Chronologie de sécurité.

Ce qu'enregistre une trace

Le traçage se règle par machine (un espace de travail, dans l'éditeur de réglages), avec le sélecteur Trace de session du volet Traçage, sous Sécurité dans les réglages de la machine. Il comporte quatre niveaux, chacun étant un sur-ensemble du précédent :

Les nouvelles machines utilisent par défaut Détails des requêtes IA, de sorte que les conversations de l'agent sont auditables d'emblée sans stocker sur le disque les corps du trafic sans rapport (téléchargements de paquets, pings de télémétrie).

Remarque : l'énumération du niveau de trace prend par défaut la valeur Désactivé dans le format de profil, de sorte qu'une machine dont les réglages stockés sont antérieurs à ce réglage se décode comme Désactivé. La valeur par défaut Détails des requêtes IA ne s'applique qu'aux machines créées à partir du modèle actuel. Choisissez le niveau délibérément lorsque l'audit importe.

L'enregistrement de métadonnées

À partir d'Activité uniquement, le proxy écrit un enregistrement de trace par requête. Chaque enregistrement — quel que soit le niveau — porte les métadonnées :

• Horodatage, hôte, port, méthode HTTP et chemin.
• Code de statut et latence, mesurés depuis le CONNECT qui a ouvert le tunnel jusqu'à la réponse.
• Octets de requête (mesurés avant tout échange d'identifiant) et octets de réponse.
• Le rapport d'échange de jetons — quels identifiants le proxy a substitués à la sortie (voir Échanges et fuites d'identifiants).
• Avertissements de fuite d'identifiants — jetons de type bearer dans la requête sortante que Bromure n'a pas générés.
• Pour les requêtes IA, lorsque le routage de modèle de la machine est défini, quel backend a servi le tour — cloud ou le modèle local (voir Modèles et fournisseurs).

C'est suffisant pour reconstituer le tableau complet de avec qui l'agent a échangé et quand sans conserver un seul octet de texte de prompt ou de réponse sur le disque. Lorsque vous voulez la piste d'audit — domaines contactés, gestion des identifiants, latence — mais pas le contenu, Activité uniquement est le niveau à choisir.

Corps capturés et conversations analysées

Au niveau Détails des requêtes IA, le proxy stocke en plus les corps complets des requêtes et réponses pour les hôtes LLM connus : Anthropic, OpenAI / ChatGPT, Google, Cohere, Mistral, Perplexity, x.ai / Grok, Groq, Replicate et HuggingFace, ainsi que l'hôte d'inférence locale lorsqu'une machine route vers un modèle local. Au niveau Tout, les corps sont conservés pour tous les hôtes.

Un corps IA capturé n'est pas seulement stocké — il est analysé. L'Inspecteur de traces le restitue sous forme de vue Conversation : le prompt système, chaque tour utilisateur, les réponses de l'assistant et les blocs structurés émis par le modèle. Ces blocs sont exactement ce qui rend utile une trace d'agent de codage :

• Appels d'outils — chaque bloc tool_use produit par le modèle, avec son entrée.
• Commandes shell — les appels d'outil Bash / Shell, c'est-à-dire les commandes que l'agent a exécutées dans la VM.
• Lectures et écritures de fichiers — les appels d'outil Read / View et Write / Edit / MultiEdit, avec les chemins qu'ils ont touchés.

Ainsi, un unique enregistrement de requête IA répond à « qu'a décidé de faire le modèle ce tour-ci » — lire ce fichier, exécuter cette commande, appeler cette API — extrait du corps brut de l'API. La même structure est ce que le tap d'événements en temps réel transforme en événements d'audit sur les Mac inscrits.

Échanges et fuites d'identifiants

Deux faits relatifs à la gestion des identifiants sont enregistrés à chaque requête, et mis en évidence car ce sont ceux qui comptent pour une revue de sécurité :

• Échanges de jetons. Lorsque le proxy remplace l'identifiant leurre détenu par la VM par le véritable identifiant sur le fil, l'enregistrement le note — sous forme d'aperçus des premiers/derniers caractères des valeurs factice et réelle (sk-a…f9q3), jamais les octets du secret. C'est le cas normal et sain : il confirme que le système d'échange fait son travail.
• Fuites. Lorsqu'une requête sortante transporte un jeton de type bearer que Bromure n'a pas généré — un véritable secret collé directement dans la VM, contournant le système d'échange — l'enregistrement le signale comme une fuite potentielle, là encore uniquement sous forme d'aperçu, étiqueté avec une classe de suspicion : knownPrefix (un préfixe de secret reconnu que Bromure n'a pas émis) ou opaqueToken (une longue valeur d'authentification opaque). Un signalement de fuite est une invitation à enquêter ; l'intégralité des mécanismes des identifiants leurres et de la détection de compromission se trouve dans Identifiants.

Chiffrement au repos et rétention

Les traces résident sous ~/Library/Application Support/BromureAC/traces/, organisées par jour :

• Les métadonnées sont ajoutées à raison d'une ligne JSON par requête dans traces/YYYY-MM-DD/<sessionID>.jsonl.
• Les corps capturés sont stockés à côté sous traces/YYYY-MM-DD/<sessionID>/<recordID>.req.enc et .res.enc — scellés en AES-GCM avec la clé maîtresse SecretsVault, la même clé détenue dans le Keychain qui chiffre les secrets de votre espace de travail. Les permissions de fichier sont 0600.

Avant toute écriture, l'enregistrement est assaini :

• Les en-têtes sensibles sont expurgés. Authorization, Proxy-Authorization, Cookie, Set-Cookie, x-amz-security-token, api-key, et tout en-tête se terminant par -api-key sont réécrits en <redacted>.
• Les secrets sont stockés uniquement sous forme d'aperçu. Les échanges de jetons et les fuites suspectées conservent les aperçus des premiers/derniers caractères — les véritables octets d'un secret n'entrent jamais dans un enregistrement de trace, chiffré ou non.

La rétention est automatique et s'exécute paresseusement (une passe de nettoyage tous les 200 ajouts) :

Séparément, l'application conserve les 5 000 derniers enregistrements dans un anneau en mémoire pour la vue en direct ; les enregistrements plus anciens restent sur le disque dans les limites des plafonds ci-dessus.

Avertissement : aux niveaux Détails des requêtes IA et Tout, l'intégralité du texte des prompts et réponses des échanges IA se trouve sur le disque — chiffrée, mais présente. Avec la protection des données personnelles activée, la trace contient toujours les vraies valeurs : elle stocke la requête telle que l'agent l'a envoyée et la réponse après la remise en place des vraies valeurs. Comme les corps sont scellés avec la clé maîtresse SecretsVault, faire pivoter cette clé rend indéchiffrables les corps précédemment capturés ; l'Inspecteur de traces affiche alors (not captured / decryption failed) là où figurerait le corps.

La fenêtre de l'Inspecteur de traces

L'Inspecteur de traces est le visualiseur en direct et filtrable de chaque échange enregistré à travers tous les espaces de travail. Il lit les mêmes enregistrements que la CLI et se met à jour en temps réel à mesure que de nouvelles requêtes circulent.

Ouverture de la fenêtre

Ouvrez-la depuis Fenêtre → Inspecteur de traces… (⇧⌘I). Elle s'ouvre aussi pré-filtrée sur une machine depuis Inspecter la trace dans le menu de la machine — la capsule portant le nom de la machine dans la barre d'outils de la fenêtre principale — ce qui vous permet de passer directement d'un agent en cours d'exécution à son propre trafic. Inspecter la trace n'apparaît que lorsque la machine est en marche. À l'ouverture, l'anneau en mémoire est préchauffé depuis le disque — en lisant uniquement les répertoires de jour d'aujourd'hui et d'hier, de sorte qu'un lancement à froid est rapide. Les enregistrements plus anciens restent sur le disque et apparaissent une fois que vous appuyez sur le bouton de rechargement lorsqu'ils sont dans la plage, ou en les lisant avec la CLI.

La liste des requêtes

Le volet de gauche est une liste d'enregistrements, du plus récent au plus ancien. Chaque ligne affiche, de gauche à droite :

• Un point de statut codé par couleur selon la classe de réponse : vert pour 2xx, bleu pour 3xx, orange pour 4xx, rouge pour 5xx, gris sinon.
• La méthode et l'hôte (le chemin est affiché en dessous, tronqué au milieu).
• Des badges, le cas échéant : un triangle d'avertissement orange pour les identifiants non échangés (une fuite potentielle), des flèches d'échange bleues pour les échanges de jetons, et une icône de document lorsqu'un corps a été capturé pour cet enregistrement.
• Le code de statut et la latence sur la droite.

Le pied de page indique N records (last M in memory) et porte un bouton Recharger depuis le disque (l'icône de flèche circulaire). La liste dispose d'une navigation complète au clavier — ↑ / ↓ pour avancer d'un pas, PgUp / PgDn pour sauter de dix, Home / End pour atteindre les extrémités — la ligne nouvellement sélectionnée étant amenée à la vue par défilement.

Filtrage

Une barre de filtre se trouve au-dessus de la liste :

Remarque : Conversations uniquement repose sur un indicateur défini lors de l'écriture de l'enregistrement. Les enregistrements capturés avant l'existence de cet indicateur comptent comme des non-conversations et sont masqués par ce filtre jusqu'à leur ré-enregistrement.

Le volet de détail

La sélection d'une ligne remplit le volet de droite. Son en-tête affiche la méthode, l'URL complète, le statut et une rangée de cellules de métadonnées — Espace de travail, Latence, tailles de Requête et de Réponse, et Heure — plus un bouton segmenté Conversation / Brut.

• Conversation restitue le chat IA analysé : prompt système, tours, appels d'outils et résultats, mis en forme pour la lecture. Il n'est disponible que lorsqu'un corps a été capturé et que l'échange a été analysé comme une conversation IA ; sinon le bouton bascule de lui-même sur Brut.
• Brut affiche les composants de l'enregistrement en sections : Identifiants non échangés (fuites potentielles), Échanges de jetons (chacun sous forme d'aperçus factice → réel), Corps de requête et Corps de réponse. Les corps sont déchiffrés à la demande lorsque vous sélectionnez l'enregistrement.

Chaque section de corps dispose d'un bouton de copie qui place le corps complet dans le presse-papiers — le texte intégral même au-delà de la troncature à l'écran, et une chaîne hexadécimale pour les corps binaires. Lorsqu'aucun corps n'a été stocké, ou que la clé maîtresse ne peut plus le déchiffrer, la section indique (not captured / decryption failed).

Sans sélection, le volet affiche un texte indicatif : Choisissez une requête — Sélectionnez une ligne à gauche pour inspecter les en-têtes, les échanges et (si capturés) les corps.

Sessions WebSocket

Les mises à niveau WebSocket de longue durée à travers le proxy — OpenAI Realtime, le responses_websockets de Codex, et similaires — sont tracées comme un enregistrement unique par session WS plutôt que perdues sous forme de binaire opaque. Lorsque le niveau de trace de l'espace de travail capture les corps pour cet hôte, les deux directions sont analysées trame par trame (RFC 6455) : le masquage est retiré, les trames de continuation sont défragmentées, et les charges utiles permessage-deflate (RFC 7692) sont décompressées, de sorte que les trames de texte sont lisibles au lieu d'être du charabia compressé.

À la fermeture, le proxy ajoute une transcription chronologique après la réponse de handshake amont et la stocke comme corps de réponse de l'enregistrement, de sorte que l'Inspecteur de traces la restitue par le chemin de corps ordinaire — vue Conversation comprise lorsqu'elle s'analyse comme un échange IA. Une entrée de transcription ressemble à ceci :

--- WebSocket session transcript ---
>>> [2026-07-13T15:30:05Z] TEXT 1234B
<<< [2026-07-13T15:30:06Z] TEXT 5678B (truncated, total 40000 bytes)

Des limites bornent une session bavarde : 1 Mo conservé par message, 4 096 messages par session, une trame maximale de 64 Mo, et un message décompressé maximal de 32 Mo ; tout ce qui dépasse un plafond est marqué (truncated, total N bytes). Les échecs d'analyse ne dégradent que la transcription — le tunnel en direct pompe les octets bruts et n'est jamais bloqué ni corrompu par le traçage.

La chronologie de sécurité

L'Inspecteur de traces répond à « qu'est-ce que l'agent a envoyé ? » ; la Chronologie de sécurité (Fenêtre → Sécurité…) répond à « qu'ont décidé les moteurs de sécurité de Bromure ? » — chaque substitution d'identifiant, verdict du pare-feu, vérification de paquet, détection d'injection de prompt, substitution de données personnelles et utilisation d'identifiant, en un seul tableau chronologique doté d'une Vue d'ensemble sur 24 heures. Contrairement au traçage, elle ne demande aucun réglage : elle est toujours enregistrée, conservée 90 jours, et survit aux redémarrages. Elle a son propre chapitre : Vue d'ensemble et chronologie de sécurité.

La CLI de traçage

Le groupe de commandes bromure-cli trace vous donne les mêmes données de trace dans le terminal. C'est un client léger : il communique avec l'application en cours d'exécution via le socket de contrôle local, de sorte que l'application GUI doit être en cours d'exécution (le client riche fait transiter le protocole identique par SSH pour atteindre une instance distante).

L'argument facultatif workspace filtre par id ou par nom. Si le traçage est désactivé pour l'espace de travail (ou si rien n'a encore été enregistré), trace ls affiche No trace records. (Tracing is per-workspace — enable it in the workspace's settings.) ; si l'application n'est pas en cours d'exécution, chaque sous-commande affiche No bromure-ac agent running. La CLI complète est documentée dans CLI, API et MCP.

Exporter une trace

Il n'y a pas de bouton « Exporter » unique — les données de trace quittent l'inspecteur par les chemins qui préservent l'intégrité de la frontière de chiffrement :

• Depuis l'Inspecteur de traces. En mode Brut, le bouton de copie du Corps de requête ou du Corps de réponse copie le corps déchiffré complet dans le presse-papiers, au-delà de toute troncature à l'écran. L'URL dans l'en-tête est un texte sélectionnable. C'est la façon d'extraire un échange — une paire prompt/réponse complète — pour un rapport ou un signalement de bogue.
• Depuis la CLI. Redirigez n'importe quelle sous-commande trace vers un fichier, par exemple bromure-cli trace summary my-workspace > audit.txt ou bromure-cli trace ls my-workspace --limit 500 > requests.txt. C'est la façon de capturer la piste de métadonnées de nombreuses requêtes à la fois.
• Depuis le disque. Le JSONL de métadonnées sous traces/YYYY-MM-DD/ est du texte brut (avec les secrets déjà expurgés en aperçus) et peut être lu directement. Les fichiers de corps .enc sont scellés en AES-GCM avec la clé maîtresse SecretsVault et ne sont déchiffrables qu'à l'intérieur de l'application — copiez-les depuis l'inspecteur, pas depuis le disque.

Ce qui ne quitte jamais votre Mac

Pour une installation individuelle et non gérée, le traçage est entièrement local :

• Les traces sont écrites dans le répertoire Application Support de votre Mac et chiffrées avec une clé détenue dans votre Keychain de session.
• Aucun enregistrement de trace, corps ou résumé n'est téléversé où que ce soit. Le proxy n'a aucun point de terminaison d'analytique câblé pour les utilisateurs individuels.
• Les classificateurs d'injection de prompt qui alimentent aussi la Chronologie de sécurité s'exécutent sur l'appareil ; voir Détection d'injection de prompt et garde-fous. Rien de votre trafic n'est envoyé à un service cloud pour analyse.

Les règles d'expurgation et d'aperçu ci-dessus font que même les données au repos ne contiennent jamais un secret utilisable. Le traçage est un journal d'audit privé, pas un appel maison.

Mode privé et télémétrie d'entreprise

Le seul cas où des données dérivées des traces quittent la machine est un Mac inscrit auprès d'un espace de travail bromure.io. L'inscription transforme le journal d'audit local en un journal visible par l'organisation — et vous donne un interrupteur pour en désengager un espace de travail individuel. Ce que voient les administrateurs, et comment fonctionne l'inscription, est couvert dans Entreprise ; cette section décrit la frontière du côté du traçage.

Le flux d'événements

Sur un Mac inscrit, les sessions diffusent des événements cloud structurés vers l'espace de travail d'administration de l'organisation, extraits du même trafic IA que capture le traçage :

• llm.request — par échange : fournisseur, hôte, chemin, statut, latence, modèle, nombres de jetons d'entrée/sortie, et les deux compteurs de cache d'Anthropic (cache_creation_input_tokens, cache_read_input_tokens, analysés même à partir des flux SSE ; le cached_tokens d'OpenAI est également pris en charge).
• tool.use — chaque appel d'outil, avec un résumé de l'entrée plafonné à 240 caractères.
• file.read / file.write — le chemin extrait et le nom de l'outil.
• command.run — la commande shell, plafonnée à 500 caractères.
• credential.token_swap — un par échange sur le fil, aperçus uniquement.
• prompt_injection.detection — transmis lorsqu'un détecteur se déclenche, portant l'intégralité de l'extrait signalé (plafonné à 20 Ko), contrairement au court aperçu de la Chronologie de sécurité.
• egress.firewall — un par verdict du pare-feu : hôte, port, protocole et action prise.
• credential.exfiltration — un faux identifiant a été observé quittant la VM vers un hôte hors de sa portée (aperçus et hôtes uniquement, jamais les octets du jeton) ; credential.exfiltration_allowed lorsque vous avez répondu Autoriser à l'alerte de compromission.
• privacy.pii_swap — pour chaque requête où la protection des données personnelles a substitué des valeurs : l'hôte et les nombres par type, jamais les valeurs.
• net.flow — sur une machine dotée de la sentinelle du noyau, chaque connexion avec sa chaîne de processus, l'appel d'outil derrière elle et la décision de l'hôte (lignée réseau).
• Les événements du bac à sable invité, de la sentinelle du noyau et du chien de garde — ce que le bac à sable invité a refusé, les alarmes d'altération de la sentinelle, et les constats du chien de garde.
• agent.reasoning — ce que l'agent a écrit avant un appel d'outil (son raisonnement, son intention annoncée et votre prompt), uniquement quand l'organisation le demande (capture_agent_reasoning dans sa politique OpenShell gérée). Il est toujours affiché localement, dans la feuille de lignée.
• Journaux HTTP détaillés des requêtes — les installations inscrites peuvent en outre diffuser les métadonnées HTTP par requête depuis la couche d'interception transparente, de sorte qu'une organisation voit la surface HTTP sortante de l'espace de travail, et pas seulement son trafic IA.

Seul le tour d'assistant le plus récent est parcouru, de sorte que l'historique renvoyé n'est jamais compté deux fois, et les prompts bruts ne sont jamais émis, sauf si l'organisation a choisi agent.reasoning — la télémétrie répond à « ce que l'IA a fait », pas à « ce que l'utilisateur a demandé ».

Les lignes de commande sont expurgées

Les lignes de commande des événements — les arguments d'un processus, la commande d'un appel d'outil, le résumé d'une entrée d'outil — sont débarrassées de leurs secrets avant d'être enregistrées dans la Chronologie de sécurité, écrites dans les journaux OCSF ou téléversées :

• Les jetons d'un format connu (Anthropic, OpenAI, GitHub, GitLab, Slack, AWS, Google, Hugging Face, npm, PyPI, DigitalOcean, xAI, Groq, JWT…) deviennent leur étiquette d'empreinte, comme [GitHub token #3f9a1c2e] — la même étiquette partout, pour que vous puissiez toujours savoir quelle clé a été utilisée.
• Tout autre secret devient *** : mots de passe dans les URL (https://user:***@host), curl -u user:*** (y compris les formes collées et groupées comme -fsSLu), cookies de curl (-b, --cookie, chaque paire), phrases de passe de certificat (-E cert:***), valeurs des en-têtes Authorization, de clé d'API, de jeton et Cookie, options du genre --password / --token / --api-key, et paires KEY=value dont le nom de clé désigne un mot de passe, un secret, un jeton ou une clé.
• Les valeurs entre guillemets sont masquées en entier, espaces comprises.
• Ce qui ne fait que ressembler à un secret est conservé : rsync -u, git checkout -b, PWD et les autres chemins.

Le tap d'événements en temps réel

Pour les sessions WebSocket de longue durée, attendre la fermeture du socket pour extraire les événements aveuglerait un administrateur pendant toute la session. À la place, un tap d'événements en temps réel surveille les trames du serveur et émet les mêmes événements llm.request / tool.use / file.read / file.write / command.run à chaque response.completed, de sorte qu'une session Realtime en cours rend compte au fil de l'eau (l'extraction au moment de la fermeture est alors ignorée pour éviter le double comptage). Le tap ne s'attache que lorsque le niveau de trace de l'espace de travail capture déjà les corps pour cet hôte — il chevauche le même chemin de capture de corps que tout le reste de ce chapitre, et n'a pas d'interface propre.

Mode privé

Le mode privé est un interrupteur par espace de travail sur le volet Traçage, affiché uniquement sur les Mac inscrits. Lorsqu'il est activé, cette machine cesse de diffuser les métadonnées de session et les événements ci-dessus vers l'espace de travail bromure.io — ni le point rouge de diffusion dans la barre d'outils (« Session metadata is being sent to bromure.io ») ni la liste de sessions de l'administrateur n'en voient quoi que ce soit. Le traçage local et l'Inspecteur de traces ne sont pas affectés : vous conservez la trace chiffrée complète sur votre propre machine.

Il existe précisément pour le cas où l'audit local et la télémétrie organisationnelle devraient diverger — par exemple, une machine où vous utilisez une clé API personnelle et ne voulez pas que cette activité figure dans les tableaux de bord de votre organisation. Sur un Mac non inscrit, rien n'est diffusé, donc l'interrupteur est entièrement masqué.

Remarque : le mode privé supprime aussi les événements prompt_injection.detection, de sorte que sur une machine privée une injection est toujours enregistrée localement dans la Chronologie de sécurité (et appliquée selon votre action de détection) mais n'est pas transmise à votre organisation. Voir Réglages de traçage pour l'interrupteur lui-même et Entreprise pour ce que diffuse l'inscription.