Tous les articles

5 min de lectureTrustPolicy

Ce que le journal d'audit d'un agent de code partagé doit enregistrer

Le jour où un problème survient est le pire moment pour commencer à journaliser. Six champs indispensables par ligne de requête, cinq par ligne d'approbation, ce qui ne doit jamais y figurer, et pourquoi c'est le propriétaire, et non le demandeur, qui le conserve.

Par Noah· Product at Muti AI

Un journal d'audit pour un agent de code partagé est un registre en ajout seul (append-only), avec une ligne par requête et une ligne par approbation, détenu par le propriétaire de la machine et exportable par lui. Il répond, a posteriori, à ces questions : qui a demandé quoi à l'agent, qui l'a autorisé, ce qui a réellement tourné et ce que cela a coûté. Si l'agent n'est utilisé que par son propriétaire, la transcription propre au runtime suffit. Dès qu'une deuxième personne peut envoyer des requêtes, ce n'est plus le cas.

Cet article détaille ces champs, dans l'ordre où le lecteur en a besoin, puis ce qui ne doit jamais y figurer.

La ligne de requête

Chaque requête produit exactement une ligne lorsqu'elle atteint un état terminal.

ChampPourquoi il est là
Request idLe handle que tout le monde utilise : dans la salle, dans les fils de discussion, dans les rapports de bug. R20260906-07.
Qui a demandéLe compte du demandeur, et s'il s'agissait du propriétaire, d'un membre disposant d'un accès permanent ou d'un invité approuvé ponctuellement. La confiance est nominative ; le journal doit indiquer de quelle personne il s'agit.
Quel agent, quelle salleL'agent indique la machine et le répertoire de travail. La salle indique l'audience qui a vu l'exécution.
Quelle règle l'a autoriséPropriétaire, autorisation permanente ou approbation ponctuelle avec le nom de l'approbateur. C'est le champ que les auditeurs lisent en premier.
Résultatdone, failed, cancelled, expired, ainsi que la classe d'erreur le cas échéant.
HorodatageCréé, démarré, terminé. L'écart entre création et démarrage correspond à l'attente d'approbation ; entre démarrage et fin, à l'exécution.
ConsommationTokens ou rapport d'utilisation propre au runtime, pour associer un coût aux requêtes empruntées.

La ligne d'approbation

Les approbations ont leur propre ligne car ce sont des décisions, et les décisions n'intéressent pas le même public que les exécutions.

ChampPourquoi
L'actionLa commande ou le chemin exact, pas une paraphrase : git push origin main, rm -rf build/, read ~/.aws/credentials.
La règle déclenchéePush sur une branche partagée, suppression, coût, identifiants ou règle personnalisée.
Qui a demandé, qui a décidéDeux noms. Ils diffèrent par conception lorsque quelqu'un emprunte l'agent.
La décisionApproved, rejected, continue read-only ou expired.
La noteCe que la personne qui décide a saisi. Les notes ont le même poids que la requête, elles ont donc toute leur place dans le registre.
LatenceLe temps d'attente de la requête. Des attentes prolongées signalent qu'il faut restreindre le périmètre des agents.

Lignes de requête et d'approbation, avec un push approuvé en orange et une suppression expirée en rouge.Lignes de requête et d'approbation, avec un push approuvé en orange et une suppression expirée en rouge.

Ce qui ne doit pas figurer dans le journal

  • Secrets. Une approbation d'identifiants enregistre qu'une clé a été consultée, pas la clé elle-même.
  • Contenu des fichiers. Les diffs sont des chemins et des décomptes de lignes. La modification se trouve dans le dépôt, là où le contrôle d'accès propre au dépôt s'applique.
  • Sortie complète des commandes. Les dernières lignes suffisent à expliquer un échec. Des journaux entiers peuvent contenir n'importe quoi.
  • Autres salles. Le journal de chaque salle est restreint à cette salle. Le propriétaire a une vue d'ensemble sur toutes les salles ; les membres ne voient que la leur.

Des propriétés, pas seulement des champs

Ajout seul (append-only). Personne ne modifie le journal, y compris le propriétaire. Les corrections sont de nouvelles lignes.

Détenu par le propriétaire. La personne dont la machine a exécuté le travail détient le registre et peut l'exporter. Les demandeurs voient leurs propres lignes dans la salle.

Intègre en cas de révocation. Révoquer un accès ou une machine annule le travail en file d'attente et laisse le travail en cours se terminer, de sorte que le journal ne comporte jamais de vide où « quelque chose a tourné mais nous avons cessé de surveiller ».

Actions du propriétaire incluses. Le propriétaire n'est pas soumis aux approbations sur son propre agent, mais ses requêtes sont journalisées de la même façon. Un journal qui n'enregistre que les personnes extérieures ne couvre que la moitié du risque.

Lire le journal

Trois questions reviennent le plus souvent, et les champs ci-dessus répondent à chacune d'elles avec un seul filtre.

  1. « Qui a pushé ça ? » Filtrez les lignes d'approbation par rule = push, lisez qui a demandé et qui a décidé.
  2. « Pourquoi cette requête a-t-elle pris une heure ? » Comparez la date de création et celle de démarrage ; l'attente d'approbation en est généralement la cause.
  3. « Combien m'a coûté le prêt de mon agent ce mois-ci ? » Faites la somme de l'utilisation sur les lignes de requête où qui a demandé n'est pas le propriétaire.

Foire aux questions

La timeline de la salle constitue-t-elle le journal d'audit ? La timeline est l'historique détaillé et lisible d'une seule exécution. Le journal d'audit est le récapitulatif ligne par ligne de tous les événements à travers les exécutions, conçu pour le filtrage et l'export. muti conserve les deux ; le journal est dérivé des mêmes événements que le daemon téléverse. Voir ce que le daemon téléverse.

Combien de temps est-il conservé ? Les lignes de requête et d'approbation sont conservées pendant toute la durée de vie de la salle. La suppression d'une salle correspond à une suppression réversible (soft-delete) ; le registre reste accessible pour le propriétaire.

Un demandeur peut-il voir les lignes des autres personnes ? Il voit la timeline de la salle, qui comprend les requêtes de chacun dans cette salle. L'export est réservé au propriétaire.

Les requêtes du propriétaire ont-elles besoin d'une approbation pour être journalisées ? Non. Les exécutions du propriétaire sont journalisées sans approbation, avec rule = owner.

Le journal est ce qui fait de « vous pourrez le révoquer plus tard » une vraie promesse. Donnez une salle à votre agent et il en intégrera un d'office.

Publié le

Donnez une salle à votre agent.

muti est gratuit pendant la bêta privée. Connectez la machine où vivent vos agents et invitez les personnes de confiance.

Commencer

Continuer la lecture

6 min de lectureComparison

QoderWake and muti

Of every agent product launched in 2026, Alibaba's QoderWake is the closest in shape to muti. Both run on your own machine, and both let a group send it work, through a chat that has to be paired first. They split on whose agent it is, what it runs, and who approves when a colleague's request reaches a delete.

9 min de lectureComparison

WorkBuddy, QwenWork and QoderWake

Tencent's WorkBuddy lets you drive the agent on your own computer from WeChat and WeCom. Alibaba's QwenWork merges desktop, cloud and DingTalk agents into one product. QoderWake runs a team of digital employees on your machine behind a single bot the whole group can mention. All three let colleagues use the agent. They answer how in very different ways.

5 min de lecturePersonal agents

An agent with its own phone number

Manus Cue gives each personal agent an email address, a phone number, a wallet and a computer. That makes the agent reachable by anyone who has the number, which changes the permission question from "what may my agent do" to "what may a stranger make it do". What Manus 2.0 shipped, and what reachability asks of an agent.