Guide technique
Le guide ultime des identités des agents IA sur AWS, Azure et GCP
Derrière chaque agent d'IA se cache une identité qui doit être authentifiée, autorisée et surveillée. Or, sur AWS, Azure et GCP, ces identités se comportent différemment. Si vous êtes un professionnel de la sécurité, ce guide pratique vous aidera à concevoir une approche cohérente et sécurisée pour les environnements multicloud.
Guide technique
Le guide ultime des identités des agents IA sur AWS, Azure et GCP
Derrière chaque agent d'IA se cache une identité qui doit être authentifiée, autorisée et surveillée. Or, sur AWS, Azure et GCP, ces identités se comportent différemment. Si vous êtes un professionnel de la sécurité, ce guide pratique vous aidera à concevoir une approche cohérente et sécurisée pour les environnements multicloud.
Demo
Voir le Silverfort plateforme en action
Découvrez pourquoi les plus grandes entreprises nous font confiance pour sécuriser ce que d’autres ne peuvent pas faire.
Démo
Section 1
Pourquoi ce guide existe-t-il ?
Vos agents IA agissent déjà comme des identités. La question est : savez-vous lesquelles ?
Lorsqu'un agent envoie un e-mail, il s'authentifie en tant que quelqu'unLorsqu'il interroge une base de données, il possède quelques uns autorisations. Lorsqu'il accède à un partage de fichiers, quelqu'un apparaît dans les journaux d'audit. Mais qui ?
Voici ce que la documentation du fournisseur ne vous dira pas :
- Les agents Azure peuvent agir sous plusieurs identités au sein d'une même conversation : utilisateur, créateur et agent lui-même.
- La configuration par défaut de GCP partage une seule identité entre tous vos agents au sein d'un même projet.
- AWS vous donne un contrôle total, ce qui signifie que toute erreur de configuration est entièrement de votre responsabilité.
Ce guide couvre ce que la documentation de la plateforme ne couvre pas : pas how pour configurer les agents, mais est ce que nous faisons les identités qu'ils utilisent réellement lorsqu'ils agissent, et ce que cela implique pour votre niveau de sécurité.
Aperçu des trois plateformes :
Plateforme complète
Philosophie de l'identité
AWS
Votre compte, votre identité. Contrôle total, responsabilité totale.
Azure
Une identité flexible pour la complexité de l'entreprise.
GCP
Infrastructure gérée, identité configurable.
À qui s’adresse ce guide :
Responsables de la sécurité en charge de la gestion des identités et des accès (IAM), de la sécurité du cloud ou de la gouvernance de l'IA dans les environnements de production.
Ce que vous apprendrez:
- Pourquoi l'identité d'un agent diffère-t-elle des identités non humaines traditionnelles ?
- Comment chaque grande plateforme cloud conçoit l'identité de l'agent
- Quel modèle d'identité chaque plateforme utilise-t-elle (avec des exemples précis) ?
- Les principaux risques liés à l'identité pour chaque plateforme
- Listes de contrôle pratiques pour la gestion des identités
Avant de commencer, posez-vous la question suivante :
- Savez-vous quelles identités vos agents utilisent pour chaque outil ?
- Un utilisateur disposant de faibles privilèges peut-il déclencher des actions nécessitant des privilèges élevés via un agent ?
- Est-il possible de révoquer l'accès d'un agent sans redéployer le code ?
- Disposez-vous d'un historique unique des actions de chaque agent ?
- Pouvez-vous remonter jusqu'à un employé ?
Si vous avez répondu « non » à l'une de ces questions, vous n'êtes pas seul – et ce guide vous aidera.
Ce document ne traite pas de la sécurité du cloud en général. Il porte spécifiquement sur l'identité des agents, c'est-à-dire qui est l'agent lorsqu'il agit.
Aperçu clé
Il est impossible de prédire ce que fera ensuite un agent d'IA.
Il ne s'agit pas d'un bug, mais bien du principe même. Les agents sont précieux car ils sont adaptables. Cependant, cette adaptabilité engendre des défis en matière de sécurité des identités auxquels les contrôles traditionnels de l'assurance maladie nationale ne sont pas adaptés.
Section 2
Pourquoi les identités des agents sont différentes
Avant d'aborder les spécificités de chaque plateforme, examinons ce qui rend les identités des agents d'IA uniques. Ce contexte est essentiel pour évaluer les recommandations spécifiques à chaque plateforme qui suivent.
Comparaison rapide : Humain vs assurance maladie nationale traditionnelle vs agent IA
Dimension
Humain
Assurance maladie nationale traditionnelle
Philosophie de l'identité
Comportement
Variable, fondé sur le jugement
Déterministe, scripté
Non déterministe, adaptatif
La prise de décision
Contextuel, responsable
Préprogrammé ou non
Modèle basé sur le contexte
Modèles d'accès
Variable, auditable
Prévisible et cohérent
Variable, dépendant de la tâche
Permissions
Évalué en fonction des rôles
Statique, de longue durée
Variable, dépendant de la tâche
Sensibilité aux entrées adverses
Ingénierie sociale
Nécessite un vol d'identifiants ou une modification du code/de la configuration
Subversion de l'invite/de l'outil
Trois risques d'identité uniques pour les agents
1. Détournement de décision par la manipulation
Les comptes de service exécutent des flux de travail déterministes. Pour modifier leur fonctionnement, un attaquant doit généralement contrôler le code du flux de travail ou sa configuration/ses entrées d'exécution.
En revanche, les agents d'IA répondent à des instructions. Pour modifier ce qui l'ont Vous devez donc élaborer la bonne entrée.
Implication: L'injection de prompts détourne le processus décisionnel d'un agent opérant sous une identité valide, produisant des effets similaires à une usurpation d'identité sans compromettre ses identifiants. L'identité reste inchangée ; ce sont les outils utilisés, les actions et les décisions prises par l'agent sous cette identité qui sont détournés. Les contrôles d'accès traditionnels sont impuissants face à ce type d'attaque.
ExempleUn attaquant insère des instructions dans un document traité par l'agent, ce qui provoque l'appel de son connecteur SQL autorisé avec SELECT * FROM customers WHERE credit_limit > 100000 et transmettre les résultats à son outil de messagerie électronique — les deux outils sont autorisés, mais la requête et le chemin d'exfiltration n'ont jamais été prévus.
2. Prolifération des identifiants sur les surfaces d'interaction
Les identifiants NHI traditionnels (comptes de service, clés API) sont généralement divulgués via des surfaces de code/configuration : secrets enregistrés, fichiers de configuration, variables d’environnement.
Les agents augmentent les risques de fuite de données, car les secrets peuvent transiter par les invites/réponses en langage naturel, les entrées/sorties des outils, les transcriptions de chat et les journaux de débogage, notamment lors du développement et du dépannage. Une bonne conception permet d'éviter ce problème, mais il est fréquent lors des premiers déploiements.
Exemple : L'agent inclut accidentellement une clé API dans une réponse, ou l'invite de l'utilisateur inclut des informations d'identification sensibles que l'agent expose.
Implication: L'hygiène des identifiants doit s'étendre aux entrées/sorties des agents, et pas seulement au code et à la configuration.
Principe de conception : Évitez de transmettre les informations confidentielles directement dans le langage naturel. Utilisez des connecteurs sécurisés/gestionnaires de secrets et des paramètres d'outils structurés pour les transmettre, et non pas directement dans le texte d'invite.
3. Exigences d'autorisation dynamiques
Les comptes de service exécutent des tâches planifiées et prévisibles, ce qui facilite l'établissement d'une base de référence pour ce qui est « normal ». Les autorisations statiques conviennent aux comptes de service car leur comportement est statique.
Les agents d'IA répondent aux requêtes des utilisateurs, ce qui rend chaque interaction unique. La notion de « normalité » évolue constamment. Les permissions statiques peuvent être surdimensionnées (entraînant des risques) ou sous-dimensionnées (provoquant des dysfonctionnements). Les utilisateurs font partie intégrante du périmètre d'accès. Un utilisateur disposant de faibles privilèges peut déclencher une action nécessitant des privilèges élevés si l'identité de l'outil de l'agent est trop étendue ou déléguée par un compte de créateur/service privilégié.
Implication: Les agents ont besoin d'autorisations limitées à la tâche spécifique, et non d'un accès général permanent.
ExempleN’accordez l’accès en lecture à une base de données que pour la durée d’une requête, et non de façon permanente. La détection d’anomalies traditionnelle (c’est-à-dire les écarts par rapport à la valeur de référence) est peu efficace car il est impossible de prédire le comportement futur d’un agent d’IA.
Pourquoi les contrôles traditionnels de l'assurance maladie nationale sont insuffisants
Approche traditionnelle
Pourquoi cela ne fonctionne pas pour les agents
Accorder des autorisations permanentes et étendues
Les agents ont besoin d'autorisations dynamiques adaptées à la tâche spécifique.
Attributions d'autorisations statiques
Même avec des jetons à durée de vie limitée, la portée des autorisations est souvent statique et excessivement large.
Surveiller les écarts d'horaire
Les agents n'ont pas d'horaires prévisibles.
Examens annuels d'accès
Dans les environnements évoluant rapidement, les agents peuvent être créés et modifiés fréquemment.
Supposons un comportement cohérent
Les agents sont intrinsèquement variables.
Note sur la terminologie :
Chaque fournisseur de cloud propose plusieurs structures de type « agent » sous différentes appellations : agents Bedrock, agents Copilot Studio, projets AI Foundry, agents Vertex AI, etc. Dans ce guide, nous définissons un « agent » comme tout système piloté par l’IA capable d’invoquer des outils ou d’accéder à des ressources de manière autonome sous une identité spécifique. Le nom précis du produit importe moins que le modèle d’identité qu’il utilise.
Si vous utilisez plusieurs clouds :
Vous gérez simultanément plusieurs modèles d'identité. Chaque section de plateforme ci-dessous est autonome, mais il est important de comprendre que vos défis en matière de gouvernance s'amplifient d'un cloud à l'autre.
Section 3
Fonctionnement des identités des agents sur chaque plateforme
La question centrale : Qui est cet agent ?
Chaque nuage répond différemment à cette question, selon sa philosophie identitaire. Avant d'entrer dans les détails, voici un cadre de réflexion unificateur pour appréhender ces différences.
Le spectre identitaire : Propriété → délégation → opacité
Tous les modèles d'identité d'agent se situent quelque part sur ce spectre :
Poste
Ce que cela veut dire
Exemple
Droit de propriété
Vous possédez et contrôlez tous les éléments d'identité
AWS
Délégation
L'identité change en fonction du contexte
Azure
Opacité
Environnement d'exécution géré par le fournisseur avec inspection/télémétrie client limitée dans le contexte d'exécution
GCP
Les plateformes peuvent couvrir plusieurs positions selon le produit (par exemple, Copilot Studio vs Foundry).
Ces modèles optimisent des choses différentes :
- Droit de propriété maximise le contrôle client et définit clairement les limites de la zone d'impact, mais exige une ingénierie IAM rigoureuse.
- Délégation Cela peut améliorer la responsabilisation humaine (c’est-à-dire les actions liées à l’initiateur), mais introduit des contextes d’identité mixtes et accroît le risque de transmission de privilèges par le biais des connecteurs/créateurs.
- Opacité réduit les frais généraux opérationnels mais limite l'inspection et les analyses médico-légales
Gardez ce spectre à l'esprit lorsque vous lisez l'approche de chaque plateforme.
TL; DR
AWS : Votre compte, votre identité.
Le contrôle total implique une responsabilité totale : définissez les rôles IAM, appliquez le principe du moindre privilège, assumez vos erreurs.
Liste de contrôle pour la gestion des identités
- Agent de cartographie → rôle d'exécution → (rôles liés à l'outil, le cas échéant)
- Vérifier les autorisations pour chaque rôle (principe du moindre privilège)
- Suivre la traçabilité de l'agent : qui l'a créé, quels outils il utilise et (pour les agents conversationnels) quels utilisateurs peuvent l'invoquer.
- Utilisez des limites d'autorisation (garde-fous IAM qui définissent les autorisations maximales qu'un rôle peut avoir, quelles que soient les politiques qui y sont associées).
- Surveillez les attributions de rôle afin de détecter les anomalies (horaires inattendus, fréquence inhabituelle, adresses IP sources inconnues ou accès à des ressources en dehors du périmètre attendu de l'agent).
AWS : Votre compte, votre identité (Bedrock et AgentCore)
La philosophie d'AWS
AWS traite les agents d'IA de la même manière que n'importe quelle autre charge de travail : Le contrôle d'identité repose sur votre compte.Cela concerne vos rôles IAM, vos compartiments S3 et vos journaux CloudWatch. Bien que Bedrock soit un service géré (AWS assure l'exécution), la gestion de vos identités (rôles, stratégies et journaux d'audit) est gérée par votre compte.
Dans AWS, l'identité est toujours gérée par IAM. L'identité d'un agent correspond à un rôle IAM, au même titre qu'une fonction Lambda ou une instance EC2. Si vous savez comment sécuriser IAM, vous disposez des bases nécessaires pour sécuriser l'identité des agents (même si ces derniers présentent des risques spécifiques, comme expliqué dans la section 2).
Comment cela s'applique aux agents Bedrock
AWS Bedrock est le service géré d'Amazon pour la création d'agents d'IA. Lorsque vous créez un agent Bedrock, AWS provisionne tout au sein de votre compte ; toutefois, vous devez comprendre la structure de l'identité.
Chaque agent Bedrock possède un Rôle d'exécution de l'agent, l'identité principale que l'agent utilise pour agir.
Si l'agent possède des groupes d'actions (les outils et les capacités que vous configurez pour votre agent), chaque groupe d'actions a des implications en matière d'identité :
Type de groupe d'actions
Impact sur l'identité
Fonction Lambda
Lambda s'exécute sous son propre rôle d'exécution (distinct du rôle d'agent). Lambda peut appeler des API externes, accéder aux services AWS ou exécuter une logique personnalisée, le tout sous son rôle IAM.
Contrôle de retour
Aucun rôle supplémentaire ; l’action renvoie le contrôle à l’application appelante, qui gère l’exécution sous sa propre identité.
Le résultat
Un agent peut impliquer plusieurs rôles IAM, selon la configuration du groupe d'actions : le rôle d'exécution de l'agent, ainsi que les rôles d'exécution Lambda ou autres rôles de service invoqués par les groupes d'actions. Vous créez et gérez ces rôles ; Bedrock ne les crée pas automatiquement.
Qu'est-ce que cela signifie pour vous?
- Vous pouvez voir à quoi l'agent est autorisé à accéder dans AWS (via les politiques IAM), mais les journaux ne vous indiqueront pas pourquoi l'agent a décidé d'accéder à une ressource.
- Vous contrôlez l'identité et vous êtes responsable de sa sécurité.
- Les modèles de sécurité standard d'AWS s'appliquent directement.
Question clé à laquelle il faut répondre :
Quels rôles IAM appartiennent à quels agents ?
Risque lié à l'identité :
Des rôles surprivilégiés qui accordent un accès supérieur aux besoins de l'agent.
Puisque vous créez le rôle IAM, toute erreur de configuration est de votre responsabilité. Commencez par des autorisations minimales et n'en augmentez que si cela est justifié.
Impact en cas de compromission :
Les rôles surprivilégiés accordent des droits d'accès supérieurs à ceux nécessaires à l'agent. Étant donné que vous créez le rôle IAM, toute erreur de configuration est de votre responsabilité. Commencez par des autorisations minimales et n'en ajoutez que si cela est justifié.
Que ce soit par vol d'identifiants, octroi de droits excessifs ou manipulation rapide entraînant des actions non intentionnelles :
L'attaquant obtient l'accès à tout ce que le rôle d'exécution de l'agent peut toucher : modèles de base, compartiments S3, bases de connaissances, ainsi que tous les rôles IAM supplémentaires si les groupes d'actions invoquent d'autres services AWS (fonctions Lambda, points de terminaison API Gateway, etc.).
Le rayon de l'explosion est limité par les autorisations IAM que vous avez configurées.
Également disponible sur AWS : AgentCore (approche Code-First)
Pour les développeurs qui créent des agents par le biais du code (et non via l'interface utilisateur sans code de Bedrock), AWS propose AgentCore. Le modèle d'identité suit la même philosophie AWS, où les agents utilisent des rôles IAM, mais avec des différences importantes :
Définition de l'identité « code-first » : Contrairement à la configuration via console de Bedrock, l'identité d'AgentCore est définie par l'infrastructure en tant que code et les configurations de déploiement. Les rôles IAM sont généralement spécifiés dans les manifestes d'application ou les modèles IaC, ce qui offre aux développeurs un contrôle total, mais les oblige à bien les configurer.
Risque de mauvaise configuration plus élevé : Étant donné que l'identité est définie par le code, AgentCore présente un risque plus élevé de :
- Rôles surprivilégiés codés en dur dans les configurations d'application
- Identifiants intégrés dans le code source
- Définition incohérente des autorisations selon les environnements (développement/préproduction/production)
- Identifiants enregistrés accidentellement dans le système de contrôle de version (exposés dans l'historique Git même après suppression)
Responsabilité du développeur : La gestion correcte des permissions incombe principalement à l'équipe de développement, qui dispose de moins d'aide via la console que l'approche gérée de Bedrock. Aucun assistant ne guide la configuration du principe du moindre privilège.
Il repose sur la même infrastructure IAM que Bedrock, mais les risques opérationnels passent d'une mauvaise configuration de l'administrateur à une mauvaise configuration du développeur.
Dérive d'identité entre les versions d'agents (AWS Bedrock)
Le socle rocheux soutient versions et alias Pour les agents, un alias permet de rediriger le trafic vers différentes versions d'agent, ce qui est utile pour les déploiements progressifs ou les tests A/B. Cependant, cela engendre un risque lié à la gouvernance des identités.
Les différentes versions peuvent présenter des différences :
- Rôles d'exécution
- Configurations des garde-corps
- Étendue des autorisations
Le risque : Les équipes de sécurité peuvent croire qu'un agent est protégé car la version actuelle applique des garde-fous adéquats, alors qu'en réalité, le trafic est redirigé vers une version plus ancienne et moins restrictive via un alias. Il s'agit d'un risque lié au cycle de vie et à la gouvernance, et non d'une vulnérabilité de Bedrock en soi, mais cela exige une gestion explicite des versions et des alias dans votre programme de sécurité des agents.
TL; DR
Azure : Plusieurs identités, un seul agent.
Le modèle d'authentification flexible facilite les intégrations d'entreprise, mais fragmente la responsabilité. Il est essentiel de connaître le mode d'authentification utilisé par chaque connecteur.
Liste de contrôle pour la gestion des identités
- Indiquez le mode d'identité utilisé par chaque connecteur.
- Autorisations de création d'audit (envisager des comptes de service dédiés)
- Sachez qu'un seul agent peut générer trois emplacements de journalisation d'audit.
- Créez des comptes dédiés à la gestion des connecteurs (et non des comptes personnels).
- Planifier le cycle de vie du propriétaire du connecteur (que se passe-t-il lorsqu'il part ?)
Azure/Microsoft : Une identité flexible pour la complexité de l’entreprise
La philosophie de Microsoft
Microsoft reconnaît la complexité des environnements d'entreprise. Différents connecteurs nécessitent différentes authentifications : parfois l'utilisateur doit s'authentifier, parfois un compte de service, parfois la personne ayant créé l'agent. Plutôt que d'imposer un modèle unique, Azure prend en charge… plusieurs modes d'identité simultanément.
Cette flexibilité permet des intégrations puissantes, mais elle crée de la complexité : un même agent peut agir sous différentes identités selon ce qu’il fait.
Comment cela s'applique-t-il à Copilot Studio ?
Microsoft documente deux modes d'authentification principaux pour les actions de Copilot Studio :
Mode d'authentification
Lorsqu'elle est utilisée
Qui joue la comédie ?
L'audit révèle
Authentification d'utilisateur
Quand l'accès doit être limité à des utilisateurs spécifiques
L'utilisateur qui parle à l'agent
L'Utilisateur
Authentification de l'auteur de l'agent
Pour un accès implicite ou à faible risque
Pour un accès implicite ou à faible risque
Fabricant
En pratique, un troisième artefact identitaire apparaît également : le principal de service de l'agent (un Entra ID L'identité de l'application est utilisée pour certains appels d'API. Cela signifie qu'un seul agent peut générer des entrées d'audit sous trois identités différentes selon son activité.
Exemple de flux : L'utilisateur demande à l'agent de « Veuillez me faire un résumé de notre pipeline de ventes et m'en informer. »:
- L'agent interroge le CRM en utilisant la connexion de l'auteur de l'agent
- Résumé des publications dans Teams à l'aide du principal de service de l'agent
- Envoie des e-mails en utilisant les autorisations déléguées de l'utilisateur.
Trois actions, trois identités, une conversation.
Qu'est-ce que cela signifie pour vous?
- Les pistes d'audit se fragmentent selon les contextes d'identité, de sorte que la corrélation entre qui a décidé, qui a exécuté et qui a été affecté est loin d'être triviale.
- Les utilisateurs disposant de faibles privilèges peuvent accéder aux ressources à privilèges élevés via des identifiants de créateur.
Question clé à laquelle il faut répondre :
Quel mode d'authentification chaque connecteur utilise-t-il ?
Risque lié à l'identité :
Élévation de privilèges via les identifiants de l'auteur agent.
Si le créateur (celui qui a configuré le connecteur) dispose de permissions élevées, chaque utilisateur de cet agent hérite de ces permissions pour les actions utilisant ce connecteur.
Microsoft recommande l'authentification utilisateur lorsque l'accès doit être limité à des utilisateurs spécifiques ; l'authentification de l'auteur est conçue pour les scénarios d'accès implicites ou à faible risque. L'utilisation d'identifiants de créateur peut entraîner un partage excessif de données ou de fonctionnalités.
Impact en cas de compromission :
Que ce soit par vol d'identifiants, compromission de compte opérateur ou manipulation de l'interface :
L'étendue de l'impact dépend du mode d'authentification utilisé et des outils/de l'étendue des accès configurés pour l'agent. Dans le pire des cas, le créateur dispose de droits d'administrateur ; par conséquent, chaque utilisateur hérite de ces droits pour ce connecteur. L'investigation nécessite la corrélation de trois sources d'audit distinctes.
Liste de contrôle pour la gestion des identités
- Indiquez le mode d'identité utilisé par chaque connecteur.
- Autorisations de création d'audit (envisager des comptes de service dédiés)
- Sachez qu'un seul agent peut générer trois emplacements de journalisation d'audit.
- Créez des comptes dédiés à la gestion des connecteurs (et non des comptes personnels).
- Planifier le cycle de vie du propriétaire du connecteur (que se passe-t-il lorsqu'il part ?)
Également disponible sur Azure : Microsoft Foundry (anciennement AI Foundry)
Le comportement en matière d'identité étant encore en évolution, il convient de le considérer comme distinct de Copilot Studio.
Microsoft Foundry est la plateforme Azure axée sur le code pour la création d'agents d'IA, contrairement à l'approche sans code de Copilot Studio. Elle existe sous deux formes :
- Classique de la fonderie : La version originale
- Fonderie (nouveau) : L'itération actuelle avec une sémantique d'identité mise à jour
Le comportement identitaire diffère entre les approches classiques et nouvelles. Dans la nouvelle Foundry, les agents peuvent utiliser une méthode explicite Agent ID pour l'identification. Toutefois, si un agent n'est pas publié, son identité peut être projet à portée limitée plutôt que spécifique à l'agent.
La sémantique des identités est encore en développement. Tous les chemins d'exécution n'ont pas été entièrement étudiés ; le comportement peut varier en fonction de l'état de déploiement, de la configuration et de la version de Foundry.
TL; DR
GCP : Simplicité gérée, visibilité limitée
Évitez le piège du compte de service par défaut. Acceptez que vous ne puissiez pas voir à l'intérieur de l'infrastructure de Google.
Liste de contrôle pour la gestion des identités
- Vérifiez que les agents n'utilisent pas l'agent de service Reasoning Engine par défaut
- Vérifier le modèle : service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (par défaut)
- Privilégiez les comptes de service personnalisés pour les charges de travail de production.
- Acceptez une visibilité limitée des infrastructures et concevez en conséquence.
- Documentez le modèle de compte de service pour la conformité
GCP : Infrastructure gérée, identité configurable
La philosophie GCP
GCP privilégie la simplicité : Google gère l'infrastructure, vous configurez l'identité.
L'environnement d'exécution est géré et opaque : il est impossible d'inspecter le runtime sous-jacent, même si la gestion des identités et des accès (IAM) est configurée via votre projet. Cela allège la charge opérationnelle, mais limite la visibilité.
Dans GCP, l'identité repose sur les comptes de service. Vous pouvez choisir d'utiliser un compte de service personnalisé ou de vous fier à l'agent de service par défaut de Google ; ce choix détermine votre niveau d'isolation.
Comment cela s'applique-t-il au moteur d'agents d'IA Vertex (moteur de raisonnement) ?
Lors du déploiement d'un agent, l'identité fonctionne sur deux niveaux :
Couche 1 : Agent de service géré par Google
Google crée automatiquement un agent de service Reasoning Engine pour votre projet. Cet agent est indispensable au fonctionnement des agents déployés. Il est limité au projet et géré par Google ; vous ne pouvez pas l'éviter.
Couche 2 : Votre choix de compte de service
Pour l'accès réel de votre agent aux ressources, vous choisissez :
Option
Ce que c'est
Niveau d'isolement
compte de service client
Vous créez une SA spécifique pour l'agent
Meilleur (recommandé pour la production)
agent de service par défaut
Utilisez le projet S géré par Google
Mauvais (partagé entre tous les agents du projet)
Critical
Si vous ne configurez pas explicitement un compte de service personnalisé, votre agent utilise l'agent de service par défaut, partagé par tous les agents de votre projet. Un seul agent compromis expose tous les agents.
Qu'est-ce que cela signifie pour vous?
- Le choix de l'identité se fait lors du déploiement, il est donc conseillé de configurer les SA personnalisés au préalable.
- Agent de service par défaut = tous les agents d'un projet partagent une seule identité = mauvaise isolation
- Comptes de service client = chaque agent a sa propre identité = bonne isolation
- Visibilité limitée sur l'infrastructure gérée par Google (vous voyez les journaux, pas l'exécution).
Question clé à laquelle il faut répondre :
Cet agent utilise-t-il un compte de service personnalisé ou l'agent de service par défaut ?
Risque lié à l'identité :
Par défaut, le serveur d'administration (SA) dispose d'un accès étendu à BigQuery et au stockage. Si plusieurs agents le partagent, la compromission de l'un d'eux compromet tous les autres.
Par défaut, le serveur d'administration (SA) dispose d'un accès étendu à BigQuery et au stockage. Si plusieurs agents le partagent, la compromission de l'un d'eux compromet tous les autres.
Impact en cas de compromission :
Que ce soit par vol d'identifiants, compromission de compte opérateur ou manipulation de l'interface :
L'étendue de l'impact dépend du mode d'authentification utilisé et des outils/de l'étendue des accès configurés pour l'agent. Dans le pire des cas, le créateur dispose de droits d'administrateur ; par conséquent, chaque utilisateur hérite de ces droits pour ce connecteur. L'investigation nécessite la corrélation de trois sources d'audit distinctes.
Liste de contrôle pour la gestion des identités
- Vérifiez que les agents n'utilisent pas l'agent de service Reasoning Engine par défaut
- Vérifier le modèle : service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (par défaut)
- Privilégiez les comptes de service personnalisés pour les charges de travail de production.
- Acceptez une visibilité limitée des infrastructures et concevez en conséquence.
- Documentez le modèle de compte de service pour la conformité
Comment identifier l'agent de service par défaut
Recherchez ce modèle dans la configuration de votre compte de service :
service-{NUMÉRO_DE_PROJET}@gcp-sa-aiplatform-re.iam.gserviceaccount.com
Le -ré Le suffixe indique l'agent de service Reasoning Engine. Ce service est géré par Google et limité au projet ; il est donc partagé par tous les agents de votre projet, sauf si vous configurez des comptes de service personnalisés.
Les protocoles et l'orchestration multiplient les risques liés à l'identité.
Au-delà des modèles d'identité spécifiques à chaque plateforme présentés ci-dessus, plusieurs mécanismes transversaux ajoutent à la complexité :
- MCP (Protocole de contexte de modèle) — Normalise la façon dont les agents se connectent aux outils
- Communication entre agents (A2A) — Des agents invoquant d'autres agents
- Orchestration des flux de travail — Chaînes d'actions d'agents coordonnées par des systèmes externes
Point critique : Ces mécanismes abstraient l'accès aux outils, mais le font pas définir la sémantique d'identité, d'autorisation ou de délégation. Le protocole gère Comment se connecter, pas qui est autorisé.
Lorsque des agents appellent d'autres agents, ou lorsque des flux de travail enchaînent plusieurs actions d'agents, l'attribution d'identité devient transitifUn utilisateur déclenche l'agent A, qui appelle l'agent B, lequel accède à une base de données. L'historique des opérations est fragmenté. Qui est l'utilisateur ayant accédé à la base de données : l'agent A, l'agent B ou l'utilisateur initial ?
Cela accentue les difficultés de gouvernance propres à chaque plateforme. Les protocoles ne sont que de la plomberie ; ils ne résolvent pas le problème d’identité.
Où cela va-t-il nous mener ?
Les agents d'aujourd'hui utilisent des outils. Les agents de demain créeront d'autres agents.
Lorsqu'un agent peut engendrer des sous-agents, chacun doté de sa propre identité, la prolifération des identités devient récursive. Une simple requête utilisateur peut déclencher un agent qui crée trois sous-agents, chacun accédant à des systèmes différents sous des identités distinctes, certains pouvant à leur tour créer leurs propres sous-agents.
Il ne s'agit pas de science-fiction. L'orchestration multi-agents est déjà en production dans des organisations de premier plan. Les défis liés à la gestion des identités que nous avons décrits dans ce guide vont s'amplifier.
Pour l'instant, concentrons-nous sur les modèles d'identité à agent unique présentés ci-dessus. La gouvernance multi-agents représente le prochain défi, mais il est indispensable de résoudre d'abord le problème de l'identité à agent unique.
TL; DR
Un aperçu du plan de jeu
Voici un aperçu des meilleures pratiques que nous détaillerons plus loin.
Découverte et inventaire
- Agents de catalogue par plateforme
- Comptes/rôles de service de cartographie par agent
- Propriété du document
- Classer par niveau de risque
Gestion des identifiants et des autorisations
- Utilisez des jetons à durée de vie limitée
- Activer la rotation automatique
- Prioriser le moindre privilège
- Stocker en toute sécurité
Surveillance et réponse
- Utiliser la journalisation centralisée
- Activer les alertes spécifiques à l'agent
Section 4
Guide des meilleures pratiques en matière d'identité
Les listes de contrôle suivantes condensent les recommandations spécifiques à chaque plateforme ci-dessus en actions concrètes. Utilisez-les comme point de départ pour votre programme d'identification des agents.
Découverte et inventaire
Avant de pouvoir recruter des agents, vous devez savoir ce que vous avez.
Agents de catalogue par plateforme
Inclure les environnements de développement, de test et de préproduction, et pas seulement la production.
- Lister tous les agents AWS Bedrock (consulter la console Bedrock, CloudFormation)
- Lister tous les agents Azure Copilot Studio (Centre d'administration Power Platform)
- Liste de tous les agents Vertex AI de GCP (console Vertex AI)
Comptes/rôles de service de cartographie par agent
Agent
Plateforme complète
Identité principale
Identités secondaires
Exemple
AWS
ARN du rôle d'exécution de l'agent
ARN des rôles liés aux outils (Lambda, API Gateway, etc.)
Exemple
Azure
Directeur de service
Identifiants du créateur, délégation de l'utilisateur
Exemple
GCP
Courriel du compte de service
N/D
- Pour AWS : rôle d’exécution de documents + tous les rôles liés aux outils (Lambda, API Gateway, etc.)
- Pour Azure : principal de service de document + tous les modes d’identité de connecteur
- Pour GCP : Modèle de compte de service de documentation (personnalisé/automatique/par défaut)
Propriété du document
- Documentez le créateur, le propriétaire de l'identité et les personnes autorisées à modifier les permissions de chaque agent.
- Vérifiez que la propriété concerne bien des comptes fonctionnels et non des comptes personnels.
Classer par niveau de risque
Niveau de risque
Critères
Fréquence des examens
Haute
Accès aux informations personnelles, aux données financières et aux systèmes d'administration
Hebdomadaire
Moyenne
Accède aux données commerciales et aux systèmes internes.
Mensuel
Low
Données publiques en lecture seule, environnement de test
Trimestriel
- Attribuer un niveau de risque à chaque agent et planifier les évaluations en conséquence.
Gestion des identifiants et des autorisations
Jetons à durée de vie limitée
- Utilisez des jetons d'une durée de vie inférieure à une heure pour les opérations sensibles.
- Privilégiez OAuth/OIDC aux clés API statiques.
- Évitez les clés de compte de service à longue durée de vie.
Rotation automatique
- Activez la rotation automatique des identifiants lorsque cela est possible.
- Pour AWS : utilisez les rôles IAM (rotation automatique intégrée).
- Pour Azure : Configurer la rotation des certificats de principal de service
- Pour GCP : utilisez Workload Identity Federation lorsque cela est possible.
Autorisations de moindre privilège
- Commencez avec aucune autorisation et ajoutez uniquement ce qui est nécessaire.
- Documentez POURQUOI chaque autorisation existe
- Utilisez des limites d'autorisation (AWS) ou un accès conditionnel (Azure) pour restreindre les autorisations.
- Analyse des autorisations avec IAM Access Analyzer (AWS) et Entra (Azure)
Stockage sécurisé
- Ne jamais saisir d'identifiants dans les invites ni les coder en dur dans la configuration de l'agent
- Utilisez des gestionnaires de secrets (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
- Accès aux identifiants d'audit
Surveillance et réponse
Journalisation centralisée
Important : Les journaux enregistrent l’exécution, et non l’intention. Vous verrez ce que l’agent a fait, mais pas pourquoi il a agi ainsi. Cela limite la profondeur des investigations concernant les incidents liés à l’IA.
Plateforme complète
Source principale du journal
Éléments à capturer (si cette option est activée)
AWS
CloudWatch, CloudTrail
Invocations d'agents, attributions de rôles IAM, appels d'API (lorsqu'ils sont configurés)
Azure
Azure Monitor, Entra ID journaux
Les 3 contextes d'identité, activité du connecteur (en fonction des paramètres de télémétrie)
GCP
Journalisation dans le cloud
Utilisation du compte de service, exécution de l'agent (visibilité limitée à ce que Google met en évidence)
- Exporter les journaux vers le SIEM
- Définir la durée de conservation conformément aux exigences de conformité
- Créer des flux/groupes de journaux spécifiques à l'agent
- Vérifiez que la journalisation est bien activée ; ne présumez pas que les configurations par défaut capturent l’activité de l’agent.
alertes spécifiques à l'agent
Créer des alertes pour :
- tentatives d'autorisation refusée
- Nouvel accès aux ressources (c.-à-d., agent accédant à de nouveaux systèmes)
- Volume d'activité inhabituel
- Exécution en dehors des heures ouvrables (si les agents ont des horaires prévus)
- tentatives d'élévation de privilèges
Guide rapide de réponse aux incidents
Remarque : Ces journaux affichent les actions de l’agent si la journalisation était activée. CloudTrail et Azure Monitor n’affichent pas automatiquement les invocations spécifiques à l’agent ; vous devez corréler l’activité IAM/Entra avec l’identité de l’agent.
Plateforme complète
Première réponse
Journaux à vérifier (si configurés)
Escalade
AWS
Révoquer le rôle d'exécution de l'agent
CloudWatch, CloudTrail (correspondance avec l'ARN du rôle de l'agent)
Prise en charge d'AWS
Azure
Désactiver l'agent dans Power Platform
Les 3 pistes d'audit — agent, créateur, utilisateurs (chacune pouvant nécessiter des requêtes distinctes)
Support technique Microsoft
GCP
Révoquer les autorisations SA
Journalisation dans le cloud (limitée aux données affichées par Google ; aucune inspection en temps réel)
Soutien Google
- Documenter les procédures de réponse aux incidents par plateforme
- Sachez qu'Azure exige la vérification de 3 emplacements d'audit
- Accepter les limites de visibilité de l'infrastructure GCP dans la planification IR
- Vérifiez que votre journalisation capture bien l'activité des agents avant d'en avoir besoin pour la réponse aux incidents.
Section 5
Référence rapide
matrice de décision de la plateforme
Facteur
Socle AWS
Azure Copilot Studio
GCP Vertex AI
Modèle d'identité
Célibataire (rôle IAM)
Multiple (2 modes + artefacts)
Compte de service unique
Complexité
Moyenne
Haute
Low
Visibilité
Full
fragmenté
Édition
Contrôle
Full
Partiel
Édition
Fardeau opérationnel
Haute
Moyenne
Low
Idéal pour
Industries réglementées, besoin de contrôle total
Intégrations d'entreprise, écosystème Microsoft
Déploiement rapide, préférences gérées
À quoi s'attendre de chaque plateforme
Les entreprises choisissent généralement leurs plateformes d'agents en fonction de leurs fonctionnalités, de leur adéquation à l'écosystème et de leur facilité d'utilisation, puis gèrent la sécurité des identités. Voici à quoi ressemble la gestion des identités selon la plateforme choisie :
Si vous utilisez AWS Bedrock :
- Attendez-vous à une visibilité complète de l'infrastructure
- Planifier la gestion des rôles IAM à grande échelle
- Tirer parti des modèles de sécurité AWS existants
- Prévoir du temps pour les frais généraux opérationnels
Si vous utilisez Azure Copilot Studio :
- Vous devrez gérer trois contextes d'identité par agent.
- Plan pour les pistes d'audit fragmentées
- Vérifiez soigneusement les autorisations du créateur de l'audit.
- Stratégie de conception de la propriété des connecteurs définie en amont
Si vous utilisez GCP Vertex AI :
- Prévoir une visibilité limitée des infrastructures
- Planifiez en tenant compte des composants gérés par Google
- Évitez les comptes de service par défaut dès le premier jour.
- Acceptez les compromis en matière de visibilité dans votre planification des relations investisseurs
Aide-mémoire pour la gestion des incidents
À noter: Les « comportements anormaux des agents » constituent une catégorie d'incident unique. Contrairement aux comptes de service qui tombent en panne de manière prévisible, les agents peuvent avoir un comportement inattendu suite à une manipulation, une dérive du modèle ou un comportement émergent, et pas seulement en cas de compromission. Votre processus de gestion des incidents doit tenir compte de cette ambiguïté.
AWS : L’agent présente un comportement anormal.
- Immédiatement: Révoquer le rôle d'exécution de l'agent (aws iam delete-role-policy)
- Enquêter: Journaux CloudWatch pour l'agent, CloudTrail pour l'activité IAM
- Contenir: Désactivez toutes les intégrations d'outils (fonctions Lambda, points de terminaison API ou autres services appelés par l'agent).
- Remédier : Vérifier les autorisations, redéployer avec le moindre privilège
Azure : L’agent présente un comportement anormal.
- Immédiatement: Désactiver l'agent dans Copilot Studio
- Enquêter: Vérifiez les TROIS pistes d'audit :
- journaux du principal de service de l'agent
- Journaux d'audit des comptes créateurs
- Journaux de délégation des utilisateurs (pour chaque utilisateur ayant effectué l'appel)
- Contenir: Désactiver les connecteurs, révoquer les identifiants du fabricant si nécessaire
- Remédier : Examinez les modes d'identité des connecteurs et envisagez l'utilisation de comptes de service dédiés.
GCP : L’agent se comporte mal
- Immédiatement: Révoquer les autorisations du compte de service
- Enquêter: Journalisation dans le cloud (remarque : visibilité limitée de l’infrastructure)
- Contenir: Si l'AS par défaut affecte TOUS les agents qui l'utilisent, désactivez tout
- Remédier : Passez à une SA personnalisée, une par agent
Modes de défaillance spécifiques à l'identité
Outre les risques spécifiques à la plateforme mentionnés ci-dessus, plusieurs modes de défaillance sont propres à l'identité de l'agent :
Les chaînes de délégation survivent aux utilisateurs : Un utilisateur autorise un mandataire à agir en son nom. L'utilisateur quitte l'organisation. La délégation peut être maintenue et le mandataire continue d'agir sous l'autorité de l'utilisateur parti.
Agents de flux de travail contournant les contrôles d'interface utilisateur : Les agents déclenchés par l'automatisation des flux de travail peuvent ignorer les procédures d'approbation habituelles. Si l'interface utilisateur impose des contrôles d'autorisation non pris en charge par l'API, les agents déclenchés par les flux de travail fonctionnent selon des règles différentes.
Héritage des privilèges entre agents : L'agent A a accès au système X. L'agent A peut invoquer l'agent B. L'agent B a-t-il désormais accès au système X ? La réponse dépend de la propagation d'identité, qui varie selon la plateforme et la configuration.
Dérive de version/alias (AWS Bedrock) : Le trafic acheminé vers une version antérieure de l'agent via un alias peut avoir des autorisations différentes de celles de la version actuelle. Le niveau de sécurité peut se dégrader silencieusement.
Il ne s'agit pas de risques génériques liés à l'IA : ce sont des lacunes de gouvernance spécifiques à l'identité qui nécessitent des contrôles spécifiques à l'identité.
Section 6
Glossaire
Groupe d'action
(AWS) Configuration définissant les outils/actions qu'un agent Bedrock peut utiliser
Authentification de l'auteur de l'agent
(Azure) Terme utilisé par Microsoft pour désigner l'utilisation des informations d'identification du créateur du connecteur
Rôle d'exécution de l'agent
(AWS) Le rôle IAM qu'un agent Bedrock assume lorsqu'il s'exécute
Rayon de l'explosion
L'étendue des ressources affectées en cas d'usurpation d'identité
Principal de service de l'agent
(Azure) Le propre de l'agent Entra ID identité de l'application — apparaît comme un troisième artefact d'identité
connecteur
(Azure) Intégration préconfigurée permettant aux agents d'interagir avec des services externes
Compte de service client
(GCP) Compte de service créé par l'utilisateur et spécifique à l'agent — recommandé pour la production
Mode d'identité
Le contexte dans lequel une action est authentifiée (utilisateur, créateur ou agent)
NHI
Identité non humaine — comptes de service, clés API et identités de machines similaires
Injection rapide
Attaque qui manipule le comportement de l'agent grâce à des entrées spécialement conçues
Agent de service du moteur de raisonnement
(GCP) Compte de service géré par Google pour les agents Vertex AI, à portée de projet
Authentification d'utilisateur
(Azure) Terme utilisé par Microsoft pour désigner l'utilisation des autorisations déléguées de l'utilisateur appelant.
Résumé
AWS : Votre compte, votre identité.
Le contrôle total implique une responsabilité totale : définissez les rôles IAM, appliquez le principe du moindre privilège, assumez vos erreurs.
Azure : Plusieurs identités, un seul agent.
Le modèle d'authentification flexible facilite les intégrations d'entreprise, mais fragmente la responsabilité. Il est essentiel de connaître le mode d'authentification utilisé par chaque connecteur.
GCP : Simplicité gérée, visibilité limitée
Évitez le piège du compte de service par défaut. Acceptez que vous ne puissiez pas voir à l'intérieur de l'infrastructure de Google.
Le point commun : les agents d’IA ne sont pas des comptes de service. Ils sont adaptatifs, imprévisibles et précieux précisément parce qu’ils ne suivent pas de scripts. Les contrôles traditionnels de l’assurance maladie nationale supposaient un comportement prévisible. Cette hypothèse est désormais caduque.
Ce que ce guide ne résout pas
Ce guide explique le fonctionnement de l'identité des agents. Il ne résout cependant pas le problème plus complexe : l'application des contrôles d'identité en temps réel, lors de l'exécution, c'est-à-dire avant que les actions ne soient effectuées, et non après.
Les fournisseurs de services cloud privilégient la conformité de la plateforme à la responsabilité de l'entreprise. Si vous attendez qu'ils résolvent le problème d'identité des agents de manière globale, vous hériterez de leurs lacunes.
L'étape suivante consiste à appliquer le contrôle d'accès en temps réel : vérification d'identité instantanée, sur toutes les plateformes, avec le contexte nécessaire pour prendre des décisions d'autorisation/de refus intelligentes. La plupart des organisations ne sont pas conçues pour cela aujourd'hui.
Voilà le travail qui nous attend.
Ce guide reflète les capacités de la plateforme en date de janvier 2026. Les fournisseurs de cloud mettent régulièrement à jour leurs services ; consultez la documentation actuelle pour plus de détails sur la mise en œuvre.