cyber-agent-engine
🇫🇷 Version française 💻 Source code (AGPL): github.com/patlegu/cyber-agent-engine
A LLM that can block an IP There is something vertiginous about giving a language model the ability to call block_ip or add_filter_rule on a production firewall. You feed it a sentence — “block this IP that’s scanning the LAN” — and a few hundred milliseconds later, a rule shows up in OPNsense. That is exactly the promise of AI-assisted DevSecOps: translate intent into action, with no console, no ticket, no CLI in between.
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 ?
cyber-agent-engine
🇬🇧 English version 💻 Code source (AGPL) : github.com/patlegu/cyber-agent-engine
La rigueur comme livrable Les cinq articles précédents de cette série ont décrit des frontières techniques : jetons plutôt que valeurs réelles, politique fail-closed, topologie hors-boîte, audit borné et packaging reproductible. Ce dernier article change d’angle. Il ne parle pas de ce que cyber-agent-engine fait, mais de comment il a été construit — et pourquoi ce comment fait partie du livrable au même titre que le code.
cyber-agent-engine
🇫🇷 Version française 💻 Source code (AGPL): github.com/patlegu/cyber-agent-engine
The firewall reflex, applied to an AI decision The first article in this series laid out the general thesis: an LLM that drives a production firewall must never cross, on its own, the boundary between intent and execution. The second showed how that boundary protects data — the model only ever sees tokens, never a real IP. This one tackles the other half of the problem: once the LLM has proposed an action on tokens, who decides whether it’s allowed to actually happen?
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
🇫🇷 Version française 💻 Source code (AGPL): github.com/patlegu/cyber-agent-engine
Rigor as a deliverable The five previous articles in this series described technical boundaries: tokens rather than real values, a fail-closed policy, an off-box topology, bounded audit, and reproducible packaging. This last article shifts angle. It is not about what cyber-agent-engine does, but about how it was built — and why that how is part of the deliverable just as much as the code.
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
🇫🇷 Version française 💻 Source code (AGPL): github.com/patlegu/cyber-agent-engine
A question of topology, not just security The first three articles in this series detailed how cyber-agent-engine constrains an LLM that drives a production firewall: tokens rather than real values (article 2), a fail-closed policy and human approval (article 3). This one tackles a prior question, almost architectural before it is a security matter: where must this LLM physically run? On the equipment it drives, or remotely, on the other side of a network call?
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
🇫🇷 Version française 💻 Source code (AGPL): github.com/patlegu/cyber-agent-engine
The invariant The first article in this series laid out the general thesis of cyber-agent-engine: an LLM that drives a production firewall must never cross, on its own, the boundary between intent and execution. This one goes deep into the most counter-intuitive pillar of that architecture, and probably the simplest to state: the reasoning LLM never sees a real IP, a real hostname, or a real secret.
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.
