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 ?
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:
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.
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.
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:
Avec des identifiants partagés:
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.
Posez ces quatre questions à n'importe quel fournisseur d'IA:
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.
Présentation de Rocket EVA 2.0
Rocket EVA: Pas d'expert CICS ? Pas de problème.
IDC Link examine comment Rocket EVA™ intègre l'IA agentique aux opérations mainframe
