--- title: "Access & sharing · intentic docs" description: "How the owner is decided, what each invited tier can do, and why the daemon rather than the UI is what enforces it." url: "https://intentic.dev/docs/access/" updated: "2026-08-10" --- Run a sandbox # Access & sharing A sandbox has one owner and any number of invited people, each on a tier that decides what they can do. The daemon enforces it — the tiers are not a UI convention. **On this page (8 sections)** - [How the owner is decided](#how-the-owner-is-decided) - [The tiers](#the-tiers) - [Inviting someone](#inviting-someone) - [What people see about each other](#what-people-see-about-each-other) - [When a member is refused](#when-a-member-is-refused) - [Programs, not people](#programs-not-people) - [If you lose a laptop](#if-you-lose-a-laptop) - [Next](#next) ## How the owner is decided Trust on first use. The first verified identity to reach a new sandbox becomes its owner, and the daemon remembers it. Nobody is assigned an owner, and the intentic platform cannot name one for you — it holds your identity and your sandbox's address, and has no way to reach in. Sign-in is directly against Google: your browser presents a Google ID token and your sandbox verifies it against Google's published keys. The platform never holds or signs that credential, which is what makes a platform compromise unable to command your sandbox. ## The tiers | Tier | Can | | --- | --- | | **Viewer** | Watch everything — agents, chats, files, the workspace. Change nothing. Safe to be generous with: every read is attributed and nothing it can do alters the sandbox. | | **Collaborator** | Drive agents and review their work: start turns, answer questions, steer, stop, rename, archive. Agent work stays on isolated branches, so driving one changes nothing in your tree. Landing and publishing become requests instead. | | **Maintainer** | Ship and operate: land work, approve drafts, use the terminal, read the logs and the connected services. The tier for anything that leaves the sandbox. | | **Owner** | Everything, plus the things that never delegate: secrets, members, control tokens, approving an image rebuild. Exactly one identity, bound at first sign-in. It cannot be granted. | They draw three real fences rather than mirroring the navigation: - **Credentials never delegate.** Secrets — even their names, even the inventory — stay with the owner. A secrets page that greets every invitee is an invitation to ask for the values. - **What leaves the sandbox needs a maintainer.** Landing into the main tree, publishing, the raw terminal. - **Driving agents is the collaborator's whole grant.** Everything below it — watching the fleet, reading files and transcripts — is the viewer tier. ## Inviting someone **Sandbox → Access**, owner only. You give an email address and pick the tier; **Collaborator** is preselected as the one that is safe to hand out without thinking and useful enough that nobody feels locked out. Re-grading someone later is the same control on their row. A grant is written to your daemon *first* and recorded on the platform second, so a grant the enforcer never received is never recorded anywhere. It fails closed. Removing someone is the same list. Roles are resolved fresh on every request rather than at sign-in, so a re-grade — or a removal — applies on that person's very next action, not whenever they next open the app. ## What people see about each other Everyone sees who is here now: a live roster of connected browsers with the view each is on, the conversation they have active, and whether they've gone idle. Presence is per browser tab and lasts exactly as long as its connection, so there is nothing to time out and no clocks to compare. Each person's tier is on the roster too — which is how everyone can see who may do what, and how a tab knows its own role without asking a question only the owner may ask. ## When a member is refused The daemon answers a member below a route's tier with a refusal that *names* the tier required, so the app can say "ask a maintainer" instead of failing blankly. That is deliberate: an unlisted read defaults to the viewer tier and an unlisted change defaults to maintainer, so a route nobody has classified can under-serve a collaborator but can never hand one a power by accident. ## Programs, not people Anything without a sign-in — a CI job, an editor bridge, a script — uses a **control token** instead of a role. Those carry their own scopes, are minted by the owner, and are revocable one at a time. See [the HTTP API](https://intentic.dev/docs/sandbox-api/). ## If you lose a laptop **Sign out everywhere** re-keys the session signer, so every browser session for this sandbox stops verifying at once — including your own, which then silently re-establishes from the Google credential it already holds. That is what makes it a button rather than a support procedure. Control tokens are revoked separately, per token, because they are held by programs rather than people. ## Next - [Parallel agents](https://intentic.dev/docs/parallel-agents/): why a collaborator driving an agent can't disturb your tree. - [Your own machine](https://intentic.dev/docs/your-machine/): connecting a computer, and the editor bridge. More in Run a sandbox [Previous ← Updates & rollback](https://intentic.dev/docs/updates/) [Next Your own machine →](https://intentic.dev/docs/your-machine/)