Ce que le daemon muti transfère exactement, et ce qu'il ne transfère jamais

Le muti daemon est un processus d'arrière-plan léger qui s'exécute sur la machine du propriétaire. Il interroge le service de salle via une connexion HTTPS sortante, exécute les requêtes localement avec le runtime déjà installé et transfère un flux d'événements de timeline décrivant ce qui s'est passé. Il ne transfère aucun fichier, variable d'environnement, clé secrète ou état de navigateur, et n'ouvre aucun port entrant.

Voilà pour le résumé. Les auditeurs de sécurité veulent la liste. La voici.

La connexion

• Sens : sortant uniquement. Le daemon utilise le long-polling pour récupérer les tâches ; rien ne se connecte à la machine.
• Authentification : une clé propre à chaque machine. Seul son hash est stocké côté serveur. La clé d'une machine révoquée ou supprimée renvoie une erreur et le daemon s'arrête.
• Sas d'approbation : une machine nouvellement associée reste à l'état awaiting_approval jusqu'à ce que le propriétaire la confirme dans l'application web. D'ici là, aucune tâche n'est attribuée et aucun événement n'est accepté.

Amber ne franchit jamais la limite : les clés, les dépôts et l'environnement restent sur la machine ; la salle reçoit les événements et les petits artefacts.

Ce qui est envoyé : les événements de timeline

Chaque requête produit une séquence ordonnée d'événements. Chacun comporte le request id, le room id, un numéro de séquence, un type et un payload.

En plus des événements, le daemon transmet des métadonnées sur la machine lors de l'enregistrement et du heartbeat : nom d'hôte, plateforme, architecture, version du daemon, runtimes détectés et leurs versions, adresses IP locale et publique, exécution ou non en tant que service.

Ce qui n'est jamais envoyé

Le daemon ne lit pas, et ne peut donc pas envoyer :

• Les variables d'environnement de l'utilisateur ou du processus de runtime.
• Les fichiers de clés : ~/.ssh, identifiants cloud, fichiers .env, trousseaux d'accès.
• Les profils de navigateur, cookies ou sessions authentifiées.
• Le dépôt ou l'arbre de travail sous forme de fichiers. Les diffs ne circulent que sous forme de chemins et de compteurs de lignes.
• Tout élément provenant d'un répertoire situé hors du répertoire de travail de l'agent, à l'exception des artefacts explicitement générés par l'agent et référencés dans la réponse.

Il n'a pas non plus la possibilité de recevoir des fichiers de la salle vers des chemins arbitraires. Les pièces jointes envoyées par un demandeur sont placées dans le contexte de l'agent pour cette seule requête.

Pourquoi les résumés suffisent

Les membres de la salle ont besoin de savoir ce que l'agent a fait, pas de cloner votre disque. Un résumé d'appel d'outil, un diff indiquant le chemin et le nombre de lignes, et les quarante dernières lignes d'une commande suffisent pour répondre à la question : « fait-il ce qu'il faut ? » sans déplacer la base de code. Si quelqu'un a besoin de l'intégralité des modifications, celles-ci se trouvent dans le dépôt sur lequel l'agent a poussé son travail, où les accès sont régis par les permissions de ce même dépôt.

C'est également pour cela que muti n'héberge pas de runtimes : dès que le runtime est délocalisé, les identifiants et les fichiers suivent. Voir agents local-first vs agents hébergés.

Vérifier par vous-même

• muti status affiche la configuration du daemon, son identifiant de processus et le chemin des journaux.
• muti logs -f permet de suivre ce qu'il envoie. Chaque requête sortante est consignée avec ses types d'événements.
• Cliquez sur Revoke pour la machine dans la console et constatez l'arrêt du daemon en l'espace d'un cycle d'interrogation.

Questions fréquentes

Le daemon transfère-t-il parfois un fichier complet ? Uniquement les artefacts : les fichiers ou images générés par l'agent et référencés dans sa réponse, afin qu'ils apparaissent dans les sorties de la salle. Ils sont téléversés vers le stockage de la salle, et non scannés sur le disque.

Le service de salle peut-il exécuter du code sur ma machine ? Il peut uniquement mettre des requêtes en file d'attente, encadrées par vos règles de permissions et vos validations. Il ne peut exécuter aucune commande arbitraire en dehors d'une requête, ni accéder aux fichiers.

Où sont stockés les événements de timeline ? Dans la base de données du service de salle, cloisonnés à la salle. Seuls les membres de la salle peuvent les lire.

Puis-je auto-héberger le service de salle ? Un mode auto-hébergé individuel est prévu sur la feuille de route ; le daemon et le service communiquent déjà via une API standard.

Si votre audit de sécurité nécessite des précisions non mentionnées ici, écrivez à service@muti.im. Sinon, offrez une salle à votre agent.