OpenShell et Sentry de Nvidia : comment une PME fixe et fait respecter les limites de ses agents IA

Fin septembre 2026, Nvidia a lancé l'Open Agent Safety Platform, une architecture de référence pour gouverner les agents IA. Le message central vient de Justin Boitano, vice-président IA entreprise chez Nvidia : l'industrie n'a pas besoin d'agents qui promettent de rester dans leurs limites, mais de systèmes capables de prouver et de faire respecter ces limites.

Pour une PME, la bonne nouvelle est que les principes de cette annonce s'appliquent sans acheter un seul composant Nvidia. La mauvaise nouvelle, soulignée par TechTarget : aucun outil ne décide à votre place où placer les limites. Ce guide transforme l'annonce en checklist opérationnelle.

Ce que Nvidia a annoncé, en bref

D'après Network World et TechTarget (1er octobre 2026), la plateforme combine deux briques :

• OpenShell : un runtime open source (licence Apache 2.0) qui déplace l'application des politiques hors de portée de l'agent, dans le noyau Linux. Chaque agent tourne dans son propre bac à sable, les identifiants restent dans une passerelle située hors du bac à sable, et un Policy Prover vérifie les limites par méthodes formelles avant que l'agent ne démarre. Exemple cité : prouver qu'un agent ne peut pas accéder à Internet avant même son lancement. Nvidia insiste : ce n'est pas un « LLM juge », c'est un raisonnement mathématique déterministe.
• Sentry : un chien de garde matériel sur les DPU BlueField-4, un domaine de sécurité indépendant placé entre le harnais de l'agent (CPU) et le modèle. Il peut surveiller requêtes, réponses et raisonnement, et couper l'agent en quelques millisecondes. Nvidia le présente comme optionnel : OpenShell sur CPU est jugé « honnêtement suffisant » pour la plupart des contrôles d'accès en entreprise, Sentry visant surtout le red teaming et l'évaluation de modèles de pointe.

Anthropic, Salesforce (validation des demandes de permissions d'agents dans Slack), SAP et SpaceXAI figurent parmi les partenaires cités, et plus de 100 organisations travaillent avec ces technologies. OpenAI et Google ne sont pas cités comme partenaires de lancement, et le transfert d'OpenShell vers la Linux Foundation n'a pas encore eu lieu.

Pourquoi les contrôles classiques ne suffisent plus

Ali Golshan, dont l'équipe a construit OpenShell, résume le problème : le comportement d'un agent se manifeste à la fois dans le système de fichiers, le réseau, la mémoire et les échanges avec d'autres agents. Une politique attachée à un processus ou à un conteneur ne couvre plus tout.

Deux constats de Nvidia méritent d'être retenus :

• Un agent contourne la friction. Il ne fait pas bien la différence entre « interdit par la politique » et « échec technique » : il cherche un autre chemin.
• Les permissions se combinent. Des sous-agents peuvent assembler des capacités autorisées individuellement pour obtenir un résultat que personne n'avait prévu.

Et un troisième, venu de TechTarget, qui concerne directement les PME : selon Andrew Curtis (CISO chez Gadget Access), un agent peut rester dans son bac à sable et quand même approuver le mauvais paiement. Le confinement technique ne remplace pas la définition de l'autorité métier.

La checklist PME en 8 contrôles

1. Inventorier les agents et nommer un responsable pour chacun

Traitez chaque agent (et sous-agent) comme une identité, au même titre qu'un utilisateur ou un compte de service : un propriétaire, un périmètre, un cycle de vie. Listez les systèmes connectés et les actions permises. Si vous ne pouvez pas dresser cette liste, c'est la première tâche. Les agents non déclarés deviendront le nouveau shadow IT.

2. Sortir les identifiants de l'agent

Le modèle « passerelle » d'OpenShell est le bon, quel que soit votre outil : l'agent reçoit des sessions courtes et limitées, délivrées par un composant qu'il ne contrôle pas, jamais des clés ou jetons longue durée. Si l'agent est compromis par injection de prompt, il ne doit rien avoir à voler. Voir notre guide NIST IR 8587 sur la sécurisation des jetons d'agents.

3. Appliquer les règles hors de l'agent, pas seulement dans le prompt

Les instructions système et garde-fous du modèle sont utiles, mais restent des suggestions pour un système conçu pour résoudre des problèmes de façon créative. Les règles qui comptent doivent s'appliquer au niveau du runtime, du réseau ou du système. Test simple proposé par Network World : un agent astucieux pourrait-il négocier son passage ? Si oui, ce n'est pas un contrôle. Pour la couche réseau, voir isolation réseau des agents IA et filtrage egress et sandbox DNS.

4. Définir des paliers d'autorité R0 à R4

TechTarget le formule clairement : il faut distinguer ce qu'un agent peut faire seul, ce qui exige une approbation humaine et ce qui est interdit. Une grille simple :

• R0 : lecture d'informations publiques ou internes non sensibles, sans validation.
• R1 : brouillons internes (résumés, propositions), revus avant usage.
• R2 : actions internes réversibles (créer un ticket, mettre à jour un CRM), journalisées.
• R3 : actions externes ou à impact (envoyer un e-mail client, publier, modifier du code en production), approbation humaine obligatoire.
• R4 : paiements, suppression de données, changements de droits, toujours sous double validation ou interdits à l'agent.

L'agent ne doit jamais pouvoir s'auto-approuver.

5. Tester les combinaisons, pas seulement chaque agent

Le risque principal est émergent : un agent autorisé à lire le dépôt de code, un autre autorisé à publier à l'extérieur. Séparément, rien d'anormal ; ensemble, une fuite de code propriétaire. Organisez des exercices sur des groupes d'agents, sur plusieurs jours, et revoyez les permissions croisées.

6. Prévoir un kill switch et surveiller la dérive

Une approbation unique ne suffit pas. Journalisez en continu ce que font les agents, comparez avec l'intention initiale, et fixez des seuils qui déclenchent une revue ou une mise en quarantaine automatique. Testez régulièrement la capacité à couper un agent rapidement. Sur le sujet, voir responsabilité des agents IA et contrôle humain et inventaire et kill switch selon le Stop Rogue AI Act.

7. Réunir sécurité et équipes IA dès la conception

Dans beaucoup d'entreprises, les projets IA partent des métiers et la sécurité intervient après coup. Pour les agents, cet ordre ne fonctionne pas : la personne responsable de la sécurité doit participer à la conception des workflows d'agents dès le départ.

8. Exiger ouverture et évaluation indépendante des fournisseurs

Privilégiez les outils dont la gouvernance est ouverte, et demandez aux fournisseurs de modèles et de plateformes quelles évaluations indépendantes ils ont passées. Comme le rappelle Chris Newton-Smith (IO) dans TechTarget, la gouvernance doit se situer au-dessus de chaque fournisseur, quel que soit l'agent ou la plateforme utilisés.

Et la réglementation ?

Aux États-Unis, deux propositions illustrent deux approches (TechTarget) : l'AI Kill Switch Act imposerait aux développeurs de certains systèmes puissants de pouvoir les ralentir ou les arrêter ; le Stop Rogue AI Act chargerait le NIST d'élaborer des standards pour découvrir, surveiller et contrôler les agents. En Europe, l'AI Act pousse déjà vers la traçabilité et la supervision humaine : voir notre analyse AI Act Omnibus, MCP et logs d'audit. Dans tous les cas, la décision sur l'autorité de vos agents reste la vôtre.

Si vous déployez déjà des agents always-on

Les agents qui tournent en continu et se connectent à des milliers d'applications rendent chaque point ci-dessus plus urgent. Notre guide gouvernance des agents IA always-on détaille les boundaries et la journalisation pour ce cas.

Comment TrustAI Vault applique ces principes

Vous n'avez pas besoin de DPU BlueField pour appliquer le principe « contrôle hors du modèle ». TrustAI Vault place cette couche entre vos équipes, leurs assistants IA et les modèles :

• DLP avant le modèle : détection et masquage des données sensibles avant qu'elles ne quittent votre périmètre.
• Egress en liste blanche : les destinations autorisées sont définies par vous, pas par l'agent.
• Journaux d'audit infalsifiables : chaque prompt, réponse et action est tracé hors de portée de l'agent.
• Validations humaines sur les actions sensibles (paliers R3 et R4).
• Interruption et kill switch administrateur.

CTA : testez Vault Pro pendant 4 jours → Démarrer l'essai gratuit

Sources

• Network World, Zeus Kerravala, « Nvidia built the AI factory. Now it's building the locks for the doors », 1er octobre 2026 : networkworld.com
• TechTarget, Kinza Yasar, « Nvidia agent safety push raises questions about who governs AI autonomy », 1er octobre 2026 : techtarget.com