OpenShell ne demande pas la permission au modèle

La première composante de la plateforme est NVIDIA OpenShell 0.1.0, un runtime sécurisé distribué en open source sous licence Apache 2.0. Chaque agent s’exécute dans une sandbox disposant de contrôles au niveau du noyau sur les fichiers, le réseau et les processus auxquels il peut accéder.

L’idée est de séparer l’agent de l’autorité qui décide ce qu’il peut faire. Une réponse générée par le modèle peut demander l’accès à une ressource, mais elle ne modifie pas directement les règles qui autorisent cet accès.

OpenShell place notamment un superviseur hors de la charge de travail de l’agent. Les requêtes réseau sortantes passent par cette couche, qui les compare à la politique définie par l’opérateur.

Les permissions portent sur les fichiers, les outils et les identifiants

L’opérateur peut déterminer quels fichiers, réseaux, outils, processus et identifiants sont accessibles. Ces restrictions restent actives lorsque l’agent exécute du code qu’il vient de générer ou crée des processus enfants.

Le runtime associe sandboxes individuelles, supervision, gestion centralisée et vérification formelle des politiques. NVIDIA décrit notamment un policy prover chargé de vérifier avant l’exécution que les permissions modélisées restent à l’intérieur des limites prévues.

Ce dernier point compte pour les agents à longue durée de vie. Une instruction en langage naturel peut être ambiguë ; une politique d’accès doit au contraire finir par produire une décision autoriser ou refuser lorsque le programme tente réellement d’ouvrir un fichier ou d’appeler un service.

Sentry déplace le surveillant sur une autre puce

OpenShell constitue la couche logicielle utilisable indépendamment. NVIDIA propose ensuite Sentry comme couche de sécurité supplémentaire dans son architecture de référence. Sentry fonctionne sur les DPU BlueField-4 et observe l’activité depuis un domaine matériel distinct de celui dans lequel s’exécute l’agent.

NVIDIA décrit ce mécanisme comme un watchdog out-of-band. Il utilise DOCA pour inspecter les interactions, associer décisions de politique, accès aux outils et accès aux données, vérifier l’identité de l’agent et appliquer des politiques zero-trust.

Selon NVIDIA, Sentry peut mettre en quarantaine et arrêter en quelques millisecondes un agent qui tente de sortir de ses limites logicielles. Ce délai est une affirmation constructeur ; il ne constitue pas à lui seul une mesure indépendante de l’efficacité de la plateforme contre l’ensemble des comportements indésirables possibles.

BlueField-4 n’est pas obligatoire pour utiliser OpenShell

La distinction évite une confusion importante. OpenShell ne nécessite pas un DPU BlueField-4. NVIDIA indique que le runtime peut fonctionner sur des infrastructures locales, on-premises, cloud ou Kubernetes prises en charge.

La société optimise son architecture pour ses processeurs Vera et ses DPU BlueField, mais OpenShell étant open source, il peut également être étendu à des plateformes de calcul tierces. NVIDIA cite explicitement Arm et Intel.

Sentry sur BlueField-4 correspond à la couche matérielle optionnelle. Son intérêt est précisément de continuer à observer et appliquer des règles depuis un domaine séparé même si le logiciel hôte ou la charge de travail de l’agent est compromis.

Dans Vera Rubin, le DPU se trouve sur le chemin vers le modèle

L’intégration devient plus étroite dans l’architecture Vera Rubin POD de NVIDIA. Chaque compute tray y comprend un BlueField-4 placé sur le chemin du nœud vers le modèle.

Cette position donne au DPU un point d’observation que l’agent ne contrôle pas directement. NVIDIA affirme pouvoir y appliquer les politiques en temps réel à la vitesse de la ligne et conserver une télémétrie indépendante du système hôte.

Le principe rappelle des architectures de sécurité déjà utilisées ailleurs dans l’informatique : le composant surveillé et le composant qui décide de son accès ne partagent pas nécessairement le même domaine de confiance.

Le modèle peut dériver sans être malveillant

NVIDIA emploie le terme drift pour décrire un agent dont les actions s’éloignent de la tâche ou des contraintes prévues. La société cite plusieurs causes possibles : une règle qui bloque l’approche initiale, un bug, un outil manquant, des instructions ambiguës ou simplement une tâche suffisamment longue pour pousser l’agent à multiplier les stratégies.

Ce cadre est plus large qu’un scénario où une IA déciderait soudainement de devenir hostile. Un agent peut dépasser son périmètre en cherchant obstinément à satisfaire une instruction parfaitement ordinaire.

C’est aussi la raison pour laquelle la plateforme s’intéresse aux sous-processus et aux sous-agents. Une restriction qui ne s’applique qu’au processus initial perd une partie de son intérêt si celui-ci peut lancer autre chose disposant de davantage de privilèges.

Contrôler le chemin vers le modèle fournit aussi un coupe-circuit

NVIDIA définit cinq principes pour son architecture. Les politiques doivent être vérifiables, leur application doit rester hors de portée de l’agent et les différents acteurs — fournisseurs de modèles, entreprises et fournisseurs de matériel — doivent partager la responsabilité de la sécurité.

Un autre principe consiste à contrôler le chemin qui permet à l’agent d’interroger son modèle. Un agent a besoin d’une nouvelle inférence pour poursuivre son raisonnement ; intercepter ce chemin fournit donc à la fois un point d’observation et un moyen d’interrompre l’exécution.

Cela ne rend pas automatiquement le comportement du modèle prévisible. Cela donne plutôt à l’infrastructure un moyen de stopper l’action même lorsque la génération elle-même n’a pas été anticipée.

OpenShell prend déjà en charge plusieurs familles d’agents

NVIDIA indique qu’OpenShell peut accueillir des agents existants comme Claude Code, Codex, OpenCode, GitHub Copilot CLI et OpenClaw, ainsi que des agents personnalisés. Le runtime accepte des modèles ouverts comme fermés.

Cette indépendance est importante pour la proposition technique. La politique de sécurité ne doit pas être réécrite entièrement chaque fois qu’une entreprise change de modèle ou de framework agentique.

Anthropic a notamment travaillé avec NVIDIA sur l’intégration de Claude Managed Agents. Dans cette architecture, la boucle de l’agent et les sandboxes où son travail s’exécute sont déjà séparées ; OpenShell et BlueField peuvent ajouter des contrôles d’accès autour de ces environnements.

Une longue liste de partenaires ne constitue pas une validation de sécurité

NVIDIA accompagne son lancement d’un écosystème comprenant notamment Anthropic, Cisco, CrowdStrike, Dell Technologies, HPE, Hugging Face, JPMorganChase, Microsoft, Palantir, Palo Alto Networks, Perplexity, Red Hat, Salesforce, SAP, Scale AI, ServiceNow et SpaceXAI.

Cette participation montre qu’il existe une demande pour des contrôles d’agents communs à plusieurs couches de l’infrastructure. Elle ne démontre pas que l’architecture arrête toutes les formes d’évasion, d’injection de prompt, d’abus d’outils ou d’élévation de privilèges.

Un runtime de sécurité ajoute lui-même du code, des politiques et des interfaces qu’il faut auditer. Une erreur dans une règle trop permissive reste une erreur même lorsque cette règle est appliquée parfaitement par le matériel.

La sécurité des agents devient un problème d’infrastructure

La différence la plus intéressante avec les garde-fous de modèle se trouve là. Un filtre de prompt ou un entraînement de sécurité cherche à influencer ce que l’agent tente de faire. OpenShell cherche à déterminer ce qu’il est effectivement autorisé à faire une fois la tentative produite.

Sentry pousse cette logique un cran plus loin : l’entité qui surveille peut être isolée du logiciel qu’elle surveille. Ce n’est pas indispensable pour chaque déploiement, et NVIDIA a évidemment intérêt à faire de BlueField une nouvelle brique de l’infrastructure agentique.

Mais le déplacement du problème est concret. Plus les agents obtiennent de vrais identifiants, des outils, des terminaux, des API et des heures pour accomplir une tâche, moins une simple instruction disant « ne fais pas cela » ressemble à une frontière de sécurité suffisante. Open Agent Safety Platform part du principe inverse : le modèle peut proposer l’action, mais l’infrastructure garde la clé de la porte.