Sécurité des agents IA : comment l'informatique doit-elle contrôler l'accès non humain aux applications professionnelles ?

La sécurité des agents d'IA devient critique lorsque des logiciels autonomes peuvent accéder aux applications professionnelles, récupérer des données sensibles et effectuer des actions sans intervention humaine continue. Pour les équipes informatiques, le défi est de déterminer quelle identité, quel accès et quelle portée leur accorder pour allier efficacité et protection.

À mesure que les organisations intègrent des agents d'IA dans les flux de travail quotidiens, les administrateurs système et les responsables de la sécurité doivent étendre les politiques d'accès au-delà des utilisateurs humains et des comptes de service traditionnels. Ce guide explique comment gérer les identités non humaines, appliquer le principe du moindre privilège et protéger à la fois les applications modernes et héritées. Je propose des mesures pratiques pour les administrateurs système, les équipes informatiques et les MSP qui cherchent à adopter l'IA tout en minimisant l'exposition.

Pourquoi l'accès de l'agent IA crée-t-il de nouveaux problèmes de sécurité ?

La gestion d'accès traditionnelle distingue généralement les utilisateurs humains des applications et des services. Les agents d'IA compliquent ce modèle car ils peuvent interpréter des informations, sélectionner des outils et initier des opérations en fonction des circonstances changeantes.

Automatisation, mais pas comme nous la connaissons :

Contrairement à l'automatisation conventionnelle, où les actions sont généralement prédéfinies, un agent IA peut déterminer quelles étapes suivre tout en travaillant vers un objectif plus large. Les variables que cela introduit ont une portée considérable, car que ce soit par erreur, manque de référence ou instruction malveillante, l'IA pourrait facilement dépasser les autorisations, entraînant des résultats indésirables. Pour les équipes informatiques, l'action initiale consiste à définir le but d'un agent IA et les limites applicables avant d'accorder l'accès à la production.

De la lecture des données commerciales à l'action sur celles-ci :

Considérez un agent IA déployé pour récupérer des dossiers de factures, comparer des informations de paiement et produire un rapport d'exception. Quelles restrictions et mesures de protection peuvent être mises en place pour prévenir des actions incorrectes au sein de l'application comptable ?

L'authentification n'est pas égale à l'autorisation :

Alors que l'authentification établit quelle identité tente d'accéder à une ressource, l'autorisation détermine quelles opérations cette identité peut effectuer. Pour les agents d'IA, ces décisions doivent rester séparées.

Un agent authentifié avec succès ne devrait recevoir que les autorisations pertinentes à sa tâche, les ressources nécessaires et restreintes par les conséquences potentielles de l'action.

Dans son 2026 travail sur l'identité des logiciels et des agents IA NIST souligne la nécessité de traiter l'identité, l'autorité, l'audit et la responsabilité des agents d'IA.

L'objectif de sécurité n'est pas seulement de décider quelles applications un agent peut ouvrir. Il doit contrôler ce que l'agent peut faire une fois l'accès accordé.

Quelle identité un agent IA devrait-il utiliser ?

Les agents d'IA ont besoin d'identités identifiables et gérables afin que les administrateurs puissent attribuer des autorisations, surveiller l'activité et révoquer l'accès si nécessaire.

Identités dédiées et informations d'identification de charge de travail

Là où cela est pris en charge, créez une charge de travail ou une identité d'agent, liée à un propriétaire nommé et à une fonction spécifique, pour suivre la responsabilité et verrouiller les privilèges à la tâche requise.

De plus, cela aide à distinguer l'activité automatisée de l'activité humaine, à appliquer des politiques de sécurité dédiées et à désactiver l'agent sans affecter l'accès d'un employé, comme dans Microsoft Entra Agent ID. L'objectif est de garder les agents IA étroitement définis, bien documentés et indépendamment audités.

Accès délégué versus accès autonome

Les agents d'IA peuvent fonctionner selon différents modèles d'autorisation.

Accès délégué permet à un agent d'agir au nom d'un utilisateur humain, dans le cadre de permissions strictes qui lui sont explicitement déléguées, potentiellement seulement pour une durée déterminée.

Accès autonome permet à un agent d'opérer sous sa propre identité et ses autorisations assignées, sans nécessiter une session humaine active. Il est donc important que les politiques d'accès et les contrôles de cycle de vie soient définis pour les agents IA autonomes ainsi que pour la propriété.

Une note sur la MFA

Les comptes partagés rendent difficile de déterminer d'où provient une action : d'un employé, d'un agent IA ou d'un autre processus automatisé. Un agent IA ne devrait pas dépendre des identifiants d'un employé, surtout pas pour une automatisation de routine.

Bien que l'authentification multi-facteurs (MFA) soit précieuse pour l'accès humain, des mécanismes d'identité de charge de travail soutenus de manière autonome sont nécessaires. Quelques exemples, selon l'application et l'infrastructure d'identité :

• identités gérées,
• identifiants fédérés,
• certificats
• ou des jetons de courte durée.

Comment l'informatique devrait-elle restreindre ce à quoi les agents d'IA peuvent accéder ?

Ici, le principe du moindre privilège est essentiel, pour donner accès uniquement aux ressources et opérations nécessaires à un but approuvé.

Le moindre privilège à travers les applications, les outils et les données

• Permissions de l'outil : Quelles API, scripts, intégrations et outils d'exécution l'agent peut-il invoquer ?
• Autorisations d'application : Quelles applications et fonctions commerciales peut-il accéder ?
• Permissions de données : Quels enregistrements, dossiers, fichiers ou bases de données peut-il lire ? Peut-il modifier ?
• Permissions système : Peut-il exécuter des commandes, accéder au système d'exploitation ou effectuer des opérations administratives ?

L'accès à l'agent IA doit être considéré à ces niveaux, et aucune autorisation ne doit être accordée sur simple demande. Ces couches doivent également se renforcer mutuellement.

Les autorisations d'application doivent également rester applicables indépendamment des paramètres du modèle d'IA. Un message indiquant à un agent de ne pas modifier les détails de paiement n'est pas équivalent à un contrôle technique empêchant la modification.

Pour les organisations renforçant l'infrastructure d'accès existante, notre Principes de Zero Trust pour l'accès à distance des PME aborder la vérification d'identité, le principe du moindre privilège et la restriction de l'exposition.

Accès limité dans le temps et opérations sensibles

Les autorisations doivent refléter non seulement ce dont un agent a besoin, mais aussi quand et pourquoi l'accès est requis. L'autorisation limitée dans le temps peut réduire l'exposition entre les tâches approuvées, tout comme des contrôles supplémentaires. Vous pourriez imposer certaines actions via le fournisseur d'identité, la passerelle d'outil, l'application ou un autre mécanisme de politique de confiance plutôt que de vous fier uniquement à l'IA.

Comment la sécurité de l'agent IA diffère-t-elle selon les applications professionnelles ?

Pas toutes les applications ne fournissent les mêmes mécanismes pour contrôler l'accès à l'IA. Les équipes informatiques doivent adapter les contrôles d'accès à leur environnement et à leurs exigences.

Applications SaaS et API

Les applications SaaS modernes offrent souvent des API qui prennent en charge des jetons d'accès limités, des rôles d'application et des autorisations déléguées.

Bien qu'ils puissent rendre l'autorisation des agents plus précise, les autorisations API peuvent encore être excessivement larges, donc les administrateurs devraient examiner la portée, restreindre l'accès et purger régulièrement les autorisations.

Applications professionnelles basées sur un navigateur

Les applications basées sur un navigateur introduisent différents défis en matière d'interaction avec l'interface graphique.

Les organisations devraient utiliser des comptes dédiés, restreindre strictement les applications disponibles et appliquer l'autorisation au sein même du logiciel professionnel. Notre article sur accès sécurisé au navigateur pour des applications privées explique comment l'attribution d'applications, l'authentification et les contrôles côté serveur peuvent réduire l'exposition inutile.

Applications Windows héritées et bureaux à distance

Les applications Windows héritées présentent un défi particulier car leurs contrôles d'accès ont généralement été conçus autour des utilisateurs humains plutôt que des processus autonomes.

Accès

Néanmoins, la technologie d'accès et d'exécution restera séparée, quels que soient les rôles commerciaux, les autorisations, les comptes Windows, les groupes de répertoires ou l'accès au niveau des applications plus large. Le type d'accès graphique reste une décision d'administration et notre article sur Agents IA et applications Windows héritées explore les implications techniques et architecturales de différents environnements d'exécution.

Sécurité

Pour des raisons de sécurité, l'accès et les autorisations ne peuvent pas être mélangés. Publier une application Windows spécifique signifie réduire l'exposition d'un ensemble complet, mais ce n'est que le début d'une stratégie de contrôle d'accès plus large. Votre travail d'administrateur est bien défini :

Mécanisme d'accès	Contrôles de sécurité principaux	Préoccupation principale
API SaaS	OAuth scopes, tokens, rôles API	Permissions excessives, mauvaise utilisation du jeton
Application de navigateur	Sessions, rôles d'application	Actions non autorisées dans une session valide
Application Windows publiée	Identité Windows, attribution d'application, autorisations	Accès au-delà de la tâche prévue
Bureau à distance complet	droits OS, restrictions de session, durcissement	Exposition plus large du système et mouvement latéral

Quels risques de cybersécurité nécessitent des contrôles supplémentaires ?

Les agents d'IA peuvent rencontrer des instructions malveillantes dans des tickets de support, des pages web, des documents ou des réponses d'outils. Cela injection de prompt peut rediriger un agent loin de sa tâche légitime, même lorsque l'attaquant ne peut pas se connecter directement. Le OWASP Top 10 pour les applications agentiques 2026 décrit les menaces pertinentes.

D'autres risques incluent des identifiants exposés dans des invites ou des journaux, l'utilisation non autorisée d'outils, l'escalade de privilèges et des données sensibles envoyées à des destinations non intentionnelles. Les flux de travail multi-agents ajoutent une autre préoccupation : les tâches déléguées ne doivent pas automatiquement accorder un accès illimité d'un agent à un autre.

Pour éviter l'exfiltration de données et autres, traitez le contenu externe comme non fiable, protégez les secrets par le biais de services d'identification pris en charge, limitez les connexions sortantes et appliquez les autorisations indépendamment du modèle d'IA. Les opérations sensibles nécessitent des contrôles au niveau de l'application ou de l'outil, et pas seulement des instructions interprétables demandant à un agent de se comporter de manière sécurisée.

Comment l'IT peut-il surveiller, révoquer et auditer l'accès des agents IA ?

La gouvernance d'accès est incomplète si les administrateurs ne peuvent pas déterminer ce qu'un agent a fait ou l'arrêter lorsque son comportement devient inattendu.

Suivi des identités, des décisions et des actions

Un enregistrement d'audit utile : identité de l'agent + propriétaire responsable + opération demandée + approbation + invocation de l'outil + action résultante + résultat.

Selon les outils impliqués, les enregistrements varieront. Aucune source unique ne raconte toute l'histoire, donc une combinaison d'événements d'authentification, d'émission de jetons d'accès, d'appels API, d'activité d'application, d'approbations, de modifications de fichiers et d'activité de session est nécessaire comme preuve. Par exemple, combinez un journal d'identité avec un enregistrement de session, en corrélant les enregistrements lorsque cela est possible.

De plus, protégez les informations sensibles autant que possible. Par exemple, si vous êtes un MSP, séparez les enregistrements d'audit par client pour préserver leurs données.

Révocation d'accès et réponse aux incidents

Prédéfinir une procédure d'arrêt par déploiement d'agent IA, avant la production.

Selon l'environnement, cela peut nécessiter la désactivation de l'identité d'un agent IA, la révocation des identifiants, la rotation des secrets, la terminaison des sessions actives et l'arrêt des tâches planifiées. Une fois terminé, évaluez les jetons précédemment émis ou les sessions établies : révoquer un identifiant n'est pas toujours suffisant pour arrêter un processus déjà actif.

Vous pouvez inclure ce qui suit dans une procédure de réponse pratique aux "mauvais comportements" :

• contient l'accès,
• préserver les journaux,
• investiguer les changements,
• remplacer les informations d'identification
• et valider que l'incident non autorisé est terminé.

Quelle est une liste de contrôle de sécurité pratique pour les agents d'IA pour les équipes informatiques ?

Pourquoi ne pas aborder la sécurité des agents IA de manière progressive ? Commencez par un flux de travail étroit, de préférence en lecture seule, puis élargissez uniquement après avoir validé les contrôles. Avant de donner à un agent un accès en production :

1. Identifier la propriété. Documenter son objectif, son opérateur/propriétaire, son environnement d'exécution, ses outils et ses flux de données.
2. Attribuer une identité distincte. Évitez les identifiants humains partagés. Établissez une responsabilité distincte.
3. Cartographier et limiter les ressources autorisées. Spécifiez les applications, les enregistrements, les données, les systèmes, les autorisations API requises, les périodes.
4. Restreindre les actions sensibles. Définir les exigences d'approbation et interdire les changements à fort impact et les privilèges inutiles.
5. Protéger les identifiants. Utilisez l'authentification de charge de travail prise en charge et les secrets gérés.
6. Validez l'environnement d'exécution. Examiner l'isolement des sessions, l'accès réseau et les paramètres de sécurité Windows pertinents.
7. Activer les preuves et la récupération : conserver des enregistrements de l'authentification, de l'exécution des outils, de l'activité des applications et des changements significatifs.
8. Scénarios d'échec de test : l'accès peut être révoqué, les sessions terminées et les activités inattendues examinées.

Par exemple, un MSP pourrait piloter un agent pour lire des enregistrements de factures ERP sélectionnés et préparer un rapport, sans lui accorder la permission de modifier des données financières. Seule une fiabilité prouvée et des permissions applicables devraient justifier une autorité plus large.

Comment TSplus peut-il aider à sécuriser l'accès aux applications Windows ?

Pour les organisations utilisant des logiciels d'entreprise basés sur Windows, l'infrastructure d'accès à distance sous-jacente fait également partie de ce processus de sécurité. Les capacités de livraison d'applications et de protection des serveurs de TSplus aident les administrateurs système à contrôler l'accès aux applications Windows hébergées de manière centralisée.

TSplus Remote Access : Livraison d'applications et attribution

TSplus Remote Access publie et attribue des applications Windows, les rendant disponibles via des connexions à distance, y compris l'accès basé sur le web. Fournir une application attribuée plutôt qu'un bureau entier peut contribuer à réduire l'exposition inutile à l'interface dans de tels flux de travail d'IA, en particulier ceux impliquant des logiciels commerciaux existants et hérités.

TSplus Advanced Security : Protection des serveurs Windows et des sessions

TSplus Advanced Security ajoute des protections de serveur Windows et de session grâce à la protection contre les attaques par force brute, des restrictions géographiques, des contrôles des heures de travail, une gestion des autorisations, une protection contre les ransomwares, des alertes et des journaux d'événements de sécurité.

Ces contrôles peuvent réduire l'exposition autour de l'hôte de l'application, complétant ainsi l'identité dédiée, l'autorisation et les protections d'exécution requises pour les agents d'IA.

Ensemble, les capacités pertinentes de TSplus soutiennent un principe pratique : maintenir un accès contrôlé aux applications professionnelles et protéger l'environnement Windows qui les entoure, tout en laissant aux administrateurs la liberté d'introduire des contrôles de sécurité spécifiques à l'IA et une orchestration là où les nouvelles charges de travail les nécessitent.

Conclusion

La sécurité des agents d'IA commence par une simple distinction : avoir la permission d'accéder à une application ne signifie pas avoir l'autorité d'effectuer chaque action à l'intérieur, le cas échéant.

Pour les administrateurs système et les MSP, rendre l'IA gérable signifie combiner des agents IA clairement identifiés, des tâches à portée étroite, des autorisations applicables, des environnements d'exécution protégés et des pistes de vérification fiables. De telles étapes permettent aux organisations d'explorer l'automatisation de l'IA sans élargir inutilement leur surface d'attaque.

Questions Fréquemment Posées

Qu'est-ce qu'une identité non humaine dans la sécurité des agents IA ?

Une identité non humaine identifie un logiciel, une charge de travail automatisée ou un agent IA plutôt qu'une personne. Elle permet aux administrateurs d'authentifier la charge de travail, d'attribuer des autorisations et de suivre son activité. Les identités d'agent dédiées peuvent améliorer la responsabilité par rapport aux comptes humains partagés.

Comment l'identité d'un agent IA est-elle différente d'un compte de service ?

Les comptes de service traditionnels prennent généralement en charge des applications prédéfinies et des processus automatisés. Les identités des agents d'IA peuvent nécessiter des contrôles supplémentaires de cycle de vie, de délégation et d'autorisation, car les agents peuvent choisir des actions de manière indépendante. Les mécanismes d'identité disponibles dépendent de la plateforme et de l'environnement d'application.

Les agents IA peuvent-ils accéder en toute sécurité aux applications Windows héritées ?

Oui, à condition que la technologie d'exécution appropriée et les contrôles d'accès soient disponibles. Les organisations doivent restreindre le compte Windows, les autorisations d'application et la session à distance. La publication d'une application individuelle peut réduire l'exposition, mais ne remplace pas la sécurité du système d'exploitation ou l'autorisation au niveau de l'application.

Quels contrôles de sécurité sont nécessaires lorsque des agents IA dépannent des appareils distants ?

Les agents de dépannage à distance ont besoin de permissions d'exécution restreintes, d'autorisation pour des actions sensibles, de journalisation et de conditions d'arrêt fiables. Notre guide compagnon sur les agents d'IA dans le support informatique explique comment superviser la remédiation automatisée, vérifier les résultats et escalader les interventions infructueuses.

Comment les administrateurs informatiques peuvent-ils révoquer l'accès d'un agent IA ?

Les administrateurs doivent désactiver l'identité de l'agent, révoquer les jetons et les identifiants applicables, terminer les sessions actives et arrêter les processus ou tâches planifiées associés. Ils doivent ensuite vérifier que l'accès est terminé et enquêter sur toute activité non autorisée.