Un agent IA prépare vos réponses clients. Une automatisation transfère des données entre votre CRM et votre outil de facturation. Un bot publie des notifications dans Slack.
Ces outils rendent service. Mais savez-vous quels accès ils utilisent, quelles données ils peuvent atteindre et qui est responsable de leur fonctionnement ?
La gestion des accès concerne aussi les logiciels qui agissent pour votre entreprise : agents IA, bots, scripts et autres automatisations.
Vous pouvez commencer à les encadrer sans lancer un vaste projet technique. Il faut d’abord identifier leurs accès, attribuer les responsabilités et organiser des contrôles réguliers. Voici comment procéder, et comment MIA peut vous aider.
Une identité non humaine, ou NHI pour Non-Human Identity, est une identité numérique utilisée par un logiciel pour accéder à un service ou à des données.
L’exemple le plus simple est le compte de service : un compte dédié à une automatisation plutôt qu’à une personne.
Pour comprendre le sujet, distinguons quatre éléments :
Une clé API est donc un moyen d’accès à suivre, mais elle ne suffit pas à décrire l’agent qui l’utilise.
Un même agent peut utiliser plusieurs identités. Plusieurs automatisations peuvent aussi partager un même accès. Une simple liste de comptes ne donne donc pas toujours une vision complète.
Un agent IA peut accéder à vos outils de plusieurs façons :
Dans le dernier cas, l’application peut enregistrer une action au nom du collaborateur, sans indiquer clairement qu’un agent l’a exécutée.
Cette distinction ressort des échanges avec les communautés IT et IAM : identifier le compte utilisé ne permet pas toujours d’identifier ce qui agit derrière ce compte. Lire la discussion sur la gouvernance des agents.
Il faut donc répondre à deux questions complémentaires :
Quels accès existent ? C’est le rôle de l’inventaire et de la gouvernance des identités.
Quel agent utilise ces accès, pour qui et pour faire quoi ? Cela demande aussi des informations sur l’exécution des agents et leurs actions.
Prenons une situation fictive.
Une responsable support configure un agent pour résumer les demandes clients. Pour aller vite, elle lui donne accès à son propre compte, qui dispose de droits d’administration.
Quelques mois plus tard, elle change de poste. L’agent continue de fonctionner, mais personne ne sait précisément :
Le problème vient d’un accès dont la justification, le responsable et le cycle de vie ont été perdus.
Trois situations méritent particulièrement votre attention :
Les accès sans responsable. Personne ne peut confirmer leur utilité ni décider de leur suppression.
Les permissions trop larges. Une automatisation conserve des droits d’administration alors qu’un accès en lecture suffirait.
Les accès partagés. Plusieurs agents utilisent le même compte ou la même clé, ce qui complique l’attribution des actions et la révocation ciblée.
Commencez par un périmètre limité : les agents et automatisations qui accèdent à votre CRM, votre support client, vos documents internes ou vos outils financiers.
Pour chaque automatisation, posez une question simple :
Comment se connecte-t-elle aux applications dont elle a besoin ?
Examinez les comptes présents dans les SaaS, puis complétez avec :
Un participant à notre discussion sur r/ciso décrit cette approche : croiser l’IdP, l’IAM cloud et le coffre de secrets pour construire l’inventaire. Ce retour d’expérience fournit une piste concrète, sans garantir une couverture exhaustive. Voir son témoignage.
Avec MIA : connectez les applications SaaS de votre périmètre pour centraliser les accès remontés par leurs connecteurs. Pour une application sans intégration API, vous pouvez créer une fiche manuelle. La profondeur de l’inventaire dépend des informations synchronisées par chaque connecteur. Découvrir l’inventaire des accès MIA.
Un agent peut fonctionner seul. Sa responsabilité doit rester attribuée à une personne.
Pour chaque agent ou compte technique, identifiez un responsable capable de :
Un nom d’équipe peut compléter cette information, mais prévoyez aussi un interlocuteur précis.
Votre registre doit au minimum contenir :
Ce registre relie l’usage métier aux accès techniques. Il complète l’inventaire lorsque les outils ne remontent pas encore toutes ces relations.
Un agent qui résume des tickets a-t-il besoin de supprimer des utilisateurs ? Une automatisation qui publie une notification doit-elle lire tous les canaux de discussion ?
C’est le principe du moindre privilège : accorder uniquement les permissions nécessaires.
En pratique :
Avec MIA : utilisez l’inventaire pour repérer les comptes à examiner, puis faites confirmer leurs besoins par les responsables concernés. Les permissions techniques fines doivent être vérifiées dans le service source lorsqu’elles ne sont pas exposées par le connecteur.
Un accès justifié au lancement d’un agent peut devenir inutile quelques mois plus tard.
Lors d’une revue, vérifiez :
Adaptez la fréquence au risque. Une expérimentation temporaire ou un accès sensible mérite un contrôle plus rapproché qu’une automatisation stable disposant de droits limités.
Avec MIA Pro : vous pouvez lancer une revue des accès d’une application, la transmettre à un responsable et exporter les résultats. Des rappels peuvent être définis tous les trois, six ou douze mois. La revue produit une décision documentée ; les accès signalés doivent ensuite être fermés. Voir le fonctionnement des revues d’accès.
Supprimer une clé sans connaître ses utilisateurs peut interrompre plusieurs automatisations.
Avant de retirer un accès, vérifiez :
Prévoyez également le départ du responsable humain : faut-il arrêter l’agent, transférer sa responsabilité ou remplacer ses moyens d’accès ?
Avec MIA : la fermeture d’un compte applicatif peut être exécutée à distance lorsque le connecteur le permet, ou planifiée à une date donnée. La révocation d’une clé API, d’un consentement OAuth ou d’une session doit être traitée dans le système concerné si elle n’est pas couverte par cette action. Comprendre l’ouverture et la fermeture des accès.
La gestion des identités non humaines repose sur plusieurs sources : les applications, le fournisseur d’identité, l’environnement cloud, le coffre de secrets et les outils d’exécution des agents.
MIA apporte un cadre de gouvernance aux accès applicatifs qu’il prend en charge :
Le journal de MIA conserve les événements et décisions de gestion des accès. Il aide à comprendre leur historique. L’analyse détaillée de ce qu’un agent a exécuté nécessite aussi les journaux de ses outils et plateformes. Découvrir la traçabilité des accès.
L’objectif : des accès identifiés, des décisions attribuées et des retraits vérifiés.
Choisissez trois applications et listez leurs automatisations connues. Commencez par celles qui donnent accès aux données les plus sensibles.
Connectez les applications disponibles dans MIA et examinez les comptes remontés. Complétez votre recherche dans l’IdP, les plateformes d’automatisation et le coffre de secrets.
Associez chaque automatisation à ses accès et à un responsable humain. Documentez les comptes partagés et les dépendances connues.
Vérifiez les besoins avec les responsables et lancez une revue des accès concernés. Identifiez ce qui doit être conservé, réduit ou retiré.
Effectuez les retraits, contrôlez leur prise en compte et fixez la prochaine revue.
Conservez également la liste des zones encore inconnues : clés non inventoriées, comptes partagés ou agents utilisant des sessions humaines. Elle vous permettra de prioriser la suite.
Découvrez MIA pour centraliser et organiser la gouvernance de vos accès SaaS.
Un agent IA est un logiciel qui réalise des tâches. Une identité non humaine représente un logiciel auprès d’un système. Un agent peut utiliser une identité dédiée, plusieurs comptes techniques ou des accès délégués par un utilisateur.
Oui. Un compte de service est une forme d’identité non humaine utilisée par un logiciel ou une automatisation. Il doit avoir un usage documenté, un responsable et des permissions adaptées.
Le SSO contribue à l’authentification, mais un inventaire doit aussi examiner les comptes techniques, clés API et autorisations déléguées. Vérifiez la couverture réelle de votre fournisseur d’identité et de vos applications.
La couverture dépend des plateformes et des sources disponibles. Un agent doté d’une identité dédiée est plus facile à identifier qu’un agent utilisant une session humaine. Croiser plusieurs sources et documenter les limites de détection reste nécessaire.
MIA peut contribuer à leur gouvernance à travers l’inventaire des comptes remontés par ses connecteurs, les revues d’accès, les fermetures prises en charge et la traçabilité. La découverte d’un type précis de compte technique, d’agent ou de clé doit être vérifiée connecteur par connecteur.
