Permissions
Permissions in Workstate work at two levels. Your role in the account decides what you can change. The namespaces you can reach decide what you, and the agents using your keys, can see.
Everyone with access to a namespace sees everything in it
Workstate has no per-document permissions. Every person who can reach a namespace, and every agent using their key, can search every source in it and read every ledger topic in it. A private repository, a restricted Confluence space or an HR policy becomes visible to all of them once it is indexed in that namespace.
Roles
Each person has one role in the account.
| Role | What they can do |
|---|---|
| Owner | Everything an admin can do, including changing another owner's access and keys. The first person in a new account is its owner. |
| Admin | Add, change, pause and delete sources, and upload files. Create and delete namespaces. Invite people, give them namespaces or take them away, and revoke their keys. |
| Member | Search, read the ledger, select Sync now, and manage their own API keys. Their agents can write to the ledger. |
Owners and admins can also do everything a member can. Nobody can invite someone at a role above their own, change the access or keys of someone above their own role, or change their own access. Everyone in the account can see the Team page, which lists each person's email address and role. See Roles.
Namespaces
- You can reach only the namespaces granted to you. A namespace is granted when it is created (to its creator and to every owner and admin), when an invitation includes it, or later by an owner or admin on the Team page.
- Owners and admins can give only the namespaces they reach themselves. A change applies to the person's next request.
- Every request is checked against your grants. A request for a namespace you cannot reach is refused. A request for a topic or source in a namespace you cannot reach gets "not found", whether or not it exists.
Keeping sensitive material separate
- Give sensitive material its own namespace. Put HR, legal or client material in a namespace of its own. Index there only what everyone who can reach it may see.
- Remember owners and admins. Every new namespace is granted to all of the account's owners and admins. Another owner or admin can take an admin's access away afterwards, but only an owner can take an owner's away.
- Check the namespaces when you invite. A member invitation starts with the namespace you are viewing. An admin or owner invitation starts with all of yours. Clear any that the person should not see.
- Check what a connection can read. Workstate indexes everything that the connecting account can read in the repositories, spaces or projects you choose. It does not copy repository permissions from GitHub, or page and issue restrictions from Confluence and Jira.
- Keep secrets out. Workstate does not filter secrets out of GitHub repositories, so remove passwords, tokens and keys before you share a repository. Uploads refuse private keys and
.envfiles. - Remember that an agent sees what you see. An agent using your key can reach every namespace you can.
When someone leaves
On the Team page, revoke all of the person's keys, and take away every namespace in their Namespaces column. Their agents lose access on their next request.
Offboarding does not remove the person from the account
Removing a seat is not built yet Coming soon, and a person's role cannot be changed. The person can still sign in to the console with GitHub, see the Team page and create new keys. Their keys reach only the namespaces they still hold. A former owner or admin keeps that role, so they can still invite people, create namespaces and revoke other people's keys, and they are given every namespace created later.
Not built yet
- Per-document permissions Coming soon. Everyone in a namespace sees everything in it.
- Single sign-on (SSO) and SAML Coming soon. People sign in with GitHub only.
- Audit export Coming soon.
- Removing a seat, and deleting an account Coming soon.