Permissions d’un agent IA : une checklist avant de connecter vos outils

Un agent peut vous aider à lire des documents sans avoir besoin de les modifier. Il peut préparer un message sans être autorisé à l’envoyer. Pourtant, une connexion proposée en quelques clics peut réunir plusieurs capacités sous une même autorisation. Avant de l’activer, distinguez ce dont le projet a besoin de ce que l’application demande.

La bonne question n’est pas seulement « cet agent est-il sécurisé ? », mais « peut-on vérifier les limites de son accès et l’arrêter sans ambiguïté ? ». Voici une méthode opérationnelle pour préparer un pilote. Elle ne constitue ni un audit, ni une attestation de conformité, ni un conseil juridique.

1. Décrire la tâche avant de choisir les permissions

Dans un exemple fictif, une association veut préparer une synthèse hebdomadaire à partir de comptes rendus. Le besoin peut être satisfait avec un dossier de documents approuvés et une sortie enregistrée dans un espace de brouillons. Il n’impose pas d’ouvrir la messagerie, les fichiers financiers ou tous les espaces partagés.

Écrivez une fiche courte :

• Objectif : produire une synthèse de cinq points, avec référence aux documents utilisés.
• Entrées autorisées : comptes rendus validés dans un dossier déterminé.
• Sortie : brouillon dans un dossier distinct, sans envoi automatique.
• Actions interdites : modifier les sources, partager un document ou consulter d’autres dossiers.
• Responsable : une personne identifiée qui valide les résultats et peut suspendre le service.

Cette fiche sert de référence lors de la connexion et du test. Si une permission ne correspond à aucune ligne, demandez une explication. Une fonctionnalité éventuellement utile dans six mois n’est pas une raison suffisante pour ouvrir l’accès aujourd’hui.

2. Examiner les droits réellement accordés

Lisez le nom du compte connecté et les capacités demandées. Un compte administrateur et un compte limité ne donnent pas le même périmètre. Vérifiez aussi les accès hérités des groupes et des dossiers parents : un dossier de test peut sembler isolé tout en contenant des raccourcis vers d’autres ressources.

Séparez quatre catégories : lire, créer, modifier et transmettre. Ajoutez la suppression si elle existe. Pour chacune, notez les ressources concernées et les utilisateurs au nom desquels l’action peut se produire. Une simple consigne « ne touche pas aux fichiers » ne remplace pas une restriction technique en lecture seule.

Si l’outil ne permet pas la granularité souhaitée, cherchez un périmètre plus étroit : copie de documents approuvés, compte dédié ou environnement de test. Ces choix ont aussi des coûts de maintenance. Ne créez pas une copie que personne ne mettra à jour ; attribuez-lui un responsable et une fréquence de révision.

3. Cartographier les copies, pas seulement les connexions

Dessinez le parcours d’un document en quelques lignes : outil d’origine, connecteur, application, service de modèle, éventuel index de recherche, journaux et export final. Pour chaque étape, demandez quelles informations quittent la source et ce qui reste après le traitement.

Votre inventaire peut tenir dans une fiche par service :

• Données reçues : document complet, extrait, métadonnées ou identifiant.
• Finalité : produire la réponse, faciliter la recherche ou diagnostiquer une erreur.
• Conservation : durée annoncée et méthode pour la vérifier.
• Suppression : commande disponible, interlocuteur et confirmation attendue.
• Accès : personnes et systèmes susceptibles de consulter les données conservées.

Ne supposez pas qu’un document supprimé de son dossier disparaît immédiatement d’un index ou d’une sauvegarde. Demandez le comportement applicable. Les réponses inconnues doivent rester marquées « à vérifier », et non être remplacées par une hypothèse rassurante.

Pour les données personnelles, faites examiner le contexte par les personnes compétentes. La ressource française de la CNIL sur le déploiement de l’IA générative est un repère à consulter pour cette revue, sans remplacer l’analyse de votre situation.

4. Séparer permission technique et approbation d’une action

Un outil peut avoir la capacité technique d’envoyer un message tout en exigeant une validation avant chaque envoi. Ce sont deux contrôles différents. Une autorisation de connexion ne devrait pas être interprétée comme une approbation de toutes les actions futures.

Définissez ce qui peut se faire seul, ce qui doit être présenté en brouillon et ce qui exige une confirmation juste avant exécution. Pour une transmission, l’écran de validation devrait montrer le destinataire exact, le contenu ou le document, ainsi que le niveau d’accès accordé. « Voulez-vous continuer ? » ne suffit pas à contrôler un partage.

Testez aussi les changements après validation. Si l’agent remplace le destinataire ou ajoute une pièce jointe, l’accord initial ne couvre plus exactement l’opération présentée. Prévoyez une nouvelle vérification plutôt qu’une approbation réutilisable sans limite.

5. Faire un test négatif avant le pilote

Utilisez uniquement des données fictives ou approuvées. Créez un document autorisé et un document hors périmètre, chacun contenant un marqueur distinct et non sensible. Demandez à l’agent de résumer le premier, puis de chercher le marqueur du second.

Le succès attendu n’est pas seulement une bonne synthèse : c’est aussi l’impossibilité de récupérer le contenu interdit. Complétez par trois essais : tentative de modification d’une source en lecture seule, tentative d’envoi sans validation et demande ambiguë sur le destinataire. Conservez la date, le compte, le résultat observé et la décision de poursuivre ou de corriger.

Un refus exprimé dans la conversation ne prouve pas à lui seul que le contrôle technique fonctionne. Lorsque c’est possible, vérifiez les événements dans le service connecté. Une opération rejetée doit apparaître comme rejetée, et non comme une action silencieusement réalisée malgré le message rassurant.

6. Répéter l’arrêt et la révocation

Préparez la procédure avant l’incident : qui arrête les tâches planifiées, qui retire l’autorisation dans le service d’origine et qui vérifie les opérations déjà lancées ? Pause du traitement, déconnexion de l’interface et révocation côté fournisseur peuvent être des étapes distinctes.

Pendant le test, suspendre les nouvelles tâches évite d’en créer pendant la coupure. Révoquez ensuite la connexion concernée, puis tentez une lecture nouvelle sur un document de test. Distinguez une réponse issue d’une copie déjà conservée d’un nouvel accès à la source : la première peut rester possible alors que le second est correctement bloqué.

Vérifiez les tâches en attente et les traitements en cours. Notez ce qui a été terminé avant la révocation, annulé après elle ou reste incertain. N’affirmez pas que tout est arrêté tant qu’un traitement externe n’a pas fourni un état vérifiable.

7. Organiser la sortie et la revue des accès

Après révocation, traitez séparément les copies : index, historiques, fichiers exportés et journaux. Identifiez celles qui doivent être supprimées, celles conservées pour une raison établie et celles dont la suppression reste à confirmer. Documentez les limites connues, notamment pour les sauvegardes.

Refaites la revue lorsqu’une personne quitte le projet, qu’un outil change ou qu’une nouvelle fonction demande davantage de droits. Pour le pilote, choisissez une date de réexamen et un responsable. La checklist devient ainsi un contrôle vivant, plutôt qu’une formalité effectuée une seule fois au moment de connecter l’agent.

8. Lire une connexion MCP comme une chaîne d’accès

MCP ne constitue pas une permission unique qui rendrait toutes les connexions équivalentes. Il faut regarder l’application IA, le serveur MCP et les services auxquels ce serveur accède. Un contrôle peut exister à un niveau et manquer au suivant.

Dans notre exemple, un outil intitulé « rechercher des comptes rendus » peut interroger un stockage plus large que le dossier autorisé. Demandez où le filtrage est appliqué : dans la consigne du modèle, dans l’outil, dans le serveur ou dans les droits du service d’origine. La première option seule ne crée pas une frontière d’accès fiable.

La documentation de sécurité MCP traite notamment la validation des autorisations, la réduction des portées et les risques liés aux serveurs locaux. Elle s’adresse aux personnes qui implémentent ou évaluent ces systèmes ; utiliser le protocole ne vaut pas certification de leur configuration. Source : bonnes pratiques de sécurité MCP.

Pour un serveur distant, identifiez l’opérateur et les services qui reçoivent les données. Pour un serveur local, vérifiez le programme lancé et les ressources auxquelles son processus peut accéder. « Local » ne signifie pas automatiquement « limité au seul fichier que j’ai sélectionné ». Une application peut avoir des droits plus larges que l’usage prévu.

Dans la fiche de connexion, consignez donc le nom vérifié du service, l’application cliente, le compte utilisé, les outils exposés et la personne qui peut retirer l’autorisation. N’y recopiez pas les secrets : documentez leur emplacement de gestion, pas leur valeur.

9. Faire correspondre tâches, outils et droits

Une matrice courte aide à repérer les permissions sans justification. Pour le pilote de synthèse, elle peut prendre cette forme :

Tâche	Ressource nécessaire	Opération attendue	Pouvoir non nécessaire
Retrouver les comptes rendus	Dossier approuvé	Recherche et lecture	Lecture de tous les espaces
Vérifier une référence	Document source	Lecture du passage	Modification de la source
Produire la synthèse	Dossier de brouillons	Création d’un fichier	Partage public ou envoi
Corriger le brouillon	Brouillon identifié	Mise à jour ciblée	Suppression d’autres fichiers

Pour chaque ligne, associez une preuve : permission affichée, restriction vérifiée et résultat d’un essai. Un outil absent de la matrice doit être désactivé pour ce pilote si cela est possible, ou faire l’objet d’une décision explicite.

La matrice doit aussi distinguer les personnes. Un responsable qui peut lire tous les dossiers ne devrait pas transmettre cette capacité à chaque utilisateur de l’agent. Testez le même outil avec deux profils de droits différents. Le résultat attendu dépend de l’identité autorisée, pas seulement du fait que le connecteur fonctionne.

Si une capacité trop large est techniquement indissociable, ne la masquez pas par une formulation rassurante. Décrivez l’écart, les mesures de réduction et la décision prise : périmètre limité, copie contrôlée ou report de la fonction. Ce relevé est plus utile qu’une case « sécurité validée » sans explication.

10. Vérifier ce qui est réellement présenté avant une action

Une confirmation humaine a de la valeur si elle montre l’opération qui sera exécutée. Pour le partage d’une synthèse, la personne doit voir le fichier exact, le destinataire et le niveau d’accès. Le nom d’un groupe sans liste ou description claire peut rendre la portée difficile à comprendre.

Préparez trois essais de validation sur des données fictives : une opération normale, une opération dont le destinataire change et une opération dont le document change après affichage. Dans les deux derniers cas, le système doit signaler que l’action n’est plus celle qui avait été présentée.

Le résumé peut omettre un détail important : une pièce jointe supplémentaire, un partage en modification au lieu de lecture ou une adresse ressemblante. Demandez une présentation orientée vers ces différences plutôt qu’une longue justification du modèle.

Prévoyez aussi une réponse explicite au refus. Si la personne annule, l’agent ne doit pas rechercher un autre canal pour obtenir le même effet. Le test consiste à vérifier l’absence d’action dans le service cible, puis à demander un état de la tâche. « Annulé » doit correspondre à une opération non réalisée, et non à une simple fermeture de fenêtre.

11. Garder des traces utiles sans recopier tous les contenus

Les journaux servent à comprendre un incident : quelle demande, quel outil, quel compte, quelle ressource et quel résultat. Ils ne devraient pas devenir automatiquement une deuxième archive complète de documents privés.

Pour une création de synthèse, un relevé peut contenir l’identifiant du dossier, les documents de référence, l’outil appelé, l’heure et le statut. Le texte intégral n’est pas toujours nécessaire pour savoir qu’une écriture a échoué. Si vous devez conserver un extrait pour diagnostiquer la qualité, définissez qui peut le consulter et pendant combien de temps selon votre situation.

Vérifiez les erreurs affichées. Un message technique peut révéler un nom de fichier, une adresse ou un détail de configuration à une personne qui ne devrait pas les voir. L’utilisateur a besoin de comprendre la prochaine étape, pas forcément de recevoir toute la trace technique.

En cas d’incident, séparez les faits établis des hypothèses. « L’outil a reçu une réponse de refus » est un fait vérifiable ; « aucune donnée n’a jamais quitté le système » demande une autre preuve. Votre compte rendu doit indiquer ce qui a été contrôlé, ce qui reste inconnu et les opérations suspendues en attendant.

12. Préparer une fiche de sortie avant le départ d’une personne

Une connexion peut dépendre du compte de la personne qui a construit le pilote. Son départ ou un changement de rôle peut alors interrompre le service, ou laisser un accès sans responsable. Identifiez cette dépendance pendant la mise en place.

La fiche de sortie doit indiquer les tâches planifiées à suspendre, les connexions à révoquer, les droits de dossiers à retirer, les copies à examiner et les livrables à transmettre au nouveau responsable. Associez chaque opération à une personne capable de la réaliser dans le service concerné.

Ne confondez pas transfert du travail et transfert des identifiants. Il est préférable d’utiliser les mécanismes de gestion de comptes et d’accès prévus par les services plutôt que de partager un mot de passe ou de recopier une clé dans une conversation. Faites effectuer les changements sensibles par les personnes habilitées, avec les validations nécessaires.

Après la sortie, rejouez un test autorisé sur un document fictif nouvellement créé. Il aide à distinguer un ancien extrait encore disponible d’un accès toujours actif à la source. Conservez ensuite le résultat de la revue et la liste des points qui demandent une confirmation externe, comme le traitement des sauvegardes.

Cette dernière étape rend la checklist durable : l’accès a un objectif, un propriétaire, un périmètre et une fin vérifiable. Elle peut être reprise lors d’un nouveau projet sans supposer que les autorisations du précédent sont toujours appropriées.

Questions fréquentes

Faut-il accepter toutes les permissions demandées ?

Non. Rattachez chaque permission à une tâche précise. Si le périmètre ne peut pas être réduit, adaptez le pilote ou choisissez une autre solution.

Retirer une connexion efface-t-il toutes les données déjà copiées ?

Pas nécessairement. Révocation et suppression des copies sont deux vérifications distinctes, à réaliser auprès de chaque service concerné.

Une confirmation humaine suffit-elle à sécuriser un agent ?

Non. Elle complète des droits limités, des tests techniques et une procédure d’arrêt. Elle doit présenter l’opération exacte pour être utile.