Zero partilha por predefinição significa que nada sobre um agente, a sua máquina ou as suas salas é visível ou utilizável por quem quer que seja até que o proprietário do agente tome a decisão específica de o partilhar, e que cada uma dessas decisões é delimitada, registada e reversível. É o único princípio na base do muti. Tudo o que parece ser uma regra de segurança separada é uma consequência sua.
Descrever as consequências em detalhe é útil porque cada uma delas proíbe um atalho que, de outra forma, seria tentador.
O princípio no topo; cinco regras por baixo, cada uma uma consequência.
Consequência 1: a sala é o limite
Nada passa de uma sala para outra. Um agente presente em duas salas não transporta memória, mensagens nem artefactos de uma para a outra. Uma pessoa numa sala não consegue ver que outra sala existe. Não existe nenhum nível de "workspace" acima das salas por onde a informação possa vazar lateralmente.
Proíbe: diretórios globais de agentes, pesquisa entre salas, listas de "recentemente ativos" que revelem outras salas.
Consequência 2: uma menção nada concede
Um @agent entrega uma mensagem na inbox do agente. A sua execução depende de uma concessão permanente ou de uma aprovação do proprietário. Estar na sala, ser mencionado ou ser a pessoa mais ruidosa na conversa não confere qualquer privilégio.
Proíbe: modelos de permissões baseados em adesão a canais; predefinições em que "qualquer pessoa na sala pode executar". Consulte Claude Code Dispatch vs uma sala.
Consequência 3: as credenciais nunca saem da máquina
O daemon envia eventos de timeline, não ficheiros nem variáveis de ambiente. Inícios de sessão, códigos de autenticação de dois fatores e acessos a chaves são encaminhados para o proprietário e nunca para o requerente, mesmo que tenha sido o requerente a originar o prompt. Não existe nenhuma funcionalidade que copie um segredo para onde quer que seja, incluindo para a própria cloud do muti.
Proíbe: runtimes alojados, cofres de credenciais na sala, fluxos do tipo "cole o seu token aqui". Consulte o que o daemon envia.
Consequência 4: quatro ações pausam sempre
Fazer push para um branch partilhado, eliminar, gastar dinheiro e aceder a credenciais são operações que param sempre à espera do proprietário em qualquer pedido vindo de outra pessoa, sob qualquer template de permissões, incluindo o de confiança total. Nenhum template pode desativar isto, porque um template é uma decisão de partilha e o princípio dita que as decisões de partilha têm de ser explícitas por ação no caso das irreversíveis.
Proíbe: um modo de "confiança cega"; pushes silenciosos feitos por utilizadores convidados. Consulte quatro ações que um agente deve sempre perguntar antes de executar.
Consequência 5: o input de chat não é de confiança
Uma mensagem vinda do Feishu, Slack ou de qualquer connector é apenas dado. Pode criar um pedido; não pode criar permissão. A identidade está vinculada a uma conta do muti, não a um nome de exibição: no Slack, pelo e-mail verificado pelo workspace, recorrendo a um código de ligação único como alternativa, de forma a que as permissões fiquem associadas à conta.
Proíbe: executar em nome de utilizadores não vinculados; confiar na noção de administrador de uma plataforma de chat.
Consequência 6: a revogação é imediata e total
Revogar uma concessão, remover um membro, revogar uma máquina ou parar o daemon produz efeitos de imediato. Os pedidos em fila da pessoa afetada são cancelados; o trabalho em execução termina e permanece no histórico para que o registo não tenha falhas.
Proíbe: períodos de tolerância; estados de "remoção pendente"; eliminação de histórico aquando da revogação.
Consequência 7: o registo é append-only e mantido pelo proprietário
Cada pedido e cada aprovação gera uma linha que o proprietário pode exportar e que ninguém consegue editar. As próprias ações do proprietário também são registadas, porque um registo apenas de terceiros é meio registo.
Proíbe: registos editáveis; registos mantidos pelo requerente; desativação voluntária de registo. Consulte o que um registo de auditoria deve conter.
O que o princípio custa
Custa conveniência em três aspetos, e aceitamos todos eles.
- Nenhuma caixa global de "perguntar a qualquer agente". Tem de estar na sala.
- Prompts ocasionais para pessoas de confiança. As quatro ações pedem autorização mesmo quando responderia que sim.
- Nenhum runtime alojado, ainda que isso fizesse desaparecer o problema da máquina adormecida. Em vez disso, a inbox é a resposta. Consulte a inbox do agente.
Perguntas frequentes
"Nada partilhado por predefinição" não é apenas uma definição? É a ausência de definições que possam partilhar mais do que o proprietário escolheu. Cada ato de partilha é uma concessão explícita, uma aprovação ou um convite, cada qual registado.
O proprietário tem de aprovar tudo para sempre? Não. Concessões permanentes eliminam aprovações pedido a pedido para pessoas em quem confia. As quatro ações continuam a pausar; essa é a única parte que não se delega.
E quanto ao uso que o próprio proprietário faz do agente? Os proprietários não estão condicionados no acesso aos seus próprios agentes, mas as suas ações são registadas da mesma forma. O princípio diz respeito à partilha, não ao acesso do proprietário à sua própria máquina.
Uma regra, sete consequências, um produto. Dê uma sala ao seu agente.
Publicado a