Solutions
Comptes de service, clés API, applications OAuth et agents IA déclarés dans vos plateformes : MIA inventorie les identités et accès que chaque source connectée expose. Visualisez les liens et droits disponibles, désignez un responsable et gardez la trace des décisions.
L'enjeu
Les identités non humaines n'entrent dans aucun de ces moments. Elles sont créées au fil des projets, par des personnes qui changent de poste ou quittent l'entreprise, et elles conservent leurs droits.
En moyenne, 109 identités machine pour une identité humaine, dont 79 identités d’agents IA.
Source : Palo Alto Networks, rapport 2026 Identity Security Landscape, enquête auprès de 2 930 décideurs.
Elles naissent dans la console d'un éditeur, un workflow ou un projet cloud, rarement dans un circuit de demande.
Scopes OAuth, rôles de projet, connexions déléguées : chaque plateforme exprime les droits à sa façon.
Celui qui a créé l'identité n'est pas forcément celui qui en répond, et il n'est pas toujours encore dans l'entreprise.
Ce que fait MIA
Un inventaire tenu à jour, des autorisations lisibles, une personne qui en répond, une décision tracée. La même méthode que pour les comptes de vos équipes, appliquée à ce que vos plateformes exposent.
MIA interroge les API d'administration de vos plateformes. Selon les données qu'elles exposent, l'inventaire peut couvrir comptes de service, clés API, applications OAuth et agents IA. Il se met à jour à chaque synchronisation.
Pour chaque objet, MIA affiche le propriétaire, les autorisations et les ressources que la source renvoie. Un lien reconstitué par MIA est signalé comme tel ; un lien impossible à établir reste marqué comme non résolu.
Le propriétaire déclaré chez l'éditeur n'est pas toujours la bonne personne. Dans MIA, vous désignez qui répond de l'objet, et vous le réattribuez quand cette personne change de poste ou quitte l'entreprise.
Nouvel objet, autorisation modifiée, propriétaire parti : les écarts remontent à la synchronisation suivante. Revues et décisions sont consignées dans le journal de MIA, avec leur date et leur auteur.
L'approche
MIA s’appuie sur les données exposées par les API d’administration de vos plateformes. Elle indique l’origine de chaque lien, y compris lorsqu’il reste non résolu.
Le propriétaire est celui que l'éditeur déclare : souvent le créateur, parfois personne, et MIA affiche alors « Non renseigné par la source ». Le responsable est la personne que vous désignez dans MIA pour répondre de l'objet et décider de son sort. Tant qu'il n'est pas choisi, l'objet reste « Non désigné ».
Le cadre
Les identités non humaines ne demandent pas un outil à part. Dans MIA, elles rejoignent le cadre que vous appliquez déjà aux comptes de vos équipes.
Sources couvertes
Les connecteurs MIA couvrent des périmètres différents selon les API disponibles. Les exemples ci-dessous montrent les objets à examiner avec votre équipe ; la couverture exacte des identités techniques, des liens et des droits se confirme source par source lors de la démo.
Les identités d’agents de votre tenant, leurs propriétaires et leurs autorisations.
Les agents de vos environnements, leurs auteurs et les connexions qu’ils utilisent.
Les applications OAuth autorisées par vos utilisateurs et les scopes qui leur sont accordés.
Les agents déployés dans vos projets et les comptes de service sous lesquels ils s’exécutent.
MIA peut inventorier les membres de l’organisation OpenAI. La visibilité sur les projets, comptes de service et clés API est à confirmer selon les droits disponibles.
MIA inventorie les membres de l’organisation via l’API d’administration Claude. La couverture des espaces de travail et des clés API reste à vérifier séparément.
MIA inventorie les membres de l’organisation via l’API d’administration Mistral. La couverture des espaces de travail et des clés API reste à vérifier séparément.
MIA peut inventorier les utilisateurs de votre instance n8n. La visibilité sur les workflows et leurs propriétaires est à confirmer lors de la démo.
MIA peut inventorier les utilisateurs Salesforce. La couverture des applications connectées, comptes d’intégration et agents est à confirmer selon votre organisation.
Le référentiel des systèmes d’IA que vous tenez dans ServiceNow, avec leurs responsables.
Et vos autres outils ? Les comptes de vos collaborateurs restent couverts par le catalogue MIA : environ 90 connecteurs, plus un connecteur SCIM 2.0 générique.
La démo
Pas de jeu de données générique : nous partons des outils que vous utilisez et nous regardons ensemble ce que MIA peut y inventorier.
Vous indiquez votre environnement : Microsoft 365, Google Workspace, Google Cloud, OpenAI, Claude, n8n, Salesforce, ServiceNow.
Pour chacune, les objets et les autorisations visibles, les liens que l’API permet d’établir et ceux qu’elle ne renvoie pas.
Les rôles d’administration et les autorisations à accorder à MIA, source par source.
Responsables, revues et journal : comment ces identités rejoignent les règles que vous appliquez déjà.
Aux équipes qui doivent pouvoir répondre, en audit comme au quotidien : quelles identités techniques ont accès à quoi, et qui en répond ?
🇫🇷 Éditeur français, hébergement chez OVHcloud à Strasbourg. MIA ne collecte que des métadonnées : identités, autorisations, dates. Jamais le contenu de vos fichiers, de vos messages ni de vos échanges avec un agent.
C’est une identité utilisée par un programme plutôt que par une personne : compte de service, clé API, application OAuth, agent IA. Elle dispose d’autorisations dans vos outils, comme le compte d’un collaborateur, mais n’en suit pas le cycle d’arrivée et de départ.
Non, et aucun outil ne le peut de façon fiable. MIA inventorie ce que vos plateformes exposent dans leurs API d’administration : agents gérés, comptes de service, clés API et applications OAuth. Un script qui utilise une clé n’apparaît qu’à travers cette clé, si la source la renvoie.
Le propriétaire est celui que l’éditeur déclare, souvent le créateur de l’objet. Le responsable est la personne que vous désignez dans MIA pour en répondre lors des revues. Les deux sont distincts : le créateur peut avoir changé de poste ou quitté l’entreprise.
Configuré désigne ce que la définition d’un agent prévoit de faire. Accordé désigne le droit réellement attribué à son identité dans la plateforme. Observé désigne l’activité visible dans les journaux de la source, lorsqu’elle les expose. MIA affiche ces trois niveaux séparément.
Cela dépend de chaque plateforme. En général, MIA a besoin d’un rôle d’administration en lecture ou d’une clé d’administration créée par un propriétaire de l’organisation. Les prérequis de chaque source sont détaillés dans la documentation.
Oui. Chaque objet suivi peut recevoir un responsable et rejoindre vos campagnes de revue, au même titre que les comptes de vos collaborateurs. Les décisions sont consignées dans le journal scellé et alimentent vos éléments de preuve pour les audits NIS2 et ISO 27001.
Non. MIA se connecte aux API d’administration de vos plateformes, sans agent à installer et sans SSO imposé. Si vous utilisez déjà Microsoft Entra ou Google Workspace comme fournisseur d’identité, MIA s’appuie dessus sans le remplacer.
En France, chez OVHcloud à Strasbourg. MIA ne collecte que des métadonnées : identifiants, autorisations, propriétaires et dates. Il ne lit ni le contenu de vos fichiers, ni vos messages, ni les échanges avec vos agents.
