Identité, permissions et audit des agents IA : relier l’action à son auteur

Commencer par une fiche d’action lisible

Pour relier l’identité, les permissions et l’audit des agents IA, partez d’une action précise. Qui l’a demandée ? Quelle identité a accédé à la ressource ? Avec quel droit ? Quelle décision autorisait cette opération ? Quel résultat a réellement été constaté ? Ces questions doivent pouvoir être suivies sans exposer un secret d’accès ni recopier tout le contenu traité.

Exemple illustratif, et non journal produit : Nadia demande à un agent de lire le document « Projet Alpha » et de proposer une réponse, sans l’envoyer. La fiche suivante est une méthode manuelle de revue ; les personnes et identifiants sont fictifs.

Les cinq champs regroupent plusieurs détails sans les confondre. L’initiatrice peut demander la tâche sans posséder le droit de l’approuver. L’identité agissante peut être un compte technique distinct. La personne habilitée à autoriser l’accès doit être nommée selon les responsabilités réelles de l’organisation.

Découpez également les opérations : document consulté, proposition produite et message envoyé sont trois résultats différents. Dans cet exemple, la réussite attendue s’arrête au texte proposé. Notez où celui-ci est consultable, sans affirmer qu’un brouillon a été enregistré dans une boîte aux lettres si vous ne l’avez pas vérifié.

Une clé authentifie une connexion ; elle ne constitue pas à elle seule un système de gouvernance des identités. Conservez une référence à l’accès et aux preuves, jamais la clé ou le jeton. Si votre identifiant manuel n’est pas propagé par les systèmes, indiquez qu’il sert seulement au rapprochement effectué par le réviseur.

Définir l’identité et les droits en entreprise

La documentation Microsoft Entra sur l’autorisation des identités d’agent distingue deux modes. Avec une permission déléguée, l’agent agit au nom d’un utilisateur dans le périmètre accordé. Avec une permission d’application, l’application agit selon des droits accordés par un administrateur. Ces mécanismes sont propres à cet environnement ; ils ne décrivent pas automatiquement tous les agents IA.

Le choix doit correspondre au responsable de l’action et à la ressource visée. Pour lire le document de l’exemple, identifiez l’emplacement et accordez seulement les droits nécessaires à sa lecture. Une proposition de réponse ne justifie pas, à elle seule, un droit d’envoi ou de modification de tous les documents.

Les rôles sur des ressources Azure, les rôles d’annuaire et les permissions Microsoft Graph ne gouvernent pas les mêmes objets. Vérifiez le contrôle qui protège réellement la ressource. Entra impose également des restrictions sur les rôles et permissions fortement privilégiés pour les identités d’agent ; un compte d’administration étendu n’est pas un raccourci approprié vers une tâche limitée.

Distinguez l’octroi technique de l’accès et l’approbation métier. Un consentement OAuth autorise un périmètre de connexion ; il ne prouve pas que chaque futur envoi a été approuvé. Dans la fiche, indiquez donc séparément le droit disponible et la décision applicable à l’opération précise.

Identifiez le propriétaire ou responsable de l’agent, la justification de l’accès et sa prochaine revue. Si votre politique prévoit une expiration, relevez-la ; n’inventez pas une durée obligatoire identique pour toutes les ressources. Un départ, une fin de projet ou le retrait d’une application doivent déclencher une vérification des droits encore actifs.

Pour les choix plus larges d’hébergement et d’accès aux données, Sécurité des agents IA en entreprise : pourquoi l’exécution locale change le risque traite l’environnement d’exécution séparément de cette fiche d’action.

Réunir les preuves d’identité et d’action

Les journaux Microsoft Entra consacrés aux agents permettent de rechercher des événements liés aux identités d’agent. Les champs agentType et blueprintId aident à rapprocher l’agent et son modèle de référence. Les activités de ce modèle apparaissent comme événements d’application, celles des identités d’agent comme événements de principal de service, et celles des comptes utilisateurs d’agent comme événements d’utilisateur.

Une personne disposant au minimum du rôle Lecteur de rapports peut consulter Microsoft Entra ID > Surveillance et intégrité > Journaux de connexion, puis utiliser les filtres d’agent. Les requêtes Microsoft Graph décrites pour ces journaux utilisent /beta ; tenez compte de ce statut lors de leur emploi.

Une connexion réussie éclaire l’accès, pas chaque opération métier ultérieure. Pour REQ-042, cherchez une correspondance entre l’identité agissante, la ressource ciblée et les heures des événements. Rapprochez ensuite ces éléments de la preuve fournie par l’application : lecture du document prévu, proposition consultable ou refus explicite.

Si les identifiants ne correspondent pas directement, documentez les critères de rapprochement et leur incertitude. Une proximité temporelle ne suffit pas toujours à attribuer une action. Une preuve cible absente ne signifie pas automatiquement réussite ou échec : gardez l’état inconnu jusqu’à vérification.

Limitez l’accès aux traces. Des références aux objets et aux décisions peuvent suffire à la revue ; recopier les documents ou messages entiers peut exposer davantage de données que nécessaire.

Documenter une réussite, un refus ou un résultat incertain

Les quatre fiches ci-dessous sont des exemples proposés, pas des opérations réalisées. Pour chaque tentative, séparez le périmètre autorisé, la décision, l’exécution et le constat. Un même modèle de fiche doit pouvoir représenter autre chose qu’un succès.

Lecture réussie

Demande : REQ-051, consulter un document déterminé. Identité et accès : agent de lecture, connexion limitée à la ressource. Décision : lecture autorisée selon la politique applicable. Tentative : ACT-051-L. Constat : la preuve cible correspond au bon document et le résultat est disponible pour revue. L’état « lecture vérifiée » ne couvre ni modification ni envoi.

Écriture en attente d’approbation

Demande : REQ-052, créer un événement avec des paramètres précis. Périmètre : écriture dans le calendrier sélectionné. Décision : approbation requise mais non encore donnée. Tentative : création non lancée. Constat : paramètres préparés, attente de décision. La fiche doit distinguer cette préparation d’un événement créé ; une autorisation technique existante ne remplace pas l’approbation attendue.

Action refusée

Demande : REQ-053, modifier un objet. Décision : refus explicite. Tentative : bloquée avant écriture, si c’est bien ce que les preuves indiquent. Constat : inspection de l’objet, état inchangé. Notez l’heure du refus et celle du contrôle. Si vous ne pouvez pas inspecter la destination, écrivez « refus constaté, état cible non vérifié », plutôt que d’affirmer l’absence de modification.

Écriture partielle ou issue incertaine

Demande : REQ-054, créer puis compléter un objet. Décision : opération autorisée. Tentative : création lancée, puis interruption sans résultat final exploitable. Constat : issue inconnue, ou objet retrouvé avec des détails incomplets. Recherchez-le dans la destination avant toute nouvelle création. S’il existe, vérifiez ce qui manque et reprenez seulement l’étape concernée ; s’il reste introuvable sans preuve suffisante, conservez l’incertitude.

Pour une reprise, ajoutez une tentative distincte reliée à la demande initiale. Ne remplacez pas le premier état par « terminé » : conservez la chronologie qui explique pourquoi la nouvelle opération était nécessaire et comment le doublon a été évité.

Poser les mêmes questions sur Android

Chez FoneClaw, cette fiche peut servir de liste de vérification manuelle pour une tâche téléphone. Le modèle sélectionné interprète la demande ; nos outils activés réalisent les opérations prises en charge. La méthode de revue proposée ici ne suppose pas une intégration Microsoft Entra ni un export natif d’audit immuable.

Pour une demande de batterie, device_battery_status renvoie un état compact de batterie et d’économie d’énergie, sans changer les réglages. Notez le demandeur, la configuration du modèle, l’outil activé, la politique effective et la valeur réellement renvoyée. Son approbation par défaut est automatique, mais le mode global et les règles propres à l’outil déterminent le comportement applicable.

Créer un événement avec calendar_create_event produit un effet externe. Dans un exemple proposé, vous souhaitez « Revue Alpha », le 12 novembre 2026 de 10 h à 11 h, dans le fuseau du téléphone, avec un rappel dix minutes avant. Confirmez le calendrier cible et les paramètres ; si l’heure de fin ou le rappel manque, demandez la précision avant l’appel de création.

Vérifiez la décision d’approbation selon la configuration effective. Après création, relevez les valeurs actualStart et actualEnd renvoyées par l’outil, puis inspectez l’événement dans le calendrier : titre, destination, début, fin et rappel. Une réponse disant « créé » ne dispense pas de ce contrôle. Pour une journée entière, le début et la fin exclusive obéissent à une autre représentation ; ne réutilisez pas sans vérification les paramètres d’un rendez-vous horaire.

Les fonctionnalités FoneClaw présentent ces actions et leurs conditions. Permissions Android, activation des outils, politique d’approbation et identifiants du fournisseur restent distincts. Si un modèle en ligne reçoit le contexte, examinez aussi sa destination et son traitement : une fiche locale ne prouve pas que tout reste sur le téléphone.

Pour une compétence ajoutée, Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action détaille le contrôle de ses accès.

Vérifier les refus et retirer les accès inutiles

Pour un contrôle proposé sans écriture, désactivez temporairement l’outil de lecture de batterie, puis demandez cette même lecture. L’observation attendue est l’absence d’exécution de l’outil désactivé ; aucune ancienne valeur ne doit être présentée comme une mesure fraîche obtenue pendant cet essai.

Notez le réglage avant le test, la demande, le refus ou blocage observé et les éventuels éléments manquants. Si une valeur apparaît, vérifiez sa provenance au lieu de conclure immédiatement que le contrôle a été contourné. Réactivez ensuite l’outil seulement si la tâche le justifie, puis effectuez une nouvelle lecture clairement distincte. Cet essai vérifie l’activation de l’outil, pas tous les contrôles Android ou fournisseur.

Retirer un accès vise les opérations futures ; cela n’efface pas automatiquement un événement déjà créé ni un message déjà envoyé. Pour une écriture incertaine, consultez la destination avant de réessayer. Si un objet doit être corrigé ou supprimé, traitez cette opération séparément, avec son périmètre et sa décision propres.

Lors de la revue, retirez les identités, connexions, permissions Android et outils devenus inutiles. Vérifiez les dérogations d’approbation encore actives et remplacez un secret exposé par le parcours du fournisseur concerné. Relevez ce qui a été retiré et ce qui reste nécessaire, sans inclure les nouveaux secrets dans la fiche.

Contrôlez enfin qui peut consulter les preuves et leur durée de conservation selon votre politique. Une conversation téléphone peut aider à comprendre une tâche, mais ne constitue pas à elle seule une trace inviolable. Une mémoire d’agent peut aussi influer sur une demande ultérieure : Mémoire d’agent IA empoisonnée sur téléphone traite ce risque distinctement.