The staff console
Our team runs Persistent Compute from a staff console, a separate site with its own sign-in. Only staff whose verified email address matches an allowlist in our deployment configuration can use it.
From the staff console, staff can see account details such as names, email addresses, team membership, plans, billing, usage, and devices, and each cloud computer's state, size, software version, and health. They can also read the feedback you send from the app, including any images you attach.
Staff can, for example, adjust billing, trials, credits, and refunds; approve access and invitations; suspend, restore, or delete accounts; retry setup or remove a cloud computer; revoke a device; manage feature flags and releases; and turn Private mode on or off for teams that run in their own AWS account.
The staff console has no view of your files, source code, terminal output, or the prompts you give your agents.
Every request the staff console makes to our backend, including reads and refused attempts, is recorded in our staff audit log with the staff member who made it. Changes are recorded before they run, and if that record can't be written, the change doesn't happen.
Hosted cloud computers
Our services manage the cloud computers we host through a fixed set of named commands, such as installing and updating our software, keeping your devices' sign-in keys in sync, checking health, and starting the sessions you ask for. Each command has a fixed script and checks its inputs before acting. None of our services can send their own scripts or create new commands.
From the staff console, staff can reach a hosted cloud computer only after you grant support access in Settings, under Advanced: Limited runs four read-only diagnostics (health, service status, recent service logs, and network), and Full also allows a shell. Team admins grant it for the team; on a personal plan you grant it yourself. You choose how long it lasts, from 4 hours to 7 days, and you can turn it off at any time. Our backend checks your grant before every request and refuses when there isn't one.
A support shell uses credentials that work only for that one computer and expire within an hour, never after your grant ends. Turning access off stops new diagnostics and shells; a shell that's already open stays open until it's closed.
While access is on, or after any use, Settings shows each grant, change, diagnostic, and shell, and teams with the audit log also see each one there.
Staff who hold production AWS credentials can still run a command or open a session on a hosted cloud computer directly through AWS Systems Manager, with full administrator access to it. Every such call is recorded in our AWS account's CloudTrail, and our operator access audit adds who made it, which computer it targeted, and when to our staff audit log, usually within minutes. It also adds the call to your support access history and your team's audit log, showing whether you had granted access at the time.
That record shows that a session was opened or a command was sent. It doesn't capture what was typed or shown, and it doesn't block access; it makes every use visible afterwards.
We access your content only when you ask us to, such as for a support request, or when the law requires it, as our Privacy Policy describes.
Cloud computers in your own AWS account
When your team runs cloud computers in its own AWS account, our access goes only through the roles your CloudFormation stack creates. Our management role can launch, stop, resize, and remove computers through your stack's launch template. On the computers themselves, it can run only the named actions defined in your stack, each of which writes to a security log in your account before it runs. It can't open a shell or run its own scripts.
One of those actions keeps the list of device keys that can sign in to your computers up to date. Teams can require that a team admin signs each key, so our services can't add one on their own.
Support access exists only when your team turns it on by updating your stack: Limited, which runs four read-only diagnostics, or Full, a shell. It lasts for the time you choose in the console, 4, 24, or 72 hours, and ends at that time, even mid-session. Its role trusts only our administration service, which staff reach through the staff console with a stated reason.
Each support action is made as that support role, so it appears in your account's CloudTrail, and each diagnostic also writes to the security log in your account before it runs. Teams with the audit log also see each use there.
Your admins and ours
Customer administration and staff administration are separate. Being an admin of your team gives no access to our staff console, and staff work through the staff console, not through your team's admin controls.