Dans l’enquête mondiale 2026 de McKinsey sur l’IA, 40 % des personnes interrogées issues d’organisations dont le chiffre d’affaires annuel dépasse 1 milliard de dollars ont déclaré déployer à grande échelle des agents IA, contre 27 % lors de l’enquête précédente. À mesure que ces déploiements prennent de l’ampleur, les équipes de sécurité doivent savoir quels agents peuvent agir, quelles identités ils utilisent et qui est responsable de leurs accès. L’étude « State of AI » de McKinsey rend cette question opérationnelle de plus en plus pertinente.
Un inventaire des agents IA est un registre mis à jour régulièrement répertoriant les agents IA et leurs déploiements, notamment leur objectif, leurs responsables, leurs identités, leurs outils, leurs droits d'accès aux données, leur statut d'autorisation et leur cycle de vie. Un inventaire efficace établit un lien entre ce qu'une organisation a approuvé, ce que ses systèmes sont configurés pour autoriser et les activités observées chez ces agents.
Cette connexion aide les équipes à repérer les déploiements sans propriétaire, à examiner les accès excessifs, à enquêter sur les actions inattendues et à désactiver des agents sans laisser derrière eux d'identifiants ni de tâches planifiées. Il s'agit là de points de départ concrets pour sécuriser la frontière de l'IA, où la surveillance repose sur l'identification des agents, de leurs propriétaires et des identités par lesquelles ils agissent.
Sources vérifiées le 28 octobre 2026. Ce guide s'appuie sur des études publiques et des recommandations en matière de sécurité. La conception de l'inventaire, l'exemple et la liste de contrôle de mise en œuvre constituent des recommandations à titre indicatif et ne résultent pas d'un déploiement testé chez un client.
Qu'est-ce qu'un inventaire d'agents IA ?
Un inventaire des agents IA répond à une série de questions concrètes : quels sont les agents présents dans l'environnement défini, où s'exécutent-ils, à quoi ont-ils accès, et qui peut les modifier ou les arrêter ? Son champ d'application doit inclure à la fois les agents approuvés et les découvertes non résolues, en établissant une distinction claire entre ces deux états.
Le guide « AI Risk Management Framework Playbook » du NIST, intitulé GOVERN 1.6, recommande des mécanismes permettant de recenser les systèmes d’IA et de désigner les responsables de la tenue de ces registres. Un inventaire des agents applique ce cadre de gouvernance aux systèmes capables d’utiliser des outils et d’effectuer des actions.
Définir ce qui constitue un agent
Dans le cadre de cet inventaire, considérez un agent IA comme un logiciel qui utilise un modèle d’IA pour sélectionner ou mettre en œuvre des étapes menant à un objectif, ce qui peut impliquer l’utilisation d’outils, l’accès à des données ou la délégation de tâches. Notez le degré d’autonomie, car un système qui rédige une réponse et un système qui l’envoie ont des conséquences opérationnelles différentes.
Cela inclut les applications personnalisées, les agents intégrés dans des logiciels en tant que service (SaaS), les assistants de codage locaux disposant d'un accès aux outils, ainsi que les agents gérés en externe et autorisés à interagir avec les ressources de l'entreprise. Il convient de les distinguer des agents de surveillance « endpoint » et de l'automatisation classique qui n'utilise pas l'IA pour déterminer les actions à entreprendre.
Un modèle endpoint, un outil ou un connecteur est une ressource associée. Il ne devient pas automatiquement un agent IA distinct. Si un agent utilise un modèle IA Frontier, enregistrez cette dépendance au modèle séparément des outils, des identifiants et de l’accès aux données du déploiement. Les capacités du modèle ne suffisent pas à elles seules à décrire ce que l’agent déployé est capable de faire. Pour les exigences de protection plus générales, consultez la section « Sécurité des agents IA ».
Séparer l'inventaire des documents associés
Plusieurs systèmes existants peuvent contribuer à la gestion des stocks. Leurs appellations varient selon les produits ; définissez donc les fonctionnalités dont votre organisation a besoin :
- Un inventaire des modèles permet de répertorier les modèles, les versions, les fournisseurs et les évaluations associées.
- Un registre ou un catalogue d'agents peut publier les définitions des agents, leurs capacités et les informations relatives à leur découverte.
- Une base de données de gestion de la configuration (CMDB) établit des liens entre les applications, l'infrastructure et les services métier.
- Une nomenclature IA décrit les composants et les dépendances concernés.
- Un inventaire opérationnel des agents relie ces enregistrements aux déploiements, aux identités, à la propriété, aux autorisations et aux preuves d'activité.
Ces fonctions peuvent partager une même plateforme ou rester connectées via des identifiants. Il est indispensable qu'il existe une relation fiable entre les enregistrements, avec une source identifiable pour chaque champ.
Pourquoi le contexte de déploiement des agents d'IA est-il important ?
Une même conception d'agent peut fonctionner dans plusieurs environnements dotés de droits d'accès différents. Se baser uniquement sur son nom masque ces différences, tandis que compter chaque exécution comme un nouvel agent donne une image exagérée du parc.
L'augmentation signalée par McKinsey concerne la mise à l'échelle des agents dans une ou plusieurs fonctions métier parmi les répondants issus de grandes entreprises, définies en fonction de leur chiffre d'affaires. L'enquête a recueilli 1 719 réponses dans 97 pays entre mai et juin 2026. Elle mesure le taux d'adoption déclaré, et non le nombre d'agents ni l'exhaustivité de l'inventaire. Concrètement, cela implique de se préparer au déploiement d'agents dans des fonctions présentant des exigences d'accès différentes.
Utilisez trois niveaux reliés entre eux dans l'inventaire :
- Définition de l'agent : la finalité, la configuration, la version, les dépendances liées au modèle et l'ensemble d'outils autorisés.
- Déploiement d'agent : une installation ou une instance de service spécifique au sein d'un environnement, d'un locataire ou d'un compte, dotée de sa propre identité et de son propre contexte d'accès.
- Exécution d'agent : exécution ou session associée à un déploiement, à un utilisateur ou à un service à l'origine de celle-ci, ainsi qu'aux enregistrements d'activité correspondants.
Par exemple, un agent d'assistance dans un environnement de test peut consulter des tickets synthétiques. Dans son déploiement en production, il peut consulter les fiches clients et mettre à jour les dossiers. Le fait qu'ils partagent le même nom d'agent ne signifie pas que leurs autorisations sont identiques. Les enregistrements de déploiement doivent également être liés à l'activité observée.
Enregistrez les travailleurs éphémères et les sous-agents à l'aide de leurs identifiants de déploiement et d'exécution parents. Créez des enregistrements de déploiement distincts lorsqu'ils acquièrent des identifiants, des droits de propriété ou des limites d'accès persistantes différents. Il s'agit d'une convention de comptage proposée ; documentez-la afin que les différentes équipes communiquent des chiffres comparables.
Frontier AI : conçue sans freins
Découvrez comment des agents autonomes peuvent franchir les limites prévues, ainsi que les mesures concrètes que les équipes de sécurité peuvent mettre en œuvre pour identifier ces agents, surveiller leurs activités et contenir tout comportement inattendu.
Télécharger le livre blanc →
Éléments à inclure dans un inventaire d'agents IA
Chaque fiche de déploiement doit contenir suffisamment d'informations pour identifier l'agent, évaluer ses compétences, trouver des éléments justificatifs et contacter une personne responsable. Le modèle ci-dessous constitue un point de départ pratique ; adaptez-le à votre environnement et à vos décisions en matière de gestion des risques.
| Superficie record |
Champs à renseigner |
Décision qu'elle soutient |
| Identification |
Identifiant de l'agent stable, identifiant de déploiement, nom, version, relation parent-enfant |
Distinguer les modèles, les déploiements et les travailleurs délégués |
| Objet et propriété |
Objectif métier, responsable désigné, responsable technique, interlocuteur du support |
Définir les responsabilités et l'utilisation prévue |
| Déploiement |
Référence de plateforme, de locataire ou de compte, d'environnement, de région, de service ou d'appareil |
Localisez l'agent et définissez ses limites |
| Identité |
Identifiants principaux, méthode d'authentification, identité initiatrice, relations de délégation |
Accès aux attributs et identification de l'autorité partagée |
| Modèle et configuration |
Référence du modèle/fournisseur, version de configuration, version ou référence d'artefact |
Suivre les changements significatifs |
| Outils et dépendances |
Identifiants d'outils, connecteurs, serveurs MCP, versions, services en aval |
Comprendre ce que l'agent peut déclencher |
| Données et destinations |
Ressources accessibles, catégories de sensibilité, destinations externes approuvées |
Évaluer les risques d'exposition et les flux de données |
| Autorité |
Actions approuvées, autorisations accordées, actions observées, conditions d'approbation |
Identifier les dérives par rapport au périmètre défini et les privilèges excessifs |
| Surveillance et intervention |
Points d'approbation humaine, procédure de suspension, responsable de la révocation, conditions de rétablissement |
Intervenir en toute sécurité lorsque cela s'avère nécessaire |
| Gouvernance |
Statut d'approbation, justification des risques, exceptions, date limite d'examen |
Prise de décisions concernant l'itinéraire et suivi des problèmes en suspens |
| Cycle de vie |
Prévu, en phase de test, actif, suspendu ou retiré ; justificatifs d'expiration et de retrait |
Gérer les accès tout au long du cycle de vie du déploiement |
| Preuves et fraîcheur |
Source, heure d'observation, dernière collecte réussie, dernière activité, niveau de confiance, lacunes |
Déterminer si une information est fiable et à jour |
Conservez dans l'inventaire les références des identifiants, les émetteurs, les champs d'application et les dates d'expiration. Stockez les valeurs secrètes dans un système de gestion des secrets adapté. La copie des jetons dans un inventaire crée un autre endroit où ils risquent d'être exposés.
Il convient de distinguer les données déclarées par le propriétaire de celles observées par un collecteur. Une finalité métier correspond généralement à une affirmation du propriétaire ; l'attribution d'un rôle dans le cadre de l'cloud , à une preuve de configuration ; et un événement API réussi, à une preuve d'activité. Chacune de ces données répond à une question différente.
Il convient également de distinguer la dernière activité, la dernière collecte réussie et la dernière vérification. Un agent peut être inactif alors que son enregistrement d'inventaire est à jour, ou actif alors que le collecteur chargé d'alimenter son enregistrement a échoué.
Comment recenser les agents IA au sein de l'entreprise
La découverte nécessite plusieurs sources, car les agents peuvent être intégrés dans des applications hébergées, des services personnalisés et des outils de développement locaux. Commencez par définir une périmètre de couverture, puis recensez les environnements et les types de déploiement que chaque source est effectivement en mesure d'observer.
Commencez par les sources de déploiement et de configuration
Récupérez les définitions d'agents disponibles à partir des plateformes d'IA approuvées, des comptes d'cloud , des interfaces d'administration SaaS, des catalogues d'applications et des pipelines de déploiement. Examinez les référentiels et les manifestes de déploiement à la recherche des services d'agents enregistrés et de leurs dépendances.
Pour les agents locaux, utilisez les logiciels et les inventaires de configuration autorisés par endpoint . La présence d'un logiciel installé indique une capacité potentielle ; elle ne prouve pas qu'un agent configuré soit en cours d'exécution ou dispose d'un accès à l'entreprise.
Enregistrez les identifiants des locataires et de l'environnement ainsi que les identifiants de la plateforme. Un même nom d'affichage peut apparaître à plusieurs endroits. Vérifiez les autorisations du collecteur, les types d'objets pris en charge, la pagination et les intervalles de rafraîchissement avant de considérer l'exportation comme terminée.
Inspectez les outils et configurations inconnus à l'aide de méthodes en lecture seule approuvées. La procédure de découverte ne doit pas exécuter un agent inconnu ni lancer un outil susceptible d'entraîner des effets indésirables dans le seul but de l'identifier.
Relier les identités et l'accès délégué
Associez les agents aux comptes de service, aux identités d'application, aux identités de charge de travail et aux accès utilisateur délégués. Vérifiez qui a accordé l'accès, les ressources concernées et si plusieurs agents partagent un même principal.
Conserver la chaîne depuis l'utilisateur ou le service d'origine jusqu'au déploiement de l'agent, au connecteur et au système en aval. Un agent peut agir sous plusieurs identités au cours d'une même tâche. Le partage des identifiants peut rendre l'attribution ambiguë ; cette information doit toutefois rester visible dans le dossier.
Le protocole MCP (Model Context Protocol) relie les applications aux outils et aux ressources. Ses recommandations en matière de sécurité expliquent comment le « token passthrough » et l'absence de validation de l'audience peuvent compromettre les limites de confiance et la responsabilité. L'inventaire d'un connecteur ne se limite donc pas à son adresse : il convient d'en consigner la relation d'authentification et l'autorité en aval.
La sécurité des identités non humaines offre un contexte utile pour la gestion des identités des services et des charges de travail concernées.
Utilisez cette activité pour identifier les lacunes
Comparez les déploiements enregistrés avec les journaux d'application disponibles, les enregistrements d'appels d'outils, les événements d'identité, les journaux d'audit d'cloud , l'activité de l'endpoint et les métadonnées réseau. Enquêtez sur les activités qui ne peuvent pas être associées à un déploiement identifiable.
Considérez le trafic vers un service d'IA comme une piste de découverte. Il peut provenir d'une personne, d'une application classique ou d'un agent. De même, un appel API générique provenant d'un compte de service ne prouve pas pour autant qu'il ait été initié par un système d'IA.
Marquez les résultats non résolus comme « candidats » jusqu’à ce que des preuves corroborantes permettent d’établir de quoi il s’agit. Les agents confirmés qui ne relèvent pas du processus d’approbation requis peuvent faire partie d’ une IA « fantôme ». Une simple divergence dans l’inventaire peut également refléter un retard dans la collecte des données, un déploiement renommé ou une attribution incomplète.
Les observations du réseau peuvent aider à identifier les destinations et les schémas de communication, mais le trafic chiffré et le partage des infrastructures limitent les informations qu'elles fournissent sur les actions individuelles des agents.
Inclure les tiers et les chefs d'entreprise
Renseignez-vous auprès des responsables des achats et des responsables applicatifs sur les fonctionnalités des agents disponibles dans le cadre des abonnements existants, des services gérés et des flux de travail hébergés en externe. Ces fonctionnalités ne sont pas nécessairement considérées comme de nouveaux achats de logiciels.
Pour les prestataires tiers, demandez les informations opérationnelles nécessaires à votre cas d'utilisation : interlocuteurs responsables, ressources d'entreprise associées, limites des autorisations, journaux disponibles, notifications de modification et procédures de suspension. Consignez les informations que le prestataire ne peut pas fournir en tant que lacune.
Les attestations du propriétaire permettent d'expliquer l'objectif et les motifs de l'autorisation. Elles permettent de corroborer les allégations techniques dans la mesure du possible, en particulier lorsqu'elles déterminent si un agent est autorisé à effectuer une action ayant des conséquences importantes.
Comment faire correspondre les données enregistrées avec l'activité observée
Le rapprochement permet de transformer un ensemble d'enregistrements en un inventaire exploitable. Il permet de comparer ce qui a été approuvé, les accès accordés et les activités observées, tout en conservant les éléments probants et les incertitudes liés à chaque constat.
Ces trois aspects doivent rester distincts. Une attribution de rôle peut avoir une portée plus large que l'objectif approuvé. Une autorisation non utilisée reste néanmoins valable. Une tentative d'appel d'API peut avoir échoué et ne doit pas être enregistrée comme une action menée à bien.
Un processus de rapprochement pratique consiste à normaliser les identifiants, à associer les preuves aux déploiements, à comparer les trois vues et à transmettre les divergences au responsable concerné. Utilisez les identifiants de plateforme et les correspondances d'identité vérifiées lorsqu'ils sont disponibles. Les noms d'affichage constituent à eux seuls des clés de correspondance peu fiables.
| Mesure |
Comment l'évaluer ? |
Ce que cela révèle |
| Précision d'extraction |
Nombre d'éléments correctement extraits divisé par le nombre total d'éléments extraits |
Entités et relations erronées ou inventées |
| Rappel d'extraction |
Nombre d'éléments correctement extraits divisé par le nombre total d'éléments de référence pertinents |
Éléments de preuve que le processus n'a pas pris en compte |
| Assistance pour les demandes d'indemnisation |
Allégations qui en découlent, étayées par les éléments de preuve cités |
La fidélité des résumés par rapport aux sources |
| Validité de la chasse |
Requêtes qui s'exécutent correctement et reflètent le comportement attendu avec les données de test |
Erreurs sémantiques masquées par une exécution réussie |
| Qualité de la décision |
Comparer les décisions rendues avec une décision de référence et les éléments de preuve présentés ultérieurement |
La question est de savoir si les renseignements influencent les décisions de manière appropriée |
| Une démarche de bout en bout |
Y compris la création, la révision, la correction, l'analyse et la maintenance |
La vitesse apparente entraîne-t-elle un surcroît de travail en aval ? |
| Utilité opérationnelle |
Suivre les résultats qui servent de base à une chasse, à un changement de méthode de détection ou à une décision de lutte |
Une valeur qui va au-delà des chiffres des rapports ou des indicateurs |
Ne remplacez pas en silence les informations contradictoires par celles provenant de la source la plus récente. Définissez l'autorité au niveau des champs, conservez l'historique pertinent et rendez les conflits non résolus consultables.
La qualité des preuves est également importante. Les recommandations de l’OWASP concernant les preuves d’exécution par des tiers établissent une distinction entre les affirmations des fournisseurs et les observations vérifiables de manière indépendante. Un enregistrement signé permet d’identifier l’auteur d’une affirmation, sans pour autant prouver que toutes les actions signalées ont bien eu lieu ni qu’aucun événement n’a été omis.
À des fins d'inventaire, notez ce que chaque observation permet d'établir et ce qu'elle ne permet pas d'établir. L'absence d'un événement signalé par un collecteur indisponible constitue un élément de preuve manquant, et non la preuve d'un comportement sûr.
Comment établir un ordre de priorité parmi les agents à évaluer
La priorité accordée à l'évaluation doit tenir compte des conséquences des actions possibles d'un agent et de la qualité de ses contrôles. Le fait qu'un modèle soit familier ou qu'une plateforme soit approuvée ne détermine pas le risque associé à chaque déploiement qui y est basé.
Utilisez les questions suivantes pour établir un ordre de priorité fondé :
- L'agent a-t-il accès à des données sensibles concernant les clients, les finances, les salariés ou les opérations ?
- Peut-il écrire, supprimer, publier, dépenser de l'argent, modifier les droits d'accès ou exécuter du code ?
- Traite-t-il du contenu non fiable susceptible d'influencer l'utilisation de l'outil ?
- Peut-il déléguer des tâches ou accéder à des outils supplémentaires au-delà du cadre initial de la tâche ?
- Les mesures à fort impact font-elles l'objet d'une autorisation indépendante, et leurs effets peuvent-ils être annulés ?
- L'équipe est-elle en mesure d'identifier le propriétaire, de reconstituer les activités concernées et de suspendre l'accès ?
La fiche pratique de l’OWASP sur la sécurité des agents IA recommande le principe du « privilège minimal », la supervision des actions à fort impact et la surveillance de la sécurité. Traduisez ces principes en champs d’inventaire pouvant être examinés et testés.
Un agent sans propriétaire disposant d'un accès en écriture à la production justifie un examen urgent. Un agent documenté en lecture seule utilisant des informations publiques peut justifier un examen moins approfondi. Il s'agit là d'exemples de hiérarchisation suggérés, et non de classifications universelles des risques.
Évaluez les autorisations effectives lorsque la plateforme le permet. Les rôles attribués, les politiques de ressources, les restrictions conditionnelles et les autorisations des connecteurs en aval peuvent interagir entre eux. Lorsque cette interaction n'est pas résolue, qualifiez l'accès effectif de « non vérifié » plutôt que d'assimiler le nom d'un rôle à une capacité avérée.
Comment maintenir l'inventaire à jour
Un inventaire reste utile lorsque les mises à jour s'inscrivent dans les processus de déploiement et de gestion des accès. Associez les mises à jour déclenchées par des événements à un rapprochement planifié et à une vérification par le responsable, en choisissant une fréquence adaptée au rythme des changements et aux risques propres à l'environnement.
Attribuer les responsabilités et définir les conditions de mise à jour
Attribuez à chaque déploiement un responsable métier et un responsable technique. Le responsable métier valide l'objectif et les conditions d'utilisation acceptables ; le responsable technique gère les détails du déploiement et les intégrations. Les équipes chargées de la gestion des identités et des accès (IAM) valident les accès, les équipes chargées de la sécurité enquêtent sur les activités suspectes et les équipes de gouvernance coordonnent les autorisations et les dérogations.
Désignez un responsable dédié au service d'inventaire lui-même. Cette personne ou cette équipe est chargée de gérer le schéma des enregistrements, l'état de santé des collecteurs, les règles de rapprochement, les contrôles d'accès et le processus d'escalade.
Déclencher une révision lorsqu'un agent reçoit un nouvel outil, une nouvelle identité, une nouvelle autorisation, une nouvelle source de données, une nouvelle destination externe, un nouveau paramètre d'autonomie ou lorsqu'un changement de configuration important est effectué. Les transferts de propriété et les exceptions arrivées à expiration nécessitent également une intervention.
Suivez l'évolution de la configuration et la date à laquelle elle est entrée en vigueur. Sinon, un enquêteur pourrait comparer les actions d'hier avec les autorisations d'aujourd'hui et tirer une conclusion erronée.
Retirer les agents et protéger le stock
La mise hors service doit empêcher toute action tout en préservant les preuves nécessaires. Désactivez les déclencheurs et les planifications concernés, révoquez les droits d'accès spécifiques aux agents, supprimez les intégrations obsolètes et vérifiez le résultat. Vérifiez les dépendances partagées avant de modifier les identifiants utilisés par d'autres charges de travail.
Conservez un dossier d'archivage contenant la décision, la date, le responsable et les preuves de vérification. Appliquez les exigences de conservation de l'organisation aux journaux, aux mémoires de stockage, aux configurations et aux documents opérationnels concernés. Les recommandations GOVERN 1.7 du NIST considèrent la mise hors service comme un processus géré, car une suppression aveugle peut entraîner des risques.
L'inventaire lui-même peut révéler des informations sensibles concernant les identités privilégiées et les systèmes accessibles. Limitez l'accès en fonction des rôles, consignez les modifications importantes et protégez les exportations. Conservez les preuves sensibles détaillées dans des systèmes contrôlés et faites-y référence à partir de l'inventaire lorsque cela est possible.
Exemple d'inventaire d'agents IA
Imaginons un agent du service client hypothétique autorisé à résumer les tickets et à rédiger des réponses. Son rôle est bien défini, mais ses droits d'accès réels dépendent du déploiement et des connecteurs qui y sont associés.
L'enregistrement d'inventaire initial identifie le responsable de l'application d'assistance, le locataire de production, la version de l'agent et l'identifiant d'un connecteur. L'ensemble des actions approuvées comprend la lecture des tickets attribués et l'enregistrement des brouillons de réponse. L'envoi de messages nécessite une décision humaine.
La réconciliation révèle que le connecteur dispose également d'une autorisation pour envoyer des messages et lire des tickets en dehors de la file d'attente prévue. Aucun envoi non autorisé n'a été constaté. Ce constat reste toutefois important : le périmètre accordé dépasse le périmètre approuvé, même si les enregistrements d'activité disponibles ne font pas état d'abus.
Le responsable technique vérifie si d'autres charges de travail partagent le connecteur, isole l'accès de l'agent dans la mesure du possible et supprime les autorisations superflues. Le réviseur consigne la modification et vérifie le comportement attendu à l'aide d'un cas de test approuvé.
Par la suite, un journal d'activité indique que ce même identifiant a effectué une écriture vers une nouvelle destination externe. Le connecteur ayant auparavant pris en charge plusieurs charges de travail, l'enquêteur vérifie les identifiants de déploiement et d'exécution avant d'attribuer cette action à l'agent de support.
Cet exemple met en évidence deux avantages distincts : l'inventaire permet de corriger les autorisations avant même qu'une utilisation abusive ne soit constatée, et il conserve le contexte nécessaire pour éviter toute attribution erronée d'incident. Il ne s'agit pas d'une affirmation concernant un client réel ni d'un test de produit.
Liste de contrôle pour la mise en œuvre d'un agent IA de gestion des stocks
Utilisez cette liste de contrôle pour établir un inventaire exploitable dans un environnement défini. Cochez une tâche comme terminée lorsque le responsable peut se référer à un document, à une décision de validation ou à un résultat de test qui la valide. Assurez le suivi des tâches en suspens en indiquant le responsable et une date de révision.
Définir le périmètre et la responsabilité
☐ Répertorier les plateformes, les comptes, les locataires, les appareils et les services externes concernés, y compris les exclusions connues.
☐ Se mettre d'accord sur ce qui constitue une définition, un déploiement et une exécution d'agent, et attribuer des identifiants stables.
☐ Désigner un responsable du processus d'inventaire, un responsable métier et un responsable technique pour chaque déploiement identifié ; transmettre les enregistrements sans responsable vers les instances compétentes pour résolution.
☐ Définir les champs obligatoires, les étapes d'approbation, les sources justificatives et les délais de révision.
☐ Limiter l'accès à l'inventaire et les exportations, et stocker les références d'identification sans copier les valeurs confidentielles.
Découvrir les agents et synchroniser les accès
☐ Recueillir les enregistrements de déploiement disponibles et répertorier les environnements non pris en charge, les collectes ayant échoué, ainsi que la dernière actualisation réussie pour chaque source.
☐ Établir une correspondance entre les déploiements et les identités, les accès délégués, les outils et les ressources en aval ; signaler les identifiants partagés et les attributions incertaines.
☐ Consigner séparément les actions approuvées, les autorisations accordées et les activités observées, en joignant les pièces justificatives et les horodatages correspondants.
☐ Examiner les divergences concernant des données sensibles ou un accès en écriture ayant des conséquences importantes, et attribuer à chaque constatation un responsable ainsi qu'une solution ou une décision d'exception.
☐ Testez les agents renommés, les enregistrements en double, les modifications d'autorisations et les échecs de collecte à l'aide de ressources de test approuvées ; vérifiez que les lacunes restent visibles.
Vérifier la maintenance et la réactivité
☐ Configurer les mises à jour déclenchées par des changements et les revues périodiques, et vérifier comment sont traités les cas de revues en retard ou d'absence de responsables.
☐ Vérifier qu'un analyste est en mesure de localiser un déploiement, d'expliquer comment y accéder, d'identifier son propriétaire et de récupérer les preuves d'activité pertinentes.
☐ Effectuer la suspension et la mise hors service à l'aide des ressources de test approuvées, en vérifiant les tâches planifiées, les accès en aval et les dépendances partagées.
☐ Conserver la décision, le nom du responsable, l'horodatage et les preuves de vérification relatives aux modifications d'accès et aux retraits.
☐ Indiquer la couverture de la propriété, l'actualité des données collectées, les divergences non résolues et les résultats des tests de réponse, en précisant les dénominateurs et les lacunes de couverture.
Comment évaluer les outils de gestion des stocks et mesurer leur couverture
Évaluez les outils en fonction des types de déploiement et des sources de preuves dont vous avez réellement besoin. Un grand nombre d'enregistrements ne suffit pas à démontrer que l'inventaire est exact, à jour ou utile dans le cadre d'une enquête.
Demandez aux fournisseurs de vous présenter la fonctionnalité de découverte sur l'ensemble de vos agents concernés, qu'ils soient hébergés, locaux, personnalisés ou tiers. Vérifiez les conditions préalables, les autorisations de collecte, la latence, les environnements non pris en charge et le comportement en cas de défaillance d'un connecteur.
Vérifiez ensuite si l'outil conserve des identifiants stables, prend en charge les identités partagées et déléguées, enregistre l'historique des configurations, fournit la traçabilité des preuves et exporte des enregistrements exploitables via des interfaces documentées. Déterminez quelles actions du flux de travail nécessitent des intégrations et des autorisations distinctes.
Utilisez un petit ensemble de mesures dont les dénominateurs sont explicites :
| Mesure |
Calcul ou test recommandé |
Limite d'interprétation |
| Couverture des biens |
Nombre de déploiements dont le responsable a été vérifié, divisé par le nombre de déploiements connus concernés |
Décrive les agents connus, et non ceux qui n'ont pas encore été découverts |
| Corrélation d'identité |
Nombre d'exécutions d'agents observées associées à un déploiement et à un principal, divisé par le nombre d'exécutions d'agents observées |
Nécessite une attribution crédible à l'agent et des preuves d'exécution disponibles |
| Fraîcheur des produits |
Nombre de sources connectées actualisées avec succès dans le délai convenu, divisé par le nombre total de sources connectées |
Indiquez séparément les sources exclues et celles qui ne sont pas étayées |
| Retard dans le rapprochement |
Les écarts non résolus, leur ancienneté et leur impact potentiel |
Une baisse du nombre d'éléments peut indiquer une perte de visibilité ; vérifiez l'état de la source. |
| Capacité d'intervention |
Date et résultat d'un test approuvé visant à localiser, mettre hors service et vérifier un agent |
Un test contrôlé ne prouve pas que toutes les voies de production sont prises en compte |
Évitez d'avancer un pourcentage portant sur « l'ensemble des agents d'entreprise » à moins que le dénominateur ne puisse être établi. En général, il est plus justifié de se référer à la couverture des comptes, des plateformes, des appareils ou des déploiements connus, en précisant explicitement les lacunes.
Intégration du stock d'agents aux opérations de sécurité
Les registres d'inventaire fournissent le contexte nécessaire à la prise de décisions en matière de sécurité : quel agent est impliqué, quelle identité utilise-t-il, quelles actions sont attendues et comment l'accès peut-il être modifié. Les workflows de détection et de réponse nécessitent, en plus de ce contexte, des données de télémétrie et des mécanismes d'application.
Associez les identifiants d'inventaire pertinents aux enquêtes de sécurité afin que les analystes puissent passer d'un événement lié à une identité ou à une charge de travail au responsable du déploiement et au périmètre approuvé. Maintenez la distinction entre une anomalie présumée, un incident faisant l'objet d'une enquête, une action recommandée et une maîtrise confirmée.
Vectra AIL’approche de sécurité et d’observabilité « native IA » de [nom de l’entreprise] s’avère pertinente lorsque les agents opèrent via des identités et une infrastructure dans des environnements connectés. Son cas d’utilisation relatif à la visibilité des actifs et des identités décrit la visibilité sur les environnements réseau, d’identité, d’ cloud et SaaS. Cela peut fournir un contexte utile lors de l’évaluation d’un programme d’inventaire ; les mappages spécifiques des agents, la télémétrie et les intégrations doivent toutefois encore être vérifiés en vue du déploiement.
Si vous évaluez cette connexion opérationnelle, demandez une démonstration d'Vectra AI axée sur les identités, les environnements et les workflows d'enquête utilisés par vos agents.
