> ## Documentation Index > Fetch the complete documentation index at: https://servo.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Identity and auth > Sign in as yourself, give lab-mates a role on the robot, and see and stop what runs on it from your own laptop. You sign in with a browser; each robot computer joined once with a key it generated itself. Giving a lab-mate the robot grants her a role on it, so nothing is ever copied between machines, and a role can be taken away in one command. ## Sign in as yourself Sign in on any computer you work from: ```bash your computer theme={null} servo login servo whoami ``` `login` opens the browser, or prints a link and a short code over ssh, and the sign-in renews itself. `whoami` names you, your organization, and whether you are an organization admin. On the robot computer the same command names the robot, because Python there acts as the robot through the agent and needs no sign-in. `servo logout` ends your sign-in, and `servo logout --everywhere` ends every sign-in you hold. ## Grant a role Give a lab-mate a role on one robot: ```bash your computer theme={null} servo access grant alice@lab.example --robot yam-cell-01 --role write ``` | Role | May | | ------- | ------------------------------------------------------------------------------------ | | `read` | See the robot and who is using it, list its sessions, and inspect models against it. | | `write` | Everything that moves the arm: start and stop sessions on it, and run episodes. | | `admin` | Everything above, plus grant and revoke access, and remove the robot. | Everyone in the organization is a member. A member may add robots, list models, register sources, and deploy and stop models, because a deployment is not tied to a robot. A member holds no role on a robot until granted one. Whoever adds a robot is its admin, and an organization admin holds `admin` on every robot. `servo access list --robot yam-cell-01` shows who holds which role. A request without the needed role is refused with the role named, on every request, so revoking takes effect immediately. Commands that run on the robot computer act as the robot and need no role, so `servo robot setup` and `servo episode list` need none. ## Work from your own laptop Alice, signed in as herself and holding `write`, sees and stops what runs on the robot without a shell there: ```bash your computer theme={null} servo robot list servo session list --robot yam-cell-01 servo session stop --robot yam-cell-01 ``` `servo robot list` shows the robot and who is using it, and `servo session list` shows each session with its deployment, instruction, who started it, and since when. Stopping a session with a running episode returns the arms to rest first; `predict`, `check`, and `run` need the attached robot, so they run on the robot computer. ## Revoke or retire Two different things, two commands: ```bash your computer theme={null} servo access revoke alice@lab.example --robot yam-cell-01 servo robot remove yam-cell-01 ``` `revoke` removes a person's role and touches nothing else. `remove` retires the record. When no computer is next to the robot, `servo join` with no line prints a code that any admin approves with `servo robot approve`. ## You now have * A lab-mate who sees and stops what runs on the robot from her own laptop, as herself. * A way to take the robot back: revoke the role, or retire the record. ## Next Private buckets, revisions, and what the checkpoint expects. The two calls under `run`, and a session that keeps its connection.