Le bot Slack de Hugging Face interroge les données de production. Le LLM ne voit jamais les clés

La plupart des équipes ne publient pas les détails de la manière dont leur agent de codage touche aux données de production. Hugging Face l'a fait. Moon Bot, un bot Slack interne, interroge Elasticsearch et MongoDB en production, ouvre des pull requests GitHub et se souvient de ce sur quoi il a travaillé la semaine dernière. Le modèle qui le pilote ne détient jamais les identifiants qui rendent tout cela possible.

Moon Bot semble trivial jusqu'à ce que vous essayiez de le construire. Il fonctionne sur le SDK open-source Pi coding agent dans un pod Kubernetes, et chaque fil Slack bénéficie de sa propre session d'agent indépendante avec l'historique complet des appels d'outils. L'article cite Kimi K2 et Claude comme backends possibles. Le support demande des précisions sur le comportement visible par les utilisateurs sans terminal ; les ingénieurs vérifient si une fonctionnalité existe ou si quelque chose est un bug. Demander « combien d'utilisateurs Pro se sont inscrits le mois dernier ? » devient une ligne dans Slack au lieu de fouiller les tableaux de bord.

Des sessions dans le stockage objet

La couche de persistance est l'atout discret. Le bot conserve trois fichiers dans un bucket privé HuggingFace nommé huggingface/moon-bot-memory. Chaque fil ajoute son historique complet de messages, appels d'outils inclus, dans un fichier JSONL. Un fichier de correspondance de fils relie les horodatages Slack aux fichiers de session, et un journal de mémoire conserve les 200 dernières interactions de tous les fils, consultables par le modèle. Comme les sessions vivent dans le stockage objet, un déploiement ou un crash ne coûte rien : le bot télécharge le bon fichier à la demande et reprend là où il s'était arrêté, même des jours plus tard.

Chaque réponse renvoie au bucket : Moon Bot téléverse la réponse markdown et le JSONL de session, puis ajoute des boutons au message. HuggingFace affiche le fichier dans une visionneuse native de traces d'agent, de sorte que chaque interaction est auditable depuis le fil lui-même.

Des identifiants que le modèle ne peut pas toucher

La conception de la sécurité est ce qui fait la valeur de l'article. Moon Bot résout un niveau d'accès pour chaque utilisateur Slack à partir de son appartenance aux groupes Okta, mise en correspondance par e-mail, reflétant l'accès que ces groupes contrôlent déjà. Basic couvre tout employé de Hugging Face : Q&R sur le code, GitHub en lecture seule et shell. Elastic ajoute des compétences de journalisation et de stockage pour les personnes ayant accès à Elasticsearch. Privileged, pour les personnes ayant accès aux bases de données dans Okta, atteint MongoDB et AWS. Les invités sont refusés d'emblée. Chaque niveau correspond à un utilisateur Linux distinct avec ses propres identifiants, de sorte que les niveaux inférieurs ne disposent physiquement pas des secrets pour atteindre Mongo ou AWS. La résolution échoue en mode fermé : si Okta ne peut pas être lu, tout le monde passe en basic, et le bot le mentionne sur chaque réponse.

Les appels d'outils s'exécutent sous l'utilisateur restreint du niveau via su -l, sans accès à /root/, où vivent les vrais secrets. Les commandes suspectes déclenchent une alerte Slack avant exécution, et le modèle dispose d'un outil report_injection pour signaler lui-même les injections de prompt. Des proxys inverses locaux couvrent le reste : le bot démarre des proxys HTTP au lancement, chacun protégé par un jeton propre au niveau, et injecte la vraie clé API côté serveur, de sorte que le runner sandboxé atteigne localhost:9201 sans jamais la voir. Le proxy Plausible est strictement autorisé sur un seul endpoint de requête et porte son propre jeton remis à chaque niveau, afin que chacun puisse consulter les analytics de trafic public. Un appel d'outil compromis peut interroger ce que son niveau autorise, mais il ne peut pas exfiltrer les identifiants.

Les pull requests fonctionnent de la même manière. Le gh sandboxé de l'agent est en lecture seule pour presque tout le monde. Les écritures passent par des outils dédiés dans le processus qui génèrent un jeton GitHub App à courte durée de vie, committent et poussent, puis le jettent, hors de portée de l'agent. Deux propriétés en découlent : tout employé peut demander une PR en brouillon sans accès en écriture personnel, et les descriptions de PR sont assemblées dans le code, pas par le modèle, de sorte que chaque PR se termine par un pied de page nommant le demandeur et liant le fil Slack et la trace de l'agent. Un second pod, bien moins privilégié, exécute le même codebase en tant que bot GitHub, sans jeton Slack ni identifiants de base de données.

Les compétences sont la partie enfichable : des fichiers Markdown injectés dans le prompt système qui indiquent au modèle comment piloter un domaine. La règle est que chaque compétence enveloppe un outil CLI, jamais un appel API direct, ce qui la rend testable et facile à remplacer. L'article en liste huit, couvrant les logs Elasticsearch, MongoDB, les codebases Hub et Spaces, GitHub, AWS Athena, le stockage Xet et les analytics de trafic public.

Un modèle à reproduire

L'article qualifie le modèle d'assez simple à répliquer : un bucket ou tout autre stockage objet, le SDK Pi, quelques fichiers de compétences et une app Slack en Socket Mode. L'infrastructure de départ, dit-il, est étonnamment mince ; la partie la plus difficile est d'écrire de bonnes compétences. Cela sous-estime l'échafaudage de sécurité, que la plupart des équipes ignoreraient. Ce qui fait fonctionner Moon Bot, c'est que le risque a été éliminé par la conception plutôt que géré par des politiques : des niveaux appliqués par des utilisateurs Linux distincts, des identifiants injectés par des proxys locaux, des jetons d'écriture créés et détruits pour chaque PR.

Moon Bot est un outil interne, avec les avantages d'un tel outil : un domaine SSO unique, des utilisateurs connus, les codebases d'une seule équipe. La leçon transférable est le modèle : rendre chaque action auditable et maintenir chaque identifiant hors de portée du modèle qui l'utilise.