Qu’est-ce que l’identité d’un agent — et pourquoi votre IA n’en possède probablement pas ?

7 min de lecture

La plupart des outils d'IA s'authentifient à l'aide des identifiants de l'opérateur humain. Cela risque de poser un problème de conformité. Voici à quoi ressemble une identité d'agent valide et pourquoi cette différence est importante aujourd'hui.

 

Le problème d'authentification dont personne ne parle

Lorsque votre agent IA intervient sur vos systèmes, sous quelle identité agit-il ?

Pour la plupart des outils d'IA actuels, la réponse est entre vos mains. L'agent se connecte avec les identifiants de l'opérateur humain, hérite de ses permissions et travaille en son nom. Chaque entrée de journal, chaque ensemble de données lu et chaque commande exécutée donne l'impression d'avoir été effectuée par un humain.

Sa conception est simple à mettre en œuvre et à démontrer. De plus, elle s'intègre parfaitement à vos systèmes de contrôle d'accès existants. Et comme aucun dysfonctionnement n'a encore été constaté, la plupart des équipes n'ont pas remarqué son absence.

Le problème du partage d'identifiants n'est pas son manque de sécurité actuel, mais son inconformité future. Les agents d'IA passent de la simple réponse aux questions à l'exécution d'actions dans les systèmes de production. Dès lors, les auditeurs et les organismes de réglementation poseront une question à laquelle les identifiants partagés ne pourront répondre: une personne ou l'IA a-t-elle effectué cette action ?

Qu’est-ce que l’identité d’un agent dans les systèmes d’IA ?

L'identité d'un agent est un identifiant unique, vérifiable et temporaire, attribué à l'agent d'IA lui-même, indépendamment de l'utilisateur humain. Elle lui confère un nom propre au sein de vos systèmes, vous permettant ainsi d'attribuer chaque action effectuée à l'agent plutôt qu'à l'opérateur.

L'identité d'un agent valide comporte trois composantes:

  • Il utilise ses propres identifiants. L'agent s'authentifie en son nom propre. Il n'emprunte ni ne partage jamais les identifiants de connexion de l'utilisateur.
  • Autorisation limitée. L'agent ne peut accéder qu'aux ressources nécessaires à la tâche spécifique.
  • À durée limitée. L'identifiant expire à la fin de la session et ne peut être réutilisé.

En quoi l'identité d'un agent diffère-t-elle d'un compte de service ?

L'identité d'agent et les comptes de service répondent à des problématiques différentes. Un compte de service est une authentification partagée et persistante, associée à une fonction telle qu'une tâche planifiée ou une intégration système. Il est généralement conservé pendant des années, accumule des autorisations au fil du temps et est utilisé par plusieurs processus.

L'identité d'un agent est liée à une tâche et limitée à une session. Elle est attribuée pour une tâche spécifique, restreinte aux besoins de cette tâche, puis supprimée à la fermeture de la session. Remplacer les identifiants d'un opérateur par un compte de service général ne résout rien. Vous avez simplement remplacé une identité partagée par une autre.

Pourquoi un agent d'IA ne devrait-il pas utiliser les identifiants de l'opérateur ?

Transmettre les identifiants de l'utilisateur à un agent d'IA crée trois problèmes: échec d'attribution, dérive des objectifs et écart croissant en matière de conformité.

Erreur d'attribution. Un auditeur examine une modification apportée à une tâche de production et demande si elle a été effectuée par un humain ou par l'IA. Si l'agent a agi sous l'identifiant de l'opérateur, le journal affiche le même nom pour les deux. Il est impossible de distinguer la décision de l'opérateur de l'action effectuée par l'agent.

Dérive des autorisations. L'agent hérite de l'ensemble des permissions de l'utilisateur, et non seulement de celles nécessaires à sa tâche. Un programmeur système senior peut détenir des droits sur des centaines d'ensembles de données, de définitions de sécurité et de planifications de tâches. Un agent diagnostiquant une défaillance de traitement par lots sous cet identifiant obtient l'intégralité de ces droits.

Lacune en matière de conformité. Les organismes de réglementation exigent désormais que les actions des agents d'IA soient attribuables et encadrées de manière indépendante. Les identifiants partagés ne répondent pas à cette exigence par nature, aussi robustes que soient vos contrôles de périmètre.

Ce qui rend ce risque difficile à ignorer, c'est que les identifiants partagés fonctionnent parfaitement jusqu'à ce que quelqu'un vous demande de prouver qui a fait quoi. Vous ne détecterez pas cette faille lors d'un test d'intrusion, mais lors d'un audit.

Qu’est-ce que l’autorisation à portée limitée pour les agents d’IA ?

L'autorisation limitée signifie que l'agent ne peut accéder qu'aux données nécessaires à la tâche spécifique et agir uniquement sur celles-ci. Si la tâche consiste à diagnostiquer un traitement par lots ayant échoué, l'agent obtient un accès en lecture aux journaux, aux résultats et aux données de performance associés à ce traitement. Il ne peut ni modifier les définitions de sécurité, ni annuler les traitements non liés, ni supprimer les jeux de données.

La plupart des outils d'IA fonctionnent différemment aujourd'hui. L'agent bénéficie des mêmes droits d'accès que l'opérateur humain, indépendamment des exigences de la tâche. Cette approche confère à chaque session d'agent un impact maximal.

L'autorisation limitée est essentielle car le principe du moindre privilège est déjà une exigence de base dans les environnements réglementés. Le cadre de gestion des risques liés à l'IA du NIST part du principe que chaque identité ne dispose que des accès nécessaires à sa fonction, et les contrôles d'accès testés par vos auditeurs reflètent cette même norme. Vous exigez déjà ce niveau d'exigence des utilisateurs humains. Les agents d'IA doivent également s'y conformer, et l'autorisation limitée leur permet d'y parvenir.

À quoi ressemble concrètement une identité d'agent appropriée ?

Prenons un exemple courant: une opération de règlement nocturne s’interrompt anormalement à 2h14 du matin. L’opérateur d’astreinte demande à un agent d’IA de diagnostiquer la panne.

 

Avec une identité d'agent appropriée:

  • L'agent s'authentifie avec ses propres identifiants éphémères, distincts de ceux de l'opérateur.
  • Son accès ne concerne que les journaux de travaux pertinents, les messages système et les données de performance.
  • Chaque lecture et chaque recommandation sont enregistrées sous l'identité de l'agent, l'opérateur étant enregistré comme approbateur humain.
  • Si l'agent propose une solution, l'opérateur l'autorise et le journal enregistre les deux identités.
  • Les identifiants expirent à la fin de la session.

 

Avec des identifiants partagés:

  • L'agent se connecte en tant qu'opérateur et dispose de tous les droits d'accès de l'opérateur.
  • Cela peut aller bien au-delà des exigences du diagnostic.
  • Le registre ne mentionne que l'identifiant de l'opérateur. Trois mois plus tard, lorsqu'un auditeur demande quelles étapes ont été effectuées par l'IA et lesquelles par l'humain, personne ne peut répondre.

Les deux méthodes peuvent permettre de résoudre le problème aussi rapidement. Seule l'une d'elles vous apporte une réponse lorsqu'on vous demande comment cela s'est produit.

Voici l'architecture Fusée® EVA™ Le système Rocket EVA attribue à chaque agent un identifiant temporaire et limité dans le temps, distinct de l'identité de l'opérateur humain. Chaque action est imputée à l'agent, et l'approbateur humain est enregistré. Les identifiants expirent à la fin de la session et ne sont pas réutilisables.

Rocket EVA renforce également les limites opérationnelles grâce à une approche de gestion des politiques basée sur le code et enregistre l'activité dans une piste d'audit immuable. Compatible avec vos contrôles existants de gestion des identités et des accès, il vous permet de consolider votre gouvernance sans avoir à refondre votre modèle de sécurité. Votre équipe bénéficie de diagnostics plus rapides et votre équipe de conformité dispose d'un historique fiable.

Comment évaluer si votre fournisseur d'IA possède une véritable identité d'agent

Posez ces quatre questions à n'importe quel fournisseur d'IA:

  1. Votre agent s'authentifie-t-il avec sa propre identité ou avec les identifiants de l'opérateur ?
  2. Cette identité a-t-elle une durée de vie limitée ? Expire-t-elle à la fin de la session ?
  3. L'autorisation est-elle limitée à la tâche ou l'agent hérite-t-il de toutes les autorisations de l'utilisateur ?
  4. Pouvez-vous produire un compte rendu qui distingue ce que l'agent a fait de ce que l'humain a fait ?

Soyez attentif aux réponses précises et architecturales. Un fournisseur incapable de répondre précisément aux quatre questions ne dispose pas d'une architecture d'identité d'agent gouvernée.

 

Découvrez comment Rocket EVA gère l'identité des agents

Rocket est une marque déposée de Rocket Software, Inc. et de ses filiales.

Questions fréquemment posées

Contenu connexe

Intelligence artificielle (IA)

Présentation de Rocket EVA 2.0

6 minutes de lecture
Rocket EVA 2.0 introduit des agents d'IA gouvernés pour les opérations informatiques mainframe et hybrides, aidant les équipes à accélérer les investigations, à étendre leur expertise et à appliquer [...]
Intelligence artificielle (IA)

Rocket EVA: Pas d'expert CICS ? Pas de problème.

Rocket Software
4 minutes de lecture
Les organisations s'appuient sur des décennies de savoir-faire pour exploiter et moderniser leurs systèmes critiques, mais cette expertise n'est pas toujours facilement disponible lorsqu'elle est [...]
Intelligence artificielle (IA)

IDC Link examine comment Rocket EVA™ intègre l'IA agentique aux opérations mainframe

1 min de lecture
Stimuler l'innovation des mainframes grâce à l'IA agentive.