Appearance
Agent residual risk & least privilege
How the LivePane agent expands the trust boundary on a linked machine, what residual risk remains for create-grant users, and how to install and run the agent with least privilege. This page is operational and threat-model documentation — not a product implementation of MFA or path policy.
Freeform remote-command surface
Once a machine is claimed and the agent is running, the server can enqueue commands that the agent executes on that host (create/destroy panes, stream terminals, list_dir, key input, and related control-plane jobs).
| Who can drive it | What they can cause |
|---|---|
| Workspace owner | Full workspace control, including member create-grants and machine lifecycle |
| Member with create grant | Create panes and use agent-backed control on machines linked to that workspace (subject to pane ownership / invite rules) |
| Member without create grant | Typically watch / limited control only — not freeform create + drive of new agent sessions |
Inherent residual risk: a user who is authorized to create panes and control sessions can cause the agent to run freeform terminal activity on the linked machine as the OS user that runs the agent process. That is a remote-command surface by design: the product’s job is to stream and control agent terminals. It is not a one-line “RCE bug” to patch away while keeping create-grant + freeform panes.
Treat create-grant as trusted-operator scope for every linked machine in that workspace. Revoke grants and unclaim machines when trust ends.
Least-privilege install and run
The agent process is the effective remote shell identity. Install and run it so compromise of a create-grant account or a stolen session token cannot escalate beyond what that OS user already could do.
Recommended posture
| Practice | Guidance |
|---|---|
| Dedicated OS user | Run livepane as a non-root / non-Administrator account created for agent work — not as your daily admin, and never as root / SYSTEM unless you deliberately accept full-host power. |
| User-level supervisor | Prefer livepane install-service (LaunchAgent / systemd user unit / user-scoped Windows service). Avoid elevating the binary into a machine-wide daemon that runs as root. |
| Home-scoped config | Keep config at ~/.livepane/agent.json under that dedicated user’s home. Do not world-write config or binary paths. |
| Minimal filesystem rights | Give the agent user only the directories and tools those panes need. Do not mount secrets, CI credentials, or production keys into its home “for convenience.” |
| Tight create grants | Grant create panes only to people you would give a shell on that host. Owners should review membership regularly. |
| Unclaim when done | Stop livepane run / uninstall the service and complete unclaim flows when a machine leaves the workspace trust boundary. |
| Keep the binary current | Use the documented upgrade path (livepane update or brew upgrade livepane) so you pick up security fixes. Prefer verified release assets (checksums). |
What not to do
- Do not run the agent as root “so panes can do anything.”
- Do not share one claimed agent across untrusted workspaces or untrusted create-grant members.
- Do not store long-lived cloud credentials in the agent user’s environment solely for convenience of freeform shells.
Developer-oriented install notes: Install the agent and the package README at packages/agent/README.md (least-privilege section).
Deferred product work (explicitly not done here)
Security audit F-012 called out stronger product mitigations. For this documentation track they remain future product work — design notes only, out of scope for implementation in the current hardening UR.
| Mitigation | Status in product today | Residual if deferred |
|---|---|---|
| MFA for privileged actions | Not implemented. Full multi-factor / step-up MFA product is future product work, deferred, and out of scope here. | A stolen SPA session or PAT can still act within its abilities without a second factor. |
| Path allowlist for directory browse | Not implemented. Server-enforced path policy / allowlists for list_dir (and related browse) are future product work, deferred, and out of scope here. | Create-grant users can browse paths the agent OS user can read, without a product-level allowlist choke. |
Do not read this page as shipping MFA or path allowlists. When those products land, update this page and link the real controls.
Operational controls that do exist today
These reduce blast radius; they do not replace least privilege or the deferred items above.
| Control | Role |
|---|---|
| Claim + owner confirm | Only workspace owners complete machine claim pairing. |
| Create grant | Owners decide which members may create panes / drive freeform agent work. |
| Unclaim / stop agent | Removes the remote-command surface for that host when the process is down and claim is cleared. |
| Session security | SPA token TTL, logout, revoke-all — see Session security. Limits stolen-browser impact; does not add MFA. |
| Least-privilege OS install | Bounds what freeform commands can touch on the host (this page). |
What this page does not claim
- No MFA product is shipped or documented as available.
- No path allowlist product for directory browse is shipped.
- No claim that freeform agent commands are impossible for authorized create-grant users — that surface is intentional product behaviour with residual risk.
- No change to agent or server application code is required to “complete” this page; it is documentation only.
Related
- Session security — SPA tokens, XSS residual risk, revoke-all
- Pen-test schedule: claim & authz — quarterly adversarial review of claim and authorization
- Install the agent — install paths and run/service
- Claim a machine — owner pairing
- MCP & CLI — scoped developer PATs (separate from the agent process identity)