Exactly what the muti daemon uploads, and what it never does

The muti daemon is a small background process on the owner’s machine. It polls the room service over an outbound HTTPS connection, runs requests locally with the runtime already installed, and uploads a stream of timeline events describing what happened. It does not upload files, environment variables, key material or browser state, and it opens no inbound port.

That is the summary. Security reviewers want the list. Here it is.

The connection

• Direction: outbound only. The daemon long-polls for work; nothing connects to the machine.
• Authentication: a per-machine key. Only its hash is stored server-side. A revoked or deleted machine’s key answers with an error and the daemon stops.
• Approval gate: a newly paired machine is awaiting_approval until the owner confirms it in the web app. Until then no job is handed out and no event is accepted.

Amber never crosses the line: keys, repositories and environment stay on the machine; the room receives events and small artifacts.

What goes up: timeline events

Every request produces an ordered sequence of events. Each carries the request id, the room id, a sequence number, a type and a payload.

Alongside events, the daemon reports machine metadata on registration and heartbeat: hostname, platform, architecture, daemon version, detected runtimes and their versions, local and public IP addresses, whether it runs as a service.

What never goes up

The daemon does not read, and therefore cannot send:

• Environment variables of the user or of the runtime process.
• Key files: ~/.ssh, cloud credentials, .env files, keychains.
• Browser profiles, cookies or logged-in sessions.
• The repository or working tree as files. Diffs travel as paths and counts.
• Anything from a directory outside the agent’s working directory, except artifacts the agent explicitly produced and that the reply references.

It also has no way to receive files from the room into arbitrary paths. Attachments a requester sends are placed into the agent’s context for that request only.

Why summaries are enough

The people in the room need to know what the agent did, not to reproduce your disk. A tool-call summary, a diff by path and count, and the last forty lines of a command answer “is it doing the right thing?” without moving the codebase. When someone needs the full change, it is in the repository the agent pushed to, where access is governed by that repository’s own permissions.

This is also why muti does not host runtimes: the moment the runtime moves, the credentials and files follow. See local-first agents vs hosted agents.

Verifying it yourself

• muti status shows the daemon’s configuration, process id and log path.
• muti logs -f follows what it sends. Every outbound request is logged with its event types.
• Revoke the machine in the console and watch the daemon stop within one poll cycle.

Frequently asked questions

Does the daemon ever upload a whole file? Only artifacts: files or images the agent produced and referenced in its reply, so they appear in the room’s outputs. They are uploaded to the room’s storage, not scanned from the disk.

Can the room service run code on my machine? It can only queue requests, which your permission rules and approvals govern. It cannot execute arbitrary commands outside a request, and it cannot reach files.

Where do timeline events live? In the room service’s database, scoped to the room. Members of the room can read them; nobody else can.

Can I run the room service myself? A single-person, self-hosted mode is on the roadmap; the daemon and the service already talk over a plain API.

If your security review needs anything not listed here, write to service@muti.im. Otherwise, give your agent a room.