Les agents IA internes deviennent utiles quand ils peuvent lire le contexte de travail et agir. Cela les rend aussi sensibles du point de vue sécurité : un agent connecté à la messagerie, aux documents, aux calendriers ou au code source est une identité logicielle qui opère dans les systèmes de l’entreprise.
Le contrôle pratique est le moindre privilège pour les agents IA. Donnez à chaque agent une identité étroitement définie, uniquement les ressources nécessaires à une tâche, des chemins d’écriture limités, des points d’approbation pour les actions à conséquence, et des preuves d’audit exploitables en revue. Ne modélisez pas un agent comme un employé pleinement digne de confiance.
Ce guide propose une méthode d’implémentation pour les équipes qui connectent des agents à Microsoft 365, Google Workspace ou GitHub.
Définir la tâche avant de choisir les permissions
« Connecter l’agent à notre espace de travail » n’est pas une exigence de permission exploitable. Partez d’une tâche bornée et décrivez-la en termes opérationnels.
Par exemple, un agent qui résume les notes de passation du support à partir d’un dossier partagé a une entrée et une sortie définies. Il n’a pas besoin par nature d’accéder à tous les documents, boîtes mail, calendriers ou dépôts. Un agent qui prépare des pull requests de mise à jour de dépendances pour des dépôts sélectionnés peut avoir besoin d’un accès aux dépôts et d’un chemin de proposition, mais pas de l’autorité de fusionner sur une branche protégée.
Documentez ces questions avant de provisionner des identifiants :
- Quel événement déclenche le travail ?
- Quels systèmes et ressources nommées l’agent peut-il lire ?
- Quelle sortie peut-il créer ou modifier ?
- Quelles actions nécessitent une approbation humaine ?
- Quels enregistrements doivent être conservés pour la revue ?
Les permissions doivent traduire cette limite de tâche. Elles ne doivent pas refléter un niveau de confiance général envers un modèle, un fournisseur ou un prompt.
Utiliser un modèle de permissions en couches
Une simple liste de scopes OAuth ne suffit pas. Combinez identité, périmètre de ressources, limites d’action, contrôles de workflow et preuves.
Utiliser une identité dédiée
Créez une identité d’application, un compte de service ou une GitHub App pour un rôle d’agent spécifique. Ne réutilisez pas un compte humain, un compte administrateur, ou une identité partagée pour des automatisations sans rapport. Une identité dédiée rend la revue et la révocation des permissions spécifiques à cet agent.
Microsoft recommande de ne demander que les permissions Microsoft Graph dont l’application a réellement besoin. Ses recommandations privilégient aussi les approches déléguées ou spécifiques à une ressource lorsque c’est possible, car des permissions d’application larges peuvent accéder aux données sans utilisateur connecté. Le guide des permissions Microsoft Graph est un bon point de départ pour évaluer si un accès applicatif à l’échelle du tenant est réellement nécessaire.
Pour Google Workspace, le partage direct de fichiers spécifiques avec un compte de service crée un périmètre de ressources plus étroit que la délégation à l’échelle du domaine. Google documente la délégation à l’échelle du domaine comme une approche nécessitant l’autorisation par un administrateur des scopes OAuth pour accéder aux données des utilisateurs. Le guide des identifiants Google Workspace détaille cette distinction.
Les GitHub Apps démarrent sans aucune permission et peuvent être installées sur des dépôts sélectionnés. GitHub recommande de n’accorder que les permissions dont une application a besoin. Le guide des permissions GitHub fournit le modèle de configuration correspondant.
Limiter à la fois le périmètre API et le périmètre des ressources
Une permission qui semble étroite peut tout de même couvrir un ensemble de données large. L’accès aux fichiers, par exemple, peut concerner un seul dossier partagé, de nombreux drives partagés, ou un domaine entier selon la configuration.
Utilisez des limites de ressources explicites en complément des scopes API : dépôts sélectionnés, dossiers approuvés, calendriers nommés, et autres destinations définies. Conservez ces liaisons dans une configuration qui peut être revue au regard de l’objectif de l’agent. Traitez tout ajout à la liste blanche comme un changement d’accès, pas comme un simple changement de prompt.
Les administrateurs Google Workspace peuvent contrôler l’accès des applications tierces par client OAuth et par scope, y compris des contrôles pour les scopes Workspace à haut risque. Les contrôles d’accès aux applications Google Workspace offrent un point de gouvernance pour autoriser, restreindre ou bloquer des intégrations. Les administrateurs Microsoft Entra peuvent restreindre ou désactiver le consentement utilisateur, y compris des politiques qui n’autorisent le consentement que pour des éditeurs vérifiés. Les contrôles de consentement utilisateur Microsoft Entra peuvent établir un point d’approbation avant qu’une application ne reçoive un accès organisationnel.
Séparer la lecture de l’écriture
L’accès en lecture et l’accès en écriture doivent être des capacités séparées. Un agent de recherche peut collecter et résumer de l’information. Un agent de proposition peut créer un brouillon, une issue, un commentaire ou une pull request. L’envoi, la publication, la suppression, la fusion, le changement de permissions ou les achats doivent suivre un chemin plus restrictif.
| Action | Posture par défaut | Contrôle |
|---|---|---|
| Rechercher dans des documents ou dépôts approuvés | Autoriser avec un accès en lecture délimité | Liste blanche de ressources et contexte de tâche conservé |
| Créer un brouillon, une issue, un commentaire ou une pull request | Autoriser dans une destination bornée | Dossier de brouillons, file d’issues ou branche de fonctionnalité |
| Envoyer un message, planifier un événement ou publier du contenu | Nécessite une approbation | Revue des destinataires, du contenu et du moment |
| Fusionner du code, supprimer du contenu, changer des permissions ou dépenser de l’argent | Non autorisé directement par défaut | Exécution détenue par un humain et vérifications de politique |
Cette structure limite l’effet d’une action incorrecte ou non désirée. Elle crée aussi une frontière révisable entre la recommandation d’un agent et un changement système à conséquence.
Placer les approbations aux frontières de conséquence
L’approbation doit intervenir juste avant l’action à impact réel, pas seulement au moment de l’installation d’une intégration. Une décision de consentement ponctuelle n’établit pas que chaque futur message, événement de calendrier ou changement de code sera approprié.
Faites en sorte que l’agent crée un paquet d’action révisable qui indique l’action prévue, les ressources concernées, le contenu proposé, la raison et une date d’expiration. Le relecteur doit pouvoir approuver, rejeter ou modifier l’action proposée. Un rejet doit arrêter l’action plutôt que de la relancer silencieusement avec une formulation différente.
Pour les workflows de code source, les branches protégées constituent un point d’application externe à l’agent. Les règles de branche GitHub peuvent exiger des revues de pull request, des vérifications de statut, des commits signés, le succès du déploiement, et des restrictions sur qui peut pousser ou contourner les protections. La documentation GitHub sur les branches protégées décrit ces contrôles. Autorisez un agent à proposer un changement via une branche et une pull request tout en préservant le processus de branche protégée pour la fusion.
Rendre l’activité reconstituable
Faites fonctionner les agents avec à la fois des événements d’audit de plateforme et des enregistrements applicatifs. Les journaux de plateforme montrent ce qu’une identité a fait. Les enregistrements de l’agent doivent capturer l’identifiant de tâche, la décision de politique, les ressources considérées, les approbations reçues, les outils invoqués et le résultat.
Les journaux d’activité Microsoft Graph fournissent une piste d’audit des requêtes HTTP du tenant et peuvent être routés vers Log Analytics, Storage ou Event Hubs pour la conservation et le suivi. Microsoft signale aussi une couverture pour les requêtes des clients IA utilisant son serveur MCP d’entreprise. La documentation des journaux d’activité Microsoft Graph explique les destinations disponibles.
Les journaux d’audit d’organisation GitHub enregistrent qui a effectué une action, ce qui s’est passé, quand, et le contexte de dépôt pertinent. GitHub fournit aussi des API de journal d’audit et des webhooks qui permettent une conservation externe et un suivi événementiel. Le guide du journal d’audit GitHub décrit ces parcours de revue.
Gardez les journaux applicatifs proportionnés. Évitez de copier des prompts, documents ou corps de mail entiers dans un stockage de logs séparé par défaut. Journalisez les identifiants, les décisions de politique et le minimum de preuves nécessaires à la revue, puis appliquez les exigences de conservation de l’organisation.
Tester dans des destinations contraintes
Avant qu’un agent ne puisse affecter des ressources de production, donnez-lui des destinations hors production pour ses actions externes. Par exemple une boîte mail de test, un calendrier isolé, un dossier approuvé, un dépôt non-production, ou un espace de branches jetables.
Utilisez le bac à sable pour vérifier que l’agent respecte les listes blanches, produit le paquet de revue requis, enregistre l’activité, et s’arrête quand la politique refuse une action. Testez des tâches normales ainsi que du contenu non fiable ou ambigu, comme un document qui demande un accès à des données sans rapport ou une issue de dépôt qui demande un changement de permissions. Le contenu récupéré doit être traité comme une donnée à analyser, pas comme une autorité pour modifier le contrat de permissions.
Réviser et révoquer l’accès régulièrement
L’accès peut devenir inapproprié à mesure que les projets, dépôts, dossiers et responsabilités changent. Maintenez un inventaire des identités et installations d’agents, de leurs propriétaires, des liaisons de ressources, de la dernière activité et de la prochaine date de revue. Retirez l’accès dormant plutôt que de le conserver sans objet actuel.
Quand la tâche d’un agent s’élargit, effectuez une nouvelle revue de permissions plutôt que d’ajouter silencieusement des scopes. Pour les GitHub Apps, le périmètre d’installation peut être limité à des dépôts sélectionnés, et les permissions peuvent être revues quand les besoins changent. GitHub documente le comportement d’installation sur dépôts sélectionnés et d’approbation des permissions.
Checklist d’implémentation
- Définir une tâche bornée et lui assigner un propriétaire métier.
- Créer une identité d’agent dédiée.
- Accorder les scopes API les plus restreints possibles et des liaisons de ressources nommées.
- Séparer les capacités de lecture, de brouillon et d’écriture à conséquence.
- Utiliser des branches et des pull requests pour les propositions de code plutôt que des changements directs sur branche protégée.
- Exiger une approbation pour l’envoi, la publication, la fusion, la suppression, la dépense ou le changement de permissions.
- Enregistrer les identifiants de tâche, les décisions de politique, les appels d’outils, les approbations et les résultats avec un contenu sensible minimal.
- Utiliser les journaux d’audit Microsoft 365 et GitHub pertinents dans le processus de supervision de l’organisation.
- Tester le workflow dans des destinations contraintes avec des entrées normales et adversariales.
- Documenter les étapes de révocation et planifier des revues d’accès.
FAQ
Un agent interne doit-il utiliser un accès délégué ou applicatif ?
Choisissez le modèle adapté à la tâche. L’accès délégué peut convenir à un agent qui agit dans le cadre de l’autorité d’un utilisateur connecté. L’accès applicatif peut convenir à un travail non supervisé, mais il nécessite un périmètre soigné car il peut fonctionner sans utilisateur connecté. Microsoft recommande des permissions minimales et privilégie les approches déléguées ou spécifiques à une ressource lorsque c’est possible. Source : bonnes pratiques de permissions Microsoft Graph.
Un agent GitHub peut-il avoir un accès en écriture ?
Oui, mais limitez cet accès à des actions définies sur des dépôts sélectionnés, comme la création de branches, de commits, de pull requests, de commentaires ou d’issues. Conservez les contrôles de branche protégée et les exigences de revue pour la fusion. Source : branches protégées GitHub.
Une boîte de dialogue d’approbation suffit-elle pour les actions sensibles ?
Non. L’approbation est un contrôle parmi d’autres. Associez-la à une identité limitée, des ressources restreintes, des destinations d’écriture bornées, des preuves d’audit et un chemin de révocation documenté.
Quel est le premier contrôle à mettre en place ?
Créer une identité dédiée avec un accès en lecture seule à un petit ensemble de ressources explicitement approuvées. Exiger une sortie en brouillon avant d’activer une capacité d’écriture externe.
Sources
- Microsoft : bonnes pratiques pour l’utilisation des permissions Microsoft Graph
- Microsoft : accéder aux journaux d’activité Microsoft Graph pour la supervision du tenant
- Microsoft : configurer la façon dont les utilisateurs consentent aux applications
- Google Workspace : créer des identifiants d’accès
- Google Workspace : contrôler quelles applications accèdent aux données Google Workspace
- GitHub : choisir les permissions d’une GitHub App
- GitHub : à propos des branches protégées
- GitHub : consulter le journal d’audit de votre organisation
Note éditoriale : l’IA a participé à la recherche et à la rédaction. Les sources ont été sélectionnées pour vérification ; un relecteur humain devrait valider ce brouillon avant publication.
Full-Stack Developer & Solutions Architect · Casablanca, Morocco
8+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.