Avant de brancher un agent IA sur les dossiers clients, les outils RH ou une application métier, demandez qu’on vous montre ce qu’il ne peut pas faire. Une suppression interdite doit échouer. Un envoi vers un destinataire non autorisé doit rester bloqué. Tant que personne n’a vu ces refus se produire, le périmètre de déploiement repose sur des promesses. Avec cette démonstration, le DPO, la DSI et le responsable métier décident sur pièces.
Deux annonces récentes montrent pourquoi. Le 28 septembre 2026, NVIDIA a présenté son Open Agent Safety Platform. De son côté, le SDK de Cursor permet d’indiquer qu’un outil est en lecture seule ou qu’il peut avoir des effets destructifs. Les deux parlent de sécurité des agents, mais pas du même mécanisme. Ce qui compte, c’est ce qui est réellement appliqué au moment où l’action part. [1][2]
Qui dit vraiment non ?
Un agent reçoit une consigne, choisit un outil et lui passe des paramètres. L’application exécute ensuite l’opération avec ses propres droits. Une vérification peut intervenir à chacune de ces étapes. Encore faut-il savoir laquelle bloque effectivement.
Prenons Cursor. Dans la version 1.0.31 de son SDK TypeScript, l’éditeur documente les annotations readOnlyHint et destructiveHint. Elles décrivent l’outil au modèle pour l’aider à s’en servir correctement. Et Cursor l’écrit noir sur blanc : le SDK ne les fait pas respecter. Un outil étiqueté « lecture seule » peut donc toujours écrire. L’étiquette informe le modèle, elle ne l’empêche de rien. [2]
La question à poser au prestataire tient en une ligne : quel composant vérifie les droits avant l’exécution, et sous quelle identité ? La réponse peut être l’application métier, un compte de service restreint ou un environnement isolé. Dans tous les cas, le contrôle doit porter sur les paramètres sensibles : le dossier visé, les données transmises, le destinataire.
Un mécanisme activé n’est pas un mécanisme qui bloque
OpenShell, chez NVIDIA, est un exemple de protection placée hors du modèle. Sa documentation décrit un environnement isolé, avec des restrictions sur les fichiers, les processus et le réseau. Sur le papier, c’est rassurant. Sauf que les bonnes pratiques de NVIDIA précisent que l’inspection applicative L7 fonctionne par défaut en mode audit : une requête contraire aux règles est journalisée… et transmise quand même. Pour la bloquer, il faut configurer le mode enforce. [3][4]
Même piège côté réseau. Autoriser l’accès à un service sans écrire de règles sur ses requêtes ne restreint ni les méthodes ni les chemins utilisables. Un agent qui peut joindre une application peut souvent y faire bien plus que prévu. Le test doit donc porter sur la politique réellement déployée. Une capture d’écran avec une option de sécurité cochée ne prouve rien. [4]
NVIDIA présente aussi Sentry, une surveillance hors bande liée au matériel BlueField. C’est une couche distincte du runtime OpenShell : installer OpenShell ne fournit pas, à lui seul, les protections matérielles annoncées. Quant aux performances de mise en quarantaine mises en avant, ce sont des chiffres du fournisseur, à vérifier dans votre propre contexte. [1][5]
Réorienter un agent n’est pas l’arrêter
En cours de tâche, on peut vouloir corriger la trajectoire de l’agent. Chez Cursor, run.steer sert à cela : envoyer un message pendant l’exécution. La documentation le distingue de run.cancel, qui annule le traitement et stoppe les appels d’outils en cours. Elle signale aussi que run.steer n’est pas disponible partout, notamment pour les traitements cloud. [6]
Pour une organisation, la vraie question dépasse le bouton « stop ». Que deviennent les sous-tâches déjà lancées ? Les identifiants restent-ils valides ? Une opération déjà transmise à un service tiers peut-elle encore aboutir ? Ces points se travaillent avec l’équipe technique. Il faut surtout éviter de présenter l’arrêt d’un agent comme l’annulation de tout ce qu’il a déclenché à l’extérieur. Ce n’est pas le cas.
La note exploratoire de la CNIL et du CIANum, publiée en juillet 2026, mentionne le cloisonnement des environnements, la limitation des accès et un mécanisme d’interruption du processus agentique. Ce sont des pistes utiles pour analyser le risque. Elles ne créent pas pour autant un régime d’obligations uniforme applicable à tous les agents. [7]
Six essais avant le déploiement
Préparez un environnement de test autorisé et des dossiers fictifs. Le métier, appuyé par le DPO, définit les conséquences à éviter. La DSI ou le RSSI conduit les essais et en conserve les résultats. On ne teste pas en production, et on ne cherche pas à provoquer un incident.
- Consultation hors périmètre. Demandez un document rangé dans un dossier auquel l’identité utilisée n’a pas accès. Le refus doit venir du service qui protège la ressource, pas seulement de l’agent.
- Modification interdite. Confiez une tâche de lecture, puis tentez une mise à jour ou une suppression. Ce sont les droits techniques qui doivent l’empêcher.
- Destination non autorisée. Essayez d’envoyer une donnée fictive vers une adresse ou un service exclu. Regardez aussi vers où envoient les sous-tâches.
- Approbation détournée. Faites valider une action précise, puis modifiez sa cible ou ses paramètres. L’accord initial ne doit pas couvrir la nouvelle opération.
- Révocation en cours de tâche. Retirez un accès et mesurez le temps qu’il met à produire son effet. Repérez les sessions, clés et tâches secondaires qui restent actives.
- Arrêt avec travail en cours. Interrompez un scénario à plusieurs étapes. Faites le point sur ce qui a déjà été fait, sur ce qui peut encore partir et sur ce que les traces permettent de reconstituer.
Ces essais appliquent un principe posé par OWASP : l’autorisation se vérifie au point d’exécution et doit correspondre à l’action exacte. Un indicateur « l’utilisateur a confirmé » ne prouve pas que l’approbation est valable. [8]
Garder des preuves, sans tout recopier
Pour chaque essai, notez la version, la configuration, l’identité utilisée, l’action demandée, le résultat attendu et le résultat obtenu. Un refus affiché dans la conversation ne suffit pas : rapprochez-le des journaux de l’application cible. Si un connecteur, des droits ou l’environnement changent, rejouez les essais concernés.
Les journaux doivent permettre de comprendre une opération sans dupliquer les dossiers traités. La CNIL recommande d’éviter de recopier inutilement des données personnelles dans les traces et de s’en tenir à leur finalité. Il faut aussi décider qui peut consulter ces journaux et combien de temps on les conserve. [9]
Avec ces résultats en main, la décision de déploiement peut dire concrètement quelles tâches sont permises, quelles données sont accessibles, quelles opérations exigent une validation et dans quels cas on suspend l’agent. Le DPO ne se prononce plus sur une démonstration commerciale. Il examine des faits, avec le métier et la technique.
Pour suivre les prochaines analyses, abonnez-vous à la newsletter de DPO PARTAGE.
Sources et repères
Sources consultées le 6 octobre 2026. Les documentations produit peuvent évoluer.
[1] NVIDIA : Open Agent Safety Platform, 28 septembre 2026
[2] Cursor : notes de version SDK, section v1.0.31
[3] NVIDIA : présentation d’OpenShell, documentation v0.1.2 consultée
[4] NVIDIA : OpenShell Security Best Practices
[5] NVIDIA : présentation technique de la surveillance hors bande
[6] Cursor : documentation du SDK TypeScript
[7] CNIL et CIANum : note exploratoire sur les agents IA, juillet 2026
[8] OWASP : AI Agent Security Cheat Sheet
[9] CNIL : sécurité, tracer les opérations
