Contexte d’exécution et limites

  • 5 minutes

Une fois qu’un agent peut effectuer des actions et se connecter à des outils, la question suivante est où et comment ces actions sont exécutées.

Le contexte d’exécution définit les limites dans lesquelles un agent fonctionne. Cela inclut le référentiel auquel il peut accéder, la branche sur laquelle il fonctionne, le flux de travail qui exécute ses tâches et les autorisations qu’il a accordées.

Sans contexte d’exécution clairement défini, le comportement de l’agent devient imprévisible et dangereux.

Dans cette unité, vous allez apprendre :

  • Que signifie le contexte d’exécution dans GitHub
  • Comment la portée du référentiel et de la branche définit les limites
  • Comment les flux de travail isolent l’exécution
  • Comment les autorisations appliquent le contrôle sur les actions de l’agent

Qu’est-ce que le contexte d’exécution ?

Le contexte d’exécution est l’ensemble de contraintes qui définissent l’emplacement d’exploitation d’un agent et ce qu’il peut accéder.

Dans GitHub, le contexte d’exécution inclut :

  • Le dépôt dans lequel l'agent opère
  • Branche que l’agent cible
  • Flux de travail qui exécute des tâches
  • Autorisations accordées à ce flux de travail

Ce contexte détermine à la fois la visibilité et la fonctionnalité.

Étendue du référentiel

Les agents fonctionnent toujours dans un référentiel. Ils peuvent uniquement lire et modifier du code dans ce référentiel. Ils interagissent avec les problèmes, les pull requests et les flux de travail qui y sont liés. Ils n’ont pas accès à d’autres référentiels, sauf si l'accès leur est explicitement accordé.

L’étendue du référentiel est la première limite qui limite le comportement de l’agent.

Configuration de l’étendue du référentiel

Pour les agents tels que l’agent cloud Copilot, cette limite est explicitement configurée au niveau du référentiel.

Pour configurer cela :

  1. Ouvrez votre référentiel sur GitHub
  2. Cliquez sur Paramètres
  3. Dans la barre latérale, sous Code & automation, cliquez sur Copilot
  4. Sélectionner l’agent cloud
  5. Activer et configurer l’agent pour ce référentiel
  6. Enregistrer votre configuration

Une fois configuré, l’agent est limité à ce référentiel et ne peut pas fonctionner en dehors de celui-ci.

Étendue de l’agent personnalisé dans un référentiel

Les agents personnalisés fonctionnent dans la même limite de référentiel, mais peuvent affiner davantage leur étendue par le biais de la configuration.

Dans un fichier d’agent personnalisé (par exemple, .github/agents/security-reviewer.agent.md), l’étendue est définie à l’aide de champs tels que :

  • applyTo → limite les fichiers ou répertoires sur lesquels l’agent se concentre sur
  • outils → définit les actions que l’agent peut effectuer

Exemple :

applyTo:
    - '**/*.js'
    - 'src/auth/**' tools:
    - read_file
    - search_files

Pour configurer un agent personnalisé :

  1. Créer le répertoire .github/agents/ dans votre dépôt
  2. Ajouter un fichier agent avec l’extension .agent.md
  3. Définir son étendue à l’aide d’applyTo et d’outils
  4. Valider et envoyer (push) le fichier

Cela permet à l’agent de se concentrer uniquement sur des parties spécifiques du référentiel et de fonctionner avec des fonctionnalités limitées.

Comment cela s’intègre dans le contexte d’exécution

L’étendue du référentiel définit l’emplacement d’exploitation de l’agent, tandis que la configuration de l’agent personnalisée définit ce que l’agent peut accéder et faire dans cette limite.

Ensemble, ils créent un contrôle en couches.

Isolation basée sur les branches

Les agents ne fonctionnent pas directement sur la branche principale.

Au lieu de cela, ils :

  • Créer une branche à partir de la branche ypu sélectionnée
  • Apporter des modifications dans cette branche
  • Ouvrir un pull request vers une branche de base

Cela isole les modifications et garantit que toutes les modifications passent en revue avant d’être fusionnées.

L’isolation basée sur les branches est un mécanisme de sécurité clé.

Configurer un agent pour utiliser l’étendue par branches

Pour configurer un agent cloud Copilot pour fonctionner avec une étendue basée sur une branche, procédez comme suit :

  1. Sélection d’une branche de base :
    • Accédez à la page Agents : accédez à la page Agents de votre dépôt GitHub.
  2. Choisissez la branche de base : lors de la délégation de tâches à l’agent de codage Copilot, vous pouvez sélectionner une branche de base spécifique. Cela permet à l’agent de créer une branche basée sur votre branche sélectionnée au lieu de la branche par défaut (généralement « main »).

Les agents personnalisés fonctionnent dans un référentiel, mais ils ne contrôlent pas directement le comportement des branches. L’étendue basée sur les branches est déterminée par le système qui exécute l’agent.

Fonctionnement

Lorsqu’il est utilisé avec un agent cloud :

  • Le système crée automatiquement une branche
  • Applique les modifications
  • Ouvre une pull request

Lorsqu’il est utilisé dans les flux de travail (CI) :

  • Le flux de travail détermine la branche
  • L’agent s’exécute dans ce contexte de branche

Que contrôlent les agents personnalisés?

Les agents des douanes définissent :

  • Sur quels dossiers ils se concentrent (applyTo)
  • Actions qu’ils peuvent effectuer (outils)
  • Comment ils se comportent (instructions)

Mais ils ne définissent pas :

  • Création de branche
  • Comportement des pull requests
  • Isolation de l’exécution

L’étendue basée sur les branches est toujours appliquée par le contexte d’exécution, et non par l’agent personnalisé lui-même.

Permettre à un agent d’effectuer des actions autonomes, notamment créer des branches et des pull requests.

Les agents peuvent effectuer des actions autonomes dans un référentiel une fois qu’ils sont activés et donnés une tâche.

Étapes:

  1. Activez l’agent pour le référentiel.

    • Accéder aux paramètres → Copilot → Agent cloud
    • Activer l’agent, sélectionner le référentiel

  2. Affectez une tâche à l’agent.

    • À partir d'un ticket, de Copilot Chat ou de l'interface des agents
    • Exemple : corriger un bogue, implémenter une fonctionnalité

  3. Autoriser l’agent à exécuter la tâche.

    L’agent :

    • Créer une branche
    • Apporter des modifications de code
    • Validez et envoyez (push) les mises à jour

  4. Passez en revue et finalisez.

    Une fois que vous êtes satisfait des modifications et des résultats du code, soumettez une pull request. Vous pouvez demander des modifications dans le pull request ou bien aller de l'avant et fusionner.

L’agent opère de manière autonome dans le référentiel en créant des branches, en modifiant du code et en ouvrant des requêtes d'extraction, tout en opérant dans un flux de travail contrôlé et révisable.

Limites du flux de travail

L’exécution se produit à l’intérieur des flux de travail alimentés par GitHub Actions. Chaque flux de travail définit les déclencheurs d’exécution, les étapes effectuées et l’environnement dans lequel le code s’exécute. Les flux de travail agissent en tant que conteneurs d’exécution contrôlés. Ils garantissent que les tâches s’exécutent dans un environnement propre, que l’exécution est reproductible et que les journaux et les résultats sont capturés. Les flux de travail sont également la façon dont le comportement de l’agent est exécuté dans les environnements CI.

Limites d’autorisation

Les autorisations définissent ce qu’un agent peut faire dans son contexte d’exécution.

Les autorisations sont attribuées aux flux de travail via des jetons, tels que le GITHUB_TOKEN.

Ces autorisations peuvent autoriser ou restreindre :

  • Lecture du contenu du référentiel
  • Écriture de code
  • Création de demandes de tirage (pull requests)
  • Accès aux secrets
  • Déclenchement des flux de travail

Les autorisations doivent toujours être définies explicitement et réduites.

Garde-fous dans les flux de travail agentiques GitHub

Les workflows agentiques de GitHub sont conçus avec une défense en profondeur. Les contrôles clés sont les suivants :

  • Jetons en lecture seule par défaut, permettant à l’agent d’inspecter l’état du référentiel sans le modifier directement.
  • Sorties sécurisées qui permettent à l’agent de proposer des actions alors qu’une étape contrôlée distincte détermine ce qui est autorisé
  • Zéro secret dans le processus de l’agent, en conservant les informations d’identification sensibles hors du runtime utilisé par l’agent de codage
  • Exécution en bac à sable et conteneurisée
  • Isolation réseau et accès sortant autorisé
  • Détection des menaces qui analyse les sorties proposées avant l’application d’une action d’écriture

Ce modèle aide à réduire les risques d’agents surprotégés, d’injections rapides et de modifications imprévues du dépôt.

Pourquoi les limites sont importantes

Le contexte d’exécution est ce qui rend les systèmes d’agent sécurisés.

En combinant :

  • Étendue du référentiel
  • Isolation des branches
  • Exécution de workflow
  • Contrôle d’autorisation

GitHub garantit que les agents fonctionnent dans des limites claires et applicables.

Cela empêche :

  • Modifications non contrôlées du code de production
  • Accès aux ressources involontaires
  • Exécution non sécurisée ou non vue

Comment les agents sont appelés par le biais de flux de travail

Pour exécuter des tâches pilotées par un agent dans le cadre de CI, vous les exécutez à l’intérieur d’un flux de travail. Dans cette configuration, le flux de travail devient la limite d’exécution et l’agent s’exécute dans l’exécuteur à l’aide des étapes et autorisations définies.

Étapes:

  1. Créez ou ouvrez un fichier de flux de travail dans votre référentiel : .github/workflows/agent-task.yml

  2. Définissez quand le flux de travail doit s’exécuter :

    on:
 workflow_dispatch: 
schedule: - cron: '0 9 * * *'

    Vous pouvez également utiliser des événements tels que push ou pull_request en fonction de votre cas d’usage.

  3. Définissez les autorisations de flux de travail :

    permissions: 
    contents: read

    Ajustez les autorisations en fonction de ce que le flux de travail doit faire.

  4. Définissez un poste et un coureur :

    jobs: 
	agent-task: 
		runs-on: ubuntu-latest

  5. Consultez le référentiel :

    uses: actions/checkout@v4

  6. Configurer Node.js:

    uses: actions/setup-node@v4 
with: node-version: '18'

  7. Fournissez l’authentification :

    env: COPILOT_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  8. Exécutez la tâche de l’agent :

    run: | npx @github/copilot-cli 
-p "Summarize recent changes in this repository" 
--no-ask-user (Optional)

  9. Utilisez un agent personnalisé :

    run: | npx @github/copilot-cli 
--agent security-reviewer 
-p "Review this code for vulnerabilities" 
--no-ask-user

Le flux de travail devient le chemin d’exécution contrôlé de l’agent. La tâche s’exécute sur un exécuteur défini, avec un déclencheur défini, à l’intérieur d’un contexte de référentiel défini et avec uniquement les autorisations accordées à ce flux de travail.

Étendue de branche et exécution du flux de travail

Les flux de travail s’exécutent sur une branche spécifique.

Étant donné que les agents apportent des modifications sur une branche :

  • L’exécution du flux de travail est limitée à cette branche
  • Les modifications sont isolées de la branche par défaut
  • La validation se produit avant la fusion

Cela garantit que l’activité de l’agent reste contenue dans une étendue d’exécution contrôlée.

À retenir

Le contexte d’exécution définit l’emplacement des agents. Les limites telles que l’étendue du référentiel, l’isolation des branches, les flux de travail et les autorisations garantissent que les actions de l’agent restent contrôlées, prévisibles et sécurisées.

Ensuite, vous apprendrez à concevoir des chemins d'exécution sécurisés, y compris les retentions, les rollbacks et les mécanismes d'escalade.