Governance
How MUON governs the crew
MUON separates two roles everywhere: an operator (you, holding an operator-tier credential) decides; an agent (any dispatched worker, or a session you attach MUON's MCP server to) does. Nothing an agent holds can approve, confirm memory, or answer a gate — those are operator-only acts, enforced by which token a caller presents, not by convention.
Approval gates
When an agent's work crosses a boundary that matters — an edit outside the expected surface, a network call, a merge, a dangerous command — MUON files a gate and the agent waits. A few rules hold everywhere a gate appears (desktop, TUI, CLI):
- Every field of the request has to be readable before you decide: the exact action, its scope, the consequence, and the bound evidence. Truncated text can never be approved.
- A native notification can deep-link to the full review — it can never let you approve directly from the notification itself.
- A decision is bound to the exact content it was made on. If the content changes after you've seen it, the old approval cannot be reused.
- A merge gate can be graph-certified: MUON reviews the diff itself against the code graph and either certifies it or names specific files REVIEW BLIND (new/unindexed files, or a stale index) that a human has to read directly. Stale or unavailable review evidence never quietly opens a bypass.
--remember <ttlMs>on the CLI can mint a content-bound receipt so one exact action is auto-allowed until it expires (1 minute to 1 hour) — never a blanket allow, and never available for a merge/ship decision.
Memory tiers
Every memory note carries exactly one of four tiers, computed by one shared rule so the desktop, TUI, and CLI can never describe the same note differently:
A person confirmed it. The only tier that unlocks global-scope promotion, pack export, and destructive-write protection.
The crew's coordinator vouched for it on the record. Settled and durable, but not human-confirmed.
Crew-visible only under an operator's explicit auto-confirm-agent-memory posture — nobody has actually vouched for it.
Nobody vouched and nothing is carrying it — the one tier that is a debt. A note that lapses (expires) returns to this tier regardless of what once vouched for it.
The pre-edit gate only ever shows trusted decision text; a contested or pending proposal shows as existence-only until you explicitly ask to read it and confirm or reject it. Untrusted note text can never reach an agent through that gate as if it were a decision.
Full-auto: standing operator consent
Full-auto lets you pre-authorize approvals instead of clicking through each one — but it is consent you grant, not a mode that removes the gate. Two properties make that true:
- It is scoped, not global by construction. You can arm it for every lane, or for specific vendor lanes only; a request MUON cannot attribute to a resolvable vendor lane is not covered by a partial selection, on purpose — an unattributable request must never ride a narrower consent than it actually has.
- It cannot cover everything. Egress actions and blocked merge reviews still ask, always. A merge that needs an explicit operator attestation over REVIEW BLIND files is exactly the kind of decision full-auto cannot manufacture.
- Every grant is a real, audited decision. Each auto-approval goes through the identical operator-tier resolve path a manual click uses, and leaves a receipt naming the action and scope it covered (redacted of secrets) — never a bare “auto-approved” with no subject.
- It fails back to you, visibly. If the brain refuses a standing grant, or a grant hasn't landed within its grace window, that request drops back to an ordinary blocking prompt — the UI is never allowed to keep calling something “auto-approving” once that claim stops being true.
What never happens
You log in to each coding agent with its own CLI, or use your own BYOK/custom-provider credential. MUON only observes readiness (installed / authenticated) and, for supported BYOK setups, forwards the one selected credential variable to the one selected child process. It never stores, proxies, or logs you into a vendor account.
MUON is loopback-only (127.0.0.1) and local-first. The sole MUON-owned outbound call is the opt-in update check described in Install — off by default, and it only ever asks “is there a newer release,” nothing else. Vendor model traffic (your agent talking to its own model) remains vendor-owned; MUON does not add a hop to it or read its contents.
MUON's telemetry module ships with a fixed provider of "none" — there is no uploader in the code at all today. Events are spooled locally (owner-only file permissions) as a bounded, enum-only vocabulary with no free-text field, which exists for local crash diagnostics and as an inspectable audit artifact, not for transmission anywhere.
Two tokens, one gate
Under the hood, everything above rests on one separation: the operator token can govern (approve, confirm memory, resize the fleet); the agent token can only do (dispatch work, propose memory, read the graph). A UI surface never holds the raw operator token itself, and an MCP server — including one attached to a session you launched — can only ever present the agent tier. There is no code path where an agent-held credential decides a gate.