Implémenter le contrôle d’accès pour la sécurité dans les agents IA

  • Rversion finale: Zurich
  • Mis à jour 11 août 2025
  • 6 minutes de lecture

    • Activez les contrôles de sécurité pour les agents IA et les workflows agentiques via les listes de contrôle d’accès (ACL) et les identités des utilisateurs.

    Vue d’ensemble de la sécurité pour les agents IA

    Les contrôles d’accès pour l’IA ServiceNow AI Platform agentique sont constitués de deux composants principaux : les listes de contrôle d’accès (ACL) et les identités des utilisateurs. La sécurité et le comportement globaux sont déterminés par la façon dont ces composants interagissent les uns avec les autres au niveau du workflow agentique, de l’agent IA et de l’outil.

    Les ACL déterminent quels utilisateurs peuvent détecter et invoquer un composant agentique. Les ACL doivent être définies individuellement pour chaque workflow agentique, agent IA et certains outils d’agent IA, tels que Now Assist les compétences personnalisées.

    Les identités des utilisateurs déterminent les rôles avec lesquels le composant agentique peut s’exécuter et, par conséquent, les données auxquelles il a accès.

    Lors de la conception de la sécurité de votre système agentique, vous devez tenir compte de chaque niveau car ils fonctionnent ensemble. Pour exécuter avec succès un workflow agentique, les ACL de tous les composants en aval doivent être transmises. Vous devez tenir compte de tous les changements dans les identités des utilisateurs, par exemple lorsqu’un composant en aval s’exécute en tant qu’utilisateur IA, qui peut avoir des autorisations élevées.

    Listes de contrôle d’accès

    Les listes de contrôle d’accès dans Now Assist les agents IA sont définies pour déterminer les utilisateurs qui peuvent détecter et invoquer un workflow agentique ou un agent IA.

    Important :
    Les ACL configurées dans Studio d'agents IA déterminent uniquement les rôles requis pour que les utilisateurs détectent et invoquent un workflow agentique ou un agent IA. Elles ne déterminent pas l’accès dont dispose le workflow agentique ou un agent IA une fois qu’il est invoqué. L’identité de l’utilisateur détermine l’accès (voir Identité de l’utilisateur ci-dessous).

    Configurer les ACL dans Studio d'agents IA

    Les ACL configurées dans le Studio d'agents IA pour les agents IA et les workflows agentiques sont Allow-If basées sur les rôles.

    La Allow-If logique accorde l’accès aux données ou aux ressources si l’une des conditions de l’ACL est remplie. L’autre type d’ACL est Deny-Unless. Deny-Unless Les ACL bloquent l’accès aux données ou aux ressources sauf si une condition est remplie, même s’il existe d’autres conditions telles que Allow-If les ACL qui accorderaient normalement l’accès à quelqu’un.

    Il existe trois options possibles pour les ACL créées dans Studio d'agents IA:

    • Any authenticated user: accorde l’accès à tout utilisateur authentifié sur l’instance, quel que soit son rôle
    • Users with specified roles: ACL par défaut et qui nécessite que vous sélectionniez les rôles qui accordent l’accès
    • Public: accorde l’accès à n’importe quel utilisateur, y compris aux invités qui ne sont pas connectés

    Toutes les ACL configurées dans Studio d'agents IA sont créées et stockées dans la table ACL de sécurité [sys_security_acl].

    Chaque agent IA et workflow agentique doit avoir sa propre ACL unique. Chaque ACL ne peut s’appliquer qu’à un seul agent IA ou workflow agentique, bien que vous puissiez créer plusieurs ACL pour un agent IA ou un workflow agentique. Vous ne pouvez pas créer un agent IA ou un workflow agentique, ni enregistrer les changements apportés à un agent IA ou à un workflow agentique existant sans ACL. Pour configurer l’ACL basée sur le Allow-If rôle et dans Studio d'agents IA le pour un agent IA, consultez la Créer un agent IA configuration guidée. Pour configurer l’ACL basée sur les Allow-If rôles et pour un workflow agentique, consultez la Créer un workflow agentique configuration guidée.

    * gen_ai_agent ACL et gen_ai_workflow *ACL sont les deux ACL expédiées par défaut. Si un agent IA ou un workflow agentique hérité n’a pas d’ACL configurée, ces deux ACL autorisent l’exécution de l’agent IA ou du workflow agentique. Ces ACL ne sont utilisées que pour les agents IA préexistants ou les workflows agentiques pour lesquels aucune ACL n’est encore configurée.

    Configuration avancée de l’ACL pour l’IA agentique

    Deny-Unless Les ACL et d’autres configurations plus complexes pour la sécurité, telles que les attributs de sécurité, sont disponibles en accédant à la table sys_security_acl et au formulaire ACL dans UI16. Ils ne sont pas disponibles dans Studio d'agents IA.

    Vous pouvez configurer plusieurs ACL pour un agent IA ou un workflow agentique en créant des enregistrements d’ACL, mais pas dans Studio d'agents IA. Si vous avez configuré des ACL supplémentaires, celles-ci peuvent ne pas apparaître dans les configurations guidées. Vérifiez la table ACL pour connaître la configuration de sécurité complète de l’agent IA ou du workflow agentique.

    Remarque :
    Seuls les utilisateurs ayant le rôle élevé approprié ont un accès direct en lecture et en écriture à la table ACL.

    Une configuration de sécurité supplémentaire est requise pour Now Assist les compétences et les flux utilisés comme outils par l’agent IA. Les ACL de niveau de compétence peuvent être configurées dans Now Assist le kit de compétences. Voir Configurer les listes de contrôle d’accès pour une compétence pour plus d’informations. La sécurité au niveau du flux peut être configurée avec des ACL directement sur la table ACL. Ces ACL sont vérifiées lorsqu’elles sont invoquées directement.

    Les ACL des niveaux de compétence sont également vérifiées lorsque l’agent IA sur lequel l’outil est activé est appelé. Les flux sont vérifiés lorsque l’agent IA tente d’utiliser le flux comme un outil.

    Remarque :
    En cas de conflit d’exigences de sécurité entre les workflows agentiques, les agents IA et les outils d’agent IA, ou si l’utilisateur appelant répond aux critères de certaines ACL mais pas d’autres, votre IA agentique peut ne pas s’exécuter. Lors de la détermination de ces paramètres de sécurité, assurez-vous de prendre en compte les paramètres de sécurité pour tous les aspects du flux agentique, du workflow agentique, des agents IA et des outils.

    Identité de l’utilisateur

    Après avoir configuré les listes de contrôle d’accès (ACL), vous devez configurer l’identité d’utilisateur (également connue sous le nom de Run as) avec laquelle l’agent IA ou le workflow agentique sera exécuté. L’identité de l’utilisateur avec lequel l’agent IA ou le workflow agentique s’exécute détermine ses autorisations et les données auxquelles il peut accéder.

    Vous pouvez choisir parmi deux configurations utilisateur possibles :
    • Utilisateur dynamique : utilisateur connecté qui appelle l’exécution d’un agent IA ou d’un workflow agentique. L’utilisateur dynamique est l’identité d’utilisateur par défaut, et vous devez utiliser l’utilisateur dynamique sauf s’il existe un besoin spécifique qui justifie un utilisateur IA.
    • Utilisateur IA : identité d’utilisateur dédiée qui exécute l’agent IA ou l’exécution d’un workflow agentique avec des rôles affectés qui ne changent pas, peu importe qui ou comment l’exécution est invoquée. Un workflow agentique ou un agent IA qui nécessite des autorisations supérieures à celles de l’utilisateur appelant d’origine est un exemple de cas qui nécessite un utilisateur IA.
    Remarque :
    L’utilisateur appelant peut changer à différentes étapes de l’exécution du workflow agentique et n’est pas toujours l’utilisateur connecté d’origine ou l’utilisateur conversationnel. L’utilisateur appelant est plutôt l’identité d’utilisateur de l’appelant qui se trouve à un niveau supérieur dans la hiérarchie du workflow agentique. Par exemple, si un agent IA s’exécute en tant qu’utilisateur IA dynamique, l’utilisateur appelant pour les outils de l’agent IA est l’utilisateur de l’agent IA plutôt que l’utilisateur conversationnel qui a invoqué l’agent IA.

    Les utilisateurs IA peuvent être sélectionnés dans Studio d'agents IA, mais les utilisateurs IA doivent déjà être créés dans la table Utilisateur [sys_user] pour les sélectionner. Les utilisateurs doivent avoir le AI Agent type d’identité pour être sélectionnés en tant qu’utilisateurs IA. Par défaut, les utilisateurs disposant du rôle sn_aia.admin n’ont pas accès à la création d’utilisateurs IA. Consultez Créer un utilisateur pour connaître la procédure à suivre pour créer un nouvel utilisateur dans la table Utilisateur.

    Les identités des utilisateurs sont configurées au niveau du workflow agentique et de l’agent IA.

    Sécurité pour les outils de script d’agent IA

    Lors de l’ajout d’outils de script aux agents IA, vous devez utiliser par défaut GlideRecordSecure au lieu de GlideRecord et addUserEncodedQuery() au lieu de addEncodedQuery(). Des avertissements s’affichent dans la configuration guidée pour les scripts qui utilisent des options moins sécurisées.