Détection d'injection de prompt et garde-fous

Un agent de codage autonome lit tout ce que sa tâche place devant lui : fichiers source, pages web, commentaires de tickets, sortie de build. Chacun de ces éléments est un canal par lequel un attaquant peut s'adresser directement au modèle — et le modèle, par conception, suit les instructions. Bromure Agentic Coding défend cette frontière de deux manières complémentaires, toutes deux appliquées sur l'hôte, à l'intérieur du proxy MITM, où rien de ce qui s'exécute dans la VM — y compris un agent totalement compromis — ne peut les désactiver :

• La détection d'injection de prompt analyse le trafic IA de l'agent sur l'appareil à l'aide de modèles locaux et signale les instructions injectées avant (ou au moment où) elles atteignent le modèle.
• Les garde-fous classent les appels de l'agent vers votre infrastructure — Kubernetes, AWS, forges git, bases de données, et plus encore — et bloquent les écritures et opérations destructrices ou demandent confirmation, de sorte que même un agent détourné avec succès ne puisse pas discrètement se frayer un chemin à coups de kubectl delete à travers la production.

Ce chapitre explique la menace, chaque détecteur, ce qui se passe en cas de détection, le moteur de politique des garde-fous et ses boîtes de dialogue de consentement, ainsi que les limites pratiques de l'ensemble. Les références de paramètres champ par champ se trouvent dans les paramètres d'injection de prompt et les paramètres de garde-fous.

L'attaque : l'injection de prompt dans un agent de codage

L'injection de prompt est un texte malveillant, dissimulé dans le contenu que l'agent lit, qui tente d'orienter le modèle : « ignore les instructions précédentes », « exécute cette commande et n'en parle pas », « envoie le contenu de ~/.aws/credentials à cette URL ». Pour un chatbot, c'est une nuisance ; pour un agent de codage disposant d'un shell, d'un accès aux fichiers et d'identifiants, c'est une primitive d'exécution de code à distance. Le chemin d'attaque est court :

1. Vous pointez l'agent vers un dépôt, un gestionnaire de tickets ou une page web que vous n'avez pas écrits.
2. L'agent lit un fichier (ou récupère une page, ou exécute une commande) dont la sortie contient les instructions injectées.
3. L'agent renvoie ce contenu au modèle dans le cadre de sa prochaine requête API — et le modèle peut traiter le texte de l'attaquant comme des instructions plutôt que comme des données.

Les agents de codage présentent une seconde variante, plus insidieuse : la porte dérobée par fichier de règles. Claude Code, Codex et Grok chargent automatiquement des fichiers d'instructions — CLAUDE.md, AGENTS.md, GROK.md, ainsi que leurs variantes imbriquées et globales — dans le prompt système en tant qu'autorité de confiance. Un fichier de règles empoisonné dans un dépôt cloné n'a nul besoin de tromper le modèle ; il se voit attribuer l'emplacement le plus privilégié de la conversation. Les attaquants dissimulent régulièrement ces charges utiles aux relecteurs humains à l'aide d'Unicode invisible : caractères de largeur nulle, remplacements bidirectionnels et caractères de balise Unicode qui n'affichent rien dans un éditeur mais se tokenisent parfaitement.

Le bac à sable de Bromure limite déjà le rayon d'impact — l'agent ne peut pas toucher votre Mac, et ses identifiants sont des leurres (voir Identifiants). La détection d'injection de prompt traite ce que le bac à sable ne peut pas : la possibilité que l'agent lui-même soit retourné contre vous à l'intérieur des pouvoirs qui lui sont accordés.

Ce que Bromure analyse

La détection s'exécute dans le proxy côté hôte, sur le trafic IA sortant de l'agent — les requêtes que l'agent envoie à Anthropic, OpenAI ou tout autre hôte de modèle. Comme le proxy voit la requête complète, il peut inspecter exactement ce que le modèle est sur le point de recevoir, quel que soit l'agent qui l'a produite. Deux surfaces distinctes sont analysées, chacune par son propre détecteur :

Tout se passe sur l'appareil. Les classificateurs sont des modèles ONNX locaux s'exécutant via ONNX Runtime sur votre Mac ; aucun contenu n'est envoyé à un service cloud pour analyse, et sur les installations non gérées aucune donnée de détection ne quitte la machine (les installations gérées peuvent transmettre les détections à leur organisation — voir la remarque dans Quand un détecteur se déclenche).

Les deux détecteurs sont des interrupteurs par espace de travail dans le volet Injection de prompt de la fenêtre Modifier l'espace de travail (l'icône rouge de triangle d'avertissement dans la barre latérale). Les deux sont désactivés par défaut — chacun nécessite un téléchargement de modèle conséquent la première fois que vous l'activez.

Les détecteurs

Détecteur de code source (PromptGuard)

Détecter les injections de prompt dans le code source évalue le contenu tool_result que l'agent ingère — contenu de fichiers, pages web, corps de tickets et de PR, sortie de commandes — avec un modèle local de classification de séquences PromptGuard (famille DeBERTa, ONNX). Il est conçu pour attraper le cas classique : un texte « ignore les instructions précédentes / exfiltre les secrets » planté dans un dépôt malveillant, attendant qu'un agent le lise.

Comment fonctionne une analyse :

• Seul le message le plus récent portant des tool_results est analysé à chaque tour. Les agents renvoient l'intégralité de l'historique de la conversation à chaque requête ; réanalyser cet historique multiplierait le coût sans aucun bénéfice, l'historique déjà vu est donc ignoré.
• Par span, jusqu'à 16 Ko de contenu sont analysés, en 8 fenêtres au maximum de 1 536 caractères chacune. La probabilité d'injection maximale parmi les fenêtres est le score du span ; le span est signalé lorsque le score atteint le seuil (0,5 par défaut).
• Les verdicts sont mis en cache par blob de contenu (512 entrées), de sorte qu'un fichier que l'agent relit — ou un span identique renvoyé dans l'historique — ne coûte rien la seconde fois.

Les paramètres de fonctionnement du modèle (longueur de séquence maximale 512 jetons, index de l'étiquette d'injection 1, seuil 0,5) peuvent être remplacés en plaçant un fichier facultatif bromure-injection.json dans le dossier du modèle — voir Téléchargement et stockage des modèles.

Détecteur de fichiers de règles (analyseur heuristique + ModernBERT)

Détecter les instructions malveillantes dans les fichiers CLAUDE.md et similaires cible la porte dérobée par fichier de règles. Il extrait les fichiers d'instructions du prompt système — en reconnaissant les enveloppes Contents of <path> (… instructions …): de Claude Code ainsi que les noms de fichiers de règles bien connus — et effectue deux passes sur eux :

1. Un analyseur heuristique déterministe (sans dépendances — il fonctionne même avant tout téléchargement de modèle, bien que l'interrupteur régisse les deux passes ensemble). Il signale :
   • Les signaux Unicode masqués n'importe où dans le prompt système : caractères de balise Unicode (U+E0000–E007F), remplacements bidirectionnels et caractères de largeur nulle ou de trait d'union conditionnel. Tous sont de gravité élevée — il n'existe pour ainsi dire aucune raison légitime à leur présence dans un fichier d'instructions.
   • Les motifs de méta-instructions dans les spans de fichiers d'instructions extraits : « ignore les instructions précédentes », « ne dis pas à l'utilisateur », « tu es désormais … », « nouvelles instructions : » — gravité élevée.
   • Les mots-clés de capacité et d'exfiltration : chemins de fichiers d'identifiants (tels que ~/.ssh ou .aws/credentials), références .env, constructions curl-pipe-vers-shell, base64-plus-pipe, rm -rf, poussées forcées, motifs d'envoi vers une URL — gravité moyenne, journalisés uniquement comme constats « à examiner ».
2. Un classificateur ONNX ModernBERT affiné (claudemd-guard) effectue une passe sémantique sur les mêmes corps de fichiers d'instructions, attrapant les instructions malveillantes qui ne correspondent à aucun motif fixe.

Les constats sont dédupliqués par session grâce à un hachage du contenu, de sorte qu'un CLAUDE.md inchangé est journalisé une seule fois — et non une fois par tour pendant toute la durée de la session.

Remarque : Dans les modes d'application Demander et Bloquer, seuls les constats heuristiques de gravité élevée (ou un verdict du modèle) déclenchent la pause ou le blocage. Les constats « à examiner » de gravité moyenne sont uniquement journalisés, et ils ne sont jamais transmis à bromure.io, même sur les installations gérées.

Téléchargement et stockage des modèles

Les modèles de détecteur ne sont jamais fournis avec l'application — ce sont des téléchargements de plusieurs centaines de mégaoctets, récupérés par détecteur depuis https://dl.bromure.io/llms/<model-dir>/<file> la première fois que vous activez l'interrupteur :

Le déroulement du téléchargement :

1. Activez l'interrupteur d'un détecteur. Une alerte de confirmation — Télécharger le modèle de détecteur <detector> ? — indique la taille : « Ceci télécharge environ <size> depuis bromure.io et utilise à peu près autant d'espace disque. Le détecteur commence à fonctionner une fois le téléchargement terminé. »
2. Cliquez sur Télécharger. Une fenêtre de progression Téléchargement du modèle affiche un pourcentage et un bouton Annuler.
3. Annuler en cours de téléchargement — ou refuser l'alerte, ou un téléchargement échoué — rétablit l'interrupteur. Un détecteur sans son modèle est une opération silencieuse sans effet, et Bromure ne prétendra pas le contraire.

Plusieurs garde-fous rendent le téléchargement robuste :

• Vérification préalable de l'espace disque libre. Un téléchargement voué à l'échec est refusé d'emblée par une alerte critique : Espace disque insuffisant pour télécharger le modèle d'injection de prompt.
• Seuils de taille minimale. Chaque fichier a un seuil de taille, de sorte qu'un téléchargement tronqué ou une page d'erreur HTML enregistrée comme model.onnx échoue bruyamment plutôt que de désactiver silencieusement le détecteur.
• Atomique et reprenable. Les téléchargements sont atomiques par fichier, et une nouvelle tentative ignore les fichiers déjà présents et valides. Les téléchargements simultanés du même modèle sont dédupliqués.
• Récupération automatique. Si un espace de travail a un détecteur activé mais que son modèle est manquant au lancement de l'application ou après l'enregistrement d'un profil, un téléchargement en arrière-plan démarre automatiquement. La progression et le résultat apparaissent dans le journal de sécurité.

Pour supprimer un modèle, supprimez son dossier sous ~/Library/Application Support/BromureAC/Models/. Un fichier facultatif bromure-injection.json placé dans un dossier de modèle remplace maxLength, injectionLabelIndex et threshold pour ce détecteur.

Remarque : Les légendes du volet citent des chiffres arrondis légèrement inférieurs (~272 Mo et ~571 Mo) ; la boîte de dialogue de confirmation calcule sa taille (~298 Mo et ~603 Mo) à partir des totaux réels en octets. Fiez-vous à la boîte de dialogue.

Quand un détecteur se déclenche : Journaliser, Demander ou Bloquer

Une même réponse partagée par espace de travail — le groupe de boutons radio Lorsqu'une injection est détectée du volet Injection de prompt — s'applique aux deux détecteurs. Le groupe est désactivé tant qu'au moins un détecteur n'est pas activé.

La boîte de dialogue Demander

En mode Me demander quoi faire, une boîte de dialogue critique intitulée Possible <detector> in "<workspace>" présente le texte signalé dans une zone de texte à chasse fixe défilante, avec le corps : « Bromure a signalé du contenu que l'agent est sur le point d'envoyer au modèle (depuis <source>). Examinez-le ci-dessous — laissez-le passer, ou bloquez cette requête ? » Les boutons sont Bloquer cette requête et Autoriser cette requête.

Votre décision est mémorisée par espace de travail, source et contenu pour le reste de l'exécution de l'application, de sorte que le même texte signalé ne fait pas l'objet d'une nouvelle demande à chaque tour — les agents renvoient constamment l'historique, et sans cette mémoire un seul fichier signalé interromprait chaque requête ultérieure. La mémoire est uniquement en mémoire vive ; elle ne survit pas à un redémarrage de l'application.

Lorsque l'espace de travail est piloté sans interface via SSH ou la CLI, la même question est rendue sous forme d'invite textuelle dans le tmux de l'espace de travail. Seul un Autoriser cette requête explicite la laisse passer — l'absence de réponse signifie blocage. Voir Accès à distance.

Ce que voit l'agent lorsqu'une requête est bloquée

En mode Bloquer unilatéralement — ou lorsque vous répondez à une boîte de dialogue Demander par Bloquer cette requête — l'agent reçoit un HTTP 451 Unavailable For Legal Reasons avec le corps :

Bromure blocked this request: possible <detector> detected in <source>.

Le modèle ne reçoit jamais le contenu empoisonné ; l'agent voit un échec propre et explicable qu'il peut vous signaler. Le résultat résolu (« autorisé » ou « bloqué ») est enregistré dans le journal de sécurité et, sur les installations gérées, transmis en tant qu'événement cloud.

Remarque : Sur les Mac inscrits à bromure.io, chaque détection est transmise en tant qu'événement prompt_injection.detection portant le détecteur, la méthode, l'action, l'hôte, la source, le score, les signaux heuristiques et — contrairement à l'aperçu de 160 caractères du journal local — l'intégralité de l'extrait signalé, plafonné à 20 Ko. Ces événements sont supprimés par l'interrupteur Mode privé de l'espace de travail et ne sont jamais envoyés sur les installations non gérées. Voir Traçage et audit et Entreprise.

Surveiller les détections : le journal de sécurité

Les détections, les constats de fichiers de règles, la progression des téléchargements de modèles et les résultats d'application apparaissent tous dans la fenêtre journal de sécurité — ouvrez Fenêtre → Journal de sécurité…. Les lignes d'injection ressemblent à :

[prompt-injection] source FLAG score=0.973 toolUse=… preview="…"
[prompt-injection] rules FLAG source=/path/CLAUDE.md signals=[zero_width(high)]
[prompt-injection] blocked: rogue instructions in /path/CLAUDE.md → api.anthropic.com

La première forme est le détecteur de code source (avec le score du modèle et un court aperçu) ; la deuxième est le détecteur de fichiers de règles (avec le chemin du fichier et les signaux heuristiques déclenchés, chacun étiqueté de sa gravité) ; la troisième enregistre un résultat d'application. Les lignes du journal local ne portent qu'un aperçu de 160 caractères du contenu signalé — le texte complet n'apparaît que dans la boîte de dialogue Demander (et, sur les installations gérées, dans l'événement cloud).

La fenêtre elle-même — un anneau en mémoire des quelque 5 000 dernières lignes, dupliqué vers stderr, avec filtrage et défilement automatique — est décrite en détail dans Protection de la chaîne d'approvisionnement, qui la partage.

Garde-fous

La détection d'injection de prompt tente d'attraper le détournement ; les garde-fous limitent ce qu'un agent détourné (ou simplement trop zélé) peut faire. C'est un moteur de politique par espace de travail, appliqué sur l'hôte, qui classe chaque appel API que l'agent effectue vers un protocole protégé comme une opération de lecture, d'écriture ou destructrice, et applique le mode de l'espace de travail pour cette ressource. Comme l'indique le volet : les garde-fous retirent les opérations destructrices des protocoles que parle cet agent ; ils sont appliqués sur l'hôte — à l'intérieur du proxy — de sorte qu'un agent malveillant ou compromis dans la VM ne puisse pas les contourner, et les appels bloqués renvoient une erreur ferme que l'agent voit.

Les quatre modes

Chaque ressource protégée dispose de son propre sélecteur de mode :

Les nouveaux espaces de travail utilisent par défaut Demander avant écriture sur chaque ressource. Les espaces de travail créés avant l'existence des garde-fous — ou les profils dont le JSON omet les champs — sont décodés comme Désactivé.

Ressources protégées

Les garde-fous couvrent les protocoles d'infrastructure que les agents de codage parlent le plus couramment. En bref (les règles complètes de classification par protocole — verbes HTTP, préfixes de noms d'actions AWS, analyse des mots-clés SQL — sont recensées dans les paramètres de garde-fous) :

• Kubernetes — les serveurs API issus des kubeconfigs de l'espace de travail. DELETE est destructeur ; GET/HEAD/OPTIONS sont des lectures ; les autres verbes sont des écritures. Un appel bloqué renvoie un Status Kubernetes JSON 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 ou du paramètre de formulaire Action=) est classé par préfixe — Delete*, Terminate*, Remove*, Purge*, Destroy*, Deregister*, Revoke* sont destructeurs ; Get*, List*, Describe* et similaires sont des lectures — avec un repli 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, classés par méthode HTTP.
• Registres Docker — les registres configurés sous Identifiants plus Docker Hub. Le pull est une lecture, le push est une écriture, DELETE est destructeur ; les appels bloqués renvoient un corps DENIED de style registre.
• GitHub / GitLab / Bitbucket — les API REST plus git sur HTTPS. git push (git-receive-pack) compte comme une écriture — bloquée en Lecture seule, soumise à confirmation en Demander avant écriture — tandis que git fetch (git-upload-pack) est toujours une lecture.
• Bases de données HTTPS — une ligne par point de terminaison configuré sous Identifiants : MongoDB Atlas Data API (find/aggregate lecture, insert/update/replace écriture, deleteOne/deleteMany destructeur), ClickHouse (classé selon le mot-clé de tête du SQL) et Elasticsearch (_search et autres points de terminaison de requête sont des lectures même en POST ; DELETE et _delete_by_query sont destructeurs).

Les garde-fous Kubernetes et Docker ne s'appliquent qu'aux hôtes dérivés des kubeconfigs de l'espace de travail et des registres configurés, et les garde-fous de base de données nécessitent que l'hôte du point de terminaison soit défini sous Identifiants — un garde-fou sans rien à cadrer ne filtre rien, et le volet vous en avertit en ligne le cas échéant.

Demander avant écriture : le courtier de consentement

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

Les autorisations sont cadrées par espace de travail et par portée de protocole : un hôte API Kubernetes, AWS dans son ensemble, un registre Docker, chaque forge git dans son ensemble, un hôte de base de données. Autoriser les écritures ClickHouse sur un hôte n'accorde rien ailleurs. Les écritures identiques simultanées se regroupent sur une seule boîte de dialogue plutôt que d'empiler les alertes. Toutes les décisions sont uniquement en mémoire vive — les autorisations cadrées sur la session (comme tout le reste concernant la session) sont effacées au démantèlement.

Sur les espaces de travail pilotés sans interface via SSH/CLI, les mêmes quatre choix sont proposés sous forme d'invite textuelle tmux ; l'absence de réponse signifie refus.

Remarque : Les autorisations d'écriture des garde-fous ne sont répertoriées dans aucune fenêtre. La fenêtre Approbations d'identifiants (Fenêtre → Approbations d'identifiants…) n'affiche que les décisions de consentement aux identifiants ; une autorisation de garde-fou expire selon son propre minuteur ou au démantèlement de la session, et il n'existe actuellement aucune interface pour en révoquer une plus tôt.

Ce que voit l'agent

Les appels bloqués renvoient un corps d'erreur de style 403 adapté au protocole — un Status Kubernetes JSON, un AccessDeniedException AWS, une charge utile DENIED de registre — dont le message se termine par « blocked by Bromure Guardrails ». L'agent obtient un échec API propre et ordinaire qu'il peut signaler et souvent contourner, plutôt qu'une connexion suspendue. Les blocages d'injection de prompt utilisent HTTP 451 et les blocages de chaîne d'approvisionnement utilisent HTTP 451 avec leur propre préfixe de corps, de sorte que les trois systèmes se distinguent d'un coup d'œil dans les journaux et la sortie de l'agent.

Performance et utilisation des ressources

• Le mode Journaliser est gratuit. Sous Journaliser mais continuer, l'analyse s'exécute après que la réponse a déjà été relayée à l'agent — la détection n'ajoute aucune latence à la boucle de l'agent.
• Les modes Demander et Bloquer analysent avant transfert. Le classificateur doit terminer avant que la requête ne soit transférée, de sorte que les tours signalés paient le coût d'inférence en ligne. Les plafonds de fenêtrage (16 Ko, 8 fenêtres par span, message le plus récent uniquement) et le cache de verdicts de 512 entrées maintiennent cela borné.
• Mémoire. Le fournisseur d'exécution CPU d'ONNX Runtime est celui par défaut et utilise environ 2 Go résidents avec les deux modèles chargés. Le fournisseur CoreML / Neural Engine est optionnel via la variable d'environnement BROMURE_INJECTION_COREML=1 — il multiplie la mémoire résidente par environ 5× (environ 9 Go avec les deux modèles) à précision identique, il est donc désactivé par défaut. BROMURE_NO_COREML force la désactivation de CoreML même si l'option est activée, et BROMURE_INJECTION_FIXED_SHAPE=1 complète chaque fenêtre de classification à une forme fixe de 512 jetons (impliqué automatiquement par l'option CoreML, pour éviter la recompilation par forme ; les verdicts sont inchangés).
• Débogage. BROMURE_AC_DEBUG=1 émet des lignes ok/score détaillées par span et des erreurs d'inférence sur stderr pour les classificateurs et l'analyseur de règles.
• Les garde-fous sont négligeables. La classification est une correspondance de chaînes sur des requêtes qui transitent déjà par le proxy ; seule la boîte de dialogue de consentement elle-même introduit une pause, et cette pause est précisément le but recherché.

Ce que la détection ne peut pas attraper

La détection d'injection de prompt est un filtre puissant, pas une garantie. Connaissez ses limites :

• Pas de modèle, pas de détection. Un détecteur est une opération silencieuse sans effet tant que son modèle n'est pas installé. Si l'interrupteur est activé mais que le téléchargement a échoué (disque plein, réseau coupé), l'espace de travail fonctionne sans protection — l'échec est journalisé dans le journal de sécurité, et une condition de disque plein déclenche une alerte modale, mais rien ne bloque l'agent entre-temps.
• Les classificateurs ont un seuil. Une injection suffisamment nouvelle ou subtile peut obtenir un score inférieur à 0,5 et passer. À l'inverse, un texte légitime proche de la sécurité (un README à propos de l'injection de prompt, par exemple) peut obtenir un score supérieur — c'est pourquoi Journaliser mais continuer est le mode par défaut et que Demander existe.
• Les heuristiques de gravité moyenne n'appliquent jamais. Les mots-clés de capacité (rm -rf, chemins d'identifiants, curl-pipe-vers-shell) dans un fichier de règles sont journalisés pour examen mais ne mettent pas en pause ni ne bloquent d'eux-mêmes — ils sont bien trop courants dans la documentation légitime des développeurs.
• Seul le trafic IA est analysé. Les détecteurs surveillent ce que l'agent envoie au modèle. Une instruction que le modèle a déjà intériorisée s'exécute via des appels d'outils ordinaires ; c'est la couche des garde-fous, plus les identifiants leurres et la détection de compromission décrits dans Identifiants.
• Les garde-fous ont des angles morts au niveau du fil. Une poussée forcée git est indiscernable d'une poussée normale sur le fil, de sorte que Bloquer les destructrices ne l'arrête pas — seuls Lecture seule et Demander avant écriture contrôlent les poussées (les suppressions explicites via les API REST de la forge restent attrapées). Pour ClickHouse, une requête sans texte SQL visible est bloquée en Lecture seule (Bromure ne peut pas prouver qu'il s'agit d'une lecture) mais passe en Bloquer les destructrices (il fait le choix permissif).

La défense en profondeur est la posture visée : la détection, les garde-fous, les identifiants leurres, les vérifications de la chaîne d'approvisionnement et la VM jetable couvrent chacun les lacunes des autres.

Configurer les volets

Les deux systèmes se configurent par espace de travail dans la fenêtre Modifier l'espace de travail :

Les références complètes champ par champ sont les paramètres d'injection de prompt et les paramètres de garde-fous. Chaque résultat de détection et d'application est auditable après coup — voir Traçage et audit.