Dans un article précédent, nous avons abordé la question de l'accès des agents. Plus précisément, nous avons expliqué pourquoi la plupart des agents IA disposent d'un accès trop étendu, et comment l'appel de fonctions régi par des règles permet de modifier cette situation.
Aujourd'hui, nous allons creuser un peu plus loin : l'identité de l'agent.
Lorsqu'un agent IA effectue une action au sein de vos systèmes d'entreprise, quelle identité utilise-t-il ? La question semble simple. Or, pour la plupart des déploiements d'IA en entreprise, la réponse est étonnamment floue.
Le piège du compte de service
Voici comment cela se passe généralement. Un développeur configure un agent IA et a besoin que celui-ci se connecte à un système backend, à un CRM, à un ERP et à un entrepôt de données. Il crée un compte de service doté des autorisations nécessaires. Il transmet ces identifiants à l'agent. Et le tour est joué.
Cette approche est pragmatique, rapide et quasi universelle. Malheureusement, ce raccourci soulève également un problème d'identité fondamental. Pire encore, c'est précisément ce genre de problème qui empêche les systèmes d'IA fonctionnels d'obtenir l'autorisation nécessaire pour être déployés en production. Voyons pourquoi il en est ainsi.
Les comptes de service ne sont pas des personnes. Ils ne sont pas associés à des fonctions, à des liens hiérarchiques ou à des politiques d'accès aux données liées au statut professionnel d'un individu en particulier. Ils ne sont pas désactivés lorsqu'un employé quitte l'entreprise. Et lorsqu'un incident se produit, qu'un agent accède à des données auxquelles il n'a pas droit ou effectue une action non autorisée, la piste d'audit mène à un compte de service, et non à la personne à l'origine de cette action.
« L'agent a consulté l'enregistrement X »n'est pas une information utile sur le plan judiciaire. «L'agent a agi au nom d'Alice, qui disposait d'un accès en lecture seule à cet enregistrement et n'avait pas autorisé cette action » est une information utile. Cette différence revêt une importance capitale lorsque l'on tente d'expliquer un incident à une équipe chargée de la conformité.
Usurpation d'identité ou délégation ?
Il existe deux modèles décrivant la manière dont un agent IA peut agir au nom d'un utilisateur.
1. Usurpation d'identité
L'usurpation d'identité signifie que l'agent endosse littéralement l'identité de l'utilisateur. Les identifiants sont partagés ou délégués de telle sorte que le système backend considère que l'action provient directement de l'utilisateur. Cette technique est simple à mettre en œuvre. Elle brouille également la frontière entre les actions humaines et celles de l'agent, d'une manière difficile à démêler a posteriori.
2. Délégation
La délégation signifie que l'agent agit dans le cadre d'une délégation d'autorité de l'utilisateur, dont la portée et la durée sont clairement définies. Le système d'arrière-plan sait qu'un agent est en train d'agir, sait quel utilisateur l'a autorisé et sait exactement ce que l'agent était autorisé à faire. Ce modèle est plus difficile à mettre en œuvre, mais c'est le seul qui garantisse une véritable responsabilité.
SnapLogic prend en charge la délégation via l'échange et la propagation de jetons OAuth2. Lorsqu'un utilisateur déclenche un agent IA via le serveur MCP, son identité et son jeton OAuth2 sont transmis tout au long de la chaîne d'exécution.
Lorsque le pipeline SnapLogic atteint le système backend, il transmet l'identité de l'utilisateur d'origine, et non celle d'un compte de service anonyme.
Pourquoi est-ce important pour la conformité ?
La propagation d'identité n'est pas seulement un détail technique. Pour les secteurs réglementés, les services financiers, le secteur de la santé et les administrations publiques, il s'agit d'une exigence de conformité incontournable en matière d'accès aux données du monde réel. Et sans cet accès, un agent IA n'est d'aucune utilité.
La plupart des systèmes d'entreprise appliquent déjà des contrôles d'accès basés sur l'identité de l'utilisateur. Par exemple, votre :
- Le CRM ne permet pas à tous les employés d'accéder à l'ensemble des dossiers clients
- Le système ERP dispose d'autorisations basées sur les rôles qui ont été soigneusement mises à jour au fil des ans
- L'entrepôt de données dispose d'une sécurité au niveau des colonnes liée à des rôles utilisateur spécifiques
Lorsque vous utilisez un compte de service générique via ces systèmes, ces contrôles ne s'appliquent pas. Les politiques existent, mais elles sont contournées. L'agent bénéficie des droits d'accès du compte de service, qui sont souvent bien plus étendus que ceux dont disposerait un utilisateur individuel.
Et non, la solution ne consiste pas à utiliser un compte aux fonctionnalités limitées, car sans accès à des données spécifiques, l'agent sera bien moins utile et son utilisation se limitera à des cas génériques et peu pertinents.
Lorsque vous transmettez l'identité de l'utilisateur, toutes ces mesures de contrôle existantes s'appliquent automatiquement. L'agent peut faire exactement ce que l'utilisateur est en mesure de faire. Vous n'avez pas eu à repenser votre modèle de sécurité pour l'IA. Il vous suffit simplement d'associer la bonne identité.
Le standard implémenté par SnapLogic : RFC 9728
Le serveur MCP de SnapLogic met en œuvre la norme RFC 9728, la spécification OAuth 2.0 relative aux métadonnées des ressources protégées. Il s'agit d'une approche de la gestion des identités fondée sur des normes, et non d'un mécanisme propriétaire qui impose de nouvelles contraintes de sécurité ou vous enferme dans un écosystème fermé.
Lorsqu'un agent IA se connecte à un serveur MCP SnapLogic, il détecte automatiquement la configuration OAuth2. La procédure d'authentification est conforme aux normes. Le jeton d'identité est propagé à travers le plan de données de SnapLogic via la propagation SecurityContext, depuis le client IA jusqu'au pipeline, puis au backend.
La question à se poser concernant vos agents IA actuels
Si votre entreprise utilise déjà des agents IA, posez-vous la question suivante : quelle identité utilisent-ils lorsqu'ils interagissent avec les systèmes backend ?
Si la réponse est « un compte de service », vous avez un problème d'identité. Vos agents opèrent en dehors du modèle d'identité et d'accès que vous avez mis des années à mettre en place.
Dans la troisième partie, nous aborderons ce qui se passe une fois que l'accès et l'identité ont été correctement gérés : le contrôle. Plus précisément, comment prouver à votre équipe de sécurité, à votre équipe chargée de la conformité et à vos auditeurs que vos agents IA font exactement ce qu'ils sont censés faire, et rien de plus ?
Il s'agit d'une série en trois parties destinée à présenter notre prochaine table ronde virtuelle intitulée «Gérer les agents IA : sécurité des accès, identité et contrôle à l'échelle de l'entreprise ».Rejoignez-nous le 10 juin dans votre région : inscrivez-vous à la diffusion EMEA ou à la diffusion en Amérique du Nord. À bientôt !
