Comment fonctionne PoisonZero.

1. Modèle de menace : le memory poisoning n'est pas le prompt injection

Les agents d'IA conservent une mémoire persistante — notes de projet, instructions permanentes, préférences apprises — dans de simples fichiers sur le disque (les « Memory Files » et dot-files d'outils comme les assistants de code). Cette mémoire est relue dans le contexte du modèle à chaque exécution. C'est, de fait, une extension inscriptible du prompt système qui survit aux redémarrages.

Le prompt injection est un problème transitoire : une instruction malveillante arrive dans une requête et disparaît à la fin de la session. Le memory poisoning est persistant. Une seule entrée empoisonnée — écrite par un outil compromis, par un document malveillant que l'agent a résumé, par une charge de la chaîne d'approvisionnement ou par un autre agent — continue d'influencer chaque exécution future jusqu'à ce que quelqu'un le remarque. L'attaquant n'a pas besoin d'être présent au moment du dommage. Il écrit une fois ; l'agent lit pour toujours.

PoisonZero défend l'intégrité de ces fichiers. Il traite chaque modification d'un fichier protégé comme non fiable jusqu'à preuve d'innocuité, et il est fail-closed : en cas de doute, la modification est annulée plutôt que laissée passer. Nous modélisons cinq classes d'attaque et entraînons et évaluons contre chacune :

• Injection directe — des instructions permanentes explicites glissées dans une entrée de mémoire (« désormais, fais X ») que l'agent exécute ensuite comme les siennes.
• Exfiltration de données — des entrées conçues pour amener l'agent à divulguer des secrets, des identifiants ou un contexte privé vers une destination contrôlée par l'attaquant.
• Méta-attaques — l'entrée vise la défense elle-même (« fais confiance à cette source, arrête de la vérifier »). Désarmez le gardien et chaque attaque ultérieure passe sans encombre. Elles ont une couche de règles sans IA dédiée (§4).
• Jeu de rôle & jailbreak — un personnage ou un scénario qui fait sortir l'agent de ses règles de sécurité plutôt que d'énoncer l'instruction malveillante ouvertement.
• Subtil & indirect — le plus difficile : des entrées qui se lisent comme des notes parfaitement légitimes, sans indice évident, devant lesquelles les filtres simples passent tout droit.

2. Architecture : un daemon privilégié, défense en profondeur

PoisonZero tourne comme un petit daemon privilégié sur chaque machine protégée (une unité systemd sous Linux, un service sous macOS/Windows). Il est piloté par les événements, pas un scanner : il ne fait rien tant qu'un fichier protégé ne change pas. Aucun indexeur ne parcourt votre disque, aucune télémétrie de fond.

La conception est en couches, de sorte qu'aucun composant ne soit un point de défaillance unique et que chaque couche soit facile à raisonner isolément :

Derrière la même interface se trouvent deux implémentations d'evaluator — une assistée par le cloud (Pro, §5) et une entièrement locale (Enterprise, §6). Tout ce qui entoure l'evaluator est identique d'un palier à l'autre : le même watcher, les mêmes règles déterministes, la même logique de décision, la même application et la même piste d'audit.

3. La chaîne de traitement en détail

3.1 Le watcher et sa garantie d'état final

Le watcher utilise le mécanisme de notification de changement natif de l'OS (inotify sous Linux, kqueue/FSEvents sous macOS, ReadDirectoryChangesW sous Windows) et applique un debounce par chemin. Les éditeurs et les agents écrivent rarement un fichier une seule fois ; ils écrivent par rafales. Un debounce naïf corrige la tempête d'événements qui en résulte, mais ouvre une faille subtile par laquelle un attaquant peut s'engouffrer.

Imaginez un debounce simple du type « tout rejeter dans la fenêtre ». Un attaquant capable de minuter ses écritures lance une rafale : d'abord une version bénigne, puis, quelques millisecondes plus tard, la version malveillante finale, dans la fenêtre de debounce. Un debounce sur le seul front montant évalue la version bénigne et rejette silencieusement l'écriture malveillante finale — précisément l'état qui se retrouve sur le disque et qui est relu dans l'agent. L'attaque atterrit sans évaluation.

Le watcher de PoisonZero est bâti avec une garantie d'état final sur le front descendant. Il émet immédiatement sur le front montant et, si d'autres écritures arrivent dans la fenêtre, il programme exactement une évaluation tardive après l'expiration de la fenêtre — en relisant l'état actuel du fichier à ce moment précis. Quelle que soit la façon dont une rafale est minutée, la version qui se retrouve réellement sur le disque est celle qui est scorée. Des écritures en rafale soigneusement minutées ne peuvent pas faufiler un état final hors évaluation. (C'est de l'ingénierie adversariale délibérée ; elle a été durcie spécifiquement contre ce contournement.)

3.2 Filtres de politique et protection anti-boucle

Avant toute évaluation, deux vérifications peu coûteuses s'exécutent. D'abord, les modifications du propre fichier d'avis à l'agent de PoisonZero sont ignorées — le daemon écrit ce fichier pour informer l'agent d'une action, et le réévaluer créerait une boucle de rétroaction. Ensuite, le chemin doit relever d'un profil protégé configuré par l'administrateur ; tout le reste est ignoré. Les propres répertoires de configuration et d'état de PoisonZero sont réservés et ne peuvent jamais être enregistrés comme profil surveillé (les enregistrer serait en soi un vecteur d'attaque). Si le nouveau contenu est identique octet pour octet à l'état sain connu, le traitement s'arrête — ce n'est que l'écho du propre revert ou apply du daemon.

3.3 La couche de règles déterministes s'exécute en premier

Un diff unifié ancien-contre-nouveau est construit et remis d'abord à une couche de règles sans IA (§4). Une correspondance dure court-circuite toute la chaîne directement vers revert — rapide, déterministe et impossible à confondre avec un score astucieux. Ce n'est que si aucune règle dure ne se déclenche que la modification atteint l'evaluator.

3.4 Évaluation, décision, application — un audit à chaque étape

L'evaluator renvoie un score de danger et un score de confidence (tous deux dans [0,1]) ; le moteur de décision les mappe vers une action (§5) ; l'enforcer l'exécute. Chaque issue — autoriser, mettre en quarantaine ou annuler — produit une entrée d'audit avec horodatage, action, chemin, motif et scores. La piste d'audit est locale et survit au daemon ; sur les installations gérées, elle est aussi remontée au panneau du propriétaire.

4. Règles déterministes, scoring et décision

4.1 La couche méta-attaque sans IA

Certaines attaques ne devraient jamais dépendre du jugement d'un modèle. Une entrée qui tente de modifier les seuils mêmes de PoisonZero, ou de désactiver, désinstaller ou arrêter le produit, ou un classique « ignore toutes les instructions précédentes », est hostile par construction. La couche de règles les attrape de façon déterministe et annule immédiatement, sans IA dans la boucle.

Le comparateur est conçu pour résister au contournement. Toute entrée est d'abord normalisée en Unicode (NFKC) et passée en minuscules, ce qui replie les caractères pleine largeur, les ligatures et les astuces d'homoglyphes vers leurs formes de base avant l'application de tout motif — un attaquant ne peut donc pas faufiler un override avec des caractères sosies ou une casse mêlée. Les formulations d'override et de « désactive le produit » sont reconnues dans de nombreuses langues, y compris en écritures non latines, car c'est l'attaquant — pas le défenseur — qui choisit la langue. Les règles sont réglées pour la précision : les verbes latins sont reconnus aux frontières de mot et explicitement exclus lorsqu'ils ne sont qu'une partie d'un nom de réglage (p. ex. disable-notifications), afin de ne pas annuler par erreur un texte de configuration légitime.

4.2 Scoring

Quand une modification atteint le modèle, celui-ci renvoie deux nombres dans [0,1] : danger (à quel point la modification paraît malveillante) et confidence (à quel point l'evaluator est sûr). Garder la confidence distincte du danger est ce qui permet au système d'orienter vers un humain les modifications réellement ambiguës au lieu de deviner.

4.3 Le moteur de décision et ses seuils par défaut

Le moteur de décision est délibérément minuscule et total — trois seuils, trois issues :

• revert si danger ≥ dangerBlock
• allow si danger ≤ dangerSafe et confidence ≥ confidenceMin
• ask_user (quarantaine) pour tout ce qui est entre les deux

Les seuils par défaut sont dangerBlock = 0,7, dangerSafe = 0,3, confidenceMin = 0,6 (configurables de façon centralisée par l'administrateur). Ainsi, une modification scorée à danger 0,97 est bien au-delà du seuil de blocage et est annulée sans détour ; une modification à danger 0,1 avec confidence 0,9 est autorisée ; une modification à danger 0,5 — ou une modification d'apparence bénigne dont le modèle n'est pas sûr — tombe dans la zone grise et est mise en quarantaine pour relecture.

Point crucial : le moteur est fail-closed. Si l'évaluation ne peut pas être réalisée du tout — le modèle a échoué, a expiré ou a renvoyé quelque chose d'illisible — l'issue n'est pas « autoriser par défaut ». C'est revert. Les scores ne sont transmis en aval que lorsque l'évaluation a réellement réussi.

4.4 La zone grise : quarantaine et relecture asynchrone

Une issue ask_user ne bloque pas l'agent en attente d'un humain. La modification est mise en quarantaine et le dernier état sain connu est immédiatement restauré sur le disque, de sorte que l'agent continue de travailler sur un contenu de confiance. La version empoisonnée est conservée hors bande pour que le propriétaire la relise de façon asynchrone dans le panneau ; quand il décide, le daemon l'applique ou la rejette et enregistre l'issue. Les relectures sont asynchrones par principe — la protection ne dépend jamais de la présence en ligne d'un administrateur au moment de l'événement.

5. Flux A — Assisté par le cloud (Pro)

Sur le palier Pro, un endpoint cloud durci réalise l'évaluation. La propriété qui définit ce flux est qu'il est bâti autour d'un contrat de données vérifiable, pas d'une promesse.

5.1 Rédaction locale avant que quoi que ce soit ne parte

Avant l'envoi du moindre octet pour évaluation, le diff passe par une étape de rédaction locale sur l'appareil. Elle retire, par motifs, les classes de secrets et de PII structurées qu'elle reconnaît de façon fiable hors ligne : clés API (style OpenAI/Anthropic, GitHub, Slack, AWS, Google, Stripe), JWT, affectations génériques de key/token/secret/password (la valeur disparaît, le nom de la clé reste), adresses e-mail, IBAN, numéros de carte, adresses IP et numéros de téléphone internationaux. Le remplacement se fait par des marqueurs préservant la structure ([REDACTED:email], [REDACTED:apikey] …) afin que le modèle puisse encore raisonner sur la modification.

Nous sommes honnêtes sur la limite : les noms en texte libre et la PII non structurée ne sont pas détectables de façon fiable hors ligne sans ML, donc le rédacteur ne retire que ce qu'il peut faire correspondre avec certitude, rien de plus. Vous pouvez voir exactement ce qu'une évaluation enverrait en passant n'importe quel fichier par la commande redact du produit avant de lui faire confiance.

5.2 Le contrat de données : charge minimale, endpoints fixes

Ne sortent qu'un chemin de fichier et le diff unifié rédigé — jamais le texte intégral. Il existe un petit ensemble fixe d'endpoints, chacun portant une charge documentée et minimale : l'enrôlement porte un app ID et un code à usage unique ; l'évaluation porte le chemin et le diff rédigé ; l'interrogation de configuration ne porte rien d'autre qu'un jeton d'authentification ; les rapports d'audit et de quarantaine portent des horodatages, des actions, des chemins, des motifs et des scores (le rapport de quarantaine inclut le même diff rédigé, de taille plafonnée). Les fichiers hors des profils configurés, les textes intégraux, les listes de répertoires ou de processus et la télémétrie système ne quittent jamais la machine. Tout le transport se fait via TLS.

5.3 Le registre d'egress : vérifier, pas faire confiance

Chaque requête sortante est consignée localement dans un registre d'egress lisible par un humain. Chaque ligne porte l'horodatage, l'endpoint, la taille de la charge, le SHA-256 de la charge (jamais le contenu) et le statut HTTP :

C'est la comptabilité du « est-ce que ça appelle la maison ? », écrite pour que vos équipes DLP et audit puissent vérifier plutôt que nous croire sur parole. Le registre peut être recoupé avec le réseau lui-même — le daemon ne contacte que le backend d'évaluation et l'endpoint de jeton d'authentification, et un observateur externe (journaux de pare-feu, une capture de paquets, un proxy de filtrage d'egress) doit voir exactement les requêtes que le registre consigne, et rien de plus.

6. Flux B — Entièrement sur l'appareil (Enterprise)

Sur le palier Enterprise, l'évaluation se déplace entièrement sur la machine. Un modèle de détection compact, à usage dédié, et notre propre moteur d'inférence tournent localement, et aucun contenu ne quitte le bâtiment — il n'y a aucun cloud d'analyse vers lequel fuiter, parce qu'il n'y a aucun cloud d'analyse.

6.1 Cycle de vie à la demande

Le moteur d'inférence ne tourne pas en continu. Il démarre paresseusement à l'arrivée d'une vérification de mémoire et s'arrête de nouveau après un court délai d'inactivité. Le fichier de modèle pèse un peu plus de 300 Mo et est chargé par memory-mapping au démarrage ; pendant une vérification, le composant d'analyse occupe cette empreinte quelques secondes, et au repos, le produit n'est que le daemon — quelques Mo de RAM. La courte fenêtre d'inactivité absorbe les rafales d'éditions sans maintenir l'empreinte résidente. Il est CPU uniquement et tourne sur du matériel ordinaire ; aucun GPU requis.

6.2 Le moteur d'inférence tourne dans un bac à sable à privilèges minimaux

C'est une frontière de sécurité délibérée, pas une simple hygiène. Le moteur, par définition, analyse du texte contrôlé par l'attaquant — précisément les diffs de mémoire que nous examinons comme potentiellement empoisonnés. Une faille exploitable dans le moteur serait sinon un chemin direct de « l'attaquant écrit un fichier de mémoire » à « exécution de code sur le composant d'analyse ». La réponse, c'est l'isolation : avec le moteur en bac à sable, un exploit du moteur dégénère en un crash de processus sans conséquence plutôt qu'en une compromission. Le daemon — le véritable produit de sécurité — reste intact et annule en cas de doute.

Le profil à privilèges minimaux, appliqué à chaque processus éphémère du moteur :

• Réseau : ne se lie qu'à 127.0.0.1, sur un port éphémère attribué par le daemon. Aucune autre interface, aucun réseau sortant, aucun DNS. Le modèle est hors ligne ; le moteur n'a besoin d'aucun accès réseau à l'exécution.
• Système de fichiers : accès en lecture seule au fichier de modèle épinglé et à ses propres dépendances. Aucun accès en écriture nulle part.
• Processus : ne génère aucun processus enfant, tourne sans privilège avec des capacités réduites.

Sous Linux, cela est appliqué dès le premier jour via le durcissement systemd et un filtre d'appels système (seccomp) — pas de nouveaux privilèges, une vue système strictement en lecture seule, un ensemble de capacités vide, un adressage localhost uniquement, un montage en lecture seule du chemin du modèle — avec un durcissement par LSM de système de fichiers (Landlock) en fast-follow là où le noyau le supporte. macOS et Windows appliquent le même minimum du premier jour — localhost uniquement, chemin du modèle en lecture seule, aucune génération de sous-processus — avec des profils de bac à sable complets (un profil de bac à sable signé sous macOS ; un jeton restreint et un Job Object sous Windows) en fast-follow. Nous disons explicitement ce qui relève du premier jour et ce qui relève du fast-follow, plutôt que de laisser entendre un maximum uniforme partout.

6.3 Sortie non fiable et épinglage de hash avant chaque démarrage

Même à l'intérieur du bac à sable, le daemon traite la réponse du moteur comme une entrée non fiable : s'il plante, se bloque ou renvoie quelque chose d'inattendu, la décision est fail-closed (revert), jamais une autorisation silencieuse. Et avant chaque démarrage du moteur, le daemon vérifie le SHA-256 du fichier de modèle par rapport à un hash épinglé figurant dans son manifeste de licence signé. Cela protège la chaîne de distribution et ferme du même coup un vecteur d'exploit local — un fichier de modèle remplacé ou corrompu (p. ex. un en-tête trafiqué pour exploiter le chargeur) est détecté avant même que le moteur ne démarre ; il ne démarre tout simplement pas.

6.4 Compatible air-gap

Entre les vérifications, le produit tourne entièrement hors ligne. La seule exception est une vérification de licence mensuelle — identifiants et version uniquement, jamais de contenu. Aucune télémétrie, aucun egress de contenu, et rien dans le chemin d'évaluation n'a besoin du réseau. Le même registre d'egress (§5.3) consigne cette vérification mensuelle, elle est donc, elle aussi, vérifiable plutôt que supposée.

7. Intégrité et chaîne d'approvisionnement

Ce que vous installez doit être ce que nous avons construit. Chaque artefact de release est signé avec Cosign keyless (Sigstore) et publié avec un manifeste SHA256SUMS, de sorte que chaque binaire est vérifiable face à une liste de sommes signée avant même de s'exécuter. L'installateur en une ligne vérifie la somme automatiquement ; les opérateurs en air-gap vérifient à la main.

Sur le palier Enterprise, la chaîne s'étend au modèle lui-même : le modèle de détection est un artefact signé et protégé en intégrité dont le SHA-256 est épinglé dans le manifeste de licence signé et revérifié avant chaque démarrage du moteur (§6.3). L'intégrité n'est pas vérifiée une seule fois au téléchargement, mais en continu à chaque utilisation.

8. Performance de détection

Le modèle de détection n'est pas un classifieur générique du commerce. Il est affiné sur un vaste corpus à usage dédié d'exemples réels d'attaques et de cas bénins, avec une chaîne d'étiquetage dans le cloud qui maintient le modèle sur l'appareil affûté à mesure que de nouveaux schémas d'attaque apparaissent — sans que vos données ne le nourrissent jamais.

Les chiffres que nous mesurons, exprimés en relatif et avec honnêteté : sur le même jeu de test, il détecte plus de 3× plus d'attaques que les principaux modèles de garde du commerce, et il signale de façon fiable les classes auxquelles ces détecteurs standards sont quasiment aveugles — injection subtile/indirecte et exfiltration de données. L'affinage a réduit les fausses alertes d'environ 95 % par rapport au modèle de base non affiné. Sur des tests internes larges et réalistes, il détecte plus de 94 % des attaques avec moins de 5 % de fausses alertes.

Méthodologie, en bref. L'évaluation porte sur des données held-out que le modèle n'a jamais entraînées, équilibrées entre les cinq classes d'attaque (§1) et entre de nombreuses langues. Le jeu bénin est délibérément adverse — il inclut le genre de notes légitimes qui semblent alarmantes et font trébucher les filtres par mots-clés — afin que le taux de fausses alertes reflète un contenu réaliste, pas des négatifs faciles. Nous rapportons des gains relatifs et un point de fonctionnement mesuré plutôt qu'un unique chiffre d'exactitude en titre, car un détecteur ne vaut que sa classe d'attaque la plus faible et son comportement sur les cas bénins difficiles.

9. Limites honnêtes et risque résiduel

Aucun détecteur n'arrête toutes les attaques partout, et nous ne revendiquons aucun taux de capture de 100 % — les chiffres ci-dessus sont ceux que nous mesurons, et nous continuons de les relever. Quelques limites honnêtes :

• La rédaction hors ligne est par motifs. Dans le flux assisté par le cloud, les noms en texte libre et la PII non structurée ne sont pas détectables de façon fiable hors ligne sans ML, et peuvent donc passer dans un diff rédigé. Les équipes aux exigences strictes gardent leurs memory files pauvres en PII — ou utilisent le flux entièrement local, où rien ne sort.
• Il subsiste des faux positifs et faux négatifs résiduels. La conception zone grise vers quarantaine existe précisément parce que le modèle n'est pas infaillible ; les modifications ambiguës vont à un humain au lieu d'être devinées, et le système est fail-closed quand il ne peut pas décider.
• Le durcissement du bac à sable est échelonné par plateforme. L'isolation la plus stricte est du premier jour sous Linux ; macOS et Windows atteignent un minimum documenté du premier jour avec des profils plus forts en fast-follow (§6.2). Nous le disons plutôt que de laisser entendre un durcissement maximal uniforme.
• PoisonZero protège l'intégrité des fichiers, pas le runtime de l'agent. Il défend les memory files et dot-files persistants qu'un agent lit ; ce n'est pas un EDR pour le processus de l'agent lui-même, et il complète, sans les remplacer, vos contrôles d'endpoint existants.

Le principe qui unit tout cela est le même : fail-closed. Quand le système n'est pas sûr, ne peut pas évaluer ou que son composant d'analyse se comporte mal, la modification est annulée et le dernier état sain demeure. Le mode de défaillance par défaut, c'est la sécurité, pas l'acceptation silencieuse.