Agents de contrôle et d’exploitation - observabilité, outils, MCP, secrets, crochets et fiabilité

Dans cette unité, vous allez apprendre :

• Découvrir les preuves et les artefacts requis pour le travail de l’agent

• Comment contrôler les outils, les intégrations MCP et les secrets en toute sécurité

• Comment les crochets appliquent les garde-fous et auditent la journalisation

• Comment concevoir pour la fiabilité en utilisant les réessais, l’escalade et le principe du moindre privilège

Preuves et artefacts requis pour les agents

Un système d’agent doit produire des artefacts visibles pour chaque action significative. Sans artefacts, vous ne pouvez pas examiner de manière fiable le comportement, les échecs de débogage ou effectuer une analyse post-hoc.

Dans GitHub, l’observabilité est obtenue par le biais d’artefacts tels que :

• les pull requests et les délais de relations permanentes,

• Comités et historique de la branche,

• exécutions de flux de travail et journaux des tâches,

• vérifications requises et résultats d’analyse, et

• téléchargé des artefacts de flux de travail (par exemple, des rapports de test).

Ensemble d’observabilité minimale

Une tâche d’agent bien conçue doit produire des preuves visibles et vérifiables à l’aide d’artefacts natifs GitHub :

• un plan structuré, généralement inclus dans la description ou la discussion d'une pull request

• une pull request délimitée et un historique de commit

• liens de flux de travail pour les vérifications requises

• artefacts téléchargés (par exemple, journaux ou rapports)

• examiner les résultats (approbations ou modifications demandées)

Charger des artéfacts de flux de travail pour une révision et le débogage

Télécharger des artefacts rend les preuves durables et vérifiables, même lorsque les journaux défilent.

Nous recommandons la meilleure pratique d’inclure des liens vers les exécutions de flux de travail et les artefacts pertinents dans la RP sous une section « Preuves » afin que les évaluateurs puissent rapidement valider les résultats.

- name: Upload test results
  uses: actions/upload-artifact@v4
  with:
    name: test-results
    path: results/

La fiabilité suppose l’échec

Les systèmes fiables supposent que l’échec se produit. Les agents ne comprennent pas les tâches, les tests échouent et les modifications entrent en conflit avec le comportement existant. Votre architecture doit détecter les défaillances tôt et fournir des chemins de récupération sécurisés.

Un modèle de fiabilité pratique comprend :

• Essais : l’agent peut mettre à jour la branche lorsque les vérifications échouent.

• Escalade : les défaillances persistantes sont résumées et transmises à un humain.

• Préparation au retour arrière : les modifications à haut risque incluent les instructions de retour arrière et les limites de portée.

Stratégie d’itération sécurisée

Utilisez une stratégie prévisible pour l’itération :

• En cas d’échec d’une vérification requise, l’agent peut réviser la branche PR et relancer les vérifications.

• Si la même vérification requise échoue deux fois, passez à un réviseur humain avec :

  • ce qui a échoué,

  • ce qui a été tenté,

  • quelles preuves existent, et

  • quelle est la prochaine étape suggérée.

Cette stratégie permet d’empêcher les boucles infinies et de rendre les échecs actionnables.

Observabilité en tant que fonctionnalité architecturale requise

Un ensemble d’observabilité minimal pour le travail autonome doit inclure :

• un artefact visible du plan,

• un PR + historique de validation,

• flux de travail pour les vérifications requises,

• artéfacts durables (journaux/rapports/traces)

• passez en revue les résultats et les approbations.

Rendre les éléments probants traçables à l’exécution et à l’état du code

Enseignez un principe d’affectation de noms/de métadonnées :

• La preuve doit être traçable à une exécution de flux de tâches spécifique et à un commit spécifique.

Cela permet d’auditer et de déboguer : vous pouvez répondre à « quelle exécution a produit cet artefact et par rapport à quel état de code ? »

Partager des informations entre les tâches avec des artefacts

Enseignez le modèle :

• Charger des artefacts où ils sont produits

• Téléchargez-les là où elles sont examinées ou déployées

Cela permet de conserver les sorties inspectables et utilisables sans intégrer les fichiers générés dans le dépôt.

Comment contrôler les outils, les intégrations MCP et les secrets en toute sécurité

La configuration du profil de l’agent fournit trois types de contrôle :

• Limite de capacité : quels outils sont autorisés (préférer les listes d’autorisation)
• Limite de visibilité : indique si l’agent est sélectionnable par l’utilisateur dans l’interface utilisateur interactive
• Limite de délégation : quels sous-agents peuvent être appelés et comment les passations se produisent - Directives de conception :
• Utilisez des ensembles d’outils en lecture seule pour la planification et la révision des agents.
• Restreindre les outils d’implémentation aux agents d’exécution.
• Traitez les modifications apportées aux listes d’autorisation des outils comme une modification sensible à la gouvernance.

Serveurs MCP : étendre les outils en toute sécurité

Les serveurs MCP étendent la fonctionnalité d’outil. Enseignez ces modèles :

• Forme de transport : certains serveurs MCP sont des points de terminaison distants ; d’autres sont des processus locaux.
• Authentification : les jetons doivent être injectés au moment de l’exécution via des limites de secret protégées.
• Contrôle de namespace : privilégiez l'activation d'un ensemble restreint d'outils plutôt que de larges caractères génériques.

Conseils opérationnels :

• L’ajout ou l’expansion des outils MCP augmente le rayon d’explosion et doit être examiné comme une dépendance à haut risque.

Contraintes de secrets et d’environnement (exclure les secrets du contenu du dépôt)

Ne placez pas de secrets dans :

• fichiers d’instructions,
• fichiers de configuration commités,
• ou le workflow YAML en texte brut.

Au lieu de:

• Utilisez des frontières secrètes protégées destinées à l’injection en temps réel,
• Passez des secrets uniquement aux composants qui en ont besoin,
• Limiter la disponibilité des secrets (par exemple, par environnement) pour réduire l’exposition.

Enseignez le principe :

• « L’environnement d’exécution de l’agent a sa propre limite secrète ; ne supposez pas qu’il hérite automatiquement des secrets CI du référentiel. »

Comment les crochets appliquent les garde-fous et auditent la journalisation

Dans GitHub Copilot agents, les hooks sont définis en tant que fichiers de configuration stockés dans le référentiel (par exemple, sous .github/hooks/). Chaque hook spécifie quand il s’exécute et l’action qu’il effectue.

Les hooks exécutent des commandes personnalisées à des points spécifiques pendant l’exécution de l’agent. Cela permet aux équipes d’appliquer des stratégies, de valider des actions et de capturer automatiquement les données d’audit.

Exemple simplifié :

{
  "name": "block-high-risk-command",
  "trigger": "pre-tool-use",
  "run": "if [[ \"$TOOL\" == \"delete\" ]]; then echo 'Blocked unsafe command'; exit 1; fi"
}

Fonctionnement du processus

• Le crochet s’exécute avant l’exécution d’un outil (avant l’utilisation de l’outil)

• Il inspecte l’action demandée

• Si l’action correspond à un modèle bloqué, l’exécution est arrêtée

Modèles de crochets courants

• Crochets de pré-action Valider ou bloquer des actions non sécurisées avant l’exécution

• Accroches post-action Utilisation des outils, sorties ou décisions pour l’audit

• Crochets d’erreur Échecs de capture et déclenchement d’escalade ou d’alerte

Quels sont les hooks qui activent

• Application de stratégies de sécurité (par exemple, blocage de commandes non sécurisées)

• Ajout de journaux d’audit pour la conformité et le débogage

• Intégration à des systèmes externes (alertes, surveillance, approbations)

• Les crochets fournissent des points de contrôle applicables qui fonctionnent indépendamment du raisonnement du modèle. Au lieu de s’appuyer sur des instructions, elles garantissent que certaines règles sont toujours appliquées pendant l’exécution.

Comment concevoir pour la fiabilité en utilisant les retentions, l’escalade et le moindre privilège

Comme nous l’avons mentionné précédemment, les agents échoueront, mais nous pouvons créer des systèmes capables d’intercepter ces défaillances et garantir que l’intervention humaine l’intercepte, par exemple voici quelques façons de s’assurer que les défaillances sont interceptées :

• Réessais limités pour les échecs temporaires

• Chemins d’escalade pour les échecs répétés

• Préparation à la réversibilité pour les changements à haut risque

• Autorisations de moindre privilège pour réduire la portée d'impact

Modèle sûr pour le retour en arrière à enseigner :

• Utilisez des références explicites (commit/tag) lors du déploiement d’une configuration sensible plutôt que 'la dernière version d'une branche'.

Rappel du principe de moindre privilège :

• Restreindre les autorisations de flux de travail par défaut et élever uniquement si nécessaire.

Autorisations de flux de travail avec privilèges minimum

Le privilège minimum réduit les risques en cas de problème. Elle empêche également l’automatisation sur-autorisée de devenir une vulnérabilité architecturale.

permissions:
  contents: read
  pull-requests: write

Cette configuration permet d’automatiser la lecture du contenu du dépôt et la mise à jour du contexte des PR (commentaires, statuts) tout en empêchant par défaut un accès d’écriture général.