Menu

Modèle de maturité d’identité des agents IA : cinq niveaux, et un seul chiffre qui dit lequel vous occupez

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
9 min de lecture
⏱️
Temps de lecture estimé
~12 minutes

En août, la CSA listait 8 risques d’identité d’agent IA. Le document suivant répond à la question qui manquait : où en êtes-vous exactement, et comment progressez-vous ? Cinq niveaux, six prérequis, et une métrique unique qui rend les tableaux de bord de couverture assez gênants à regarder.

La suite logique des 8 risques

Fin août les 8 risques d’identité d’agent IA que la CSA veut voir sur le bureau de tout RSSI. Identités orphelines, permissions excessives, identifiants statiques, combinaisons toxiques : une bonne liste, concrète, plus utile que la moyenne des publications de ce genre. Mais une liste de risques ne dit jamais où vous en êtes. Elle dit ce que vous devriez craindre, pas ce que vous devriez faire lundi matin, ni dans quel ordre.

Le document publié par la CSA le mois suivant comble précisément ce trou. Il propose un modèle de maturité en cinq niveaux et, surtout, une manière de mesurer honnêtement le sien. Je le lis comme le tome 2 : le premier posait le diagnostic, celui-ci propose la trajectoire.

Le scénario d’ouverture est d’une banalité . Un agent de support reçoit une instruction injectée lui demandant d’accéder au dossier d’un autre client. Il obtempère, parce que l’instruction est bien formée et que son token dispose de permissions larges. Aucun identifiant volé, aucune faille exploitée dans le sens habituel du terme. Le token portait simplement encore le périmètre d’un pilote de deux semaines terminé depuis longtemps.

Aucune brèche là-dedans. Juste un privilège qui s’est comporté exactement comme on l’avait configuré, six mois plus tôt, pour deux semaines.

La CSA revient plusieurs fois sur la différence de nature. Un compte de service classique fixe son périmètre au design time ; un agent, lui, détermine son périmètre effectif au runtime, en fonction de ce qu’il lit et de ce qu’on lui demande. Vos contrôles IAM ont été conçus pour le premier cas.

Six prérequis avant de mettre un agent en production

La CSA a fait un choix que j’aurais fait aussi : commencer par la porte d’entrée, pas par le tableau de bord. Avant de parler niveaux, elle pose six conditions à remplir pour qu’un agent ait le droit d’aller en production. Ce sont des gates, pas des bonnes pratiques.

  1. Une identité uniquement attribuable par agent, jamais partagée avec un autre agent ni avec un administrateur humain.
  2. Un propriétaire nommé, enregistré à la création, pas attribué rétroactivement six mois plus tard quand quelqu’un ouvre un ticket.
  3. Des permissions justifiées au regard d’un objectif déclaré, plutôt qu’héritées d’un rôle ou recopiées depuis l’agent précédent.
  4. Une durée de vie de credential plus courte que votre fenêtre de détection. Formulation que je trouve remarquable : elle transforme une question de politique en question d’ingénierie mesurable.
  5. Une piste d’audit complète par identité : chaque action horodatée, avec l’identité exécutante et le résultat, routée quelque part que la chaîne de détection lit vraiment.
  6. Un chemin de révocation testé, mesuré en secondes. Si vous ne l’avez jamais exécuté, vous ne connaissez pas votre temps de révocation ; vous connaissez celui de la documentation.

Le point 3 est le plus souvent violé en pratique, et c’est presque toujours par commodité plutôt que par négligence. On copie le rôle de l’agent qui marchait déjà. Ça marche tout de suite, ça ne repasse jamais en revue, et six itérations plus tard le dernier agent déployé porte l’union de tous les besoins de ses prédécesseurs. J’avais montré le même mécanisme d’accumulation dans l’analyse du flux OBO cassé de l’Azure SRE Agent : le rayon d’impact n’est jamais décidé le jour de l’incident, il est décidé des mois avant, au moment de l’attribution.

Note du PandaRedacteur : « propriétaire nommé, enregistré à la création ». Traduction opérationnelle : quelqu’un dont le nom apparaît dans un champ obligatoire, et qui recevra le mail à trois heures du matin. C’est fou ce que la rigueur d’un inventaire s’améliore quand ce champ n’accepte pas « équipe plateforme ».

Les cinq niveaux, et ce qui sépare vraiment chacun du suivant

Deux lectures possibles du modèle s’affrontent ici. La lecture paresseuse consiste à cocher son niveau et à le mettre dans un slide de comité. La lecture utile consiste à regarder la marche qui manque, parce que chaque transition coûte un type d’effort différent, et que personne ne saute la trois.

📬 Disponible pour les abonnés gratuits Substack
Cet article est également publié sur ma newsletter Substack, avec la mise en page d'origine.

La métrique qui remplace tous vos pourcentages

Une idée à retenir de ce document, et ce n’est pas l’échelle à cinq niveaux ; les modèles de maturité, on en produit un par trimestre dans cette industrie. C’est la métrique proposée pour se situer : le time to revocation, l’intervalle entre le moment où un credential est compromis et le moment où il ne sert plus à rien.

La CSA justifie ce choix par une phrase que vous pouvez réutiliser telle quelle en réunion : « 95 % des identités d’agent sont inventoriées » ne dit rien sur ce que ces identités atteignent, ni sur la vitesse à laquelle on peut en arrêter une seule.

Pour révoquer vite, il faut avoir découvert l’identité, savoir à qui elle appartient, connaître son périmètre, et disposer d’un mécanisme de révocation qui marche. Un seul chiffre, qui s’effondre dès qu’une des quatre briques manque. Le même raisonnement m’avait fait défendre SSVC contre les scores de vulnérabilités : préférer une mesure qui force une décision à une mesure qui décore un rapport.

Deux avertissements accompagnent cette métrique, et tous les deux méritent d’être affichés au mur.

Ne moyennez pas. Ne fondez pas la gouvernance d’identité des agents dans un score organisationnel unique aux côtés de l’identité humaine. Vingt ans de maturité IAM côté humain vont mécaniquement masquer la moitié non gouvernée du parc ; et cette moitié-là est précisément la classe d’identités dont le périmètre d’action est le plus large et le moins prévisible. Une moyenne entre un domaine mature et un domaine inexistant produit un chiffre honorable et une décision fausse.

Le coffre-fort n’est pas le périmètre. Déplacer un credential dans un gestionnaire de secrets améliore la façon dont il est stocké. Ça ne change strictement rien à ce qui se passe quand l’agent qui le détient est détourné. L’hygiène de stockage et le périmètre d’action sont deux axes indépendants, et c’est le second qui décide du rayon d’impact.

Note du PandaRedacteur : celui-là, je l’entends une fois par mois. « On a migré vers un vault, le sujet secrets est traité. » Non. Vous avez rangé les clés dans un tiroir fermé ; la porte qu’elles ouvrent fait toujours la même taille. C’était déjà le fond de mon article sur l’explosion des fuites de secrets IA, où 64 % des secrets exposés n’étaient toujours pas révoqués.

Exemple concret : le token du pilote qui n’a jamais rétréci

Voici le scénario de la CSA déroulé pas à pas, parce qu’il n’y a rien d’exotique dedans et que c’est précisément ce qui le rend intéressant.

  1. En mars, une équipe lance un pilote de deux semaines : un agent qui résume l’historique de tickets d’un client pour le conseiller support. Pour aller vite, on lui attribue le rôle applicatif existant, celui du back-office. Il couvre l’ensemble des dossiers clients, parce que personne n’avait prévu qu’un jour un composant n’en lirait qu’un seul.
  2. Le pilote se termine. L’agent, lui, ne s’arrête pas ; il est utile, deux équipes l’utilisent déjà. Le passage en production se fait sans revue d’identité, puisqu’il n’y avait pas de nouvelle identité à créer. Le token du pilote continue de fonctionner. Aucun ticket n’est ouvert.
  3. En septembre, un client rédige un message de support contenant, en plus de sa demande réelle, une consigne bien formée à destination de l’agent : récupérer et résumer les échanges d’un autre compte client, désigné par son identifiant.
  4. L’agent traite le message. Rien dans son contexte ne lui permet de séparer la demande du client de la consigne injectée ; c’est le problème structurel de l’injection de prompt indirecte, qu’aucun garde-fou ne ferme complètement aujourd’hui.
  5. Il appelle l’API métier avec son token. L’appel est autorisé. Il l’est parce que le rôle du back-office couvre l’ensemble des dossiers, et parce que rien n’a jamais réduit ce périmètre depuis mars.
  6. Le résumé demandé revient dans la conversation, avec des données appartenant à un tiers.
  7. Trois jours plus tard, quelqu’un remarque l’anomalie. Commence alors la vraie question : quels autres dossiers cet agent a-t-il lus depuis six mois ? Sans journalisation par identité, la réponse honnête est « on ne sait pas ».

Le point 5 est celui qui compte. Aucun contrôle n’a été contourné ; le système a fait exactement ce pour quoi il était configuré. L’injection n’a été que le déclencheur ; le périmètre était le vrai problème, et il attendait depuis six mois.

Note du PandaRedacteur : mon passage préféré reste l’étape 2. Le pilote qui devient de la production sans jamais changer de statut administratif, c’est un grand classique. Il existe des tokens en circulation aujourd’hui qui sont plus anciens que l’équipe qui les a créés.

Comment faire progresser une organisation

Trois efforts se distinguent, et ils ne se substituent pas les uns aux autres.

📬 Disponible pour les abonnés gratuits Substack
Cet article est également publié sur ma newsletter Substack, avec la mise en page d'origine.

📚 Quelques références pour aller plus loin

À retenir 📌

  • ✓ Ce modèle est la suite des 8 risques d'identité d'agent : la liste posait le diagnostic, les cinq niveaux donnent la trajectoire et l'ordre des étapes.
  • ✓ Un agent fixe son périmètre au runtime, pas au design time. C'est ce qui rend les contrôles IAM pensés pour les comptes de service insuffisants.
  • ✓ Le niveau 4 (Right-sized) est le premier qui satisfait les six prérequis : en dessous, vous avez des agents en production sans remplir vos propres conditions d'entrée.
  • ✓ Le time to revocation remplace les taux de couverture : un seul chiffre qui échoue dès qu'une des quatre briques (découverte, propriété, périmètre, révocation) manque.
  • ✓ Ne moyennez jamais identité humaine et identité d'agent dans un score unique : vingt ans de maturité côté humain masqueront la moitié non gouvernée du parc.
  • ✓ Le vault améliore le stockage, jamais le périmètre : hygiène de stockage et portée d'action sont deux axes indépendants, et c'est le second qui décide du rayon d'impact.
LinkedIn Reddit Substack