Résumé
La sécurisation des agents d’IA autonomes nécessite une architecture Zero Trust axée sur l’identité, reposant sur des identifiants à durée de vie limitée, une autorisation « on-behalf-of » à double niveau, des identités d’agents attestées de manière cryptographique, une désactivation automatisée et continue, ainsi que des conceptions de systèmes fail-closed en cas d’échec.
Les agents d’IA exécutent des workflows au sein des entreprises, mais comme les outils reposant sur des LLM sont de nature probabiliste, les considérer comme des utilisateurs classiques représente un risque majeur pour la sécurité. Un déploiement sécurisé nécessite une approche centrée sur l’identité, qui équilibre l’autonomie et un contrôle centralisé strict.
Sécuriser ce paradigme implique de répondre à trois questions essentielles mises en avant dans le plan d’action pour l’entreprise agentique sécurisée :
- Où sont mes agents ?
- À quoi peuvent-ils se connecter ?
- Que peuvent-ils faire ?
En définissant des garde-fous clairs autour de l’authentification et de l’autorisation, les entreprises peuvent innover rapidement sans exposer leurs systèmes critiques. Voici les cinq règles essentielles pour sécuriser les agents d’IA autonomes dans l’entreprise.
Règles de sécurité fondamentales pour les architectures d’agents d’IA
| Règle de sécurité | Risque principal atténué | Mécanisme/standard central |
|---|---|---|
| Identifiants à durée de vie limitée | Vol de token, usurpation d’identité à grande échelle | Tokens d’accès à durée de vie limitée via un fournisseur d’identité central |
| Autorisation « on-behalf-of » à deux niveaux | Élévation des privilèges, absence de traçabilité | Vérification du chevauchement de permission entre l’agent et l’utilisateur humain |
| Identité cryptographique | Usurpation d’agent, exécution non vérifiée | Attestation à distance et journaux d’audit cryptographiques immuables |
| Gestion automatisée du cycle de vie des utilisateurs | Shadow AI abandonnée, dérive de l’injection de prompt | Élagage automatisé des identités et revue périodique de l’inventaire |
| Architecture à fermeture sécurisée | Déni de service lié à la télémétrie de sécurité, exécution non surveillée | Les interruptions de sécurité entraînent par défaut la révocation totale de l’accès |
Comment gérez-vous les identifiants pour les agents d’IA autonomes ?
Éliminer les identifiants d’agent à longue durée de vie au profit de tokens à durée de vie limitée
Fournir à un agent d’IA des identifiants directs et permanents, comme des clés API statiques ou des tokens d’accès personnels, expose à un risque majeur. Lorsqu’un agent utilise ces identifiants, il se fait effectivement passer pour un utilisateur disposant de privilèges étendus, souvent mal connus, ce qui signifie qu’une seule clé compromise peut entraîner des dommages importants sur différents systèmes.
- La solution : les agents doivent uniquement utiliser des tokens d’accès à durée de vie limitée, extraits via un fournisseur d’identité centralisé.
- Application architecturale : les architectures doivent explicitement bloquer les autorisations OAuth directes et les navigateurs agentiques capables d’usurper des sessions. Cette conception met en place un point de contrôle central qui permet aux équipes sécurité de révoquer instantanément l’accès à l’aide d’un arrêt d’urgence unique si un agent s’écarte.
Qu’est-ce que l’autorisation au nom d’autrui dans l’IA agentique ?
Appliquer une authentification réelle à double niveau pour l’autorisation « on-behalf-of »
La plupart des déploiements actuels de l’IA reposent sur une usurpation d’identité des utilisateurs et utilisatrices qui pose problème, masque la traçabilité et remet en cause les principes du moindre privilège. Pour résoudre ce problème, il est nécessaire de relier l’identité et l’exécution au sein d’un framework de gouvernance unifié et cohérent.
- Vérification à double niveau : les workflows « on-behalf-of » authentiques nécessitent une autorisation à double niveau : le serveur d’autorisation vérifie de manière indépendante les autorisations de l’agent actif ainsi que celles de la personne sous-jacente.
- Périmètre effectif : l’agent se voit accorder uniquement le périmètre commun aux deux ensembles d’autorisations.
- Auditabilité : ce contexte dynamique offre une visibilité totale, car les journaux d’audit enregistrent simultanément les deux identités, ce qui permet une traçabilité claire et complète de bout en bout.
Comment établir une identité cryptographique pour les agents d’IA ?
Exiger une identité cryptographique et des audits immuables
Vous ne pouvez pas sécuriser un agent si vous ne pouvez pas l’identifier de manière unique et fiable. Les agents autonomes doivent s’authentifier à l’aide d’identifiants cryptographiquement uniques reposant sur un stockage sécurisé et une attestation à distance.
- Journaux d’audit immuables : chaque demande d’autorisation et chaque action effectuée par l’agent doivent être consignées dans une piste d’audit immuable préservant l’intégrité cryptographique.
- Contrôle de révocation : vous avez besoin d’un point de contrôle centralisé pour conserver la capacité de révoquer immédiatement ces identifiants dès que nécessaire.
Comment gérez-vous le cycle de vie des agents d’IA d’entreprise ?
Automatiser la gestion continue du cycle de vie de l’identité
Le principe du moindre privilège est une démarche continue, et non une configuration ponctuelle. Les agents non surveillés (« Shadow AI ») deviennent des cibles privilégiées pour les attaquants.
- Réduction de l’impact : limiter les privilèges d’un agent réduit l’impact potentiel si un LLM subit une injection de prompt ou génère des actions non souhaitées.
- Déprovisioning automatisé : les équipes sécurité doivent régulièrement examiner les inventaires d’agents afin de supprimer ceux qui présentent une inactivité, une faible valeur métier ou des performances irrégulières. La désactivation des agents inutilisés permet également d’éviter que des identifiants abandonnés ne deviennent des cibles faciles pour les attaquants.
Qu’est-ce qu’une architecture à défaillance bloquante pour les agents d’IA ?
Imposer des architectures de sécurité à fermeture par défaut
Les interruptions système ou les défaillances de sécurité ne doivent jamais entraîner une extension des capacités d’un agent d’IA.
- Mécanismes de sécurité en cas de défaillance : si l’authentification, l’autorisation ou le dispositif de sécurité d’un agent est interrompu, le système doit immédiatement basculer vers une indisponibilité totale.
- Stratégie de résilience : le mode « Fail-closed » permet de garantir qu’une dégradation de la sécurité ne se traduit pas par un accès autonome non vérifié. Par exemple, une attaque par déni de service réussie contre un sous-système de sécurité doit entraîner l’arrêt de l’agent plutôt que de le laisser sans surveillance.
Établir une base de sécurité centrée sur l’identité avec Okta for AI Agents
Sécuriser les agents d’IA autonomes implique d’aller au-delà des contrôles d’accès traditionnels afin de mettre en place une visibilité centralisée, des identifiants à durée de vie limitée et des architectures fail-closed strictes.
Okta for AI Agents peut vous aider à mettre en place ces garde-fous axés sur l’identité et à déployer en toute sécurité des workflows agentiques au sein de votre entreprise.
