Donner à un agent Hermes l’accès à GitHub

Pourquoi le token ne doit pas vivre dans l’agent

Hermes Agent, l’agent open source de Nous Research, sait très bien travailler avec GitHub. La question est de savoir où va l’identifiant. Dans une installation auto-hébergée, le token GitHub finit dans un fichier .env ou dans config.yaml, à côté de l’agent, sur une machine que vous gardez allumée, mettez à jour et sauvegardez. Quiconque, ou quoi que ce soit, qui peut lire cette configuration, y compris l’agent lui-même sous un prompt malveillant, peut lire le token et pousser avec.

Sur Atako, l’identifiant reste hors de ce tableau. Vous connectez GitHub une fois, au niveau de l’entreprise. Le token est stocké côté serveur et injecté au moment où l’appel part. L’agent Hermes ne le reçoit jamais : il demande au broker d’intégrations d’exécuter une action, et le broker décide si cette action est permise. Le même mécanisme couvre tous les connecteurs du catalogue ; ce que vous apprenez ici vaut donc pour le suivant.

Ce qu’il vous faut avant de commencer

Il vous faut un compte GitHub qui voit les dépôts sur lesquels l’agent travaillera, et un agent Atako qui tourne sur le harnais Hermes. Hermes est le harnais par défaut des nouveaux agents : un agent tout juste créé convient donc déjà. Si vous hésitez encore sur le harnais, la page pilier sur les agents autonomes explique comment fonctionne un agent sur la plateforme.

Créer un token au périmètre le plus étroit

Un token fin a deux plafonds. Le premier est la liste des dépôts : vous les choisissez à la création du token, et GitHub refuse tout ce qui est en dehors. Le second est la liste des permissions, chacune en Read-only ou en Read and write. Même si vous accordez plus tard davantage dans Atako, GitHub refuse ce que le token ne couvre pas.

Le moindre privilège, ici, c’est de commencer en lecture seule. Donnez au token Read-only sur Issues et Pull requests, ajoutez Contents et Actions en Read-only si l’agent doit consulter des fichiers ou des exécutions, et limitez-le à un ou deux dépôts. Observez l’agent une semaine dans le journal. S’il doit commenter une issue ou l’étiqueter, relevez seulement Issues en Read and write. Ne laissez Contents et Pull requests modifiables que si vous voulez vraiment que l’agent change du code, ce dont la plupart des tâches de tri et de reporting n’ont pas besoin. Fixez une date d’expiration pour que le token ne vive pas éternellement par accident.

Traitez le token comme un mot de passe. Collez-le dans Atako et nulle part ailleurs : ni dans une conversation avec l’agent, ni dans une issue. Une fois connecté, vous n’avez plus besoin de le revoir.

Connecter une fois, accorder par agent

Connecter GitHub dans Atako est une action au niveau de l’entreprise, faite depuis le catalogue d’intégrations. Elle rend GitHub disponible, mais ne donne aucun droit à un agent. Les droits viennent de l’accord que vous créez sur chaque agent.

Cet accord fonctionne en deux couches. Vous choisissez d’abord un niveau avec les puces Lecture et Écriture. Vous cochez ensuite les endpoints un par un. Un agent qui résume la semaine reçoit list_pull_requests et get_pull_request, et rien d’autre. Un agent qui trie les issues reçoit list_issues et get_issue pour lire, update_issue et add_issue_comment pour écrire. Deux agents peuvent partager la même connexion avec des droits très différents, et la liste des endpoints cochés est la liste de ce que chacun peut faire.

Parler à l’agent

Une fois l’accord créé, vous n’écrivez aucune configuration d’outil. Vous décrivez le travail en langage courant : liste les issues ouvertes depuis lundi, étiquette-les et commente celles qui n’ont pas d’étapes de reproduction. L’agent choisit les bons endpoints parmi ceux qui lui ont été accordés, les appelle par le broker et vous rend compte. Un endpoint non accordé ne peut pas être appelé, et c’est à vous de décider d’élargir ou non l’accord.

Comme un agent Hermes tourne aussi selon un calendrier, le même accord sert les tâches récurrentes. Un récapitulatif des pull requests le vendredi ou un coup d’œil quotidien aux workflows en échec utilisent exactement les droits que vous avez déjà définis.

Garder un œil sur ce qui se passe

Chaque appel qui passe par le broker est enregistré : quel outil, quel statut, quel code HTTP, quelle durée. Cet enregistrement est visible sur l’agent et dans le dashboard de l’entreprise, dans la vue d’usage des intégrations et dans le journal des intégrations. C’est votre piste d’audit. Quand un contributeur demande qui a fermé une issue, vous ouvrez le journal et vous voyez l’appel, au lieu de deviner à partir de la seule chronologie de l’issue.

Le journal aide aussi à ajuster les droits. Si vous voyez un agent tenter à répétition un endpoint qui ne lui a pas été accordé, c’est un signal : soit la tâche en a besoin et vous l’ajoutez en connaissance de cause, soit l’agent dérive et le prompt demande du travail.

Ce que cette configuration ne fait pas

L’accord sélectionne des endpoints. Il ne restreint pas les issues qu’un endpoint peut toucher : un agent autorisé à appeler update_issue peut modifier toute issue des dépôts que le token atteint. Si vous voulez une frontière plus étroite, limitez le token à moins de dépôts, ou gardez les écritures sensibles derrière une étape humaine. Donnez à l’agent la règle de proposer d’abord le changement dans la conversation, puis de l’appliquer après votre confirmation.

Pour le côté GitHub du connecteur, avec toutes les actions qu’il expose, consultez la page de l’intégration GitHub. Le guide HubSpot avec Hermes suit les mêmes étapes. Pour des flux de travail concrets, le cas d’usage tri de CI montre ce que fait un agent face à des exécutions en échec, et le cas d’usage sentinelle de bugs couvre les signalements entrants.