Sécuriser un pipeline CI quand des agents de code y tournent

Faire tourner un agent de code dans votre pipeline CI est tentant : revue automatique de PR, correction de bugs en tâche de fond, triage d’issues. Mais un agent dans GitHub Actions n’est pas un simple script — c’est une entité qui interprète du texte et agit. Et si ce texte vient d’une source non fiable, vous avez ouvert une brèche. Voici comment durcir un pipeline où des agents tournent, sans renoncer à leurs bénéfices.

Le vecteur d’attaque : issue et PR comme entrée

Le scénario est simple et redoutable. Un adversaire n’a besoin que de la capacité de créer une issue ou une pull request — accessible à tout compte GitHub gratuit. Si un workflow déclenche un agent qui lit le titre, le corps ou un commentaire, et que cet agent dispose de permissions élevées (écriture sur le dépôt, accès aux secrets), une instruction malveillante glissée dans le texte peut détourner le pipeline : exfiltrer un secret, pousser du code, ouvrir une PR piégée. C’est l’injection de prompt appliquée à la CI, et c’est l’un des vecteurs de supply chain les plus actifs de 2026, comme nous l’avons vu dans le panorama de la sécurité des agents.

Règle n°1 : séparer déclenchement et privilèges

Le piège classique est le trigger pull_request_target, qui s’exécute avec les permissions du dépôt cible tout en manipulant du code venu de l’extérieur. Préférez pull_request pour les contributions non fiables, et ne donnez jamais de secrets à un job qui traite du contenu externe. Le principe : le job qui lit du contenu non fiable ne doit pas être le job qui a les droits.

# Durcir un job d’agent dans GitHub Actions
permissions:
  contents: read        # lecture seule par défaut
  pull-requests: read

jobs:
  agent-review:
    runs-on: ubuntu-latest
    # Pas de secrets exposés au job qui lit du contenu non fiable
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Revue par agent (sans droits d’écriture)
        env:
          # Jamais le token du dépôt ici
          MODEL_API_KEY: ${{ secrets.MODEL_API_KEY }}
        run: ./scripts/agent-review.sh

Règle n°2 : moindre privilège, toujours

Déclarez explicitement permissions: contents: read au niveau du workflow, puis n’élargissez qu’au job précis qui en a besoin. Un agent qui relit une PR n’a pas besoin d’écrire sur main. Un agent qui triage des issues n’a pas besoin d’accéder à vos secrets de déploiement. Le GITHUB_TOKEN doit être scellé au strict nécessaire, et les secrets sensibles isolés dans des jobs qui ne touchent jamais de contenu externe.

Règle n°3 : isolation par worktree ou sandbox

Quand un agent modifie du code, faites-le dans un worktree git dédié ou un conteneur isolé, jamais directement dans l’espace de travail privilégié. C’est le même principe que la Copilot app, qui fait tourner chaque session d’agent dans son propre worktree. L’isolation garantit qu’un agent qui dérape — par erreur ou par injection — ne contamine pas l’ensemble.

Règle n°4 : contenu externe = données, jamais instructions

• Traiter comme non fiable tout ce qui vient de l’extérieur : issue, commentaire, corps de PR, page web lue par l’agent.
• Ne jamais exécuter une action sensible sur la seule foi d’une instruction trouvée dans ce contenu.
• Épingler les dépendances et les actions par SHA, pas par tag mouvant, pour éviter la substitution.
• Exiger une validation humaine avant toute écriture sur les branches protégées ou tout accès aux secrets.

Règle n°5 : auditer et mesurer

Un agent en CI doit être observable : que lit-il, que décide-t-il, qu’exécute-t-il ? Les hooks d’observabilité qui se généralisent en 2026 servent exactement à cela. Journalisez les décisions de l’agent, alertez sur les comportements anormaux, et intégrez ces logs à votre revue de sécurité. Un pipeline d’agents non audité est un pipeline dont vous ne maîtrisez pas la surface d’attaque.

La sécurité d’un CI avec agents n’est pas une case à cocher, c’est une discipline — la même rigueur que celle appliquée aux workflows de développement par sous-agents. Ces règles ne sont pas exotiques : ce sont les principes de sécurité classiques, appliqués à un nouvel acteur qui interprète du langage. La difficulté n’est pas technique, elle est organisationnelle : instaurer la pratique dans l’équipe. C’est précisément ce que nous cadrons en atelier — brancher les agents sur votre CI de façon productive et sûre, avec des garde-fous explicites plutôt que des incidents à répétition.

Sources : CSA: GitHub Action prompt injection (Cloud Security Alliance), OWASP prompt injection 2026 (Help Net Security).