1 points par skwuwu 2026-04-24 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Il s’agit d’un runtime permettant d’utiliser en toute sécurité des agents autonomes comme OpenClaw.

Les agents autonomes disposent d’un champ d’action plus large que les agents classiques, ce qui les rend potentiellement bien plus utiles. Mais comme ils exigent aussi des privilèges puissants, leur utilisation sans garde-fous suscitait des inquiétudes, qu’il s’agisse d’appels d’API erronés ou de permissions excessives comme rm-rf. Dans les faits, des incidents de sécurité graves ont effectivement été observés, par exemple la suppression accidentelle de fichiers réels dans OpenClaw ou l’exécution de code malveillant sur Clawhub.

Je souhaitais utiliser OpenClaw via une instance AWS, mais les contre-mesures existantes, comme NVDIA NemoClaw, présentaient une dépendance matérielle et imposaient en pratique de gérer une infrastructure de type Kubernetes. À l’inverse, le faire tourner simplement dans Docker posait aussi problème, car il avait été conçu à l’origine comme un simple conteneur, ce qui compliquait fortement la définition de politiques et le contrôle des permissions.

J’ai donc créé une couche de sécurité légère ne nécessitant pas d’infrastructure supplémentaire, composée de deux binaires Rust. Elle n’a pas de dépendances additionnelles et fonctionne aussi dans d’autres environnements, mais comme elle s’appuie sur des fonctionnalités du noyau Linux, un environnement Linux est recommandé.

Les principaux composants techniques du projet sont les suivants :

  1. Un proxy qui classe tout le trafic sortant HTTP/HTTPS selon les politiques définies, avec des actions de type allow/deny/delay
  2. seccomp-bpf et une isolation par namespaces pour empêcher l’agent de contourner le proxy
  3. La prévention des abus de permissions sur les syscalls de l’agent, ainsi que l’interdiction des opérations directes sur les fichiers locaux via un système overlayfs
  4. La prévention des fuites grâce au secret injection, afin que l’agent ne puisse pas connaître les clés d’API

Des informations plus détaillées sur l’implémentation technique sont documentées sur GitHub, séparément pour chaque composant. Les tests de stress de base, notamment sur la sûreté mémoire et la prévention des processus orphelins à l’arrêt, sont terminés, et le système a passé des tests sur des exécutions de plus de 60 minutes (OpenClaw et Hermes agent exécutés sur une instance AWS). La latence mesurée est également restée négligeable par rapport à l’exécution réelle de l’agent.

Je pense que cela pourra être utile à celles et ceux qui, comme moi, utilisent des agents en production sur un serveur Linux, ou qui ont besoin de déboguer ou de contrôler le trafic d’un agent. Comme il s’agit d’un outil en ligne de commande, l’UI peut être peu pratique, mais il est aussi possible de vérifier simplement son état via une page HTML statique. Les signalements de bugs, retours et autres questions sont les bienvenus !

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.