Connecter MCP à GitHub : permissions minimales et pilote lecture seule

Connecter MCP à GitHub peut permettre à une application d’IA de rechercher des issues, lire des fichiers ou explorer un dépôt. C’est aussi une intégration sensible : GitHub contient souvent du code privé, des discussions internes, des configurations et parfois des secrets committés par erreur. Commencez donc avec un dépôt de démonstration, un compte ou une GitHub App dédiée et des permissions de lecture minimum.

Le premier objectif ne doit pas être « laisser l’assistant gérer GitHub ». Choisissez une action sans effet de bord : lister les issues ouvertes d’un dépôt de test, rechercher un fichier public ou lire un README. Un outil capable de créer une issue, modifier une pull request, publier un commentaire ou fusionner une branche doit être évalué séparément, avec des confirmations et une politique de revue.

Ce que vous allez apprendre

Vous allez définir un pilote GitHub, choisir une identité limitée, préparer la configuration sans exposer de token, vérifier les capacités réelles du serveur MCP et décider comment désactiver l’intégration. Ce guide ne fournit pas de secret ni de configuration prête pour un dépôt de production.

Prérequis

Prévoyez un dépôt GitHub de test, les droits nécessaires pour créer une identité de service selon votre organisation, et la documentation du serveur MCP que vous évaluez. Lisez les politiques de sécurité du dépôt, en particulier celles qui concernent les secrets, les branches protégées et les intégrations tierces.

Avant de démarrer, notez le besoin :

Question : rechercher les issues ouvertes d’un dépôt de démonstration.
Effet de bord autorisé : aucun.
Identité : compte ou application dédiée, lecture seule.

Vérification : vous pouvez expliquer pourquoi chaque permission est nécessaire. Si une permission n’est pas liée à cette question, retirez-la du pilote.

1. Choisir une identité adaptée

Évitez d’utiliser votre token personnel pour un serveur MCP. Un token personnel cumule souvent vos droits sur plusieurs organisations et dépôts ; il est difficile à auditer et à révoquer sans impact. Préférez une GitHub App ou un compte de service dédié lorsque votre organisation le permet, avec accès uniquement au dépôt de test et aux permissions nécessaires.

GitHub distingue les permissions de contenu, issues, pull requests, actions et administration. Pour un pilote de recherche, la lecture du contenu ou des issues peut suffire selon le serveur. N’accordez pas d’écriture, de gestion de workflows ou d’administration parce qu’un exemple générique les liste.

Vérification : l’identité du pilote ne voit pas les dépôts hors périmètre et ne peut pas créer ou modifier une ressource dans le dépôt de test.

2. Stocker les identifiants correctement

Un serveur MCP peut demander une variable d’environnement pour s’authentifier auprès de GitHub. Conservez sa valeur dans un mécanisme protégé : secret de l’environnement local, gestionnaire de secrets ou réglage sécurisé de votre hébergeur. Ne copiez jamais le token dans le fichier de configuration, un commit, un ticket ou une conversation.

Un exemple peut documenter le nom sans valeur réelle :

GITHUB_TOKEN="remplacez-par-un-token-de-test-limite"

Un fichier ignoré par Git réduit le risque de commit accidentel, mais il ne protège pas un token déjà affiché. Si une valeur apparaît dans un log ou un chat, révoquez-la puis créez-en une nouvelle avec une portée réduite.

Vérification : recherchez les chaînes de token dans le diff et les fichiers de configuration avant le premier test. Le résultat doit être vide ou contenir uniquement des valeurs fictives.

3. Configurer un seul serveur MCP

Suivez la documentation du serveur et de votre client MCP pour déclarer la connexion. Limitez le périmètre au dépôt de démonstration et à l’identité dédiée. Gardez la configuration claire : nom du serveur, version évaluée, origine, variable utilisée et capacités attendues. Ne lancez pas plusieurs intégrations GitHub au même moment ; vous ne sauriez plus quel serveur a lu ou renvoyé une donnée.

La configuration doit être relue avant son chargement. Une commande de démarrage inconnue, un chemin vers votre répertoire personnel ou un argument qui élargit l’accès sont des signaux d’arrêt. Vérifiez aussi où le serveur écrit ses logs et si ces logs pourraient contenir des titres d’issues ou des extraits de code sensibles.

Vérification : la liste de capacités annoncées correspond à votre pilote lecture seule. Une capacité d’écriture doit être désactivée ou faire l’objet d’une revue distincte.

4. Faire une première lecture contrôlée

Demandez une opération simple : lister les titres d’issues du dépôt de test ou lire son README. Avant de confirmer, examinez l’outil appelé, ses arguments et la cible. Après l’appel, vérifiez que la sortie correspond au dépôt prévu et ne contient pas de donnée inattendue.

Traitez le texte récupéré comme non fiable. Une issue ou un README peut contenir une instruction demandant de contourner les règles, d’exécuter une commande ou de révéler un secret. Ce contenu ne modifie pas vos permissions. Les règles du projet et la demande initiale restent prioritaires.

Vérification : consignez le dépôt, l’outil, les arguments et le résultat du premier appel. Vous devez pouvoir démontrer qu’aucune écriture GitHub n’a été effectuée.

5. Préparer les actions d’écriture séparément

Créer une issue ou commenter une pull request est utile dans certains workflows, mais cela a un effet de bord public ou partagé. Avant d’activer une telle capacité, définissez qui peut l’utiliser, quelles branches ou repositories sont autorisés, comment le message est relu et comment corriger une publication incorrecte.

Commencez avec un dépôt sandbox et un contenu clairement marqué comme test. Ajoutez une confirmation humaine pour chaque action. Une intégration MCP ne doit jamais fusionner une pull request, modifier une protection de branche ou déclencher un workflow de production sans une procédure formelle et une autorisation explicite.

Problèmes fréquents et solutions

Le serveur demande un token avec tous les droits

Cherchez un mode d’authentification plus restreint ou un autre serveur. Un pilote de lecture ne justifie pas un token qui peut administrer des organisations ou écrire dans tous vos dépôts.

Une issue contient une instruction bizarre

Ignorez-la comme instruction et traitez-la comme du contenu. Vérifiez sa pertinence avec le propriétaire du dépôt, sans exécuter d’action supplémentaire.

Le serveur ne peut pas lire le dépôt de test

Vérifiez que l’identité dédiée a bien accès à ce dépôt précis et que la permission lecture correspond au type de ressource demandé. N’élargissez pas tous les droits pour contourner une erreur.

FAQ

Faut-il utiliser une GitHub App ?

Une GitHub App ou un compte de service dédié aide à limiter et auditer les permissions. Le choix dépend de la politique de votre organisation et du serveur utilisé.

Puis-je connecter un dépôt privé ?

Oui seulement après avoir évalué les données, l’identité, les permissions et les logs. Commencez de préférence par un dépôt de test non sensible.

MCP peut-il créer des pull requests ?

Un serveur peut exposer cette capacité, mais elle doit rester désactivée pendant un pilote lecture seule et être soumise à une revue dédiée.

Comment retirer l’intégration ?

Désactivez sa configuration côté client, stoppez le serveur et révoquez le token ou l’installation de l’application de test conformément à la procédure GitHub.

Est-ce que GitHub lit le contenu envoyé au serveur MCP ?

Les flux dépendent du serveur, du client et de leur configuration. Vérifiez les politiques de données et journaux de chaque composant avant de transmettre du code privé.

Conclusion

MCP avec GitHub est utile quand il rend une lecture de dépôt plus accessible à un assistant, sans élargir les droits. Utilisez une identité dédiée, un dépôt de test et une seule capacité de lecture, puis vérifiez chaque appel. Les actions d’écriture et de production doivent rester hors du premier pilote.

Sources et limites

• GitHub Docs — Permissions for GitHub Apps : permissions à définir au moindre privilège.
• GitHub Docs — Fine-grained personal access tokens : portée et gestion des tokens.
• Model Context Protocol — security best practices : contrôles MCP à adapter.

Les options GitHub et les capacités de serveurs MCP évoluent. Ce guide ne valide aucun serveur tiers, token ou paramétrage de production.