Tout agent IA a besoin d'une identité

Une entreprise donne à un agent IA l'accès à son espace de stockage partagé, à sa plateforme CRM et à son système de messagerie. L'agent peut consulter les dossiers clients, préparer des devis, mettre à jour les opportunités commerciales et envoyer des messages de suivi. Il intervient dans plusieurs applications et effectue des tâches qui nécessitaient auparavant l'intervention d'un employé. Pourtant, l'entreprise peut encore avoir du mal à répondre à une question fondamentale : qui agit lorsque l'agent accomplit ce travail ?

De nombreuses organisations créent des agents en tant qu’extensions d’un compte utilisateur, d’une application logicielle ou d’un identifiant de service partagé. Cela peut s’avérer suffisant dans le cadre d’un projet pilote contrôlé. Cela devient toutefois dangereux dès lors que l’agent commence à fonctionner de manière autonome, en accédant à des informations sensibles ou en déclenchant des actions sur plusieurs systèmes. Un agent d’entreprise doit disposer de sa propre place identifiable au sein de l’organisation. L’entreprise doit savoir ce qu’est l’agent, qui l’a autorisé, à quelles ressources il peut accéder, quelles actions il est autorisé à effectuer et à quel moment ses autorisations doivent expirer. Sans cette identité, l’agent peut devenir un acteur numérique puissant, doté d’un accès étendu et d’une responsabilité limitée.

Un agent, c'est bien plus qu'une simple application

Les logiciels d'entreprise traditionnels suivent généralement des instructions prévisibles. Une application reçoit une entrée définie, exécute un processus programmé et produit une sortie attendue. Les équipes de sécurité peuvent cartographier ses connexions et préciser les opérations qu'elle effectue.

Les agents IA se comportent différemment. Ils interprètent les objectifs, choisissent les étapes intermédiaires et font appel à des outils en fonction de la situation à laquelle ils sont confrontés. Un agent commercial peut par exemple consulter une fiche client dans le CRM, examiner la correspondance antérieure, consulter un fichier de tarification, rédiger une proposition et demander à un autre agent de vérifier les conditions.

L'ordre des opérations peut varier d'une tâche à l'autre. Cette flexibilité constitue l'un des principaux atouts des agents, mais elle complique également le contrôle d'accès. Une application classique peut avoir besoin d'une autorisation pour exécuter un petit nombre d'opérations prédéfinies. Un agent peut potentiellement combiner plusieurs autorisations légitimes d'une manière que personne n'avait anticipée au moment où ces autorisations ont été accordées.

La question de la sécurité prend donc une autre dimension. Les entreprises doivent déterminer non seulement si l'agent est autorisé à se connecter à un système, mais aussi s'il doit effectuer une action spécifique, sur une ressource donnée, dans un but précis et sous l'autorité d'une personne en particulier. L'identité individuelle constitue la base permettant de répondre à ces questions.

Le partage des identifiants sape la responsabilité

La manière la plus simple de connecter un agent aux systèmes d'entreprise consiste souvent à lui attribuer un compte de service existant ou à lui permettre d'agir en utilisant les identifiants d'un employé.

Ces deux approches posent des problèmes. Lorsque plusieurs agents utilisent le même compte de service, les journaux d'activité peuvent indiquer que ce compte a ouvert un document ou modifié un enregistrement sans préciser quel agent a effectué l'action. Les enquêteurs peuvent constater qu'un événement s'est produit, mais ne sont pas toujours en mesure de retracer le flux de travail correspondant.

Le fait de permettre à un agent d'hériter de l'identité d'un employé crée une autre ambiguïté. Le système peut enregistrer l'employé comme l'auteur de l'action, même lorsque c'est l'agent qui a choisi et exécuté cette action de manière indépendante.

Cela revêt une importance particulière lorsqu'un agent envoie une instruction de paiement erronée, modifie la fiche d'un client ou divulgue des informations confidentielles. L'entreprise doit déterminer si l'employé a demandé cette action, si l'agent est allé au-delà de la demande et quel système lui a permis de la mener à bien.

Une identité propre à chaque agent permet d'obtenir une piste d'audit plus claire. Elle permet à l'organisation de faire la distinction entre les décisions humaines, les actions déléguées et les étapes autonomes effectuées dans le cadre d'un flux de travail approuvé.

Cette séparation facilite les enquêtes sur les incidents, les contrôles de conformité et la supervision opérationnelle courante. Elle empêche également l'entreprise de considérer chaque erreur commise par un agent comme si elle avait été commise personnellement par l'employé qui en est le responsable.

Tout agent a besoin d'un parrain responsable

Le fait de doter un agent d’une identité technique ne suffit pas à le rendre responsable. L’organisation doit également désigner un responsable humain.

Un agent peut intervenir dans plusieurs services, mais quelqu'un doit rester responsable de son objectif, de ses autorisations et de son bon fonctionnement. Ce responsable doit comprendre ce que fait l'agent, quelles données il utilise et quelles conséquences pourraient survenir s'il fonctionnait de manière incorrecte.

Le responsable n'a pas besoin d'approuver chaque action courante. Une validation constante réduirait considérablement l'intérêt de l'automatisation. Le responsable doit plutôt définir les limites dans lesquelles l'agent opère.

Cela implique notamment de demander l'accès, d'examiner les autorisations inhabituelles, de vérifier que l'agent répond toujours à un objectif métier légitime et de déterminer à quel moment l'organisation doit le suspendre ou le retirer.

La responsabilité ne doit pas rester informelle. Un projet pilote lancé par un employé peut progressivement s'intégrer à un processus essentiel, même après que cet employé a changé de poste ou a quitté l'entreprise. L'agent peut continuer à disposer des droits d'accès et à exécuter des tâches sans qu'il y ait de responsable opérationnel en poste.

Les entreprises sont déjà confrontées à ce problème avec les applications et les comptes de service abandonnés. Les agents peuvent aggraver la situation, car ils ne se contentent pas de conserver leurs droits d'accès : ils peuvent continuer à les utiliser.

Les autorisations doivent dépendre de la tâche

Un agent ne devrait pas bénéficier de tous les droits d'accès dont dispose son commanditaire.

Un dirigeant peut être habilité à consulter les données relatives aux rémunérations, à approuver des dépenses et à prendre connaissance de documents confidentiels du conseil d'administration. Un mandataire chargé d'organiser des réunions pour le compte du dirigeant n'a pas besoin des mêmes pouvoirs.

Les entreprises doivent attribuer les autorisations en fonction du rôle défini de chaque agent. Un agent chargé de la planification peut avoir besoin d'accéder aux disponibilités du calendrier, mais pas nécessairement au contenu complet de chaque réunion. Un agent chargé des achats peut comparer les devis des fournisseurs sans pour autant disposer de l'autorisation d'approuver un contrat. Un agent du service client peut consulter les informations relatives à un compte sans pour autant pouvoir modifier les détails de paiement.

Il s'agit du principe du privilège minimal appliqué aux systèmes basés sur des agents. L'agent ne dispose que des droits d'accès nécessaires à l'exécution de la tâche qui lui a été confiée.

Le principe semble familier, mais les agents compliquent son application. Les développeurs peuvent ajouter des outils à mesure que le projet prend de l'ampleur, les services peuvent connecter de nouvelles sources de données et les utilisateurs peuvent demander des fonctionnalités plus étendues. L'agent accumule progressivement des autorisations qui ne correspondent plus à son objectif initial.

Les équipes de sécurité devraient donc considérer les révisions des autorisations comme un processus continu plutôt que comme une simple vérification ponctuelle du déploiement.

Ils doivent également faire la distinction entre la consultation d'informations et l'exécution d'une action. Permettre à un agent de consulter une facture n'est pas la même chose que lui permettre de modifier le compte bancaire associé à cette facture. Lire un projet de contrat n'est pas la même chose que l'envoyer à la contrepartie.

Les actions les plus importantes peuvent nécessiter un contrôle supplémentaire, tel qu'une validation humaine, une authentification renforcée ou une confirmation via un système distinct.

La délégation doit être visible

De nombreux agents n'agissent pas entièrement de leur propre chef. Ils effectuent des tâches qui leur sont confiées par un utilisateur.

Le système d'identification devrait préserver cette relation.

Un enregistrement doit indiquer qu'un employé donné a donné pour instruction à un agent donné d'effectuer une tâche bien définie. Le système doit ensuite faire la distinction entre les actions couvertes par cette instruction et les étapes supplémentaires choisies par l'agent au cours de l'exécution.

C'est important, car la délégation n'équivaut pas à un consentement illimité.

Un employé peut demander à un agent de dresser une liste des factures en souffrance. Cette demande n'autorise pas nécessairement l'agent à contacter les clients, à modifier les conditions de paiement ou à engager des procédures de recouvrement. Le fait que l'agent soit en mesure de déterminer la marche à suivre ne doit pas lui donner automatiquement le droit de passer à l'action.

Des contrôles de délégation clairs permettent aux entreprises d'allier autonomie et pouvoirs bien définis. Le responsable peut décider de la manière d'exécuter une tâche approuvée, tout en ne pouvant pas étendre cette tâche au-delà du périmètre autorisé.

La délégation doit également être limitée dans le temps. Un agent qui bénéficie d'un accès temporaire pour mener à bien un projet doit perdre cet accès dès que le projet est terminé. Une autorisation temporaire ne doit pas se transformer en autorisation permanente simplement parce que personne n'a pensé à la retirer.

L'identité rend la surveillance plus utile

Les entreprises ne peuvent pas contrôler des agents qu'elles ne parviennent pas à identifier.

Un inventaire doit répertorier chaque agent déployé, son responsable, sa fonction, les systèmes auxquels il est connecté et les autorisations qui lui ont été attribuées. L'organisation doit également savoir si l'agent est actif, expérimental, suspendu ou s'il doit être retiré du service.

Cela permet de jeter les bases d'un suivi efficace.

Les équipes de sécurité peuvent détecter toute activité inhabituelle lorsqu'elles connaissent le rôle habituel d'un agent. Un agent chargé de la recherche qui tente soudainement de modifier des données relatives à la paie présente un écart manifeste. Un agent du service client qui exporte un volume inhabituellement important d'enregistrements peut nécessiter une enquête immédiate.

L'organisation peut également comparer des agents similaires et identifier les doublons. Il arrive en effet que plusieurs services aient créé des outils distincts qui remplissent pratiquement la même fonction, tout en accédant aux mêmes données via des contrôles différents.

En l'absence d'un inventaire des identités, ces agents peuvent se multiplier plus rapidement que la structure de gouvernance qui les encadre. Chaque nouvel agent devient un acteur non humain supplémentaire capable d'accéder aux systèmes, de détenir des identifiants et de créer des dépendances opérationnelles.

La visibilité doit être assurée dès la phase de développement, et non après le déploiement. Les plateformes « low-code » permettent aux équipes métier de créer des agents sans avoir à attendre la mise en place d’un projet logiciel centralisé. Cette rapidité peut s’avérer utile, mais l’agent ainsi créé doit tout de même être soumis au processus d’identification et de validation de l’entreprise avant de se voir accorder un accès à l’environnement de production.

Les agents ont besoin d'un cycle de vie

Les employés rejoignent l'entreprise, changent de poste et la quittent. Leurs droits d'accès doivent évoluer en fonction de ces changements.

Les agents doivent avoir un cycle de vie équivalent.

Une entreprise doit déterminer comment un agent obtient son identité, qui approuve ses autorisations initiales et à quel moment ces autorisations sont réexaminées. Elle doit également définir la marche à suivre lorsque l'employé responsable quitte l'entreprise, lorsque le processus sous-jacent évolue ou lorsque l'agent est remplacé par une version plus récente.

Un agent mis à jour peut nécessiter une nouvelle évaluation, même s'il conserve le même nom. Un changement de modèle, de connexion à un outil ou de jeu d'instructions peut modifier son comportement et les risques qu'il engendre.

La mise hors service mérite une attention particulière. La désactivation de l'interface visible ne supprime pas nécessairement les clés API, les processus en arrière-plan, les tâches planifiées ou les connexions à d'autres agents. L'organisation doit révoquer les identifiants, fermer les voies d'accès et conserver les enregistrements nécessaires à un audit ou à une enquête.

Les agents inactifs ne doivent pas rester opérationnels indéfiniment. Un agent qui n'a pas effectué de tâche légitime pendant une période définie peut se voir retirer automatiquement ses droits d'accès jusqu'à ce que son propriétaire confirme qu'il est toujours nécessaire.

L'approbation humaine ne peut pas tout résoudre

Les entreprises réagissent souvent au risque lié aux agents en plaçant une personne à la fin du processus. L'agent prépare l'action, puis l'employé clique sur « Valider ».

Ce dispositif de contrôle peut s'avérer utile, notamment en matière de paiements, de contrats, de communications externes et de modifications apportées à des dossiers sensibles. Il n'est toutefois pas suffisant à lui seul.

Les employés peuvent approuver rapidement les demandes, car l'agent fournit généralement un travail satisfaisant. Ils ne comprennent pas toujours à quelles données l'agent a eu accès, comment il est parvenu à sa conclusion ou si une demande apparemment courante comporte une étape inhabituelle.

L'efficacité de la validation diminue également lorsque les agents génèrent un volume important de décisions. Un évaluateur humain qui reçoit des centaines de demandes peu contextualisées risque de se limiter à un simple contrôle de forme.

Les contrôles d'identité et d'accès allègent la charge de travail des réviseurs humains en empêchant l'agent de proposer ou d'exécuter des actions qui ne relèvent pas de son rôle autorisé. L'approbation humaine peut ainsi se concentrer sur les décisions ayant une réelle incidence, plutôt que de devoir pallier un modèle d'autorisations trop large.

La conception la plus efficace combine ces deux éléments. L'agent dispose d'une identité bien définie, d'une autorité limitée et d'un historique complet de ses activités. L'intervention humaine intervient lorsque l'impact potentiel le justifie.

L'identité est le point de départ des agents d'entreprise

Les entreprises évaluent souvent les agents d'IA en fonction de ce qu'ils sont capables de réaliser. Elles comparent les performances des modèles, les possibilités d'intégration et la charge de travail que le système peut automatiser.

Le déploiement en production soulève une autre question : sous l'autorité de qui l'agent agit-il ?

Pour qu'une réponse soit fiable, il ne suffit pas qu'un nom s'affiche dans un tableau de bord. L'agent doit disposer d'une identité technique distincte, d'un responsable désigné, d'autorisations spécifiques à ses tâches, d'une délégation de tâches visible et d'un cycle de vie géré. Ses actions doivent rester attribuables, même lorsqu'il collabore avec d'autres agents ou intervient sur plusieurs systèmes d'entreprise.

Ces mesures de contrôle n'éliminent pas les risques liés aux logiciels autonomes. Elles permettent toutefois de les maîtriser.

Un agent sans identité peut accumuler des droits d'accès, effectuer des actions et créer des dépendances tout en restant difficile à tracer ou à supprimer. Un agent doté d'une identité clairement gérée devient un acteur reconnu au sein de l'entreprise, dont l'organisation peut contrôler, limiter et révoquer les droits.

À mesure que les entreprises déploient davantage d'agents, la gestion des identités ne se limitera plus à la périphérie du déploiement. Elle déterminera si l'organisation peut accroître l'autonomie sans perdre le contrôle.