Giving an AI access to a computer is both useful and uncomfortable.
I still want the agent to do real work: inspect repositories, edit files, run tests, open terminals, recover jobs and operate across multiple devices. Making the agent deliberately weak would also make the remote system less useful.
The better question is where authority should live.
A server-side yes is not the final answer
Light Remote has several permission layers. The account controls product capabilities. A durable session binds work to one explicit device. The server routes requests to that target.
The final deny still belongs to device-local policy.
An account may be entitled to a capability while the device refuses systemctl, package managers, Docker, LXD or other privileged operations. I want the final “no” to live where the consequences occur.
The cloud can grant capability. The device keeps the final deny.
Do not silently switch targets
A remote system can be tempted to “help” when the requested target is offline by running on another available machine. Light Remote intentionally does not do that.
A durable session is bound to one device. If that target is unavailable, the request should fail or recover on the same target. Success on the wrong machine is usually worse than failure on the right one.
Policy denials still need to be understandable
Recent Activity exposes a sanitized view of sessions, jobs, terminal events, routing and policy. A denied job can be explained as a device-local policy denial without replaying raw commands, tokens or sensitive stderr into the conversation.
Observability should explain behavior without becoming a new data-leak path.
A real terminal has real side effects
PTY and ConPTY sessions can run interactive editors, REPLs and installers. Their lifecycle therefore stays explicit: start, input, output, resize, signal and stop, all bound to the same session and device.
The reviewer sandbox is not a fake demo
For plugin review, I did not want a miniature MCP server returning fixture responses. The reviewer environment runs the same control-plane and runtime paths as the product, but with isolated accounts and devices.
It includes Main/Fleet behavior, Local Wall, signed device channels, filesystem/Git operations, PTY, activity and policy. The reviewer account cannot enumerate production users, devices, files, keys or logs.
Safe operations are allowed while privileged administration is deliberately denied, so review can exercise both success and refusal paths.
Destructive actions should look destructive
Set Main is consequential but reversible. Revoke and Remove are destructive lifecycle operations. Giving them separate tools, schemas and annotations makes intent clearer than hiding them behind a generic “manage device” action.
I do not need the AI to be harmless; I need boundaries to stay real
Agents will keep getting more capable. Trusting them to always infer the right boundary is not enough. Account OAuth, local enrollment approval, explicit targets and device-local policy provide boundaries that do not depend on the agent being cautious.
No approved comments yet.