Agents IA en entreprise : le zero trust arrive. Ce qu’OpenShell (Nvidia) change à Lyon

Les agents IA, ce n’est plus du texte. C’est de l’exécution

Jusqu’ici, la sécurité des LLM en entreprise se résumait souvent à une peur simple : « il va dire n’importe quoi » ou « il va fuiter un document ». Avec les agents IA, le problème grossit et change de nature. Un agent ne se contente pas de répondre. Il agit. Il appelle des API, ouvre des tickets, modifie un CRM, pousse du code sur Git, envoie des mails, lance des commandes, manipule des fichiers.

Donc la question pour une DSI ou un RSSI à Lyon n’est plus « est-ce que le modèle hallucine ? ». C’est « qu’est-ce qu’on autorise à s’exécuter, où, avec quelle identité, et comment on le prouve après coup ». C’est là que la logique zero trust IA s’impose : traiter l’agent comme non fiable par défaut, et contrôler son exécution en temps réel.

Ce papier prend un exemple concret côté industrie : OpenShell (NVIDIA), un runtime open source qui illustre une approche « confinement + contrôle d’exécution ». Pas pour en faire la promo. Pour en tirer des principes transposables, surtout si tu as déjà des pilotes d’agents (ou pire, une agentic stack fragmentée) dans ta boîte lyonnaise.

Pourquoi les agents IA explosent la surface de risque

Un agent, dans sa version « entreprise », c’est rarement juste un LLM. NVIDIA résume bien l’idée : il faut mettre des contrôles d’exécution autour d’un agent existant, sans lui faire confiance. Source : billet NVIDIA Developer sur les runtime controls. (developer.nvidia.com)

Dans la pratique, un agent c’est :

• un LLM (cloud, on-prem, open weights, peu importe),
• des outils (connecteurs SaaS, API internes, RPA, scripts),
• des identités (comptes techniques, OAuth, SSO),
• des secrets (tokens, clés API, certificats),
• de l’exécution (runtime, réseau, filesystem, shells, conteneurs).

Le risque n’est plus le texte généré. Le risque, c’est la chaîne d’actions que l’agent peut enchaîner automatiquement, parfois très vite, parfois 24/7, parfois sans qu’un humain ne relise. Et si tu as plusieurs plateformes d’agents, tu multiplies les chemins possibles.

Des incidents « agentic » déjà déclarés, et une stack souvent éclatée

La Cloud Security Alliance (CSA) indique que près d’une organisation sur deux déclare avoir subi un incident de sécurité lié à des agents IA. Source CSA, 15 avril 2026. (cloudsecurityalliance.org)

Même source, autre signal : la fragmentation est la norme. 5% n’utilisent qu’une seule plateforme agentique, 44% en utilisent 2 à 3, 43% en utilisent 4 ou plus. (cloudsecurityalliance.org)

Traduction terrain côté DSI lyonnaise : tu as un agent dans M365, un autre dans ton outil ITSM, un POC dans un framework dev, et une automatisation low-code qui « fait agent » sans dire son nom. La gouvernance des agents IA devient vite un sujet d’architecture et de contrôle interne, pas un sujet « innovation ».

Trois erreurs classiques qui te mettent dedans

• Penser que des garde-fous prompt suffisent. OWASP rappelle que la surface d’attaque, c’est le système complet : modèle, prompts, RAG, outils et permissions derrière les outils. Et surtout les scénarios d’injection indirecte via contenus ingérés. (owasp.github.io)
• Donner à l’agent des accès “comme un humain”. Comptes partagés, tokens longue durée, droits trop larges. Sauf qu’un agent est continu, API-driven, et peut industrialiser une erreur ou une compromission. CSA insiste sur ce piège. (cloudsecurityalliance.org)
• Laisser les contrôles dans le périmètre de l’agent. Si la politique, le contrôle ou la capacité d’audit est manipulable par l’agent, tu joues à te faire contourner. NVIDIA met en avant que les contrôles doivent être hors de portée de l’agent. (developer.nvidia.com)

Zero trust IA : ce que ça veut dire, concrètement, pour un RSSI

Le zero trust appliqué aux agents IA, ce n’est pas un slogan. C’est une posture :

• Ne jamais considérer l’agent comme “de confiance”. Même si le code est à toi. Même si le modèle est « enterprise ». Même si c’est dans ton cloud.
• Accès juste à temps. L’agent n’a pas des droits permanents « au cas où ». Il obtient un accès ponctuel, borné, traçable.
• Périmètre strict. Réseau, services, filesystem, commandes, tout est limité.
• Preuve et traçabilité. Tu dois pouvoir répondre à : qui a fait quoi, quand, avec quel secret, dans quel contexte, et pourquoi c’était autorisé.

C’est exactement l’esprit décrit dans l’architecture de référence autour d’OpenShell : agent considéré untrusted, contrôles centralisés, politiques appliquées à l’exécution. Source NVIDIA Developer. (developer.nvidia.com)

OpenShell (Nvidia) : l’idée à retenir, sans le packaging

OpenShell est présenté comme un runtime open source qui apporte des contrôles d’exécution aux agents : isolation, contrôle d’accès, gestion de credentials, audit, politiques. Source : dépôt GitHub. (github.com)

Ce qui est intéressant ici, ce n’est pas « OpenShell ou pas OpenShell ». C’est le pattern : plutôt que de bricoler des prompts et des règles applicatives, tu poses une couche d’exécution qui contrôle ce que l’agent peut faire.

1) Confinement : le sandbox comme ceinture de sécurité

Premier pilier : confinement. L’agent tourne dans un sandbox qui borne :

• les process qu’il peut lancer,
• le filesystem qu’il peut lire ou écrire,
• les sorties réseau (egress),
• l’injection et l’usage de credentials,
• la production de logs locaux utiles à l’audit.

Source : doc OpenShell “How it works”. (docs.nvidia.com)

Point RSSI : le sandbox ne rend pas l’agent « sûr ». Il rend l’échec moins catastrophique. Et ça change beaucoup quand l’agent a un accès à un shell, à Git, ou à des connecteurs sensibles.

2) Contrôle d’exécution : décider en dehors de l’agent

Deuxième pilier : contrôle d’exécution et gouvernance. L’architecture décrite met en avant une séparation avec une passerelle et un superviseur (Gateway, Supervisor), plus une CLI côté opérateur. L’objectif : appliquer des politiques de sécurité de façon centralisée, sans dépendre de la bonne foi du code agent. Source : doc “How it works”. (docs.nvidia.com)

Traduction terrain : l’agent demande “je veux appeler tel service” ou “je veux exécuter telle action”. Et un composant externe dit oui ou non, journalise, et impose des limites. Tu n’es plus dans le « l’agent a déjà les clés et on espère ». Tu es dans le « l’agent obtient le minimum, au moment où c’est requis ».

3) Vérification formelle des politiques : limiter les angles morts

OpenShell met en avant la formal policy verification pour analyser ou valider si des permissions demandées restent dans des bornes définies. Source NVIDIA Developer. (developer.nvidia.com)

Sans rentrer dans le formalisme : l’idée est bonne pour la gouvernance agents IA. Tu veux éviter les politiques “texte” ambiguës, ou les exceptions empilées. Tu veux des règles testables, versionnées, auditables.

4) Industrialisation : le signal Kubernetes

Un billet CNCF (4 novembre 2026) décrit un déploiement “OpenShell on Kubernetes” et insiste sur la séparation control path / data path, avec un exemple de versions (OpenShell 0.1.3, Agent Sandbox v1.0.5, Kubernetes 1.35, Cilium 1.20, Kyverno 1.18.2). Source CNCF. (cncf.io)

Pour une DSI lyonnaise déjà sur Kubernetes, c’est un repère : ce type de runtime se pense comme une brique platform, pas comme un script dans un coin.

Les risques concrets à expliquer aux métiers (et à tes équipes)

Si tu veux faire passer des contrôles, il faut des scénarios simples. Voilà ceux qui reviennent le plus avec les agents connectés à des outils.

Tool misuse et excessive agency : l’agent “trop autonome”

L’agent a le droit d’écrire dans Git. Il corrige un bug, puis “améliore” autre chose, puis pousse sur la mauvaise branche, puis déclenche un pipeline. Ou il a le droit d’envoyer un mail, et il envoie à trop large. Ou il modifie un ticket ITSM, et il ferme un incident encore actif.

Ce sont des cas d’agency excessive : l’agent a trop de marge de manœuvre. OWASP Top 10 for LLM Applications (2025) couvre ces familles de risques, notamment tool misuse. (owasp.org)

Indirect prompt injection : l’ordre malveillant est dans le document

L’instruction malveillante n’est pas dans le prompt initial. Elle est dans une page web, un PDF, une issue Git, un ticket support. L’agent la lit via un outil (RAG, navigateur, connecteur), puis exécute des actions derrière.

OWASP recommande explicitement de tester ces scénarios, car ils touchent les sorties d’outils et les données ingérées. (owasp.github.io)

Secrets sprawl : plus d’outils, plus de clés, plus de fuites

Chaque connecteur ajoute des tokens, des scopes OAuth, des comptes de service. Plus tu branches, plus tu crées des secrets à gérer. Et plus tu augmentes la proba qu’un token traîne dans un log, un repo, une variable d’environnement, ou qu’il soit trop permissif.

Si tu veux du concret côté Lyon IA, tu peux recouper avec une logique déjà posée sur le site : 1Password for Agents et gestion des secrets : autoriser des agents IA sans fuite.

Grille d’adoption locale à Lyon : quand ça vaut le coût, quand c’est trop tôt

Tu n’as pas besoin d’un runtime type OpenShell pour chaque usage. Tu en as besoin quand tu bascules de “assistant” à “agent qui agit”. Voilà une grille simple.

Cas où une approche zero trust IA devient vite indispensable

• Accès à des systèmes de prod : CI/CD, infra, IAM, ITSM, outils d’admin.
• Écriture dans des systèmes critiques : CRM, ERP, référentiels, Git, bases de connaissances “source of truth”.
• Actions externes : envoi d’emails, messages clients, paiements, commandes, publication.
• Agents multi-étapes : planification, exécution, vérification, puis nouvelle exécution.
• Contexte réglementaire fort : santé, finance, industrie critique, secteur public, et tout ce qui attire les audits.

Cas où tu peux temporiser (mais pas ignorer la sécurité)

• Agent en lecture seule sur une base documentaire interne, avec sortie non automatique (un humain valide).
• Automatisation limitée à un bac à sable (données non sensibles, environnements isolés).
• Usage ponctuel, sans connecteurs “écriture”, et sans secrets persistants.

Les prérequis côté DSI/RSSI (avant de parler “runtime”)

Le zero trust IA se casse la figure si tu n’as pas le socle. Voilà l’ordre logique.

1) Identités : pas de comptes partagés, pas de tokens longue durée

• Une identité par agent (ou par classe d’agent), avec des droits minimaux.
• Scopes courts et rotation.
• Séparation dev, test, prod.

Si tu dois convaincre en interne, rappelle le point CSA : donner à l’agent des accès “comme un humain” est un piège, car l’agent opère en continu. (cloudsecurityalliance.org)

2) Secrets : centraliser, injecter au bon moment, tracer

• Un vault ou gestionnaire de secrets, pas des variables d’environnement dans tous les sens.
• Injection just-in-time quand l’action est autorisée.
• Révocation rapide si incident.

3) Logs et audit : si tu ne peux pas prouver, tu ne maîtrises pas

• Journaliser les appels d’outils (quel outil, quels paramètres, quel résultat, quel statut).
• Corrélation avec l’identité de l’agent et le contexte (ticket, demande, utilisateur initiateur).
• Détection des comportements anormaux (volume, destinations réseau, patterns d’erreurs).

Sur Lyon IA, un angle utile à relire avant d’automatiser : Agents IA et cybersécurité : effacement de traces, audit des logs et accès avant d’automatiser.

4) Gouvernance agents IA : qui a le droit de créer quoi, avec quels connecteurs

• Un registre des agents : owner, objectifs, outils branchés, environnements, données manipulées.
• Un process de revue : ajout d’un connecteur = revue sécurité, pas un clic.
• Des tests orientés attaques agentic : injection indirecte, tool misuse, escalade via connecteurs.

Si tu veux un point de départ opérationnel sur le site : Agents IA : 10 garde-fous avant d’automatiser en entreprise (accès, données, actions) et Shadow AI en entreprise : détecter et cadrer les usages IA non autorisés (checklist RSSI Lyon).

Si tu n’as pas la pile “runtime” : mesures minimales qui font déjà la différence

Tout le monde n’a pas Kubernetes, Cilium, Kyverno et une platform team dispo. Pas grave. Tu peux poser des contrôles simples, maintenant.

Mesure 1 : lecture seule par défaut, écriture sous validation

• Connecteurs en read-only tant que le risque n’est pas cadré.
• Actions d’écriture avec validation humaine (workflow d’approbation).

Mesure 2 : egress réseau verrouillé

• Liste blanche de domaines et API autorisées.
• Blocage des sorties arbitraires (exfiltration via “un connecteur quelconque”).

Mesure 3 : un compte de service par outil, scopes minimaux

• Pas de token “admin” qui fait tout.
• Un token par usage, par environnement, avec expiration.

Mesure 4 : sandbox basique

• Exécution dans un conteneur ou VM dédiée.
• Filesystem éphémère quand c’est possible.
• Pas d’accès direct aux partages sensibles.

Mesure 5 : logs exploitables et alertes simples

• Centraliser les logs des actions agent (outils appelés, erreurs, volumes).
• Alertes sur : pics d’appels API, destinations nouvelles, tentatives de commandes interdites.

Plan d’action 30 jours pour une DSI/RSSI à Lyon

Objectif : passer de “on teste des agents” à “on sait ce qu’ils peuvent faire, et on peut le prouver”.

Semaine 1 : inventaire et stop aux accès trop larges

• Liste des agents et automatisations “agent-like” (y compris low-code).
• Liste des outils branchés, et surtout ceux en écriture.
• Coupure des comptes partagés et tokens longue durée quand c’est identifié.

Semaine 2 : socle identité, secrets, egress

• Identité dédiée par agent ou par famille.
• Gestion des secrets centralisée, rotation, révocation.
• Règles egress réseau et whitelists sur les environnements agent.

Semaine 3 : politiques et tests orientés agentic

• Écriture d’une politique simple : quels outils, quelles actions, quelles validations.
• Jeux de tests : injection indirecte, tool misuse, permissions excessives. OWASP donne le cadre de test. (owasp.github.io)

Semaine 4 : contrôle d’exécution ou garde-fous équivalents

• Si tu as la plateforme : évaluer un runtime de type “confinement + contrôle d’exécution” (OpenShell illustre le pattern).
• Sinon : valider un mode “lecture seule + approbation + logs + egress” comme standard interne.
• Mettre en place un processus d’onboarding agent : ajout d’un connecteur = revue sécurité et traçabilité.

Ce qu’il faut retenir pour sécuriser vos agents IA à Lyon

Les agents IA en entreprise déplacent le risque : on quitte la génération de texte, on entre dans l’exécution d’actions. Les incidents existent déjà à grande échelle (CSA). La réponse qui monte, c’est le zero trust IA : agent non fiable par défaut, accès just-in-time, confinement, audit, politiques hors de portée de l’agent.

OpenShell (NVIDIA) est un bon prétexte pour comprendre le pattern “sandbox + contrôle d’exécution” : même si tu ne l’adoptes pas, c’est la direction. Si tu dois démarrer petit, impose au moins lecture seule par défaut, secrets propres, egress verrouillé, identité dédiée, logs exploitables. Et garde une règle simple : si l’agent peut écrire ou exécuter, tu dois pouvoir le limiter et le retracer.

Pour compléter côté terrain lyonnais, tu peux aussi recouper avec : Sécuriser un agent IA qui a accès à vos outils et IA agentique et sécurité : pourquoi vos agents IA sont un nouveau risque.