Esattamente cosa carica il daemon di muti, e cosa non fa mai

Il daemon di muti è un piccolo processo in background sulla macchina del proprietario. Effettua il polling del servizio della stanza tramite una connessione HTTPS in uscita, esegue le richieste localmente con il runtime già installato e carica un flusso di eventi della timeline che descrivono ciò che è accaduto. Non carica file, variabili d'ambiente, materiale crittografico relativo alle chiavi o lo stato del browser, e non apre alcuna porta in ingresso.

Questo è il riassunto. Chi si occupa di sicurezza vuole l'elenco. Eccolo.

La connessione

• Direzione: solo in uscita. Il daemon effettua un long polling per ricevere lavoro; nulla si connette alla macchina.
• Autenticazione: una chiave per macchina. Lato server viene memorizzato solo il suo hash. La chiave di una macchina revocata o eliminata risponde con un errore e il daemon si arresta.
• Gate di approvazione: una macchina appena associata è awaiting_approval finché il proprietario non la conferma nella web app. Fino ad allora non viene assegnato alcun job e nessun evento viene accettato.

Amber non oltrepassa mai la linea: chiavi, repository e ambiente rimangono sulla macchina; la stanza riceve eventi e piccoli artefatti.

Cosa viene inviato: eventi della timeline

Ogni richiesta produce una sequenza ordinata di eventi. Ognuno contiene l'id della richiesta, l'id della stanza, un numero progressivo, un tipo e un payload.

Oltre agli eventi, il daemon invia i metadati della macchina durante la registrazione e l'heartbeat: hostname, piattaforma, architettura, versione del daemon, runtime rilevati e relative versioni, indirizzi IP locali e pubblici, e se è in esecuzione come servizio.

Cosa non viene mai inviato

Il daemon non legge, e quindi non può inviare:

• Variabili d'ambiente dell'utente o del processo di runtime.
• File contenenti chiavi: ~/.ssh, credenziali cloud, file .env, portachiavi di sistema.
• Profili del browser, cookie o sessioni autenticate.
• Il repository o il working tree sotto forma di file. I diff viaggiano solo come percorsi e conteggi.
• Qualsiasi elemento proveniente da una directory esterna alla working directory dell'agente, a eccezione degli artefatti prodotti esplicitamente dall'agente e a cui la risposta fa riferimento.

Inoltre, non ha alcun modo di ricevere file dalla stanza in percorsi arbitrari. Gli allegati inviati da chi formula una richiesta vengono inseriti nel contesto dell'agente solo ed esclusivamente per quella richiesta.

Perché i riepiloghi sono sufficienti

Le persone nella stanza devono sapere cosa ha fatto l'agente, non riprodurre il contenuto del tuo disco. Un riepilogo della chiamata al tool, un diff per percorso e conteggio e le ultime quaranta righe di un comando rispondono alla domanda "sta facendo la cosa giusta?" senza spostare il codebase. Quando qualcuno ha bisogno della modifica completa, questa si trova nel repository su cui l'agente ha fatto il push, dove l'accesso è regolato dai permessi di quel repository.

Questo è anche il motivo per cui muti non ospita runtime: nel momento in cui il runtime viene spostato altrove, le credenziali e i file lo seguono. Vedi local-first agents vs hosted agents.

Come verificarlo di persona

• muti status mostra la configurazione del daemon, l'id del processo e il percorso dei log.
• muti logs -f segue ciò che viene inviato. Ogni richiesta in uscita viene registrata con i relativi tipi di evento.
• Esegui Revoke della macchina nella console e osserva il daemon arrestarsi entro un singolo ciclo di polling.

Domande frequenti

Il daemon carica mai un file intero? Solo gli artefatti: file o immagini prodotti dall'agente e menzionati nella sua risposta, affinché appaiano tra gli output della stanza. Vengono caricati nello storage della stanza, non scansionati dal disco.

Il servizio della stanza può eseguire codice sulla mia macchina? Può solo accodare richieste, regolate dalle tue regole sui permessi e dalle tue approvazioni. Non può eseguire comandi arbitrari al di fuori di una richiesta e non può accedere ai file.

Dove risiedono gli eventi della timeline? Nel database del servizio della stanza, limitati alla stanza stessa. I membri della stanza possono leggerli; nessun altro può farlo.

Posso eseguire il servizio della stanza autonomamente? Una modalità self-hosted per utente singolo è nella roadmap; il daemon e il servizio comunicano già tramite una semplice API.

Se la tua revisione di sicurezza richiede informazioni non elencate qui, scrivi a service@muti.im. Altrimenti, dai una stanza al tuo agente.