Ton agent IA a un compte. Peux-tu prouver ce qu'il a touché ?
Pose une question simple à ton équipe sécurité ce matin : quels agents IA peuvent atteindre votre système financier ? Presque tous répondront en quelques secondes. Demande-leur ensuite de prouver ce que ces agents ont réellement touché mardi dernier à 14h07. Ce silence, c'est le sujet.
Le Pulse Report Q4 2026 de JumpCloud, mené auprès de 250 décideurs IT aux États-Unis et au Royaume-Uni, chiffre ce silence : 72% constatent un écart modéré à important entre ce à quoi leur IA peut accéder et ce qu'ils peuvent prouver qu'elle a consulté. Seuls 4% ne voient aucun écart significatif. Et 99% des dirigeants interrogés se disent confiants dans leur capacité à auditer l'activité de l'IA, alors que 37% seulement y sont réellement préparés.
La confiance n'est pas une preuve. Nous le vérifions chaque jour chez nos clients.
Les trois écarts que personne ne budgète
Le rapport structure le problème en trois défaillances qui se recouvrent, et ce cadrage mérite une place dans votre prochain comité de direction.
L'écart d'identité. 55% des organisations utilisent ou testent déjà des agents capables de modifier des systèmes, des permissions, des enregistrements ou des workflows. Parmi elles, 41% seulement ont pleinement intégré ces agents aux mêmes politiques de gestion des identités et des accès que celles qui régissent les salariés. Les 59% restants les gèrent partiellement, ou via des politiques et des outils séparés. Et 63% des environnements d'agents mélangent encore des comptes de service partagés et des clés API à longue durée de vie, exactement ce qui rend toute traçabilité impossible six semaines plus tard.
L'écart de preuve. 72% ne peuvent pas reconstituer complètement ce qu'une IA a touché. Seuls 34% peuvent pleinement prouver comment l'IA a interagi avec des données sensibles. Sur les douze derniers mois, 92% déclarent au moins un incident ou une exposition liée à l'IA, et 36% ont enquêté sur une alerte sans jamais savoir à quoi l'IA avait accédé.
L'écart de préparation. Seules 20% des organisations atteignent le plus haut niveau de maturité en auditabilité. 64% sont au niveau intermédiaire : les contrôles existent, mais la couverture est inégale et les trous n'apparaissent qu'en audit ou après un incident. 30% signalent de l'IA fantôme qu'ils ne peuvent pas surveiller entièrement, et 14% seulement revoient les permissions IA en continu ou de façon automatisée.
Lus ensemble, la conclusion est inconfortable. Les contrôles sont généralement là. Ce qui manque, c'est la couverture : des contrôles qui s'arrêtent à l'outil autorisé et n'atteignent jamais le système connecté, qui couvrent les salariés et sautent les agents.
Pourquoi c'est plus dur que de l'IAM classique
Un agent est, par conception, un utilisateur mal élevé. Il agit au nom de quelqu'un, détient des identifiants qui survivent à la tâche, traverse le ticketing, le CRM, la finance, la gestion des postes et l'identité, et change de comportement quand son prompt ou son modèle change. Les preuves de ce qu'il a fait sont éclatées en trois endroits : la console de l'outil IA, le système qu'il a touché et l'annuaire qui porte l'identité. Reconstituer une seule action suppose de joindre les trois, et la plupart des organisations ne l'ont jamais fait une seule fois.
Le rapport montre aussi que les organisations exploitent en moyenne 2,7 outils IA, chacun atteignant environ trois catégories de systèmes d'entreprise, et qu'une sur trois affirme que l'IA peut atteindre la couche de gestion des identités elle-même. Ce chiffre devrait arrêter la discussion. Un agent qui atteint l'IAM n'est pas un outil de productivité. C'est un principal administratif avec une fenêtre de chat.
La question de l'autonomie a un chiffre
46% des organisations autorisent automatiquement les actions à haut risque des agents. Seules 18% exigent une validation humaine avant que l'agent agisse. Si ton agent peut payer une facture, faire tourner une clé ou réinitialiser un mot de passe sans humain dans la boucle, tu as automatisé précisément la partie du processus où vivait le jugement.
Nous ne plaidons pas pour la fatigue de validation à chaque clic. Nous plaidons pour que haut risque ait une définition écrite, et que cette définition soit encodée là où l'action se produit, pas dans un PDF de politique que personne ne lit pendant un incident.
Ce que font vraiment les équipes matures
Le rapport se termine par un cycle de vie IAM agentique en quatre étapes : découvrir chaque agent, y compris ceux dont l'IT n'a jamais entendu parler ; enregistrer chacun avec un objectif, un périmètre et un propriétaire humain nommé ; dimensionner les accès pour qu'ils expirent avec la mission ; et gouverner en continu, car les permissions des agents dérivent plus vite que les revues trimestrielles.
La plupart s'arrêtent à la première étape, parfois à la deuxième. Voici la version que nous déployons chez nos clients, dans l'ordre qui produit des preuves le plus vite.
- Inventorie les agents comme tes SaaS. Récupère chaque autorisation OAuth, clé API et service principal, puis associe chaque agent à un propriétaire humain. Pas de propriétaire, pas d'accès.
- Supprime les comptes partagés. Un agent sur un compte de service partagé ne peut être attribué à rien. Donne à chaque agent sa propre identité et des identifiants à courte durée de vie : l'écart de preuve commence à se refermer la même semaine.
- Définis le haut risque dans le code. Paiements, changements de permissions, exports de données, écritures en production. Tout ce qui figure sur cette liste passe par une barrière déterministe, pas par l'avis d'un modèle sur le fait que ça semble acceptable.
- Envoie l'activité des agents dans le SIEM que tu as déjà. La console de l'éditeur d'IA n'est pas ta piste d'audit. Garde les preuves là où tes enquêteurs regardent déjà.
- Revois en continu, pas chaque trimestre. Automatise la revue des permissions et traite un changement de permission d'agent comme un changement de pare-feu : journalisé, revu, réversible.
Rien de tout cela n'exige d'acheter une nouvelle plateforme dès le premier jour. Cela exige de traiter les agents comme une seconde population d'identités, avec la même discipline que celle appliquée aux humains, et de le faire avant l'incident, pas pendant l'enquête.
Le message pour ton équipe
Le chiffre inconfortable de ce rapport n'est pas 72%. C'est 99% contre 37% : l'écart entre la confiance affichée et la préparation réelle. Une confiance non adossée à des logs, des périmètres et des propriétaires nommés est un risque, parce que c'est ce qui maintient le problème hors de la feuille de route jusqu'à ce qu'un auditeur ou un attaquant le trouve.
Commence cette semaine par une question concrète : prends ton agent le plus privilégié, nomme son propriétaire à voix haute et essaie de reconstituer ses dix dernières actions à partir de tes propres logs. Si tu y arrives, tu es en avance sur presque tout le marché. Sinon, tu sais exactement où va le prochain trimestre de travail sécurité, et tu as un chiffre pour le justifier.
Bien mieux qu'une découverte en pleine violation.