# Per-user Linux accounts When several people share one AgentWorks server, each person gets their own Linux account on that machine — a "slot". Your commands and coding assistants run as *you*, so another person's work is simply out of reach. ## How one command runs
1. Who's asking?The service looks up your slot in the admin-owned table. No slot, no run — never a silent fallback.
→
2. Switch userOne fixed launcher runs as your account. It can do nothing else.
→
3. Check the requestProgram on the allow-list? Folder inside the allowed roots? Your own terminal?
→
4. Run confinedAs you, in exactly the allowed folders, with a minimal fixed environment.
The launcher adds no privilege beyond your own account — there is nothing in it for a compromised account to gain. The program list, folder roots, and user-to-slot table are all owned by the administrator, so neither the service nor any user can widen them. ## Who can reach what

Service

Verifies every caller.
Belongs to every group, so it can serve files and start launches for anyone.
Holds the credential store — no user account can read it.

Alice's slot

✓ Her own files and runs
✓ Folders explicitly shared with her
✗ Bob's files, terminals, launches
✗ Service credentials and config

Bob's slot

✓ His own files and runs
✓ Folders explicitly shared with him
✗ Alice's files, terminals, launches
✗ Service credentials and config
Shared folders are granted to a slot at launch, mirroring exactly what the launch allows — read or read/write, per path. Everything a slot creates stays inside its group; nothing is world-readable. ## Terminals stay apart too Each slot gets its **own terminal server** with its own socket, so one user can never see or type into another's panes. A router sends each terminal command to the server owning that session; anything else goes to the platform's own server unchanged. Terminals start with a minimal fixed environment — no service secrets — and pasted content travels only with the session being pasted into. ## For administrators - Provision once as root, then add people (account + slot in one step). Signing in never provisions anything. - With slots on, shell commands require a folder guard — unguarded commands are refused rather than run as the shared account. - Freeing a slot releases the table entry; clear the slot's runtime files before someone else reuses it. Switches: `AGENTWORKS_SLOTS=on` (shell commands), `AGENTWORKS_SLOT_CLI=on` (coding assistants, optionally limited to listed people while rolling out). Hosts without slots behave exactly as before. Related: [Provider credentials](provider_credentials.md), [Security overview](README.md).