Exactamente qué sube el daemon de muti y qué no hace nunca

El daemon de muti es un proceso ligero en segundo plano en la máquina del propietario. Consulta el servicio de la sala mediante una conexión HTTPS saliente, ejecuta solicitudes en local con el runtime ya instalado y sube un flujo de eventos a la línea de tiempo describiendo lo ocurrido. No sube archivos, variables de entorno, claves ni el estado del navegador, y no abre ningún puerto entrante.

Ese es el resumen. Quienes revisan la seguridad quieren la lista. Aquí está.

La conexión

• Dirección: solo saliente. El daemon utiliza long polling para recibir trabajo; nada se conecta a la máquina.
• Autenticación: una clave por máquina. En el servidor solo se almacena su hash. Si la máquina se revoca o se elimina, su clave responde con un error y el daemon se detiene.
• Control de aprobación: una máquina recién vinculada permanece en awaiting_approval hasta que el propietario la confirma en la aplicación web. Hasta entonces no se asigna ningún trabajo ni se acepta ningún evento.

El ámbar nunca cruza la línea: las claves, los repositorios y el entorno se quedan en la máquina; la sala recibe eventos y artefactos pequeños.

Lo que sube: eventos de la línea de tiempo

Cada solicitud genera una secuencia ordenada de eventos. Cada uno incluye el id de solicitud, el id de sala, un número de secuencia, un tipo y un payload.

Junto con los eventos, el daemon envía metadatos de la máquina en el registro y en cada heartbeat: hostname, plataforma, arquitectura, versión del daemon, runtimes detectados y sus versiones, direcciones IP local y pública, y si se ejecuta como servicio.

Lo que nunca sube

El daemon no lee y, por tanto, no puede enviar:

• Variables de entorno del usuario o del proceso del runtime.
• Archivos de claves: ~/.ssh, credenciales cloud, archivos .env, keychains.
• Perfiles del navegador, cookies o sesiones iniciadas.
• El repositorio o el árbol de trabajo como archivos. Los diffs se transmiten como rutas y recuentos de líneas.
• Nada procedente de un directorio fuera del directorio de trabajo del agente, salvo artefactos que el agente haya generado explícitamente y a los que haga referencia en su respuesta.

Tampoco tiene forma de recibir archivos de la sala en rutas arbitrarias. Los archivos adjuntos que envíe quien hace la solicitud se colocan en el contexto del agente únicamente para esa solicitud.

Por qué los resúmenes son suficientes

Las personas en la sala necesitan saber qué ha hecho el agente, no reproducir tu disco. Un resumen de la llamada a una herramienta, un diff con ruta y recuento de líneas, y las últimas cuarenta líneas de un comando responden a la pregunta de si «está haciendo lo correcto» sin transferir la base de código. Si alguien necesita ver el cambio completo, está en el repositorio al que el agente hizo push, donde el acceso se rige por los propios permisos de ese repositorio.

Por eso muti tampoco aloja runtimes: en cuanto el runtime se traslada, las credenciales y los archivos van detrás. Consulta agentes local-first frente a agentes alojados.

Cómo comprobarlo tú mismo

• muti status muestra la configuración del daemon, el process id y la ruta de los logs.
• muti logs -f sigue lo que envía en tiempo real. Cada solicitud saliente queda registrada con sus tipos de evento.
• Revoca la máquina en la consola y observa cómo el daemon se detiene en un solo ciclo de sondeo.

Preguntas frecuentes

¿Llega a subir el daemon algún archivo completo? Solo artefactos: archivos o imágenes que el agente ha generado y referenciado en su respuesta para que aparezcan entre los resultados de la sala. Se suben al almacenamiento de la sala, no se escanean del disco.

¿Puede el servicio de la sala ejecutar código en mi máquina? Solo puede poner solicitudes en cola, las cuales están reguladas por tus reglas de permisos y aprobaciones. No puede ejecutar comandos arbitrarios fuera de una solicitud ni puede acceder a tus archivos.

¿Dónde se guardan los eventos de la línea de tiempo? En la base de datos del servicio de la sala, delimitados a la sala. Los miembros de la sala pueden leerlos; nadie más.

¿Puedo alojar el servicio de la sala yo mismo? Tenemos en el roadmap un modo autoalojado para una sola persona; el daemon y el servicio ya se comunican mediante una API estándar.

Si en tu revisión de seguridad necesitas algo que no esté aquí, escribe a service@muti.im. Si no, dale una sala a tu agente.