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
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.
LoRA Factory · N°5
L’IA au Service de l’Infrastructure : Extension IaC & Vision Future Dans les articles précédents, nous avons exploré comment lora-factory transforme les APIs d’outils de sécurité en agents intelligents. Pour conclure cette série, nous allons voir comment cette même technologie s’étend à un pilier fondamental de l’informatique moderne : l’Infrastructure as Code (IaC).
Le pipeline de l’Usine à LoRAs est par nature modulaire. Au lieu d’ingérer une spécification OpenAPI, nous avons appris au moteur à ingérer des patterns de code Ansible (YAML) et Terraform (HCL).
Important Traduction d’un article du site PRO CUSTODIBUS
Le contenu de cette page est la traduction Française de l’article Forwarding WireGuard Connections on Windows de Justin Ludwig
Transfert de connexions WireGuard sur Windows WireGuard fonctionne généralement bien par défaut sur Windows avec une connexion Point-to-Point, ou comme un “Point” dans une liaison conventionnelle Point-to-Site, ou comme un “Spoke” dans une liaison Hub-and-Spoke ; et si vous souhaitez exposer un service réseau (comme un serveur web) sur un tel point ou spoke, vous pouvez le faire en apportant une ou deux modifications à son pare-feu Windows.
Important Traduction d’un article du site PRO CUSTODIBUS
Le contenu de cette page est la traduction Française de l’article Waypipe over WireGuard de Justin Ludwig
Waypipe via WireGuard La méthode la plus directe de lancer des applications Wayland natives à distance est avec Waypipe. La façon la plus simple de faire ça est par le biais d’une connexion SSH ; vous pouvez cependant utiliser WireGuard, grâce à un outil comme Socat ou Netcat.
Important Traduction d’un article du site PRO CUSTODIBUS
Le contenu de cette page est la traduction Française de l’article WireGuard Containers for Overlapping Networks de Justin Ludwig
Conteneurs WireGuard pour réseaux clients chevauchants Lorsque vous utilisez WireGuard pour connecter depuis le même serveur à différents réseaux clients privés qui utilisent le même espace d’adressage réseau, vous pouvez utiliser le routage de stratégie pour éviter les collisions d’adresses. Ce mécanisme a été détaillé dans l’article original WireGuard avec des réseaux clients chevauchants.
HAProxy : Plongée au Cœur du Fonctionnement d’un Géant de la Répartition de Charge HAProxy est une technologie incontournable dans le paysage des infrastructures web modernes. Souvent perçu comme un simple répartiteur de charge, ses capacités s’étendent bien au-delà, le positionnant comme un véritable contrôleur de livraison d’applications (Application Delivery Controller - ADC) open-source. Cet article est le premier d’une série visant à démystifier HAProxy, en commençant par une exploration détaillée de son fonctionnement interne.
Important En cours Le contenu de cette page est en cours d’édition.
Tout bouge en permanence sur cette page et notemment les schémas.
Ne pas utiliser le contenu de cette page, c’est uniquement un bloc note, du brainstorming. N’a pas forcément de sens.
Vous étes prévenu !! :-) Cas d’usage de HAProxy dans REDHAT OpenShift 1. HAProxy comme Routeur/Contrôleur d’Entrée (Ingress Controller) 1.1 Rôle Principal : C’est le cas d’utilisation le plus courant et fondamental.
Important En cours de rédaction!
Le contenu de cet article n’est pas du tout exploitable.
Introduction IS-IS est un protocole de routage à état de liens qui permet la transmission efficace de données dans des réseaux vastes et complexes. Aujourd’hui, de nombreux passionnés de réseaux ont entendu parler du terme protocole de routage, qui désigne un ensemble de règles et d’algorithmes. Les protocoles de routage sont utilisés par les périphériques réseau pour déterminer le meilleur chemin d’envoi des données entre la source et la destination.
