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
🇫🇷 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
🇫🇷 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
🇫🇷 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
🇫🇷 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.
