Sécuriser les agents IA : gérer identités et secrets en 6 étapes

Accès invisibles en entreprise, votre agent IA lit des tickets, appelle une API de facturation et dépose des fichiers dans le cloud. Son identité technique possède parfois des droits hérités, un jeton longue durée ou une clé copiée dans une variable d’environnement. Si ce secret fuit, la révocation devient incertaine et les journaux distinguent mal l’action de l’agent, d’un script ou d’un attaquant. Le rapport 2024 de Verizon indique que 68 % des violations impliquent un élément humain, notamment l’usage d’identifiants compromis (Verizon, Data Breach Investigations Report 2024).

Regarder les coulisses des accès, c’est suivre le cycle complet d’une identité non humaine : création, attribution, utilisation, rotation et révocation. L’analyse porte sur les coffres à secrets, les comptes de service, les permissions minimales, les journaux exploitables et les contrôles capables d’arrêter un agent sans couper toute l’activité. Elle examine aussi les angles morts des plateformes SaaS et des chaînes d’outils. Cette lecture arrive au moment où les agents exécutent des actions avec davantage d’autonomie, tandis que leurs accès restent souvent conçus pour des humains, afin de mesurer le risque réel avant l’incident.

En bref : comment sécuriser les identités et les secrets des agents IA en entreprise

La réponse tient en trois règles : attribuer à chaque agent IA une identité distincte, limiter précisément ses permissions et stocker ses secrets dans un coffre dédié. Aucun agent ne doit partager le compte d’un salarié, conserver une clé dans son code ou accéder durablement à des données inutiles. Les accès doivent être temporaires, traçables, révocables et régulièrement vérifiés, avec une surveillance adaptée aux actions réellement exécutées.

• Une identité par agent : attribuez à chaque agent IA un compte technique distinct, avec propriétaire, usages autorisés et procédure de révocation clairement définis.
• Des secrets protégés : stockez les clés et mots de passe dans un gestionnaire de secrets, jamais dans les instructions, journaux ou dépôts de code.
• Des droits minimaux : limitez chaque agent aux outils, données et opérations nécessaires, puis supprimez automatiquement les accès devenus inutiles.
• Une surveillance active : journalisez les connexions, appels d’outils et changements de permissions pour détecter rapidement une utilisation anormale.

Comment sécuriser les identités non humaines et les secrets de vos agents IA en 2026 ?

Le premier risque reste l’identité technique utilisée par l’agent, pas seulement le modèle. Un agent qui consulte un CRM, crée un ticket ou lance une fonction cloud doit disposer d’un compte distinct, traçable et limité à son action. Une clé API copiée dans un prompt, un dépôt Git ou une variable mal protégée devient alors un accès réutilisable par toute personne ou application qui la récupère. Le NIST AI Risk Management Framework recommande d’identifier les composants, les accès et les responsabilités avant le déploiement.

Les secrets doivent disparaître du code et des instructions persistantes. Utilisez un gestionnaire comme HashiCorp Vault ou le coffre de votre fournisseur cloud, puis délivrez des identifiants temporaires à l’agent. AWS documente cette approche avec IAM Roles Anywhere, qui évite de stocker des clés longues durées sur des machines. Chaque secret doit posséder un propriétaire, une date d’expiration et une procédure de révocation testée. Le renouvellement automatique réduit l’impact d’une fuite, sans supprimer la nécessité de journaux exploitables.

Les permissions doivent rester étroites, même lorsque l’agent paraît fiable. Un agent chargé de préparer des factures n’a pas besoin de supprimer des clients, d’exporter toute la base ou d’administrer le fournisseur cloud. Le modèle d’autorisation de Google Zanzibar, décrit par Google pour des contrôles fins à grande échelle, illustre l’intérêt d’une décision d’accès séparée de l’application. Pour une PME, la traduction pratique consiste à définir une action, une ressource, une justification et une durée pour chaque outil.

La surveillance doit compléter les contrôles préalables. Les journaux doivent associer chaque appel à l’identité de l’agent, au modèle utilisé, à l’utilisateur demandeur, à l’outil invoqué et au résultat obtenu. Le rapport OWASP Top 10 for LLM Applications cite notamment la divulgation d’informations sensibles et l’excès d’autonomie parmi les risques à traiter. Une alerte peut viser une séquence inhabituelle, comme une lecture massive suivie d’un envoi externe. Testez aussi la révocation en production, car une procédure non exercée reste une hypothèse.

Comment sécuriser les identités non humaines de vos agents IA en 3 étapes ?

1. Remplacer les secrets partagés par des identités traçables

Cartographiez chaque agent avant de modifier vos outils. Un agent chargé de classer des tickets, un autre qui interroge votre CRM et un troisième qui lance des déploiements possèdent des besoins différents. Créez une fiche par identité non humaine avec son propriétaire, sa fonction, ses données accessibles, ses horaires d’exécution et ses dépendances. Évitez les comptes génériques comme agent-prod ou bot-admin, impossibles à attribuer précisément après incident. Cette cartographie devient votre référence pour supprimer les accès oubliés et limiter chaque agent à son périmètre réel.

Préférez une identité fédérée aux clés API copiées dans des variables d’environnement permanentes. Un agent exécuté dans GitHub Actions peut recevoir un jeton court via OpenID Connect pour accéder temporairement à un coffre ou à un service cloud. AWS documente cette approche avec les rôles IAM et l’identité OIDC, sans stocker de clé longue durée dans le dépôt (documentation AWS). Vérifiez toutefois l’audience, le dépôt autorisé, la branche et l’environnement avant d’accepter le jeton présenté par la plateforme.

Isolez les environnements afin qu’un agent de test ne puisse pas atteindre les données de production. Utilisez des projets, comptes cloud ou espaces de travail distincts, puis associez une identité différente à chaque zone. Un agent LangChain développé sur un poste local ne doit pas réutiliser la même autorisation qu’un service déployé dans Kubernetes. Cette séparation réduit la portée d’une fuite, d’un mauvais paramétrage ou d’une réponse générée qui déclencherait un appel dangereux vers une base opérationnelle.

Documentez les exceptions plutôt que de tolérer des privilèges permanents. Si un agent de facturation doit exceptionnellement exporter des données, prévoyez une approbation, une durée d’expiration et un journal d’utilisation. Microsoft Entra Workload ID permet d’associer une charge de travail à une identité gérée et d’éviter certains secrets statiques (documentation Microsoft). Faites vérifier chaque exception par le responsable du système concerné, puis supprimez-la automatiquement à l’échéance prévue.

2. Placer les secrets dans un coffre, pas dans le code

Centralisez les secrets dans un gestionnaire conçu pour leur stockage, leur rotation et leur consultation contrôlée. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault et Google Secret Manager proposent des mécanismes adaptés à des agents exécutés par des services. Un agent qui appelle Salesforce ou un modèle externe récupère le secret au démarrage, selon son identité, sans l’embarquer dans son dépôt. La documentation de Vault décrit notamment les identités, politiques et moteurs de secrets nécessaires à cette séparation (guide officiel).

Supprimez les fuites existantes avant de déplacer les clés. Recherchez les dépôts Git, images de conteneur, journaux CI, tickets et fichiers .env, car un secret retiré du code reste présent dans l’historique. GitHub secret scanning peut détecter plusieurs formats de jetons et avertir lors d’une exposition (documentation GitHub). Après détection, révoquez immédiatement la clé concernée, créez-en une nouvelle et examinez les appels réalisés pendant sa période d’exposition.

Organisez la rotation selon la capacité réelle de chaque fournisseur. Une clé utilisée par un agent de support ne doit pas survivre sans contrôle parce qu’un script ancien dépend d’elle. Préparez une double clé temporaire, déployez la nouvelle valeur, vérifiez les appels, puis révoquez l’ancienne. Pour les fournisseurs qui ne proposent pas de rotation automatisée, créez une tâche planifiée et une procédure testée. AWS recommande l’usage de Secrets Manager pour automatiser la rotation de certaines informations d’accès (documentation AWS).

Nettoyez les journaux pour empêcher un agent de révéler une valeur sensible dans une réponse ou une trace. Masquez les paramètres d’URL, les en-têtes d’autorisation, les messages d’exception et les sorties d’outils. Un agent utilisant OpenAI ou Azure OpenAI ne doit jamais recevoir une clé dans son prompt, car elle pourrait être recopiée vers un canal externe. Configurez des filtres de redaction dans votre observabilité, puis testez-les avec des valeurs factices ressemblant aux secrets réels.

3. Contrôler chaque appel et réagir aux écarts

Journalisez les décisions avec assez de contexte pour enquêter sans enregistrer les secrets. Conservez l’identité de l’agent, l’utilisateur déclencheur, l’outil appelé, la ressource ciblée, l’horodatage, le résultat et le motif de refus. Pour un agent qui crée des commandes dans SAP, ces éléments permettent de distinguer une action autorisée d’une instruction injectée dans un document fournisseur. N’enregistrez pas automatiquement les prompts contenant des données personnelles ou commerciales, privilégiez une conservation proportionnée et documentée.

Ajoutez des garde-fous avant les actions irréversibles. Un agent peut préparer un virement, supprimer une ressource ou modifier un droit, mais l’exécution doit exiger une validation humaine lorsque le risque le justifie. Des outils comme OPA Gatekeeper appliquent des règles d’accès dans Kubernetes, tandis que l’OWASP Agentic AI Threats and Mitigations propose des mesures contre les abus d’outils et d’identités (guide OWASP). Testez chaque règle avec des scénarios d’échec réalistes.

Surveillez les écarts plutôt que les seuls échecs d’authentification. Une identité peut utiliser des identifiants valides tout en appelant soudainement une nouvelle API, un volume inhabituel de données ou une région inconnue. Définissez une base d’usage par agent, puis déclenchez une alerte lorsqu’un changement dépasse les règles prévues. En cas de suspicion, désactivez l’identité non humaine, révoquez ses jetons, préservez les journaux et vérifiez les actions effectuées avant le rétablissement.

Testez le retrait au même titre que l’attribution. Lorsqu’un agent est supprimé, son compte, ses rôles, ses clés, ses webhooks et ses accès aux files de messages doivent disparaître. Programmez un exercice trimestriel avec un agent fictif, puis mesurez le temps nécessaire pour couper tous ses accès. Le NIST recommande d’intégrer la gestion des identités, l’authentification et la surveillance dans le cycle de vie des systèmes d’IA (AI Risk Management Framework). Conservez les résultats et corrigez chaque écart observé.

Tableau comparatif

Solution ou méthode	Type d’identité	Gestion des secrets	Cas d’usage pour un agent IA	Points de vigilance
Microsoft Entra Workload ID	Identité applicative fédérée	Jetons courts via fédération OIDC, sans secret statique	Agent déployé sur Azure, GitHub Actions ou Kubernetes qui appelle Microsoft Graph et des services Azure	Configurer précisément les audiences, les sujets autorisés et les rôles applicatifs
AWS IAM Roles Anywhere	Identité de charge de travail basée sur certificat	Certificats X.509 et clés privées stockés côté hôte ou dans un coffre	Agent exécuté hors AWS qui doit accéder temporairement à S3, Bedrock ou d’autres services AWS	Protéger la clé privée, limiter la durée des certificats et surveiller les rôles assumés
Google Cloud Workload Identity Federation	Identité fédérée entre un fournisseur externe et Google Cloud	Jetons courts issus d’OIDC ou de SAML, sans clé de compte de service persistante	Agent hébergé sur Kubernetes, GitHub Actions ou un autre fournisseur cloud qui appelle Vertex AI	Restreindre le fournisseur, les attributs acceptés et les permissions IAM
HashiCorp Vault	Coffre de secrets et identité de machine	Secrets dynamiques, certificats et clés renouvelables	Agent qui doit obtenir temporairement un mot de passe de base de données, une clé API ou un certificat	Prévoir l’authentification de l’agent, la rotation et la révocation en cas d’incident
CyberArk Conjur	Gestion des secrets pour applications et charges de travail	Secrets centralisés avec politiques d’accès par identité	Agent déployé sur Kubernetes ou dans un pipeline qui utilise des accès à des bases et des services internes	Éviter les politiques trop larges et séparer les identités entre environnements
Kubernetes ServiceAccount avec OIDC	Identité de workload liée à un pod	Jetons projetés et fédération vers un fournisseur cloud ou un coffre	Agent conteneurisé qui appelle un service cloud sans embarquer de clé statique dans l’image	Désactiver les montages inutiles, limiter les permissions RBAC et contrôler les audiences des jetons

Quelles erreurs faut-il éviter ?

Un compte partagé permanent : donner à plusieurs agents la même identité de service simplifie le premier déploiement, puis détruit la traçabilité. Si un agent lit une base clients, crée un ticket et lance une commande d’administration avec le même jeton, impossible d’attribuer précisément l’action ou de couper un seul accès. Les équipes conservent alors une clé API longue durée dans un coffre, parfois copiée dans une variable d’environnement ou un fichier de configuration. Préférez une identité par agent et par environnement, avec des droits séparés, une expiration courte et une révocation testée.

Un secret dans le prompt : placer une clé, un mot de passe ou une consigne d’accès dans le message système ne protège rien. L’agent peut le révéler après une injection indirecte, par exemple via une page web, un document indexé ou un ticket contenant une instruction hostile. Le secret peut aussi apparaître dans les traces, les captures de conversation ou les outils de supervision. Le prompt doit décrire une capacité, jamais porter son secret. Déléguez l’appel à un service intermédiaire qui récupère la valeur sans l’exposer au modèle.

Un jeton trop polyvalent : certains déploiements utilisent un jeton OAuth prévu pour une application humaine, parce que le connecteur fonctionne immédiatement. Cette identité hérite parfois de la lecture des fichiers, de l’envoi de courriels et de la modification des groupes. Une fuite donne alors à l’attaquant une porte d’entrée bien plus large que prévu. Les incidents liés à CircleCI en 2023 ont rappelé le risque des jetons persistants compromis dans les chaînes automatisées (avis de sécurité CircleCI, janvier 2023). Utilisez des audiences dédiées, des portées minimales et des limites par action.

La MFA contournée par partage : imposer une authentification multifacteur à un agent sans prévoir son fonctionnement pousse parfois l’équipe à utiliser le compte d’un salarié, à conserver une session ouverte ou à désactiver la vérification. Le problème ne vient pas de la MFA, mais d’une identité humaine détournée pour une tâche automatisée. Créez une identité non humaine distincte, avec authentification machine, propriétaire nommé, durée de vie définie et journalisation. Pour les actions sensibles, ajoutez une validation humaine séparée, sans transmettre au modèle un code ou une session personnelle.

Conclusion

La priorité reste claire : un agent IA n’est pas un simple logiciel. Chaque identité non humaine doit disposer d’un compte distinct, d’autorisations limitées et d’une durée de vie maîtrisée. Les secrets ne doivent jamais être enfouis dans un prompt, un dépôt de code ou une variable partagée. Centralisez leur stockage, imposez une rotation automatique et journalisez chaque accès. Cette discipline réduit le rayon d’exposition lorsqu’un agent est compromis, tout en facilitant l’analyse des incidents. Pour approfondir, cartographiez les identités de vos agents IA.

Le contrôle doit suivre : les droits accordés à un agent doivent refléter sa tâche réelle, non ses capacités théoriques. Préférez des permissions ciblées, des comptes séparés par environnement et des validations humaines pour les actions sensibles. Une clé statique oubliée peut ouvrir un accès durable, surtout si aucune alerte ne signale son utilisation. Surveillez les appels, les changements de privilèges et les comportements inhabituels. Consultez notre guide sur la rotation des secrets pour structurer ce cycle sans alourdir l’exploitation.

Une gouvernance pragmatique ne repose pas sur un outil miracle. Elle combine inventaire régulier, séparation des rôles, authentification forte, secrets temporaires et revues d’accès compréhensibles par toute l’équipe. La direction doit fixer un niveau d’exigence, tandis que les responsables techniques vérifient les preuves : qui a donné l’accès, pour quelle action, pendant combien de temps. Cette clarté transforme la sécurité des agents en pratique quotidienne, plutôt qu’en promesse abstraite. Pour comparer les approches, évaluez les solutions de gestion des secrets selon vos contraintes réelles.