Zéro partage par défaut signifie que rien concernant un agent, sa machine ou ses salles n'est visible ni utilisable par quiconque tant que le propriétaire de l'agent n'a pas pris la décision explicite de le partager, et que chacune de ces décisions est délimitée, enregistrée et réversible. C'est le principe unique sous-jacent à muti. Tout ce qui ressemble à une règle de sécurité distincte n'en est qu'une conséquence.
Énoncer ces conséquences est utile, car chacune d'elles interdit un raccourci qui serait autrement tentant.
Le principe au sommet ; cinq règles en dessous, chacune étant une conséquence.
Conséquence 1 : la salle est la frontière
Rien ne passe d'une salle à l'autre. Un agent présent dans deux salles ne transporte aucune mémoire, aucun message et aucun artefact de l'une à l'autre. Une personne présente dans une salle ne peut pas savoir qu'une autre salle existe. Il n'existe aucun niveau « workspace » au-dessus des salles par lequel des éléments pourraient fuiter de manière latérale.
Interdit : les annuaires globaux d'agents, la recherche transversale entre salles, les listes d'« activité récente » révélant d'autres salles.
Conséquence 2 : une mention n'accorde aucun droit
Un @agent remet un message dans l'inbox de l'agent. Son exécution dépend d'une autorisation permanente ou d'une approbation du propriétaire. Faire partie de la salle, être mentionné ou être la personne la plus active du fil de discussion ne confère aucun droit.
Interdit : les modèles de permissions basés sur l'appartenance à un canal ; les réglages par défaut de type « quiconque est dans la salle peut exécuter ». Voir Claude Code Dispatch vs une salle.
Conséquence 3 : les identifiants ne quittent jamais la machine
Le daemon téléverse des événements de timeline, pas des fichiers ni l'environnement. Les connexions, les codes à double facteur et les accès aux clés sont acheminés vers le propriétaire et jamais vers le demandeur, même si ce demandeur est à l'origine du prompt. Aucune fonctionnalité ne copie un secret où que ce soit, y compris sur le cloud de muti.
Interdit : les runtimes hébergés, les coffres-forts d'identifiants dans la salle, les parcours du type « collez votre token ici ». Voir ce que le daemon téléverse.
Conséquence 4 : quatre actions marquent toujours une pause
Pousser sur une branche partagée, supprimer, dépenser de l'argent et toucher aux identifiants requièrent une interruption pour solliciter le propriétaire à chaque requête venant de quelqu'un d'autre, quel que soit le modèle de permissions, y compris en confiance totale. Aucun modèle ne peut désactiver cela, car un modèle est une décision de partage, et le principe exige que les décisions de partage soient explicites action par action pour les opérations irréversibles.
Interdit : un mode « confiance aveugle » ; les pushs silencieux par des utilisateurs invités. Voir quatre actions pour lesquelles un agent devrait toujours demander confirmation avant d'agir.
Conséquence 5 : les entrées de chat ne sont pas fiables
Un message provenant de Feishu, Slack ou de tout autre connecteur est une simple donnée. Il peut créer une requête ; il ne peut pas créer de permission. L'identité est liée à un compte muti, et non à un nom d'affichage : dans Slack, via l'adresse e-mail validée par l'espace de travail, avec un code de liaison à usage unique comme solution de secours, afin que les permissions soient rattachées au compte.
Interdit : l'exécution pour des utilisateurs non associés ; le fait de faire confiance à la notion d'administrateur d'une plateforme de chat.
Conséquence 6 : la révocation est immédiate et totale
Révoquer une autorisation, retirer un membre, révoquer une machine ou arrêter le daemon prend effet immédiatement. Les requêtes en file d'attente de la personne concernée sont annulées ; le travail en cours d'exécution se termine et reste dans l'historique afin que le journal ne comporte aucun trou.
Interdit : les périodes de grâce ; les états « suppression en attente » ; la suppression de l'historique lors d'une révocation.
Conséquence 7 : le journal est en ajout seul et conservé par le propriétaire
Chaque requête et chaque approbation produit une ligne que le propriétaire peut exporter et que personne ne peut modifier. Les actions propres au propriétaire sont également journalisées, car un registre qui ne consigne que les personnes extérieures n'est qu'un demi-registre.
Interdit : les journaux modifiables ; les journaux conservés par le demandeur ; la désactivation de la journalisation. Voir ce qu'un journal d'audit doit consigner.
Ce que coûte ce principe
Il sacrifie la facilité à trois endroits, et nous assumons ces trois choix.
- Pas de champ global « interroger n'importe quel agent ». Il faut être dans la salle.
- Des sollicitations ponctuelles pour les personnes de confiance. Les quatre actions demandent confirmation même lorsque vous auriez dit oui.
- Aucun runtime hébergé, même si cela ferait disparaître le problème de la machine en veille. L'inbox apporte plutôt la réponse. Voir l'inbox de l'agent.
Foire aux questions
Le principe du « rien n'est partagé par défaut » n'est-il pas simplement un paramètre ? C'est l'absence de paramètres susceptibles de partager plus que ce que le propriétaire a choisi. Chaque acte de partage est une autorisation explicite, une approbation ou une invitation, chacune étant enregistrée.
Le propriétaire doit-il tout approuver en permanence ? Non. Les autorisations permanentes suppriment les approbations au cas par cas pour les personnes en qui vous avez confiance. Les quatre actions marquent toujours une pause ; c'est le seul aspect qui ne se délègue pas.
Qu'en est-il de l'utilisation de l'agent par le propriétaire lui-même ? Les propriétaires ne sont pas soumis à des restrictions sur leurs propres agents, mais leurs actions sont journalisées de la même manière. Le principe concerne le partage, pas l'accès du propriétaire à sa propre machine.
Une règle, sept conséquences, un produit. Donnez une salle à votre agent.
Publié le