cyber-agent-engine
🇬🇧 English version 💻 Code source (AGPL) : github.com/patlegu/cyber-agent-engine
De « ça marche » à « déployable par un tiers » Les quatre premiers articles de cette série ont décrit des frontières : jetons plutôt que valeurs réelles (article 2), politique fail-closed et approbation humaine (article 3), LLM hors de l’équipement qu’il pilote (article 4). Chacune répond à la question « qu’est-ce que le système a le droit de faire, de voir, ou de laisser fuiter ?
cyber-agent-engine
🇬🇧 English version 💻 Code source (AGPL) : github.com/patlegu/cyber-agent-engine
Une question de topologie, pas seulement de sécurité Les trois premiers articles de cette série ont détaillé comment cyber-agent-engine encadre un LLM qui pilote un pare-feu de production : jetons plutôt que valeurs réelles (article 2), politique fail-closed et approbation humaine (article 3). Celui-ci s’attaque à une question antérieure, presque architecturale avant d’être sécuritaire : où ce LLM doit-il physiquement s’exécuter ?
cyber-agent-engine
🇬🇧 English version 💻 Code source (AGPL) : github.com/patlegu/cyber-agent-engine
L’invariant Le premier article de cette série posait la thèse générale de cyber-agent-engine : un LLM qui pilote un pare-feu de production ne doit jamais franchir seul la frontière entre intention et exécution. Celui-ci descend dans le pilier le plus contre-intuitif de cette architecture, et probablement le plus simple à énoncer : le LLM de raisonnement ne voit jamais une IP réelle, un hostname réel ou un secret réel.
cyber-agent-engine
🇬🇧 English version 💻 Code source (AGPL) : github.com/patlegu/cyber-agent-engine
Le réflexe firewall, appliqué à une décision d’IA Le premier article de cette série posait la thèse générale : un LLM qui pilote un pare-feu de production ne doit jamais franchir seul la frontière entre intention et exécution. Le deuxième montrait comment cette frontière protège les données — le modèle ne voit que des jetons, jamais une IP réelle. Celui-ci s’attaque à l’autre moitié du problème : une fois que le LLM a proposé une action sur des jetons, qui décide si elle a le droit de se produire ?
cyber-agent-engine
🇬🇧 English version 💻 Code source (AGPL) : github.com/patlegu/cyber-agent-engine
Un LLM qui peut bloquer une IP Il y a quelque chose de vertigineux à donner à un modèle de langage la capacité d’appeler block_ip ou add_filter_rule sur un pare-feu de production. On lui tend une phrase — « bloque cette IP qui scanne le LAN » — et quelques centaines de millisecondes plus tard, une règle apparaît dans OPNsense. C’est exactement la promesse du DevSecOps assisté par IA : traduire l’intention en action, sans passer par une console, un ticket ou une CLI.
AnonyNER · N°1
Quand spaCy ne voit pas l’infrastructure : le problème NLP des logs de sécurité Avant d’envoyer des logs à un éditeur de logiciels pour investigation, à un LLM externe pour analyse, ou simplement de les archiver conformément au RGPD, une question s’impose : ces logs contiennent-ils des informations qui exposent mon infrastructure ?
La réponse est presque toujours oui. Et les outils NLP standards — aussi performants soient-ils sur le langage courant — sont largement aveugles aux entités spécifiques au domaine de la sécurité.
AnonyNER · N°4
Recollect & Rank : quand un LLM désanonymise vos logs Une opération d’anonymisation réussie au sens technique — toutes les IPs masquées, tous les comptes remplacés par des tokens — peut échouer au sens de la confidentialité si le contexte restant permet de reconstruire ce qui a été masqué. Ce n’est pas une hypothèse théorique. Les outils pour y parvenir sont disponibles publiquement.
Le problème des quasi-identifiants La définition classique du PII (Personally Identifiable Information) couvre les données directement identifiantes : nom, numéro de sécurité sociale, adresse email.
