S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

NemoClaw, analyse et prise en main de la « prison » pour sécuriser les agents IA

ClosedClaw

NemoClaw, analyse et prise en main de la « prison » pour sécuriser les agents IA

Illustration : Flock

Les agents IA sont capables du meilleur… comme du pire (dans le pire, sont-ils les meilleurs ?). De nombreux utilisateurs se lancent dans l’aventure sans toujours en mesurer les enjeux ni les dangers (réels). OpenClaw est à la fois catalyseur d’annonces de machines pour que tout le monde puisse en profiter, et de « prisons » sécurisées pour empêcher les agents IA de faire n’importe quoi. Nous terminons par une prise en main rapide de NemoClaw.

Le 18 mars à 15h14

Lors de la GTC, NVIDIA a annoncé NemoClaw, en version alpha pour l’instant, un projet open source pour encadrer les agents IA et notamment OpenClaw. En pratique, c’est un environnement présenté comme sécurisé avec « des garde-fous en matière de confidentialité et de sécurité, donnant aux utilisateurs le contrôle sur le comportement de leurs agents et la gestion de leurs données ».

NemoClaw : sécuriser OpenClaw pour l’empêcher de faire n’importe quoi

OpenClaw (ex-Clawdbot et ex-Moltbot) est un projet open source développé par Peter Steinberger, qui est désormais chez OpenAI. Il s’agit, pour rappel, d’un agent IA auquel vous pouvez donner accès à toutes ou parties de vos données pour qu’il se transforme en assistant virtuel de votre quotidien.

Il reste 95% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (24)

votre avatar
Une introduction d'article validée par la fédération française de funk
votre avatar
(ou Coluche ^^)
votre avatar
oh, je suis trop jeune pour tout ça, sans vouloir t'offenser 😁
votre avatar
Ça pas /dev/null le meilleur moyen de sécuriser openclaw ?
votre avatar
Sur le papier, c'est une bonne idée/nouvelle.
Mais faut-il croire le mastodonte qu'est devenu nvidia, ou nos données vont encore être aspirées pour je ne sais quel usage ?
C'est un challenge à poser à Sebastien ou à Jean : auditer la sandbox !
votre avatar
Ah, il a accès sans restriction à /tmp, donc à l'agent ssh. Ça veut dire qu'à distance, c'est open-bar pour lui !
votre avatar
Rien ne dit qu'il ait accès à tout ce qui est dans /tmp.

Normalement, tu limites les accès aux fichiers au possesseur des fichiers si tu ne veux pas qu'un autre puisse les lire.
votre avatar
La socket vers l'agent ssh appartient bien à l'utilisateur lui-même.

Mais j'avais oublié que le chemin par défaut venait de changer et est désormais $HOME/.ssh/agent/. Tant pis, ça aurait été drôle de confier sa clef ssh à un agent IA.
votre avatar
Le fait qu’une spécialiste du sujet se fasse berner comme une débutante est un signal d’alarme pour tout le monde : faites très attention ! Donner accès à ses données et informations n’est pas sans conséquences ; les risques sont importants et réels. Même si tout va bien, rien ne dit que ce sera toujours le cas. Il n’est pas question de ne pas utiliser l’IA générative, juste de comprendre les tenants et aboutissants pour ne pas faire n’importe quoi.
Pour moi, il faut considérer les agents IA comme des stagiaires : ils peuvent être très efficaces et en même temps faire des bêtises d'une puissance incommensurable. ^^'

Note : ce n'est pas l'apanage des stagiaires, mais chez eux c'est plus ou moins attendu, disons. 😉
votre avatar
Je ne suis pas sûr qu'un stagiaire vide ta boite mail après que tu lui ai demandé de confirmer ce qu'il allait faire quand même :D
votre avatar
Tu as raison : un stagiaire oublierai de demander confirmation. :pastaper:
votre avatar
curl -fsSL https://nvidia.com/nemoclaw.sh | bash
Euh, un machin de sécurité qui s'installe sans lire le script, c'est quand même à éviter !
votre avatar
Saut de la foi.
votre avatar
Après, tu peux télécharger le .sh et le valider manuellement.
C'est la même procédure pour ollama si je me rappelle bien, et c'est ce que j'ai fait.

Après, je vois pas de différence fondamentale avec le téléchargement d'un .exe sur le site d'un éditeur.
votre avatar
bah un script Bash tu peux le regarder. Un .exe compilé ce n'est pas vraiment le même effort.
votre avatar
On est d'accord : au final, et contrairement à ce que laisse penser le message de fred42, l'utilisation d'un .sh est peut-être plus sécurisé qu'un .exe.
Et comme il ne parlait pas explicitement de .exe dans son commentaire, peut-être pourrait-il nous éclairer sur le sens premier de son commentaire, que j'ai peut-être mal interprété. 😉
votre avatar
Ce que je veux dire, c'est que c'est une mauvaise idée d'exécuter un shell que l'on est en train de télécharger sans le lire auparavant.
Expliquer que la commande de l'article avec le pipe est la bonne méthode pour installer ce logiciel
est une aberration d'un point de vue sécurité.
La commande vient de la documentation sur le site de nvidia, mais c'est dommage de la copier telle quelle sans dire qu'il vaut mieux contrôler le contenu du fichier.

Pourquoi voudrais-tu que je parle d'un exe alors que l'on parle d'une installation sur Linux ? Je n'ai rien à dire sur un exe, ça fait longtemps que je n'utilise plus Windows.
votre avatar
En fait, je suis d'accord qu'exécuter un script shell inconnu sur son PC n'est pas une bonne idée, mais je ne vois pas comment installer un programme sans exécuter à un moment un traitement inconnu (sauf à installer un programme open source et à l'avoir lu entièrement).

Si je comprends bien ton point de vue, il aurait fallu qu'ils indiquent de télécharger le script et de l'exécuter après coup ?
votre avatar
J'allais poser la question !
C'est quand même paradoxal de déployer un outil de contrôle d'autonomie de façon aussi obscure...
votre avatar
En quoi est-ce obscur ?
votre avatar
"télécharge n'importe quoi et exécute le sans aucun contrôle préalable."

Même sous windows on ne peut pas exécuter un fichier fraîchement téléchargé, il faut valider une popup, qui ne se dégrise qu'après un minimum de contrôle (antivirus, smartscreen...)

Là c'est la méthode normale et conseillée sachant que n’importe quelle distrib linux possède un gestionnaire de paquet un minium sécurisé, pourquoi ne pas proposé un paquet propre ?
Le gestionnaire de paquete, contrôle les signatures avant dépaquetage, les dépendances sont contrôlées et installées automatiquement...
votre avatar
n’importe quelle distrib linux possède un gestionnaire de paquet un minium sécurisé, pourquoi ne pas proposé un paquet propre ?
Parce qu'il n'existe pas une distribution linux, mais des centaines. Et je passe sur les différentes versions au sein d'une même distribution. Maintenir un paquet sous linux, même en se limitant au distribution les plus répandues, c'est une plaie, car ce n'est pas un paquet qu'il faut maintenir, mais plusieurs dizaines (sans compter les tests qui vont avec).

Le script qui vérifie directement la présence des dépendances est paradoxalement bien plus portable, et surtout, ne nécessite pas obligatoirement les droits root.
votre avatar
Le script qui vérifie directement la présence des dépendances est paradoxalement bien plus portable, et surtout, ne nécessite pas obligatoirement les droits root.
euh non je ne pense pas, ce truc ne doit fonctionner correctement que dans un docker avec une unique archi (amd64 ?) :
# NemoClaw installer — installs Node.js, Ollama (if GPU present), and NemoClaw.
Si chaque package commence à installer / upgrader sa propre version de node.js et npm ça va vite être la fête à la saucisse (which node & node -v vont renvoyer une version random selon le dernier script lancé ?? )
toutes les installs sont codées à la main à base de download / exécution de script, il n'y'a aucun contrôles de dépendances (ça télécharge un binaire de node, sans vérifier la présence d'éventuel pré-requis à node !)

c'est aussi un problème car ça télécharge la version "vanilla", hors les distrib incluent régulièrement des patchs pour s'ajuster aux spécificités de la distrib , exemple sous alpine : https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/nodejs/APKBUILD
je compte 10 patch appliqués aux sources lors de la compilation...
Chez debian y'a carrément un dossier pour les patches par archi : https://sources.debian.org/src/nodejs/24.14.0%2Bdfsg%2B~cs24.12.0-2/debian/patches
Si des dev ont écrits tous ces patches pendant leur temps libre, y'a sans doute une raison ;)

Si c'est fait pour docker c'est là où c'est un peu con, y'a pas quarante distrib à gérer : ubuntu, alpine tu gères déjà 80% des cas :D
votre avatar
euh non je ne pense pas, ce truc ne doit fonctionner correctement que dans un docker avec une unique archi
Pourquoi que dans un docker ? Et puis c'est oublier que Docker c'est, entre autre, fait pour isoler un service (isolation des autres, isolation des ressources comme les accès au système de fichiers). Là, il s'agit quand même de laisser l'accès à l'ensemble des fichiers d'un utilisateur, ce qui rend Docker pas vraiment le bon choix rien qu'à cause de ça.

Et je ne parle pas de l'accès au GPU sous Docker qui nécessite une configuration spécifique.

Ni même que docker est plutôt fait pour des services accessibles en réseau. Là où nemoclaw / openclaw sont plutôt des outils CLI...

Franchement, docker ne me parait pas du tout adapté pour ce genre de techno (avis personnel hein).
Si chaque package commence à installer / upgrader sa propre version de node.js et npm ça va vite être la fête à la saucisse
C'est déjà la fête à la saucisse. Le nombre d'outils qui déploie leur propre version de node/npm, c'est juste dingue. Un de plus ou un de moins...

Surtout que ces outils (node/npm) se "virtualisent" très bien (=installation dans un répertoire propre pour encapsulation dans un autre projet). Donc tu peux très bien les ajouter sans les mettres dans le PATH (et donc sans foutre le bordel partout).
c'est aussi un problème car ça télécharge la version "vanilla", hors les distrib incluent régulièrement des patchs pour s'ajuster aux spécificités de la distrib
En quoi c'est un problème ? D'autant plus pour un usage spécifique pour un logiciel spécifique ! Il vaut mieux se baser sur une version vanilla que sur une version modifiée par les distributions. Et encore une fois, l'installation faite n'est pas faite pour être utiliser par le système. Elle ne sera au pire qu'au niveau de l'utilisateur (et node/npm supporte très bien les multiples versions en simultanées) et seulement si aucune installation n'est trouvée.

Et si par la suite tu installes node via ta distribution, tu te retrouveras automatiquement à l'utiliser, car sera présent plus tôt dans le path. Donc pas vraiment de risque d'interférences...