cyber-agent-engine
🇫🇷 Version française 💻 Source code (AGPL): github.com/patlegu/cyber-agent-engine
From “it works” to “deployable by a third party” The first four articles in this series described boundaries: tokens rather than real values (article 2), a fail-closed policy and human approval (article 3), the LLM off the equipment it drives (article 4). Each answers the question “what is the system allowed to do, to see, or to leak?” This one shifts register: it is no longer about what the system does while it runs, but about what it takes for a third party — not the author of the code, not someone who knows the internals — to run it with confidence, on their own infrastructure, without re-reading all of core/ to check that no guarantee tears at startup.
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 ?
victor_le_nettoyeur
Avant d’envoyer des logs à un éditeur, de les injecter dans un LLM externe ou de les archiver conformément au RGPD, une question se pose inévitablement : ces fichiers contiennent-ils des informations qui exposent mon infrastructure ?
Les logs de sécurité sont denses en données sensibles — adresses IP internes, noms d’hôtes, identifiants de comptes de service, clés API, adresses MAC. Et contrairement aux bases de données ou aux formulaires, leur format n’est jamais tout à fait uniforme : chaque équipement, chaque version de daemon, chaque intégration produit ses propres variantes.
