Un RSSI se présente en réunion du conseil d’administration avec une réponse incomplète

Imaginez un scénario qui se répétera dans des centaines d’entreprises au cours des prochains mois. Un RSSI entre en réunion de conseil d’administration et déclare : « Notre stratégie OpenClaw, c’est NemoClaw. OpenShell de NVIDIA est notre moteur de règles. Cisco, CrowdStrike et Microsoft l’utilisent tous comme base. Nous sommes couverts. »

Le conseil acquiesce. Le support de présentation est impressionnant. Le RSSI a réellement travaillé : il a évalué l’exécution, choisi les bons partenaires d’infrastructure, déployé des agents dans un environnement sandboxé avec des garde-fous réseau. Selon tous les critères raisonnables de sécurité à l’exécution, l’architecture est solide.

Six mois plus tard, l’auditeur CMMC arrive. Sa première question ne porte pas sur le sandboxing à l’exécution. Elle ne concerne pas les garde-fous réseau. Elle ne porte pas non plus sur le modèle utilisé par les agents.

La question est la suivante : « Montrez-moi à quels CUI cet agent a accédé, avec quelle autorisation, avec quel chiffrement, et produisez la piste d’audit reliant cet accès à un autorisateur humain. »

C’est à ce moment-là que le RSSI découvre que la politique d’exécution et la politique de conformité sont deux choses différentes. Et à ce stade, l’écart de conformité s’est creusé pendant six mois d’interactions d’agents non gouvernées, impossibles à auditer a posteriori. Les preuves exigées par l’auditeur n’existent pas. Non pas parce que le RSSI a été négligent, mais parce que l’architecture a traité le mauvais niveau.

Ce scénario n’est pas hypothétique. Il résulte inévitablement de la confusion entre la notion de « moteur de règles » selon Jensen Huang et les exigences réglementaires de conformité. Comprendre cette distinction est la décision de gouvernance la plus cruciale qu’un RSSI ou un responsable conformité devra prendre en 2026.

Ce que Huang a réellement dit — et ce que cela signifie vraiment

La précision est essentielle ici. Lors du keynote GTC 2026, Huang a présenté NVIDIA OpenShell comme partie intégrante de la stack NemoClaw et a déclaré que ces technologies pouvaient servir de « moteur de règles pour toutes les entreprises SaaS du monde ».

La VP de NVIDIA, Kari Briski, a précisé lors d’un point presse pré-conférence : « OpenShell fournit la couche d’infrastructure manquante sous les claws pour leur donner l’accès nécessaire à leur productivité, tout en appliquant des garde-fous de sécurité, réseau et confidentialité basés sur des règles. »

Ces déclarations décrivent précisément ce que fait OpenShell. Il s’agit d’un runtime open source qui isole l’exécution des agents, applique des contrôles réseau, gère l’isolation des données au niveau de l’exécution et fournit l’infrastructure permettant aux agents d’opérer dans des limites définies. C’est une fonction utile et nécessaire.

Mais « moteur de règles » a une signification bien spécifique dans le contexte de la conformité, différente de celle employée par NVIDIA. Pour un responsable conformité HIPAA, « moteur de règles » signifie : contrôles d’accès sur les informations médicales protégées (PHI), application du principe du minimum nécessaire, validation du chiffrement et pistes d’audit. Pour un auditeur CMMC, cela signifie : accès autorisé aux CUI avec contrôles documentés et dossiers de preuves. Pour Huang, cela signifie : garde-fous à l’exécution pour la façon dont les agents interagissent avec les applications SaaS.

Les deux usages sont légitimes. Le risque, c’est de les confondre.

L’architecture technique du fossé : politique d’exécution vs politique de gouvernance des données

La différence entre politique d’exécution et politique de gouvernance des données n’est pas sémantique. Elle est architecturale. Comprendre où chacune agit dans la stack d’entreprise est essentiel pour bâtir une stratégie OpenClaw complète.

La politique d’exécution (domaine d’OpenShell) agit au niveau de l’exécution des agents. Elle répond à des questions telles que : cet agent peut-il invoquer cet outil ? Peut-il accéder à ce chemin réseau ? Fonctionne-t-il dans un environnement sandboxé adéquat ? L’environnement d’exécution est-il isolé du reste du système ? Ce sont des contrôles d’infrastructure qui limitent ce que l’agent peut faire en tant que processus informatique.

La politique de gouvernance des données (domaine de la conformité) agit au niveau de l’accès aux données. Elle répond à des questions telles que : cet agent peut-il accéder à ce fichier précis ? Avec quelle autorisation — et qui est l’autorisateur humain ? Les données sont-elles chiffrées avec une cryptographie validée ? Chaque accès est-il consigné dans un journal infalsifiable ? Ce journal d’audit peut-il être relié à une exigence réglementaire précise ? Ce sont des contrôles au niveau des données qui limitent l’information accessible à l’agent et produisent les preuves exigées pour la conformité. Sans cette couche, les entreprises n’ont aucune base pour la gestion de la posture de sécurité des données alors que les agents IA se multiplient.

Le rapport prévisionnel 2026 de Kiteworks montre à quel point les entreprises sont éloignées des exigences de gouvernance des données pour l’IA. Seules 43 % disposent d’une passerelle centralisée pour les données IA. Dix-neuf pour cent ont assemblé des solutions ponctuelles sans politique cohérente. Sept pour cent n’ont aucun contrôle dédié à l’IA.

OpenShell ne traite aucun de ces manques au niveau des données. Ce n’est pas sa vocation. Il a été conçu pour sécuriser l’exécution des agents — un problème différent.

Ce que chaque cadre réglementaire exige réellement — et où OpenShell est insuffisant

Les réglementations ne régulent pas les agents. Elles régulent les données. Cette distinction est à la base du fossé de conformité.

HIPAA impose aux entités couvertes de mettre en place des contrôles d’accès sur les informations médicales protégées (§164.312(a)(1)), d’appliquer le principe du minimum nécessaire (§164.502(b)), de tenir des journaux d’audit des accès aux PHI (§164.312(b)) et d’appliquer un chiffrement aux PHI électroniques (§164.312(a)(2)(iv)). Imaginez un établissement de santé où un agent IA extrait des dossiers patients pour générer des comptes rendus de sortie. Cet agent est soumis à toutes ces exigences. Le sandbox d’OpenShell n’applique pas le principe du minimum nécessaire au niveau du fichier — il ne peut pas empêcher l’agent d’accéder à des dossiers de patients hors du workflow en cours. Il ne produit pas de journaux d’audit spécifiques aux PHI indiquant quels dossiers ont été consultés pour quel patient. Il n’applique pas de chiffrement validé FIPS 140-3 aux données au repos. Quand l’enquêteur de l’OCR demande la preuve des contrôles d’accès sur les interactions de l’agent avec les PHI, les garde-fous à l’exécution ne suffisent pas.

CMMC exige un accès autorisé aux informations non classifiées contrôlées avec des contrôles d’accès documentés (AC.1.001, AC.2.006), la journalisation des accès aux CUI (AU.2.042) et un chiffrement validé (SC.3.177). Un sous-traitant de la défense utilisant des agents IA pour traiter des dossiers techniques doit démontrer que chaque interaction d’agent avec des CUI a été autorisée par une personne identifiée, consignée au niveau de l’opération et chiffrée avec une cryptographie validée. Les garde-fous réseau d’OpenShell ne répondent pas à ces exigences précises. Un auditeur CMMC doit voir des chaînes de délégation reliant les actions de l’agent à des autorisateurs humains — ce qu’une couche de gouvernance des données seule peut fournir.

PCI DSS 4.0 impose un accès restreint aux données de titulaires de carte selon le besoin d’en connaître (Exigence 7), le chiffrement des données de carte (Exigence 4) et la journalisation de tous les accès (Exigence 10). Un agent OpenClaw traitant des données de paiement dans un runtime NemoClaw reste soumis à toutes ces exigences, quel que soit le niveau de sandboxing. Le QSA n’évaluera pas le runtime. Il vérifiera si l’accès aux données de carte était restreint, chiffré et journalisé selon les exigences PCI DSS.

SOX Section 404 impose des contrôles IT généraux sur les données financières, incluant la gestion des identités et des accès, la gestion des changements et les pistes d’audit. Un agent accédant à des données de reporting financier — extraction de chiffres trimestriels, rapprochement de comptes, génération de rapports — doit fonctionner sous les mêmes contrôles ITGC qu’un collaborateur humain. Ces contrôles doivent être démontrables aux auditeurs, avec des preuves disponibles à la demande.

Dans tous les cas, l’exigence réglementaire cible la couche données, pas la couche exécution. OpenShell sécurise l’exécution. Il ne rend pas l’accès aux données conforme.

L’exemple Microsoft : même les partenaires de NVIDIA font la distinction

La validation la plus forte de la distinction exécution/données vient des propres partenaires de NVIDIA. Microsoft Security a annoncé un partenariat avec NVIDIA sur l’apprentissage adversarial via Nemotron et OpenShell, Alexander Stojanovic, VP de l’équipe NEXT AI de Microsoft Security, évoquant « une amélioration de 160x dans la détection et la mitigation des attaques IA ». C’est un vrai progrès en matière de détection des menaces à l’exécution — pour identifier quand des agents sont manipulés, compromis ou détournés.

En parallèle, le blog sécurité de Microsoft a publié des recommandations détaillées pour exécuter OpenClaw en toute sécurité, conseillant de le traiter comme « exécution de code non approuvé avec identifiants persistants » et de ne le déployer que dans des environnements totalement isolés avec des identifiants dédiés et non privilégiés. Les recommandations précisent que les agents locaux héritent de tous les privilèges de la machine hôte, que la mémoire persistante signifie que toute donnée compromise reste accessible d’une session à l’autre, et que les outils de sécurité traditionnels peinent à détecter le comportement des agents.

Ces deux positions ne sont pas contradictoires. Elles sont complémentaires — et illustrent précisément l’architecture en couches décrite ici. Microsoft investit dans la protection à l’exécution via OpenShell (couche 2) tout en reconnaissant que la protection à l’exécution seule ne résout pas le risque d’accès aux données (couche 3). L’amélioration de 160x de Microsoft dans la détection des attaques IA permet d’identifier plus vite les agents compromis. Cela ne signifie pas que les données auxquelles ces agents ont accédé sont gouvernées, chiffrées ou auditées avec une chaîne de traçabilité conforme aux exigences d’un auditeur.

Si Microsoft — partenaire sécurité de NVIDIA — maintient cette distinction dans ses recommandations officielles, les RSSI d’entreprise doivent l’intégrer dans leurs décisions d’architecture.

L’écosystème Cisco et CrowdStrike : excellents sur les couches 1 et 2, silencieux sur la couche 3

L’écosystème qui se construit autour de NemoClaw renforce cette complémentarité. AI Defense de Cisco sécurise l’exécution des agents et fut l’une des premières solutions de sécurité d’entreprise intégrées à la stack NemoClaw. Le Blueprint Secure-by-Design de CrowdStrike intègre la détection des menaces directement dans les workflows de déploiement des agents. L’intégration LangChain permet le développement local d’agents avec des hooks de gouvernance au niveau de l’exécution.

Toutes ces fonctions de sécurité sont utiles. Et toutes agissent au niveau de l’exécution et de l’infrastructure. Aucune n’applique de règles ABAC sur les opérations individuelles de fichiers — elles ne font pas la différence entre un agent qui lit un dossier et un agent qui télécharge son contenu. Aucune ne produit de dossiers de preuves spécifiques à la conformité réglementaire (HIPAA, CMMC, PCI, SOX). Aucune ne conserve la chaîne de délégation de l’action de l’agent à l’autorisateur humain, lien exigé par les auditeurs. Aucune n’applique de chiffrement validé FIPS 140-3 aux données accédées par les agents au repos.

CrowdStrike a publié une analyse détaillée des risques de sécurité OpenClaw et a diffusé un pack de recherche et de suppression de contenu à l’échelle de l’entreprise via Falcon for IT. Leur priorité : la détection et la réponse — localiser les déploiements OpenClaw sur les endpoints gérés, comprendre l’exposition, remédier au risque. C’est un travail de couche 2, et il est important. Mais la couche 3 — gouverner les accès aux données par les agents, sous quels contrôles de conformité, avec quelles preuves d’audit — reste ignorée par tous les partenaires de l’écosystème NVIDIA. L’écosystème sécurise l’agent. Personne ne sécurise les données auxquelles l’agent accède.

Comment Kiteworks Compliant AI comble la couche conformité laissée ouverte par OpenShell

Kiteworks Compliant AI agit sur la couche 3 de l’architecture OpenClaw d’entreprise — la gouvernance des données IA et la conformité réglementaire. Il intercepte chaque interaction d’agent IA avec des données sensibles de l’entreprise, vérifie l’identité, applique la politique ABAC, utilise un chiffrement validé FIPS 140-3 et capture des journaux d’audit infalsifiables avant tout accès aux données. Il s’intercale entre les agents IA et les données réglementées dont ils ont besoin, gouvernant l’accès indépendamment du modèle, du runtime ou du framework agent.

L’architecture met en œuvre quatre exigences incontournables pour un accès conforme aux données IA. L’authentification de l’identité de l’agent vérifie chaque agent avant l’accès aux données et relie l’agent à l’autorisateur humain qui a délégué le workflow. L’application de la politique ABAC évalue chaque demande d’accès selon plusieurs dimensions : profil de l’agent, classification des données, contexte de la demande et opération spécifique. Le chiffrement validé FIPS 140-3 protège toutes les données accédées par les agents avec des modules cryptographiques conformes aux exigences d’audit fédérales et d’entreprise. Enfin, les pistes d’audit infalsifiables consignent chaque interaction — qui, quoi, quand, pourquoi — et alimentent directement les SIEM d’entreprise.

Le serveur Kiteworks Secure MCP régit les assistants IA interactifs (Claude, Copilot) via le Model Context Protocol avec authentification OAuth 2.0. La passerelle de données IA gère les pipelines RAG programmatiques et les workflows automatisés. Trois assistants gouvernés dédiés étendent la conformité aux opérations de données réglementées les plus courantes — gestion de fichiers, opérations sur dossiers, création de formulaires — chacun étant vérifié par identité, évalué ABAC, chiffré FIPS 140-3 et journalisé de façon infalsifiable. Les deux modes d’intégration appliquent la même gouvernance : les politiques Kiteworks Compliant AI s’appliquent systématiquement, quel que soit le mode d’intégration.

Ce n’est pas un concurrent d’OpenShell. C’est la couche dont OpenShell a besoin en dessous pour compléter la conformité. NemoClaw sécurise l’exécution des agents. Kiteworks Compliant AI gouverne et audite les données auxquelles ils accèdent, permettant aux entreprises de prouver leur conformité sur tous les cadres réglementaires.

Ce que les RSSI et responsables conformité doivent faire avant leur prochain audit de gouvernance IA

Premièrement, auditez votre architecture actuelle de gouvernance IA selon le modèle en trois couches. Cartographiez chaque contrôle existant à sa couche (calcul, exécution, données). Identifiez la couche la plus lacunaire. Pour 57 % des organisations selon le rapport prévisionnel 2026 de Kiteworks, il s’agit de la couche 3.

Deuxièmement, sensibilisez votre conseil d’administration à la différence entre politique d’exécution et politique de conformité avant qu’il n’entende « moteur de règles » et pense que le problème est résolu. Utilisez l’analogie Kubernetes : les politiques réseau ne satisfont pas votre auditeur, le sandboxing non plus. C’est d’autant plus crucial pour les organisations soumises à DORA et NIS 2, où les obligations de gestion des risques TIC incluent désormais explicitement les systèmes IA.

Troisièmement, cartographiez vos obligations réglementaires spécifiques (HIPAA, CMMC, PCI DSS, SOX) aux interactions des agents IA. Documentez les exigences applicables à l’accès aux données par les agents et vérifiez que vos contrôles actuels les couvrent. La plupart des organisations découvriront des lacunes importantes. Un audit formel des risques liés à l’accès aux données par les agents IA devient une attente réglementaire, plus seulement une bonne pratique.

Quatrièmement, déployez une gouvernance centralisée des données IA avant d’étendre les déploiements d’agents. Les organisations qui mettent en place l’infrastructure de gouvernance avant de passer à l’échelle évitent le coût d’une adaptation ultérieure. Chaque semaine sans gouvernance au niveau des données est une semaine d’interactions non gouvernées, impossibles à auditer a posteriori.

Cinquièmement, positionnez la gouvernance de la conformité comme accélérateur de l’IA lors de vos discussions internes. Les organisations qui déploient l’IA le plus vite sont celles qui passent le plus rapidement la revue de protection des données IA. Une gouvernance automatisée et intégrée remplace la validation manuelle de conformité qui bloque les projets IA dans toutes les entreprises réglementées.

Le compte à rebours conformité est lancé. Les dispositions à haut risque de l’AI Act européen seront pleinement applicables en août 2026. Gartner prévoit que plus de 50 % des grandes entreprises feront l’objet d’audits obligatoires de conformité IA d’ici la fin de l’année. Il faut bâtir la couche 3 avant l’arrivée de l’auditeur, pas après. 

Pour en savoir plus sur l’accompagnement Kiteworks, réservez votre démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Stratégies Zéro Trust pour une protection abordable de la confidentialité IA
• Article de blog
  Comment 77 % des organisations échouent sur la sécurité des données IA
• eBook
  Le fossé de la gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.