Security model

Remote control reaches a machine that holds your source, your credentials, and shells that can run anything. The design below is the record of what that costs and what is done about it — stated plainly, including the parts that are still deliberate limitations.

The invariants

Your account is the trust model: A device pairs because it holds a session on the same Marginal Utility account the Mac is signed into, and every authorized request re-checks that it still does. Signing the Mac out revokes every paired device on the next request. There is no armed setting that skips this: an option to turn the trust model off would be an option to have no trust model.
Nothing listens: The Mac opens no port and serves no certificate. It dials out and holds a connection to the relay, which is what lets remote control be armed by default without exposing anything on your network — and why Off is the setting that genuinely matters, since dialling out is what carries your credential off the Mac.
Account isolation is the topology, not a check: The relay routes every caller to an object named for their account, so two accounts are two objects with no path between them. There is no name a device could ask for that reaches someone else's Mac. The Mac's own account check still runs on every request; that is defence in depth, not a duplicate.
Two credentials, two headers: Your account session authenticates a device to the relay; its Saggar grant authenticates it to the Mac. The relay swaps them when it passes the request on, so the account token never reaches the Mac at all.
The code alone is not sufficient: Two things gate a pairing, in order. The account check runs first, so a device on someone else's account is refused before anyone is asked about it; then a human at that Mac confirms the device. Neither is optional. The ceremony.
Capabilities are clamped server-side: What a client asks for is not what it gets — the Mac clamps every grant to its own ceiling, at the moment it authorizes the pairing.
Data is minimized by tier: A view-tier device receives no transcript tails and no filesystem paths. Redaction happens on the Mac, before the bytes leave it.
No bearer token in a URL: A live stream cannot set a header, so it carries two single-use, short-lived tickets instead — one for the Mac, one for the relay. Nothing sensitive lands in history, proxy logs, or Referer headers.
Grants live in the Keychain: Pairing grants and the push signing key are stored in the login Keychain, not a JSON file beside your code. Revocation is immediate on the next request, and it takes a device's push subscription with it.
Rate limits and an audit log: Per-peer limits blunt grinding, and the Settings pane shows you the log of what was asked and what was answered — denials included. This is remote code execution by design; an action with no record of which device asked for it would be the bug.

What this does not claim

The relay cannot read or forge terminal traffic. Your browser and Mac derive an end-to-end AES-GCM key from their P-256 keys. Commands authenticate their route and a one-time nonce, and responses bind themselves to that request. The relay can still interrupt availability and learns which Macs are online.
There is no offline path. A relay outage means no remote control at all, even from the next room.
An external security review is still the recommended next step, and it now belongs at the relay: what changed with it is the reachability, not the authorization model.
A drive-tier grant can type anything into a shell on your Mac. That is the point of the tier, and the reason it is separated from approve.
Saggar is unsandboxed by design; it drives your real shells in your real directories.

Reading further

The project keeps a full hardening record of what was found, what was fixed, and what is still open. Security issues should be reported privately.