Le contexte de sécurité est important pour l'IA agentique.
L'IA agentique peut fonctionner avec un accès au minimum de privilèges et néanmoins violer la politique de sécurité.
Le défi
Le contexte de sécurité définit qui peut faire quoi avec un ensemble de données donné. Les autorisations de création, de modification ou de suppression de données sur les systèmes d’entreprise sont définies par les exigences commerciales attribuées à des rôles spécifiques. Dans une entreprise où des humains remplissent certains rôles, lorsqu’ils utilisent un logiciel, ce logiciel doit avoir un contexte de sécurité pour fonctionner. Et ce contexte de sécurité est mis en œuvre à l’aide de comptes. Le logiciel s’exécute généralement en tant que compte d’utilisateur ou en tant que compte de service. Les comptes de service sont créés pour permettre aux autorisations logicielles de manipuler les données de l’entreprise indépendamment du contexte de sécurité de chaque utilisateur spécifique.
L'attribution d'un accès le moins privilégié à diverses ressources d'entreprise est simple pour les utilisateurs en fonction de leurs rôles, mais les services, bien que toujours limités, sont configurés pour autoriser l'accès le plus privilégié afin qu'ils puissent effectuer toutes les actions requises tout au long d'un processus. Par exemple, un utilisateur peut uniquement avoir un accès en écriture à un ensemble d'enregistrements dans un système qui correspond à ses comptes clients attribués et un accès en lecture seule à tous les autres comptes clients. Les comptes de service, en revanche, ont besoin d'un accès en écriture à tous les comptes.
L’écart de privilèges au sein de l’automatisation des processus.
Lors de l’utilisation de l’IA agentique, l’activité de l’utilisateur et l’activité du processus métier de l’entreprise se mélangent. Les processus d’entreprise sont conçus pour fournir un résultat de manière sommaire (c’est-à-dire pour tous les clients, pour tous les employés, pour toutes les instances). Pour fonctionner, les comptes de service ont généralement besoin d’autorisations plus élevées que la plupart des utilisateurs individuels, mais c’est un utilisateur individuel ou une équipe d’utilisateurs qui est responsable du lancement, de la surveillance et de la supervision des processus d’entreprise.
Par exemple, une organisation emploie un assistant IA agentique pour soutenir l’intégration de nouveaux employés. Chaque nouvel employé a un rôle spécifique et, en fonction de ce rôle, une entreprise doit accéder aux systèmes de l'entreprise à un certain niveau. L'assistant d'IA agentique fonctionne dans le contexte du personnel RH effectuant l'intégration. Alors, que se passe-t-il si l’agent IA doit provisionner un nouveau compte utilisateur avec des autorisations qui dépassent celles d’un ou plusieurs membres de l’équipe RH ?
Si les autorisations de l'agent sont définies en fonction du processus qui doit s'exécuter et non en fonction du fait que la personne utilisant l'agent est autorisée individuellement, des violations de sécurité peuvent se produire car le logiciel contrôlé par l'utilisateur donne accès à des données auxquelles il n'est pas autorisé à accéder. En revanche, si l’action est bloquée en raison d’un manque d’autorisations, l’utilisateur ne peut pas terminer la tâche.
Ce scénario peut être résolu en ramifiant le processus. Une sous-tâche est attribuée à une personne disposant de l’autorité nécessaire pour accorder des autorisations au niveau requis, et une fois approuvée, le processus peut passer à l’étape suivante. Cette technique de segmentation des actions par contexte de sécurité devrait également être appliquée aux solutions agentiques.
Mappage des changements de contexte de sécurité de surface
L’utilisation de l’IA agentique peut augmenter la probabilité que le logiciel utilisé pour lancer un processus dans le contexte d’un utilisateur finisse par obtenir des privilèges élevés lors du passage au contexte d’un agent exécuté avec un compte de service. Dans ce cas, il est important que le système agentique fonctionne de manière à ce que les privilèges élevés et l'accès aux données ne violent pas la politique de sécurité.
Une carte de flux de processus montrant le changement de contexte de sécurité au cours des étapes d'un flux de travail. Les changements de privilèges et de sensibilité sont cartographiés aux points d’accès aux données.
Attention à l'écart et avancez
La conception d'agents d'IA avec un contexte de sécurité approprié commence par répondre à cette question : le processus automatisé est-il censé être un assistant personnel déployé auprès d'un ou plusieurs utilisateurs ou s'agit-il d'un processus métier généralisé qui doit être exécuté à grande échelle pour le compte de l'entreprise ?
S'il s'agit d'un processus personnel, concentrez-vous sur la vérification que toutes les actions et exigences d'accès aux données sont conformes à la politique de sécurité de l'entreprise existante pour les utilisateurs ciblés. Si des exceptions sont trouvées, séparez les actions nécessitant des privilèges élevés et confirmez que l'accès et les actions sont correctement mappés aux individus avec les différents niveaux requis.
Si le processus est généralisé pour l'entreprise, examinez la conception du compte de service pour déterminer si l'accès le plus privilégié crée des failles de sécurité comme celle du premier exemple ci-dessus, et vérifiez à nouveau que les données sensibles ne sont pas exposées aux utilisateurs qui ne disposent pas des privilèges requis.
Les organisations doivent inclure le contexte de sécurité dans la conception des agents personnels et d’entreprise. En séparant les tâches qui nécessitent des privilèges élevés et en tenant compte du fait qu'un utilisateur ou un compte de service exécutera l'action, le risque de failles de sécurité involontaires diminuera.
Pour une perspective supplémentaire sur la tension entre l'automatisation et la sécurité, lisez : Apaiser la tension entre sécurité des données et automatisation | F5