Aller au contenu
Retour aux Tutoriels

Verrouiller les pipelines d'agents de codage IA : configuration sandbox, frontières de permissions et portes de revue automatisées

Intermédiaire · 1 hour · 3 min de lecture · Byte Smith · · Mis à jour 14 mars 2026

Avant de commencer

  • Bases de GitHub Actions (création et édition de fichiers YAML de workflow)
  • Familiarité avec les concepts CI/CD (pipelines, jobs, steps)
  • Bases de Docker (construction d'images, exécution de conteneurs)
  • Un dépôt GitHub où vous pouvez activer Actions

Ce que vous apprendrez

  • Détecter les pull requests générées par l'IA en utilisant les métadonnées de commit et les labels
  • Définir un fichier de politique comme code qui contrôle ce que les agents IA peuvent modifier
  • Exécuter des scans de sécurité automatisés (secrets, dépendances, SAST) sur chaque PR générée par l'IA
  • Exécuter les tests dans un sandbox Docker isolé avant le merge
  • Calculer un score de risque et appliquer des exigences de revue par niveau
  • Émettre des événements d'audit structurés pour la conformité et la réponse aux incidents
Sur cette page

Ce tutoriel guide la mise en place du pipeline ai-code-gate, un workflow GitHub Actions qui détecte les pull requests générées par l’IA, applique la politique comme code, exécute des scans de sécurité, teste dans un sandbox et contrôle les merges par niveau de risque. Pour la stratégie plus large derrière ces contrôles, consultez l’article de blog compagnon : Securing AI Coding Agent Workflows.

Le dépôt est modulaire : chaque étape du pipeline est une action composite autonome que vous pouvez adopter individuellement, et une bibliothèque TypeScript partagée (src/) contient le moteur de politique, la logique de détection et le scoring de risque que les actions consomment.

Ce tutoriel est très riche en code. Les étapes clés sont :

  1. Détecter les pull requests générées par l’IA — Vérifier les trailers de co-auteur pour les patterns d’agent IA, les noms d’utilisateur de bot connus et les labels de PR.
  2. Définir votre fichier de politique — Créer un .ai-code-gate.yml avec les patterns autorisés, bloqués et les limites de périmètre.
  3. Exécuter les vérifications de politique — Valider chaque fichier modifié contre votre politique en utilisant l’API GitHub et minimatch.
  4. Exécuter les scans de sécurité automatisés — Exécuter gitleaks, Semgrep et npm audit sur chaque PR générée par l’IA.
  5. Exécuter les tests dans un sandbox — Construire et exécuter les tests dans un conteneur Docker isolé avec --network=none, --memory=512m et --cpus=1.
  6. Calculer le risque et appliquer les portes de revue — Combiner les résultats des scans en un score de risque unique qui détermine les exigences de revue (LOW: auto-merge, MEDIUM: 1 approbation, HIGH: 2 approbations dont sécurité).
  7. Câbler le workflow et la journalisation d’audit — Connecter toutes les actions dans un workflow à jobs parallèles avec des événements d’audit structurés.
Attention

Bloquez les fichiers de configuration CI/CD par défaut. Un agent IA qui peut modifier le YAML de workflow peut potentiellement escalader ses propres permissions ou désactiver les portes que vous construisez ici.

Astuce

Claude Code ajoute un trailer Co-Authored-By: Claude à chaque commit par défaut. Les PRs d’agent GitHub Copilot viennent de comptes bot dédiés. Cursor et Aider incluent typiquement des identifiants d’outil dans les messages de commit. Vérifier les trois signaux vous donne une haute couverture sans faux négatifs.

Pour le code source complet, les actions composites, les modules TypeScript partagés, les tests, les exemples de politiques et le workflow complet, consultez le dépôt ai-code-gate sur GitHub.

Obtenez la checklist gratuite de gouvernance du code IA →

Tutoriels connexes qui étendent ce travail :

La gouvernance est la couche manquante entre l’adoption d’outils de codage IA et la préparation entreprise. Les équipes qui expédient du code généré par l’IA sans détection, application de politique, scanning de sécurité, test en sandbox et revue basée sur le risque acceptent un risque non quantifié. Le pipeline que vous construisez ici rend ce risque visible, mesurable et applicable.