Un agent IA peut raisonner, utiliser des outils et adapter ses actions aux données qu’il rencontre. Cette souplesse élargit aussi le périmètre du risque : protéger uniquement le modèle ne suffit pas. Les recommandations de NVIDIA encadrent donc le code, les données, les identités, les services et l’infrastructure qui entourent l’agent.
Limiter dès le départ l’identité et la mission de l’agent
Attribuez à chaque agent une identité traçable et des identifiants limités à la tâche prévue. Avant le déploiement, définissez les actions autorisées : fiches qu’il peut modifier, outils qu’il peut appeler et destinations auxquelles il peut accéder.
L’exemple présenté par NVIDIA distingue clairement deux permissions souvent confondues : pouvoir modifier une fiche client ne donne pas automatiquement le droit d’exporter les données de ce client. Cette séparation doit être inscrite dans la politique d’accès, plutôt que laissée à l’interprétation du modèle.
Une demande d’accès supplémentaire doit rester hors du pouvoir de l’agent. Celui-ci peut signaler qu’une permission plus large est nécessaire, mais il ne doit ni approuver sa propre demande ni appliquer seul le changement. Les actions sensibles et les modifications de permissions restent soumises à une approbation humaine. Le compromis est concret : le workflow peut être interrompu lorsqu’une tâche s’élargit, mais l’identité créée pour une mission précise ne devient pas un identifiant à usage général.
Placer les limites d’exécution en dehors du raisonnement
L’environnement d’exécution doit limiter indépendamment les fichiers accessibles, les destinations réseau et les processus autorisés. Ces restrictions doivent continuer de s’appliquer lorsque l’agent produit une instruction dangereuse ou suit un contenu malveillant.
Dans le scénario décrit par NVIDIA, une instruction dissimulée dans un document joint pousse l’agent à tenter d’exporter des données client vers une destination non autorisée. Une politique réseau doit bloquer ce transfert à la frontière de l’environnement d’exécution. L’agent ne doit pas pouvoir contourner cette restriction en modifiant son raisonnement ou en demandant une route plus large.
NVIDIA présente OpenShell comme un environnement d’exécution sécurisé open source qui applique des politiques hors de portée de l’agent et fournit une exécution en bac à sable. La même source cite Cisco DefenseClaw pour la gouvernance et JFrog pour analyser et vérifier les skills, ainsi que pour contrôler les skills disponibles.
Ces exemples couvrent plusieurs niveaux d’un même principe : le composant qui décide d’une action ne doit pas pouvoir réécrire seul la règle qui le limite. Sans cette séparation, une restriction déclarée dans le workflow ne constitue pas une frontière de déploiement fiable.
Considérer les documents, les outils et les skills comme des surfaces d’attaque
Lorsqu’un agent peut appeler des outils, un document joint n’est pas seulement une source de contexte. Il peut contenir des instructions qui réorientent le workflow vers un export de données ou une autre action non autorisée. Alignez donc l’accès aux données, aux outils et au réseau sur la mission déclarée, et rendez chaque permission explicite.
La même discipline s’applique aux skills et aux workflows. Analysez et vérifiez les skills avant de les rendre disponibles, puis limitez la sélection à ce qu’exige la tâche. Vous réduisez ainsi le nombre de chemins qu’une instruction inattendue peut activer.
Cette approche réduit la flexibilité de l’agent. Lorsqu’une mission s’élargit réellement, il faudra demander une décision humaine ou modifier le workflow. Cette interruption est le compromis à accepter pour éviter qu’une nouvelle instruction ne se transforme directement en autorité supplémentaire.
Conserver la preuve de chaque décision importante
Les journaux protégés doivent enregistrer l’appel d’outil, la décision d’autorisation et le résultat. Conserver uniquement l’issue finale ne permet pas de savoir à quel moment une frontière a été sollicitée ou franchie.
Dans le scénario du document malveillant présenté par NVIDIA, les enregistrements doivent permettre de retrouver l’appel d’outil tenté, l’autorisation bloquée et l’action qui a suivi. Protégez ces journaux contre les modifications et désignez la personne ou l’équipe chargée de leur examen.
La piste d’audit n’a pas pour but de conserver une transcription exhaustive sans usage opérationnel. Elle doit répondre à trois questions : ce que l’agent a tenté de faire, quelle politique l’a autorisé ou bloqué, et ce qui s’est passé ensuite.
Tester les frontières avant d’autoriser la production
Avant le déploiement, vérifiez que l’agent ne peut pas obtenir des identifiants hors de son périmètre, envoyer des données sensibles vers une destination interdite, modifier ses permissions ou perturber la supervision. Ces tests évaluent la séparation entre le raisonnement de l’agent et le système qui le contient.
- Tentez d’obtenir un identifiant hors périmètre. Vérifiez que la demande est refusée ou soumise à une approbation humaine.
- Fournissez un chemin vers une destination de données non autorisée. Vérifiez que la politique réseau bloque le transfert.
- Tentez de modifier une permission. Confirmez que l’agent ne peut ni approuver ni appliquer seul ce changement.
- Tentez de modifier ou de contourner la supervision. Confirmez que les journaux protégés enregistrent toujours l’appel, la décision et le résultat.
Répétez cette série après toute modification importante du modèle, des outils ou des workflows. NVIDIA demande également qu’un responsable désigné décide si l’agent peut entrer en production et déclenche une remédiation lorsqu’une protection échoue. La réussite d’un test précédent ne suffit donc pas à établir qu’une version modifiée conserve le même périmètre de risque.
Relier ces contrôles à la gouvernance de l’organisation
IBM a indiqué le 8 juin 2026 que 77 % des 2 000 responsables technologiques interrogés estimaient que l’adoption de l’IA progressait plus vite que les capacités de gouvernance de leur organisation. La même étude indique que 59 % considéraient la sécurité et la conformité comme des obstacles majeurs au déploiement des agents. Selon le rapport d’IBM, les organisations ayant intégré le contrôle à leurs systèmes connaissaient 25 % d’incidents en moins.
Ces chiffres décrivent une pression générale sur la gouvernance ; ils ne remplacent pas les tests des permissions et de l’environnement d’exécution d’un agent donné. IBM a également annoncé le 15 avril 2026 une évaluation de cybersécurité destinée à révéler les failles de sécurité, les faiblesses des politiques, les expositions propres à l’IA et les voies d’exploitation.
IBM décrit par ailleurs son service IBM Autonomous Security comme un service multi-agents qui analyse les expositions et les environnements d’exécution, applique des politiques, détecte les anomalies, contient les menaces et alimente les systèmes de gouvernance et de gestion des risques. Ces éléments rattachent les contrôles techniques de l’agent aux processus de sécurité plus larges, sans dispenser l’équipe de vérifier les actions réellement permises par sa configuration.
Valider ce qui peut changer avant la mise en production
L’agent peut adapter ses actions à de nouvelles données, mais son identité, ses identifiants, ses limites d’exécution, ses points d’approbation et sa piste d’audit doivent continuer à s’appliquer. Si une tâche nécessite un accès plus large, arrêtez le workflow, révisez la politique ou obtenez l’approbation humaine requise. Ne laissez pas l’agent étendre lui-même son autorité.
La mise en production est justifiée lorsque les limites bloquent les cas d’échec définis, que les journaux conservent les éléments nécessaires et qu’un responsable désigné accepte le résultat. Après un changement important du modèle, d’un outil ou d’un workflow, relancez les tests de frontière avant de remettre l’agent en service.