--- title: "54 % des entreprises ont déjà eu un incident avec un agent IA. La cause racine est l’identité." slug: "ai-agent-incident-identity-credential-sharing" metaDescription: "Une nouvelle étude montre que la plupart des entreprises laissent les agents IA partager des identifiants. Voici ce que cela signifie pour votre rayon d’impact, et comment la gouvernance IA comble cette faille." publishedAt: "2026-07-23T00:00:00.000Z" ---
Plus de la moitié des entreprises ont déjà eu un incident de sécurité confirmé impliquant un agent IA ou un quasi-incident. C’est le titre d’une nouvelle étude VentureBeat Pulse publiée cette semaine, couvrant 107 entreprises utilisant activement des agents IA autonomes dans leurs activités.
Ce chiffre ne surprendra personne qui suit le sujet. Ce qui doit vous inquiéter, c’est la raison qui le sous-tend.
Seules 32 % des entreprises attribuent à chaque agent IA une identité propre, gérée et limitée. Les autres laissent les agents partager des identifiants - utilisant des clés API partagées, des jetons de compte de service, ou dans certains cas les mêmes identifiants que les utilisateurs humains. Et seulement 30 % isolent leurs agents à risque élevé dans des environnements sandbox.
Ce n’est pas un problème de modèle. Ce n’est pas un problème d’injection de prompt. C’est un problème de gouvernance que les équipes de sécurité tentent de résoudre avec de mauvais outils.
Pourquoi le partage des identifiants est une défaillance structurelle
Donner la même clé API à deux agents ne crée pas seulement une facilité. Cela concentre la portée d’impact de toute compromission future en un seul domaine de défaillance.
Imaginez ce que cela signifie en pratique. Vous déployez un agent IA pour gérer le tri des tickets support client. Il a besoin d’un accès en lecture à votre CRM. Vous lui donnez le même compte de service que votre pipeline de données utilise parce que créer un nouveau compte prend une demi-journée et que le sprint se termine vendredi. Trois mois plus tard, un second agent - qui écrit dans votre entrepôt de données - est lancé avec la même clé parce que la pratique est déjà établie.
Vous avez maintenant deux agents avec des profils de risque très différents partageant une même identité. Si l’un est compromis - par un prompt malveillant, un outil mal configuré, un appel API sur-permissionné - l’attaquant obtient la portée d’impact des deux agents, pas d’un seul.
C’est le même principe qui rendait les mouvements latéraux si efficaces dans les attaques traditionnelles en entreprise. Des identifiants partagés signifient une exposition partagée. La différence avec les agents IA est qu’ils agissent plus vite, prennent des décisions plus autonomes, et ont souvent des accès qui feraient hausser les sourcils si un humain les demandait.
Le problème de la pile de sécurité est pire qu’il n’y paraît
Voici la partie des données VentureBeat qui devrait mettre mal à l’aise les responsables sécurité en entreprise : les scores de satisfaction.
Les organisations interrogées ont évalué leurs contrôles de sécurité IA actuels à 4,2 sur 5 en moyenne. Pourtant, seulement un tiers estime que leurs défenses sont réellement en avance sur les attaquants utilisant l’IA. Et une large majorité prévoit de changer ou d’améliorer leurs outils dans l’année.
Satisfaits des contrôles qu’ils prévoient pourtant de remplacer. C’est une combinaison dangereuse.
La raison de ce décalage vient de la provenance des contrôles. La pile de sécurité de la plupart des entreprises est majoritairement native aux fournisseurs - garde-fous OpenAI, contrôles Google Cloud, politiques Azure, fonctionnalités gérées d’Anthropic. Ce ne sont pas de mauvais outils. Mais ils ont été conçus pour gouverner les modèles, pas pour gouverner le comportement organisationnel des agents dans votre environnement.
Les contrôles natifs répondent à des questions comme : « Ce prompt a-t-il violé la politique de contenu ? » Ils sont beaucoup moins efficaces pour répondre à : « Cet agent doit-il avoir accès à ce système ? Son comportement est-il conforme à ce que nous avons autorisé ? Quand cet agent a agi mardi dernier, était-ce dans le cadre approuvé par son responsable métier ? »
Ces secondes questions relèvent de la gouvernance IA. Et la plupart des entreprises ne sont pas équipées pour y répondre.
Ce que fait réellement Aona ici
Le fossé de sécurité des agents ne sera pas comblé par des fournisseurs de modèles ajoutant plus de garde-fous. Il sera comblé par les entreprises qui construisent l’infrastructure de gouvernance entre les agents déployés et les systèmes qu’ils touchent.
C’est précisément pour cela qu’Aona a été conçu.
Aona découvre chaque agent IA opérant dans votre environnement - pas seulement ceux validés par votre équipe IT, mais aussi ceux lancés indépendamment par les unités métier, ceux que vos développeurs testent en production, ceux qui existent dans la zone grise entre outils approuvés et logiciels fantômes. L’IA fantôme ne reste pas dans l’ombre quand les agents commencent à agir.
Une fois cet inventaire établi, Aona cartographie ce à quoi chaque agent peut accéder, ce qu’il fait réellement, et si son comportement est conforme à la politique définie par votre équipe de gouvernance. Quand un agent agit en dehors de ces limites - effectuant des appels inattendus, accédant à des systèmes non autorisés par son responsable métier - Aona génère une alerte, pas un exercice de forensique trois mois après les faits.
Le problème du partage d’identifiants dans les données VentureBeat est réel. Mais le problème plus profond est que la plupart des entreprises n’ont aucun moyen systématique de savoir combien d’agents tournent, encore moins sous quelle identité chacun opère. On ne peut pas limiter des identités non inventoriées.
Que faire avant que votre incident ne devienne le 55e
Si vous faites partie de la majorité des entreprises n’ayant pas encore eu d’incident confirmé lié à un agent, ces constats structurels doivent susciter quelques questions concrètes pour vos équipes sécurité et gouvernance.
Premièrement : combien d’agents IA tournent actuellement dans votre environnement ? Pas seulement ceux dans votre système de tickets - tous. La plupart des entreprises sous-estiment largement ce nombre. Si votre réponse est un chiffre rond, elle est probablement fausse.
Deuxièmement : sur quels identifiants ces agents fonctionnent-ils ? Si vous ne pouvez pas répondre par agent, il y a presque certainement du partage d’identifiants quelque part.
Troisièmement : qui est le responsable métier nommé pour chaque agent ? Pas le développeur qui l’a créé, mais la personne responsable des actions qu’il prend. Si l’agent cause une panne ou une fuite de données, qui est contacté ? Sans réponse claire, votre posture de gouvernance est plus faible que votre posture de sécurité ne le laisse penser.
Quatrièmement : avez-vous une visibilité sur ce que ces agents font réellement, en quasi temps réel ? Les logs natifs des fournisseurs indiquent ce qui s’est passé. Ils ne disent pas si cela respectait la politique.
Les données VentureBeat montrent que les entreprises sont à l’aise dans cet écart. Les scores de satisfaction sont élevés. Les incidents sont traités comme des quasi-accidents. C’est précisément le moment avant l’incident qui ne reste pas silencieux.
Aona vous fournit l’inventaire, la couche politique et la surveillance pour combler ce fossé avant qu’il ne devienne votre faille. Pour voir cela appliqué à votre parc d’agents, contactez l’équipe sur [aona.ai](https://aona.ai).
---
Ce billet fait référence à l’étude VentureBeat Pulse publiée le 16 juillet 2026, basée sur une enquête auprès de 107 entreprises déployant activement des agents IA autonomes.
