Brahim Bousnguar

Notes · Article

Espérer n’est pas sécuriser : les cinq pièces d’un agent en entreprise

Par · · 12 min de lecture

À la GTC Berlin, le 21 octobre, Jensen Huang a démonté un agent IA en cinq pièces : le modèle, le harnais (harness), la sandbox dans laquelle tourne ce harnais, la connaissance de votre entreprise et vos outils. Son conseil à toute entreprise qui se prépare aux agents commence par la sandbox, pas par le modèle. Aujourd’hui, la seule chose entre un agent et vos clés SSH, c’est un prompt qui lui demande gentiment. OpenShell, la réponse de NVIDIA, place les règles hors de l’agent, là où une politique contrôle chaque fichier, chaque appel système et chaque connexion réseau.

La partie agents de la keynote va à peu près de la minute 41 à la minute 66. C’est la checklist la plus claire que j’aie vue sur ce qu’une entreprise doit avoir en place avant que des agents touchent à ses systèmes. C’est aussi la keynote d’un fournisseur, donc je signale les affirmations arrivées sans chiffre. Je fais tourner une flotte d’agents OpenClaw sur un Mac mini, et à la fin je confronte ma propre installation à la liste.

Un agent, c’est cinq pièces, et une seule est le modèle

Jensen a ouvert sur le grand changement de l’année. Les agents réfléchissent, raisonnent, itèrent et utilisent des outils, et cela brûle une quantité énorme de tokens : la consommation de tokens, selon ses mots, « a explosé », et la demande en GPU avec elle. Selon lui, c’est OpenClaw, dont NVIDIA parlait en début d’année, qui a lancé la vague d’agents open source qu’on voit partout aujourd’hui.

Puis l’anatomie. Le modèle de langage génère des tokens. Le harnais les consomme ; Jensen l’appelle l’exosquelette, et son exemple, c’est OpenClaw. Le harnais vit dans une sandbox qui l’isole du reste du système. Les deux dernières pièces sont la connaissance et les outils.

Le schéma de NVIDIA dessine le harnais comme une boucle : prendre le contexte, raisonner, planifier, agir, puis recommencer, avec la connaissance et les outils branchés en dessous. Le modèle réfléchit. Les quatre autres pièces décident de ce que cette réflexion peut toucher.

1Modèle

génère les tokens

3Sandbox l’isole du reste du système

2Harnais l’exosquelette

  1. Contexte
  2. Raisonnement
  3. Plan
  4. Action

4Connaissance

les données de l’entreprise

5Outils

ce avec quoi l’agent agit

Jensen« Modèles, sandbox, harnais, connaissance et outils. Ce sont les cinq éléments d’un agent. »

La boucle est le dessin du harnais par NVIDIA, redessiné et numéroté dans l’ordre de Jensen. La surbrillance parcourt les quatre étapes ; les carrés sont des tokens.

Le « s’il te plaît » n’est pas un modèle de sécurité

Avant de rendre les agents utiles, dit Jensen, il faut les sécuriser. Un agent est un système autonome qui a accès à des fichiers, des ressources, des réseaux et des outils. Ses privilèges doivent être minimaux, et il doit être surveillé en permanence.

La vidéo qui a suivi contient la meilleure phrase de la keynote. Aujourd’hui, la seule chose qui empêche un agent d’abuser de ses accès, c’est de lui demander gentiment. « S’il te plaît, ne supprime rien. S’il te plaît, ne touche pas à mes clés SSH. » NVIDIA appelle ça l’approche du « s’il te plaît », et y répond en trois mots : « hope isn’t security », espérer n’est pas sécuriser.

J’ai écrit ces prompts. Tous ceux qui font tourner des agents l’ont fait. Le problème, c’est l’endroit où ils vivent : dans le contexte de l’agent lui-même, là où atterrit aussi une injection de prompt venue d’un e-mail ou d’une page web.

La vidéo compare avec les débuts du web. Les virus étaient partout jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire. Personne n’a demandé gentiment à la page. OpenShell veut être ce navigateur pour les agents : vous écrivez une politique qui dit ce que chaque agent peut toucher, et elle s’applique aux appels système, aux accès fichiers et aux connexions réseau, en dehors de l’agent, « pas seulement dans les garde-fous du LLM ».

L’approche du « s’il te plaît »

Demander gentiment

Dans le prompt

S’il te plaît, ne supprime rien.

S’il te plaît, ne touche pas à mes clés SSH.

Clés atteintes

La règle vit dans le contexte de l’agent

contre

Appliqué hors de l’agent

Une politique

Dans la politique

fichiers : ~/.ssh interdit

réseau : hôtes approuvés seulement

Refusé par la politique

Le contrôle est là où l’agent ne peut pas le modifier

Les débuts du webLes virus étaient partout jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire.

La même requête, deux fois. Les lignes de politique sont mon croquis, pas la syntaxe d’OpenShell.

Les clés n’entrent jamais dans la sandbox

C’est la partie à copier, même si vous n’installez jamais OpenShell. Le projet est open source sous Apache 2.0, et sa documentation d’architecture répartit le travail en quatre.

  • La sandbox contient l’agent et n’a aucune route directe vers le réseau. Elle intercepte chaque connexion et chaque requête DNS, identifie le programme qui en est à l’origine et la transmet. Elle ne décide jamais rien.
  • Le superviseur se tient hors de la sandbox et prend les décisions. Il vérifie chaque requête contre la politique, ouvre la vraie connexion si elle est autorisée, et détient les identifiants.
  • La gateway est le plan de contrôle : l’identité, les politiques et le cycle de vie de chaque sandbox.
  • Le policy prover tourne dans la gateway et contrôle par vérification formelle les changements de politique proposés.

L’astuce des identifiants est celle que je préfère. Un provider associe un service à un identifiant stocké, et le superviseur ne l’ajoute qu’aux requêtes destinées à un endpoint que la politique approuve. L’agent ne voit jamais la vraie clé. Comme le dit la vidéo, un agent compromis ne peut pas faire fuiter une clé qu’il n’a jamais eue.

Les règles ne bougent pas toutes au même rythme non plus. Les règles de système de fichiers et de processus sont figées à la création de la sandbox. Les règles réseau se rechargent pendant qu’elle tourne, et les identifiants peuvent être ajoutés, renouvelés ou révoqués à l’exécution.

Gatewayplan de contrôle : identité, politique, sandboxespolicy prover

  1. 1AgentOuvre une connexion ou une requête DNS. La sandbox n’a aucune route directe vers l’extérieur.
  2. 2SandboxL’intercepte, identifie le programme à l’origine, la transmet. Ne décide rien.
  3. 3SuperviseurVérifie la requête contre la politique, hors de la sandbox.
  4. 4SuperviseurAjoute l’identifiant pour un endpoint approuvé seulement, puis ouvre la vraie connexion.
  5. 5SuperviseurUn hôte que la politique n’approuve pas : refusé.

La vidéoUn agent compromis ne peut pas faire fuiter une clé qu’il n’a jamais eue.

Une requête autorisée, puis une refusée. Le carré est la requête : il passe au cobalt quand le superviseur ajoute la clé, au rouge quand elle est refusée.

Chaque lancement a ses propres privilèges

De retour sur scène, Jensen a posé l’idée qui transforme un conteneur en produit. Chaque niveau de capacité, chaque tâche confiée à l’agent, chaque personne qui l’utilise : chaque combinaison demande un niveau de privilège différent. À chaque lancement d’un agent, les privilèges changent. Les privilèges, l’application des politiques et la surveillance doivent donc tous se jouer à l’exécution.

C’est le travail du prover. Quand un agent demande un nouvel accès, OpenShell vérifie ce que le changement autoriserait avant de l’appliquer. La documentation liste ce qui est signalé : une nouvelle portée avec des identifiants, une nouvelle méthode HTTP, un accès aux métadonnées cloud. Le moindre signalement bloque l’approbation automatique, et le changement attend un humain. Dans les mots de la vidéo : les agents n’obtiennent jamais plus d’accès que prévu.

Il a aussi précisé que ce n’est pas réservé aux entreprises qui construisent des agents. C’est pour toutes celles qui vont recevoir des agents et les laisser tourner chez elles. Voilà l’exigence pour les entreprises, en une ligne : il vous faut le runtime même si vous n’écrivez jamais d’agent. Sur la même scène, il a annoncé un partenariat entre Anthropic et NVIDIA autour d’agents Claude qui tournent dans OpenShell.

C’est aussi la conclusion de Jiquan Ngiam dans ma note sur les collègues IA dans Slack : les bonnes permissions dépendent de qui a demandé, de qui verra la réponse et de la tâche, donc elles se décident message par message.

Capacité+Tâche+Personne=Les privilèges de ce lancement

Le prover signaleUne nouvelle portée avec des identifiants, une nouvelle méthode HTTP, l’accès aux métadonnées cloud. Le moindre signalement bloque l’approbation automatique.

Figé à la créationLes règles de fichiers et de processus. Les règles réseau et les identifiants changent pendant l’exécution.

La hauteur des barres est schématique : NVIDIA ne donne aucun chiffre. La liste des signalements et les couches viennent de la documentation d’OpenShell.

Un second garde, sur sa propre puce

OpenShell applique ses règles depuis le noyau de l’hôte. L’option supplémentaire de NVIDIA quitte carrément l’hôte. Sentry tourne sur un BlueField-4, un DPU : un processeur sur la carte réseau du serveur, dans son propre domaine matériel. Le trafic de raisonnement de l’agent vers le modèle passe par lui. Si l’agent planifie une action non voulue, Sentry met à jour la politique et coupe la connexion au modèle, ce qui met l’agent en quarantaine, en quelques millisecondes selon NVIDIA. Il conserve pour l’équipe sécurité des traces où toute altération se voit et ne dépend pas des logs de l’hôte ni de l’agent.

Deux réserves. NVIDIA présente Sentry comme optionnel, une couche en plus, pas une obligation. Et je n’ai trouvé aucune méthode publiée derrière ces « millisecondes ». À Berlin, l’ensemble est présenté comme l’architecture de référence OpenShell : Vera Rubin pour l’inférence du modèle, des CPU Vera pour les harnais et les outils, un BlueField-4 qui fait tourner Sentry.

TraceScellée, pour la détection, l’enquête et la réponse

Selon NVIDIAQuarantaine en quelques millisecondes, même si l’hôte est compromis. Aucune méthode publiée.

Sentry est optionnel, une couche au-dessus d’OpenShell. Les trois blocs suivent l’architecture de référence OpenShell annoncée à Berlin.

Louer le modèle généraliste, posséder le spécialisé

Ensuite, les modèles. Jensen ne s’attend pas à ce qu’une entreprise fasse tout tourner sur un seul modèle. Quand le travail est assez générique, un modèle généraliste fait un travail incroyablement bon. Quand le travail renferme trop de votre savoir propriétaire, et que vous voulez continuer à l’améliorer, vous prenez un modèle ouvert et vous le post-entraînez sur vos propres données. Chaque entreprise, dit-il, utilisera les deux.

La famille ouverte de NVIDIA s’appelle Nemotron, livrée avec les poids ouverts, les données d’entraînement et les scripts pour la reproduire, si bien que vous savez d’où vient le modèle. Il a été franc sur la limite : ces modèles « ne sont pas forcément la frontière des frontières », surtout pour le langage. La promesse, c’est qu’une fois post-entraînés sur vos données, ils atteignent le niveau de la frontière pour votre cas d’usage. Il l’a appuyée sur des binômes de partenaires, dont Baseten avec CodeRabbit et Scale avec Skydance, et sans aucun benchmark sur scène.

Ma flotte est déjà découpée ainsi. La plupart de mes agents tournent sur Claude. Fortuna, celui qui lit mon appli de finances, tourne sur Qwen 3.6, sur le Mac mini lui-même.

Travail assez générique

Louer

Modèle généralistefermé ou ouvert, utilisé tel quel

« Va faire un travail incroyablement bon »

Toutes les entreprises s’en serviront

et

Votre savoir propriétaire

Posséder

  1. Poids ouverts
  2. Les données d’entraînement
  3. Les scripts pour le reproduire
  4. Vos données : post-entraînez-le

Et continuez à l’améliorer

JensenCes modèles « ne sont pas forcément la frontière des frontières, surtout pour le modèle de langage ».

Les deux, pas l’un ou l’autre. La recette est ce que NVIDIA livre avec les poids de Nemotron ; la dernière ligne est la part qui n’appartient qu’à vous.

La connaissance fait des agents des super-agents

« Ce qui transforme ces agents en super-agents, c’est de leur donner accès à la connaissance de votre entreprise. » La brique de NVIDIA pour ça, c’est l’agent knowledge foundation : des bibliothèques et des modèles qui tirent du sens de vos données, qu’elles soient non structurées, comme des PDF qu’il faut une IA pour lire, ou structurées, comme les lignes d’une base de données.

Il en a nommé les pièces une par une. Nemotron Parse lit les documents. Nemotron Embed rapproche une requête de ce que contient une base vectorielle. Nemotron Rerank prend les nombreuses sources trouvées pour une requête et les classe par pertinence. Kumo prédit ce qui risque d’arriver à partir d’une base structurée.

Puis son exemple. Un avis arrive : un fournisseur livrera moins ou en retard. C’est un document. Vos commandes sont dans une base SQL. Kumo prédit quelles commandes vont manquer, et de combien. Puis la recherche vectorielle trouve le document d’ingénierie d’un composant de remplacement. Une seule question, et elle traverse un document, une base de données et une archive.

C’est la partie la plus proche de mon métier. Je connecte des systèmes de commerce pour gagner ma vie, et un agent ne peut répondre à cette question qu’une fois que quelqu’un l’a branché au système de commandes.

  1. 1L’avis

    Un document, donc non structuré. Parse le lit.

  2. 2Les commandes

    Des lignes en SQL. Kumo prédit lesquelles vont manquer, et de combien.

  3. 3La solution

    La recherche vectorielle trouve la doc d’ingénierie d’un remplaçant.

Parselit les documentsEmbedrapproche une requête de la base vectorielleRerankclasse les sources par pertinenceKumoprédit à partir de données structurées

Son exemple, étape par étape. Les quatre noms en dessous sont les pièces de l’agent knowledge foundation de NVIDIA qu’il a citées sur scène.

Les outils, c’est le métier

La dernière pièce, ce sont les outils. Les bibliothèques CUDA-X de NVIDIA sont des simulateurs, des solveurs, des moteurs de traitement de données et des bibliothèques métier, et Jensen les appelle les joyaux de la couronne de l’entreprise. La phrase de la vidéo : le scientifique le plus brillant a toujours besoin d’un laboratoire, et le meilleur ingénieur a toujours besoin de simulateurs et de solveurs.

Il a aussi expliqué pourquoi le code est passé en premier. Le logiciel a été l’un des premiers domaines conquis par les agents, et là, un compilateur ou Python suffit à l’agent. Les autres métiers demandent plus d’outils.

La vidéo en a montré trois. Lila Sciences, qui conçoit une thérapie contre le lymphome B : l’agent Iris transforme l’objectif en plan expérimental, des agents lancent des millions d’expériences virtuelles dans un laboratoire numérique (dry lab), les meilleurs candidats partent dans une usine scientifique IA où des robots les fabriquent et les testent, et les résultats reviennent à Iris. Siemens, dans son usine électronique d’Erlangen : des agents produisent des prototypes virtuels et des données synthétiques, recommandent des plans de production à partir des commandes, des stocks et de la configuration des lignes, et un jumeau numérique vérifie ces plans par simulation physique avant que quoi que ce soit change dans l’atelier. Dassault Systèmes, qui adapte une portière de Volkswagen Golf pour le Tiguan : un agent de simulation détecte un problème de vibration, le renvoie à l’agent de conception, et l’ingénieur choisit le design final.

Son résumé ensuite : « Construire des agents, ce n’est pas si difficile. » Cinq pièces. Le modèle et le harnais existent en versions fermées et ouvertes. Puis le runtime OpenShell, « et ensuite, surtout, la connaissance et les outils, et cette connaissance et ces outils vous appartiennent. C’est votre expertise. »

ObjectifUne thérapie contre le lymphome B

PlanIris transforme l’objectif en plan expérimental

Dry labBioNeMo lance des millions d’expériences virtuelles

Usine scientifiqueDes robots fabriquent et testent les meilleurs candidats

RésultatsRetour à Iris, qui oriente les conceptions suivantes

Siemens, ErlangenPrototypes virtuels et données synthétiques, plans de production tirés des commandes et des lignes, un jumeau numérique les vérifie d’abord

Dassault SystèmesUne portière de Golf retravaillée pour le Tiguan. La simulation trouve une vibration, la conception la corrige, l’ingénieur choisit

La vidéoLe scientifique le plus brillant a toujours besoin d’un laboratoire.

La boucle de Lila telle que la vidéo la raconte. La surbrillance la parcourt comme les résultats : un tour, puis un autre.

Où en sont mes propres agents

J’ai donc confronté ma flotte OpenClaw aux cinq pièces.

Le modèle est mixte : Claude pour la plupart des agents, Qwen 3.6 en local pour quelques-uns. Le harnais, c’est OpenClaw 2026.9.4. La connaissance passe par huit serveurs MCP branchés sur mes propres applis. Les outils sont filtrés par une liste d’interdits par agent dans openclaw.json : Rex, mon coach nutrition, n’a aucun shell, et seul Nova peut atteindre mon téléphone.

La sandbox, c’est la ligne vide. Mes agents exécutent leurs outils sur l’hôte, ce qui est le comportement par défaut d’OpenClaw, et précisément ce contre quoi je mettais en garde dans ma comparaison d’OpenClaw et Hermes.

Ces listes d’interdits sont du vrai code, pas un « s’il te plaît ». Mais c’est le harnais qui les applique, sur la même machine que l’agent, et elles nomment des outils. Tout agent qui a encore un shell peut atteindre tout ce que mon compte utilisateur atteint. C’est exactement le contrôle depuis l’intérieur de l’agent que NVIDIA juge insuffisant.

  1. ModèleClaude pour la plupart des agents, Qwen 3.6 sur le mini pour quelques-unsMixte
  2. HarnaisOpenClaw 2026.9.4Oui
  3. ConnaissanceHuit serveurs MCP branchés sur mes applisOui
  4. OutilsUne liste d’interdits par agent. Rex n’a pas de shell ; seul Nova atteint le téléphoneInterne
  5. SandboxAucune : les outils tournent sur l’hôte, par défaut dans OpenClawPas encore

L’écartMes règles vivent dans le harnais. L’idée de NVIDIA est de les placer hors de l’agent.

Mon installation au 23 octobre, lue dans mon openclaw.json. La dernière ligne est celle que la keynote dit de faire en premier.

À vous d’essayer

OpenShell tourne sous Linux, sous macOS sur Apple Silicon ou sous Windows avec WSL 2, avec Docker, Podman ou la virtualisation de l’hôte. Deux commandes :

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

L’installeur met en place la CLI et une gateway locale, et la sandbox par défaut est un Ubuntu minimal sans agent dedans. Le guide Run your first agent y installe OpenCode sur un modèle OpenRouter gratuit et montre comment approuver les nouveaux accès au fur et à mesure que l’agent les demande. Je ne l’ai pas encore lancé : lisez cette note comme une lecture, pas comme un test.

Pour aller plus loin :

Si votre entreprise se prépare aux agents, commencez par la partie ingrate. Écrivez ce que chaque agent a le droit de toucher, et placez ce contrôle là où l’agent ne peut pas le modifier. Si vous essayez OpenShell avant moi, dites-moi combien d’approbations il a fallu avant que votre agent devienne utile.

Texte brut: hope-isnt-security-enterprise-agents.md · Flux Atom · Toutes les notes

Contact

Écrivez-moi.

b.bousnguar@gmail.com

Intégration SAP Commerce Cloud, MuleSoft et Salesforce · Nantes · FR / EN